A Structured QA Process

The blog post I chose this week comes from stickyminds.com and discusses how the quality assurance testing process is changing.  In the post (https://www.stickyminds.com/article/4-strategies-structured-qa-process) Praveena Ramakrishnan gives a general overview of the old way of testing where the tester was just focused on finding bugs.  Then they discuss how their next job gave her a different perspective.  That her job wasn’t just to find the bugs and try to break the program, but to work as a team towards the overall improvement of the software.  I think she has a positive view of her role as a tester and how employ some strategies to continue that positive mentality.  Her first strategy is to review documentation.  This is a good reminder for testers at all levels.  When approaching a project we need to remember not to rush into writing tests before we read the documentation and have a solid understanding of not only what the program is doing, but also try and gain some perspective of what the designers want the program to do.  The second strategy is to research past defects.  When we look at the past issues we can try to identify if there are any patterns.  This could help speed up future testing by improving the efficiency.  She then emphasizes that it is important to triage the defects.  When we as testers find a bug we should report it as soon as possible, but that is only the beginning.  After that we should look into what caused the issue to occur and what version it was added to the code.  This again helps paint a fuller picture of the defects and the code in general so that we can identify any patterns and try to improve in the future.  This goes into the last strategy which is to go beyond the reported issue.  Try and look beyond just your tests.  If you have logs review them as well.  The tests may pass, but you notice other errors occurring.  Catching these can improve future performance as well as prevent future defects.  Going above and beyond the minimum also typically results in higher pride in your work.  Employing these strategies will have a snowball effect to your job.  While you may not see a clear difference overnight keep working on implementing them and over time your skills will improve leaps and bounds over your peers.  Remember that it’s not just about breaking the application until the developers fix all the bugs, it’s about being a part of a team that strives to create the best product possible.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s