Is quality optional? The warm and fuzzy response is “Of course not. You must have quality in anything you create, perform or produce.” The grey area is when you ask “How should quality be assured?”
An independent quality effort on IT projects is often regarded as a ‘nice to have’ option that would be present if they only had the time and money to invest into it. Due to various constraints, the quality effort is spread across the existing teams to achieve. Project Management is responsible for it, but has no way of assuring it. Development is responsible for it but has no time to commit to it. Design is responsible for it but has no way to answer to it.
There are committed, trained and passionate QA professionals out there. They are not developers that washed out nor are they wanna-be developers. These are the people who like to delve into the requirements of a project, define the parameters, review the various pathways and test the limitations. They not only test what it is, but what is should be and what it shouldn’t be.
A good example is this: Draw a circle on a piece of paper. Set it in front of someone and ask they how they would test it.
- A Developer would start to tell you to take measurements of the circle, evaluate the ’roundness’ of it, what type of paper it’s on and if it was written in pen or pencil. Their job is to make things, so their default is to evaluate what has been made. It’s not a failing, it’s what makes them good at their job. Development!
- A Project Manager would ask who wants the circle, what’s the timeline for it and what’s their budget. Their job is to make things happen, to enable and to drive forward. Again, it’s not a failing, it is what causes projects to be successful under their care.
- A Quality Assurance (QA) professional would ask what the requirements were. Nothing more. It doesn’t matter what has been pushed in front of us. It’s irrelevant. What the client wanted, what their requirements were, what is it supposed to be, is the question. It was supposed to be a child’s rubber ball. Knowing the circumference of the hand drawn circle, what the budget was or what instrument was used to create it, is useless. It’s a wasted effort. It is not what was requested. Without that mindset, without that commitment, without that irreverence to the effort already exerted, the quality effort is lost.
2. high grade; superiority; excellence: wood grain of quality.
In high school, students are often frustrated at the sight of someone checking their work. The red pen comes out, circles and X’s are drawn. Phrases are underlined and question marks with arrows appear, asking for clarification. Why hadn’t they seen the errors? They had read it over several times. The trap is seeing what was intended, rather than what has been created. The editor is free from knowledge of the intent and is therefore unencumbered.
People cannot objectively or effectively review their own work. A “fresh pair of eyes”, without any investment into what is being presented will provide an impartial analysis. Peer reviews are powerful tools to use throughout a project. However they can often be clouded by their own knowledge of the project, the knowledge of how much effort had been invested and the compromise of “good enough”.
A stand alone QA effort will provide the checks and balances to keep a project balanced. The need to complete the work, the need to deliver on budget and the need to deliver what was requested. Each of these require their own ‘champion’ who will fight for them. Some battles will be won, some lost. In the end it is the project that wins overall.
The life cycle of a bug during the project testing stage is detection, capture, documentation, correction, evaluation and closure (assuming that it is fixed correctly the first time). Create 20 of the same type of bug and your project will not only extend in time, but also require an extension of the budget.
“If you don’t have time to do it right, when will you have time to do it over?”
The level of complexity of the bug has no bearing on wether it should be corrected or not. The priority of the bug establishes what should and shouldn’t be fixed. A low complexity bug would be a spelling mistake. It is quick and easy to correct. However the priority of that bug would be high, due to the poor impression on the user experience with the product (if they can’t bother to spell correctly, how can a user trust them with their money/information/etc.). One highlights the effort that must be allotted to correct the issue, needed for budgets and timelines. The other highlights the importance of the bug to the project, if it compromises its ability to be successful or not. The balancing act between complexity and priority must be weighed.
QA has no investment in wether a bug is corrected or not. There is however a commitment to informing the stake holders of the issue and it’s potential impact. Managing the risk against the impact to the project allows the stake holders to make an educated decision. Once that decision is made, QA accepts the new standard and moves forward.
An independent review not only ensures that the end product requested will be what is delivered, but also reviews the process in which it was generated. Errors that crop up during review are corrected. However QA will also review the nature of those errors in general. Should a particular type of error repeatedly crop up, it will be flagged. “How do we learn from this error, how it was made so that we don’t generate it again?” Not only is the product improved, but so is the process that created it.
“Insanity: doing the same thing over and over again and expecting different results.” – Albert Einstein
Without acknowledging the changes needed to the process, the errors are doomed to be generated over and over again. If Development does not acknowledge the creation of these bugs, they are doomed to generate them and extend the development life cycle. While the generation of bugs is expected, the repeated offense of generating the same bug is not.
A tested project reveals insight into the process. When the process improves, it also improves the quality of the projects created within it.
Quality can sometimes be compromised due to it’s nature of ramping up towards the end of a project. As more is developed, more can be tested. As bugs are cleared it opens the pathways to test a project completely, where it may have been blocked previously. As the final touches are applied, the final details are tested. Desperation tends to set in, deliver early, on time or late, there is always a push to deliver it sooner rather than later if possible. If a corner is cut, it’s typically at the end where compromises of “good enough” are made.
Of course the risk is greatest when decisions are rushed and made with unknowns still in play. However that risk, acknowledging that there are unknowns, can be responsibly flagged and decided upon. There is no perfect timeline, perfect budget, perfect project where there are no surprises. They happen. The key is to know that they will happen and to have a plan to adjust and adapt when they’re encountered. A quality effort will enable a project to do so efficiently and effectively.
No, quality isn’t optional. If implemented properly, it will improve the process, the project and the bottom line.