We can all agree that Quality is vital to software development. So when does the Quality Assurance (QA) team get involved in the process? Historically, QA resources have not been engaged until after development starts, or more often than not, when development finishes. Agile methodologies have begun to remedy this by including QA resources earlier in the Software Development Life Cycle (SDLC), but there is a hangover from the waterfall days where Quality Assurance equated to “Tester”.
Let’s start with a couple of quick definitions.
Quality Assurance Engineer: A Quality Assurance Engineer is an engineer with a comprehensive understanding of what constitutes a high performance, defect-free software solution who works with the team to ensure overall quality.
Software Tester: A Software Tester executes and manages day-to-day running of test cases, submitting and reporting defects.
Don’t misunderstand these definitions; there is still an enormous need for manual test folks and automation doesn’t solve all problems. The distinction is in the scope of responsibility and qualifications. QA resources still test, but with automations tools, code practices and open source. The need for “button pushing” has been significantly reduced. A good QA Engineer is engaged in, and adds value to, the entire SDLC.
So what exactly does QA mean? The new definition of a Quality Assurance Engineer, “Engineer” being the key word, means that this person should be in charge of the overall picture of what Quality means to a project. With that definition in mind, this means that the QA representative should be involved in ALL aspects of the process, not just when someone needs to run tests.
Simple Example
The single most important piece of a QA person’s tool kit, and without a doubt the single hardest thing to come by and almost always overlooked during the planning phase, is data. At most, it’s a bullet item in the requirements document with a small statistically invalid sample set. Here is a simple example:
A customer wants to store the location of its clients. The initial data is entered by the customer via a webpage. With numerous variations of a simple concept, this problem can become extremely complex. If a data sample set is not considered, acquired and validated, a larger margin of error can occur.
Consider City, State and Zip code:
- Minneapolis, MN, 55417
- Minneapolis Minnesota
- Minneapolis, Minnesota 55417-12343
- Any variety of combinations of misspellings and formats (Is Validation present? Did someone check?).
The system actually takes:
- Front End System: Minneapolis, Minnesota 55417-12343
- Middleware only processes: Minneapolis, MN 55417-12343
- Backend can only store: MN 55417
Did someone validate this before it went through 6 months of development? Hoping that the Web Developer talked to the middleware coder and the DBA while the BA (possibly non-technical) produces the requirements documentation is not a strategy.
This problem increases exponentially as more fields are added and the solution becomes more distributed. If a team member is not asking the appropriate questions during the initial phases, this can lead to incorrectly designed infrastructure, large rework cycles and additional costs. Typically if a QA resource is not involved early in the process, data discrepancies are not found until testing begins.
Back to our original question: When should QA get involved? Immediately! Their unique perspective ensures that an overall perspective of quality is maintained throughout the entire process, addressing concerns earlier, and reducing the cost of rework.
This is just an introduction to a 5-part series on The Value of Quality Assurance. In the following posts, we will break down the SDLC into its core components and answer two vital questions:
- Why is Quality Assurance important to the SDLC?
- How do Quality Assurance Engineers add value to the SDLC and overall business?
Stay tuned!