Are you in a quandary over how QA is supposed to work in an Agile Delivery Team? Were things better for you when you could count on having complete requirements to start from and completed systems to test to? Are you finding yourself over worked and stressed out with the constant churn of new requirements that Agile encourages and the constant set of new working software every two weeks?
Maybe it’s time to step back, take a breath, and embrace the changes that need to occur when you and your organization stop trying to test quality into code and transition into baking quality in from the start. So, what’s your new role, and what can you expect to do in this capacity?
Traditional waterfall software development methodology follows a time-honored progression of:
- gathering all of a project’s requirements up front
- analyzing requirements to come up with a solution design
- implementing design into code
- testing the code (by QA)
- deploying the code to production once QA says that it is “ready to ship.”
Then some silly Agilist (yes, I’m one of them) questions what happens when you miss a requirement, new requirements comes along, or someone changes their mind. The normal reaction is that you have a very long cycle of events that start a lot of the process over, and contribute to a lot of waste from unnecessary rework. Since QA is near the end of this long process, when things change, and the amount of time left to stay on schedule gets tight, several effects are normally seen:
- People start saying that they need less time to test. I wonder if that might affect quality.
- People start trying to stop change from occurring by having things such as Change Review Boards. This really makes me hit my head with the palm of my hand. Now that the customer knows what they need, we try to inhibit that from changing anything. I wonder if that’s a good outcome for the business?
- People blame QA for not wanting to test early. But QA has a point here. If you test one piece now, and another piece later, who is to say that the stuff you did later didn’t have side effects that broke the stuff you finished before?
Does any of this sound familiar?
The short story is that the tried and true waterfall methodology is just too costly for standard software projects (let’s not get into avionic control systems or radiation therapy machine software for the moment). It’s costly because we assume that we can gather all of the requirements at the start of a project, that none of those requirements will ever change, and that we can perfectly plan for every development event in advance. My claim is that the waterfall methodology makes you comfortable in thinking that you can plan everything up front and then just execute on the plan and get it right the first time through. But it just doesn’t work like that in the real world! There will be mistakes, and the mistakes will cause costly rework. This rework will be more costly than it has to be because we find the defects late in the game.
As you know, the Agile software development process is different. For purposes of this article, the process is different in two very important ways:
- We limit planning details for things that are too far into the future, because things will change, and we want to wait until the last responsible moment when we have the most information to make the best decisions (Poppendieck).
- We work in self-organized teams of generalized specialists with roles that blur. Furthermore, everyone on these delivery teams will be needed to make the software: developers, business analysts, user experience people, architects, technical publications people, QA, and anyone else needed! The team’s job is to understand the problem, and figure out their solution. They are not told what to do. They are self-governed, and will strive to plan every day to figure out the optimal way to make the best use of all their resources to solve the problems being worked on.
So, in Agile, we start off without a complete understanding of everything. We have to discover not only the problem, but also the solution. And there is no one to tell us how to make the solution – that’s something else we have to figure out. Oh, and don’t forget to expect changes to occur. Is this why you’re sort of at odds with the process? It doesn’t seem fully baked. Well, I want to tell you that once you get into this mindset, there is no going back.
The problem that most QA people have with the process isn’t with the process itself. It’s with what their management thinks that they should be doing, and what they are used to doing to please their management. Most non- QA people confuse Quality Assurance personnel with the traditional QC (Quality Control) personnel that come from the manufacturing world. In the manufacturing world, it is standard to fully design the process from beginning to end then start the assembly line in motion. QC people monitor goods coming off of the assembly line. Bad products are tossed into one pile, and good ones get placed in another. Wash, rinse, and repeat until the whistle sounds to the end of the shift.
As you know, the QA role is actually much different. Quality Assurance is all about ensuring that the goods delivered from the process are right from the start. The idea is to have zero defects coming off of the line. In manufacturing, using QC to toss the bad ones out is costly enough. But when we use QC in the software development world, we are asking people to start the process over when a defect is found (back to requirements, analysis, design, implementation, and testing). The really horrible part is that we have to start the QA testing all over again once the defect is remediated, because we can’t trust that something else is not messed up as a side effect of fixing our original defect. Talk about costly. This can be deadly to a company!
So, the trick is to embrace the real meaning of QA. Get back to designing systems that allow us to become part of the solution in making code work the first time and all the time. Stop being turned into QC people who are mere gatekeepers between the end of development and the beginning of deployment. After all, when you were hired, the title on the job description said QA, not QC, didn’t it? Your management would rather pay you to work smarter, not harder. Doing a QC sort of job is hard in the software world because you have to fight the tedium of performing the same regression tests over and over.
So, what can I suggest?
First, start by actually being part of the delivery team. QA people need the same understanding of the domain to test in as developers need to code from. In fact, the difference between requirements (in Agile, we call these features, and represent them in stories), and tests is almost nonexistent. That is, if the requirement is to “produce a system that can add 12 to 13 and get 25”, the test for that is “Enter 12 into the system. Then enter 13 into the system. Add. Check that 25 is returned.” Do you find a lot of difference there? Again, working arm and arm with the rest of the delivery team and designing tests as the Agile stories are developed is the first step.
Now, what do you do when there are just no tests to develop for any particular day? Nothing? Watch YouTube for an entire day? No. You are a full member of an Agile team. As a team, you have to decide how to make best use all of your resources. That may mean that in a morning Scrum, you and your team decide that since there are no tests to develop you can do something else such as a coding, writing user documentation, or do some GUI work. It all depends on what you’re capable of and how much you are willing to stretch. Agile teams work together which is good for you, the team, and for your organization simultaneously.
Let’s talk about exactly how the testing part goes. When you design tests, can you give me a good reason that you don’t automate them as you develop them? Didn’t think so. You will get numerous benefits. The labor and tedium of regression testing goes away. You get a computer to do the grunt work and it never complains. The automated tests become a barometer of doneness. As more and more tests start working, you have hard metrics of how close you are to being done.
The final benefit from automated testing is that you get to apply your brain to challenge and test concepts which is why you were hired into a QA role to begin with. You are more than a QC machine who rejects code with a fail stamp. QA needs to be recognized as a valued player from the start of the process that bakes quality into the code from the beginning. QA people need to take an active role from the start and full-fledged membership in the Agile delivery team for your next project is where you can make your stand.
About the Author
Howard Deiner Howard Deiner is an independent software consultant who specializes in Agile process and practices. He has a varied background spanning 36 years in the industry, with extensive domain knowledge in commercial software, aerospace, and financial services. He has played many of the roles in the development arena, such as developer, analyst, team lead, architect, and project manager.