If you are working in an under-staffed IT department like mine, it’s likely that most of the QA leads work on atleast 3-4 projects/systems and always busy with planning/testing and juggling between project deadlines and priorities. This means skipping some of the design discussions on new projects or the project manager assumes that QA is busy and they tend not to include QA in most of the early project discussions and meetings.
As a result QA end up getting involved in the project real late and will try to do the scanning, thinking, planning when the development is already on the verge of delivering the code. This will make QA process really worse and you might not have everything(even the right test cases or tools) to do QA as a value added service & may delay product certification. In order to meet the deadline, QA may even end up not catching or fixing all the defects/limitations in the product/system and shoot for “Ship it now and fix it later strategy”.
For a qa lead or a manager nothing is important than starting early in the project. Try your best to occupy the center seat in the kick-off, design meetings and project planning/discussions. Don’t be shy or ride in the back seat thinking that QA has no role to play till certification begins. At minimal QA will get benefited by these meetings if not add value during these phases. Being in these meetings will help QA understand the new product/system better, remember “Better knowledge brings better results”.
Don’t forget to Wear your goggles with skeptical view to scan the requirements and add value by providing feedback. QA can challenge requirements by asking good questions, you are the right person to identify requirements that might not be testable.
QA leads involvement during analysis and requirements gathering helps think through the test ideas, test data, planning test environment & tools. Planning early will provides some good time till the certification start to enhance our ideas & test strategy. The other important advantage of having a Software Test Manager involved in early product planning is he/she can forecast time, materials and resources and provide important inputs that are not covered in the specification.
There is definite benefit by involving QA team actively from the onset of a project through maintenance, I generally have found this as very effective from a business prospective. So no matter how busy the QA team is with other things, as a leader make sure you find the QA resource to get involved early in the project. This probably means making sure management sees value in it and fund QA being involved and working with the project manager & team so that QA representation in these meetings is encouraged and appreciated. Results speaks for themselves when QA is participated from beginning to end…..so it’s an easy mantra to chant “Start early, catch early and finish strong!!”
Quality starts from step zero, when the high level requirements are drafted, at this time dev is not even involved. QA mgmt. at this stage should make sure the reqs allign with gaols and objectives.
In short ,quality is built into the fabric….for me if the fabric quality is not good there nothing that can be done other than throwing it away. At this time the final QA step just becomes a ritual.
Madhu, Can’t agree with you more…. Having seen the success / struggle in cases where QA being involved / not involved in the very early stages of projects…. No doubt that QA starting Early is Right and Smart, it’s a big benefit for the product quality and business. Thanks for your comments..
[...] so feel free to place an increased portion of the testing in the hands of the developers , always remember to start early in the project, device all possible test scenarios, put them in a [...]
Madhu and Tara,
Most ideally its simple COMMON SENSE which stands out before you draw out any stratergy for involvement of QA with quality certification on any product.
Most of the products designed are Timed to Market.
Inspite of you providing 10 days or 100 days or 1000 days of Testing there cannot be any guarantee of NO defects coming out of any product (if tested out of bounds).
To get to these points there has to be a Thin and Thick line drawn with reference to the Requirements. The phrase “If i had 8 hours to cut down a tree, i would have spent 6 hours sharpening the Axe”
Similarly the Ground work (w.r.t Sales/ Marketing/ Solution Engineering/ Architects/ H/w or S/w depedndency/ deployment / maintenance) has be sufficently planned and CLEAR so that the requirements are very clear with NO unknowns [which is WHY we get into these sort of discussions...]
What the product is been developed and which kind of market or customer its been focussed on is the main ITEM. This is the FIRST step to be analyzed and taken up for any project.
I Still Insist Not every Living Being on this planet is same (most likely) and not every methodology can be similar for identical products. Its Situation what differs for which the Best Judgement with a bit of Common Sense is the ONLY Solution.