How can a QA help prevent rather than cure?

Ever recall when your doctor would say, ‘If you had brushed your teeth regularly, you wouldn’t have had a cavity.’ or ‘If you had taken a right diet, you wouldn’t have fallen sick.’ ? Hmm it always stinks to hear those kind of phrases right? But when you come to think about it, what if we did exactly those? I guess if we did, then we wouldn’t have to get a root canal or take those medications to get better and less pain. You see, it’s the same everywhere in nature, even in software development.

We tend to skip things beforehand and leave it to the guys to develop and when they are done, next thing you know, customer had totally the wrong expectation than what was done. Or, it would be something that would have so many bugs that couldn’t be fixed before deadline and project gets canceled/there is delay in payment. It’s pretty much a very common incident, right? Well, what if we tried to improve this situation. Realizations have occurred in time and measures were taken. Processes has been made for improvement and effectiveness. Roles have evolved to many types to play in significant activities within these different kinds of process. So where can a QA’s role take place and what kind of activities can be done?

A QA’s role doesn’t only mean involvement in test phase but in many other areas. After all, test is part of quality assurance. A QA can participate in ensuring quality in requirements analysis phase, design phase, during development, test and in release phase. The whole idea is to ensure quality. It might seem that too unrealistic for a QA to do all these things in all phases but QA can do significant activities and ensure the other activities are done. In that case QA roles can be divided in areas. By maintaining processes and checking, the workflow will be much more refined. But now let’s have a look on different areas where how a QA in a development team, within the development lifecycle can help prevent, rather than cure.

QA in Requirement Analysis Phase

During the requirement gathering phase, there is communication involved between the client and the people who gather requirements. This may be in some case the account managers, the requirements manager, product manager etc. Requirements are taken based on what clients want to be developed. Sometimes how to be developed. Now there is three scenarios to be considered when taking in requirements which sometimes tends to me missed out.

A.  New Functionality   

B. Extension/Change in Functionality

C. Functionality that implicitly effects another

Now A is very easy to plug in itself but when it interconnects with C, there needs to be some kind of knowledge in between in order to understand the impact on the existing functionality. B is also applicable in the this case.

So how is this related to a QA being involved? When personnel who gathers requirements from the client, quite often, they do not have the functionality in mind completely or maybe the technical limitations, thus resulting to promises that cannot be delivered. In this case have a member from the development team ( could be a senior developer/ architect ) and a QA engineer who knows the functionality well enough can provide valuable input in helping derive meaningful and functional requirements. In addition, the QA can point out the different perspectives of quality in making the client aware of different consequences, thus helping the client understand better on what they actually want.  By discussion, QA can help the client in deriving the acceptance criteria and use cases though with which the client can verify the end product. In summary, QA helps in ensuring that qualitative requirements are given.

QA in Design Phase

I noticed that during the Design phase, it involves the techies only and assumed that other than them, others won’t be able to provide any information that could help or understand the architecture. I would say that in any phase, a second opinion is always helpful.

So how can a QA help giving a second opinion here? During the discussion in this phase goes very in-depth into units to understand the whole architecture to be built. Doing so, sometimes the overview is missed and many criteria that the client is looking for gets faded away. The QA can bring  up the points time to time. Now you might say why do  you need a QA to point out. You can have the things written and ensure the design supports it, which is absolutely correct. But experience says that getting to the technical parts, the flows, usability, performance, scalability on usage and things like these sometimes gets opt out. The QA can add support in bringing up the quality attributes into incorporating them in the design as well as add different points in client essence since being involved during the requirements phase. It’s very important for the builders to understand the nature of the client and their usage of the system. In summary, QA helps in ensuring that qualitative design considers the quality attributes is made.

QA in Development Phase

We all follow the traditional way of developing and then testing the product delivered. And we all know that always we end up with bugs which makes it difficult for the testers and developers to come to an agreement in solving the bugs. How about we try to reduce these problems after the test phase? I’m sure things can be done ahead so that the cost in fixing those numerous amount of bugs later is much less. Here is where a QA can play the necessary role.

During the development the QA can do the following things and others if needed:

• Write test cases of the functionality and share them with the developers so that all the positive and negative cases are covered.
• Help the developers understand the nature of the clients on how they will use the system so that the developers can build keeping that sense in mind.
• Help in ensuring that all scenarios are covered in the unit tests, boundaries. Basically giving an idea to the developers on certain things that usually testers find out obvious bugs out from.
• Help by raising concerns on where the system can be error-prone.
• Help by giving pointers on areas where performance, scalability, usability matters.
• Go through the little functionality being developed and see if it conforms to the acceptance criteria.
• Before delivering the product, ensure with the delivers that correct functionality is being delivered with quality.

QA in Test & Release Phase

After everything is done, it’s time to to test the end product and finish it off by releasing it to the clients. Once again, with quality. During the test phase, the QA can assist the other testers to test the software. Also, the QA can help in making a successful release. During the release, when there is little to do, the QA still has work to do. Before the next cycle starts, the QA can prepare quality attributes that were missed in the previous release and make note to accomplish in the next one. This may include in preparing guidelines, checklists, process change etc.

Conclusion

So we pretty much covered on the activities of  a QA in the development life cycle and the importance of it’s role within. In conclusion, QA helps in ensuring that ultimately a product with quality is made. So why wait and let something go wrong in the end and fight over fixing it? Why not try from the begin to refine things so we have less mess-sweeping up to do. Isn’t prevention better than cure? I’ll let you think and decide on that. Until then, happy QA-ing !