Most people in the industry are undoubtedly familiar with the Software Development Lifecycle (SDLC).
Reference: Wikipedia
I was having lunch with a recruiter colleague, and I was learning about the QA requests from lots of customers. Most defined the QA role well within the “Testing” oval as shown in the picture. From my questioning, it appears that the agile movement has done little to alter this SDLC. In fact, this process is still alive and very will, even within agile teams. The difference is in the batch size. Rather than doing analysis on a batch of 50 features and then moving that full batch to design, the agile movement has reduced that batch size considerably, and in some cases reduced it down to a batch size of 1. Lean agile teams are likely to use a batch size of 1 and continuously pull features through the lifecycle. As an aside, I find that even when working on a single feature, this cycle is still in play, although the feature is more likely to jump backward and redo a portion of the phase before if new information is found.
The reason for the reflection on QA is that my recruiter colleague still predominantly receives requests for QA folks to fill the roll of the testing phase. This means that the QA involvement happens after analysis, after design, after implementation, and only when defects can no longer be prevented. They can only be discovered. Inspectors at the end of an assembly line are powerless to prevent defective parts. They can only discover them through inspection and serve a Quality Control role to prevent defective parts from being shipped. The same is true in software, and many others have written the same.
I shared a very successful project where we incorporated what would otherwise be a very traditional QA Manager into an agile process and yielded great results and a very low defect rate. When crafting the team’s process, the QA Manager worked in between the analysis and design phases of a given feature to understand and then define the test cases. That is, based on the current understanding of the feature, how will we test it? The work required to create the test cases was sufficient to find analysis gaps early and force them to be filled. The additional information and context contained in the test cases added the design activity as well and yield, in my opinion, a more robust design that was less prone to defects of oversight. In this project, we saw the time spent coding reduced to less than 50% of the overall project effort. In fact, at the beginning of the project, programmers were about 50% of project staff, and half-way through, the programmer staff had been reduced to 1/3 of overall project staff. By crafting a process that pulled thoughts of QA to the beginning of the process, we modified the environment to one in which it was hard for defects to be created in the first place. In the end, we found no need to create a defect tracking database, and the team was applauded for its quality. The production launch, which always carries some risk, was a trivial affair, and the system is currently being used by many to perform their daily job.
Our industry stills see QA not as assuring quality, but merely controlling quality through inspection. Some savvy development managers already have changed traditional QA job descriptions, but there is a long way to go before these notions reach the mainstream of the industry.
What are your experiences with QA?
Never underestimate the staying power of a term misunderstood. Some people are remarkably persistent in clinging to wrong definitions.
Earlier in my career, I was fortunate to have a boss/mentor for whom getting things done wasn’t enough…constantly improving the process by which we got things done was important as well. He explained that the QA role was not about testing, but about auditing compliance by all the various disciplines (analysis, design, coding, testing, release management, etc.) in order to assure the quality of the product.
My view: http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/
—Michael B.
My most successful and satisfying experience with a QA group was at a client that was trying to do Acceptance Test Driven Development. This is very similar to what you described here in that the QA team members worked on the test cases before the developers started coding. In addition, we had one member of the QA team who would actually pair with us on the code. While she wasn’t a developer at all, she would ask questions and her involvement would actually drive us to write more expressive code so that she could follow along better with what it was doing.
I’ve been fortunate to work for a company where my input is not only appreciated but expected in each of the other ovals in your diagram.
The cycle shown is still valid because you can’t test something that doesn’t exist yet, but that /testing/ oval is only the final part of my contributions to any project.
Thank you all for the feedback.
I think you hit the nail on the head. Good testers test everything… The business problem, the spec, the code, the process, even the tests too. We are constantly looking for ways to do more for less cost. We ultimately want to do whatever it takes to make our customers love our product. We have no fear of refactoring code to make it easier to test. We realize there is no silver bullet, and we strive to test every product or feature in the exact unique way that best fits that particular problem. We can code and like to code, but even more, we love pushing for quality from day one of product cycle.
To ignore this and only consider Quality after implementation is short-sighted. I capitalize it to reflect that quality is a process that spans the full product cycle and everyone involved. A great tester will help a team every step of the way.
QA is a joke! as you mentioned, it helps not to ship Crap to clients, but you still have the Crap in-house. talking about quality, no one seems to mention code-quality and who ensures that ?
for the past two years I changed 3 jobs mainly due to being very managerial driven orgs. where so much time, attention and effort was spent on anything but the code base!
where in your perfect SDLC circle do I see REFACTORING? nowhere! but you and somehow the rest of responses are glorifying testing:
” Good testers test everything… The business problem, the spec, the code, the process, even the tests too. ”
COOL, but who does really pay attention to the code? my experience is that any long-term projects in companies turn eventually into spaghetti code of utter nu-comprehension and tests will pass and they will give you a false notion of QUALITY!
how come FOSS deliver superior quality than most proprietary products ? (if you think different you are delusional) WITHOUT so much planing, management, compliance etc. never having an army of QAs, never working on source control systems looking like tax return forms (TFS).
let good coders manage themselves !!! and NO, not all coders are the same, hiring 3 more is worse than hiring 1.
aaa and the Agile business
can’t claim to know that much about agile, but Agile is the most hypocritical soft-dev methodologies from all I had encountered:
using TFS != Agile
using TDD != Agile
too much planing != Agile