The Quality Assurance Unit should be seen as an extension of Business Systems Analysis, and although part of the overall development team, should operate outside of the direct influence of the developers themselves. Members of this unit would be involved in the entire process of development, from change control to release, but should examine and analyze individual issues from their own perspective, and then hold the developers to those standards.
Quality Assurance should assess the requirements as gathered, and design and implement quality control procedures on the resulting deliverables. This means that the QA Unit would be responsible for creating and maintaining their own test plans and development of their own regression cases and harness.
This would mean that a Quality Assurance agent would need a basic understanding of the stakeholder's vision, and experience with software development in general, since most automated regression harnesses consist of scripted applications that run independently of the main project, but are triggered on the main project's build, and are typically custom-written in any number of different scripting languages (JavaScript, Perl, Python, etc.).
This unit would also be responsible for the development and creation of metrics to track the software quality in its current state, as well as to compare the improvement with previous versions, in order to help increase the value and maturity of the testing process. Also, total numbers of failures in comparison to clean releases on an issue-by-issue basis should be tracked as well, in order to identify any areas that can be improved.
The Quality Assurance unit should be not only keenly familiar with, but our primary champions of:
- Continuous Integration
- Regression Harnessing
- Insistence on Developer Unit Testing
- Load, Performance, and Fault Testing
- Clarity of Requirements
- Overall Test Coverage
- Failure Rates
- Process Improvements
- Requirements Gathering
- Reporting Defects
- User Acceptance Testing
- Ownership of Issues Through Release
The basic ticket workflow during the course of development would be as follows:
Initial Requirements [BSA] ->
Test Plan Creation [QA] ->
Regression Case Creation [QA] ->
Developer Assignment [BA] ->
Developer Commit [Dev] ->
Release Testing [QA] ->
————————————————-
If QA Failure, Requirements Verification [BA] ->
If QA Failure, Developer Assignment [BA] ->
If QA Failure, Re-Commit [Dev] ->
————————————————-
Release Testing [QA] ->
User Acceptance Testing ->
Release
Manually testing individual tickets at the completion of a sprint has its merits, and if used in conjunction with the tools and concepts listed above may uncover isolated issues that can then be incorporated into the test suite, but manual observation has become less and less necessary with the advent of automated regression testing, unit testing, and detailed test planning.
Quality Assurance should not just be interested in the quality of the final product, but all intermediate work products.
Our Quality Assurance unit should be concerned not only with the live environment, but should also be interested in maintaining a certain level of quality and stability within all environments. This would include coordination with the release manager for downhill data refreshes, or initiating or repairing automated populating scripts that can be triggered from a build, dropping the entire schema, re-creating it, and populating it with sufficient data as to represent a sufficient proxy for the UAT and live environments.
Our Quality Assurance unit should view the software development team as a black box that takes in some form of customer requirements and outputs software. Although the unit should be involved with all aspects of the development. the Quality Assurance unit is most effective when it is able to examine the deliverable against its test cases without interference or influence from the development team.
As a side note, iso-9001, which is a common RFC for Quality Assurance in many fields can be boiled down to three simple principles:
- Ask someone what they're doing
- Ask them how they know that is what they should be doing
- This should lead to some documentation which should match
Quality Assurance should be concerned with these principles as they apply to the process.
The practices and methodologies discussed in this article are meant to cover the entire development lifecycle. This ranges from requirement analysis, development, and finally, the testing phases. Quality Assurance should demonstrate that identifying issues during the development process is favorable to having the stakeholder bring them to your attention in a production environment, when the technical debt and cost of changes are high.
This means that Quality Assurance should be involved in the entire process, and not just brought in to test tickets prior to release.
Above all else, QA should take it personally if a product goes live and issues arise that weren't caught prior to release.