After taking a great webinar from www.threebeacons.com and a good talk from Nathan Eror www.neror.com; I have a better understanding of Agile and how QA works in that team. Using this information and the process of actually scoping an Agile project with my team- I believe we have a general concept of how Agile works.
The first things we needed to understand were the words- the jargon…. I have also learned that there are like 8,000 different ways to do Agile and every team takes what works from the best versions…
Release- the actual final piece of software.
Iteration- Time frame used to break up each development cycle within the entire release cycle. Usually 1 to 2 weeks in length. You want at least 4 iterations per release in order to take advantage of Agile methodology.
Epic- It’s like a phase- more like a block of functional pieces that are logically grouped together. Ex: Login Page for Online Application
Story- mini, functional pieces of the release within each epic. Ex: I am a Acme customer and I need to login to the Acme site with my email address. Stories should be phrased as a functional need- not CODE or DEV work. Clients do not care about Tables and embedded graphics. They want to see what works.
Unit Testing- The heart of Agile. Test everything as you build it. Automate the testing if possible.
I will go into a whole different blog about testing- I am sure I am about to learn a lot as I am being helped by a developer on setting up our testing, repository and bug tracking systems next week.
Basically what we learned is that Agile works if you sell it to the client as collaborative. Your team MUST buy off on how iterations work and that everything- including testing and build deployment go into each iteration so that at the end of the iteration, you have a functional product for testing and sign off. The product does not have to have all functionality, just what the client needs to provide a more defined scope as each iteration is completed.
We had to define optimal programmer hours available for each iteration. We determined for our first project that we would sell 50 “points” for each iteration. Those points were based on programming hours and difficulty of each story.
That brings me to my next revelation- you have to basically scope the project down to the story level before you can quote it- so planning and pre-project fact finding is critical. The idea is to pre-qualify the lead and plan the hell out of the project before you walk in with a presentation. Then the client can shoot it apart through the Agile process by redefining needs.
I will post more as I get deeper. What we have found makes Agile great for us- although a bit cumbersome for smaller projects. We are finding our middle ground.
Hi Andrew,
I noticed your post on LinkedIn, so I thought I would check this out. I did not see anything mentioned about security, so I wanted to offer some advice. My colleagues and I have come across many applications that met their software requirements, but they did not have any formal security processes integrated into their software development lifecycle. This often leads to high rick vulnerabilities that are found in the architecture or design flaws just before or after the product is in production. Many times these issues could have been resolved at the start and during the development if security had been integrated into the development process. Here are some good starter documents, if you have not already become familiar with a Security Development Lifecycle:
* Microsoft, Microsoft SDL, http://www.microsoft.com/downloads/details.aspx?FamilyID=d045a05a-c1fc-48c3-b4d5-b20353f97122&displaylang=en
* B. Sullivan, Agile SDL: Streamline Security Practices For Agile Development, MSDN Magazine, http://msdn.microsoft.com/en-us/magazine/dd153756.aspx
* D. Wichers, Agile Security Breaking the Waterfall Mindset, AppSecEU08, http://www.owasp.org/images/b/b8/AppSecEU08-Agile_and_Secure.ppt
Hi Andrew:
Interesting thread – what I’ve learned (the hard way) working with Agile teams is that if the “right” balance is not found between streamlining documentation for agility and not having sufficient / adequate documentation, large rocks lie ahead when your project ship puts out to sea and flips over into production.
With my own particular specialization on the link between testing and requirements, I’ve found major problems occuring when the app breaks or testing indicates faulty design or code – which then can’t be traced back to original requirements, because of a lack of documentation.
No need to go nuts on documentation, but having at least well-formed use cases and robustness diagrams (and solid design documents) can help drive better results, so that time-for-testing (which has been squeezed on 100% of the projects I’ve ever worked on) is used to validate that the app meets requirements (the purpose of testing), rather than spending time you don’t have trying to find and report defects (which is not the purpose of testing).
This is particularly frustrating after an app goes into production, when things break and then you can’t figure out what happened or why – because you don’t have sufficient documentation / requirements to go back to review.
Better to spend time up-front doing proper documentation than spending time and lots of money chasing things much farther down the road that should have been done right the first time. Good luck with the team.
Sorry – one last comment about automating testing . . . . setting a goal of trying to automate as much as possible can be very dangerous, if you don’t have well-formed requirements-designs-code, because you’ll just end up getting more crap faster than if you had not automated.
Additionally, somewhat arbitrarily setting up to automate testing can be self-defeating when you don’t have solid requirements/design docs, because then it’s tough to figure out if the errors are being caused by poor reqs/design or because the tool itself (or the test environment or the data being used) wasn’t properly set-up.
If your team embarks on test-driven development at the unit level (“test as you go”), chances are you’re going to get higher quality code than using more traditional dev methods, so that when the app reaches a higher level of testing (integration or system test), you’ll be more likely to get good results using a tool, because higher quality code is being feed into it.
Again, if you work with a tight, high quality SDLC methodology and use approaches designed to ensure high quality output code – from the very beginning of the project – you’ll have far fewer quality issues to deal with at higher levels of application integration (especially if your app has to interface with external or 3rd party apps) and as you get closer to production.
Then, after a first release when the application is stable and whatever defects are present are known, transitioning to more robust test automation (especially when working with a highly complex application, such as a mainframe mortgage banking or insurance app) at that point makes a great deal of sense (it lowers the cost of regression testing as the app is enhanced or updated in various ways).