4 Strategies for a Structured QA Process

[article]
Summary:
Being a software tester is no longer just about finding bugs. It is about continuous improvement, defining a clear test strategy, and going that extra mile to improve quality. Following a consistent, structured approach to QA will help you acquire more knowledge about the product you are testing, ask questions you otherwise may not have thought of, and become a true owner of quality.

A tester’s role is evolving along with the change in industry technology and a shift toward an agile methodology. This transition opens unexplored, exciting, and challenging opportunities for testers everywhere. Let’s look at what this shift has meant for testers’ careers through the lens of my personal experience.

The Old Way: Just Find Bugs

My initial years as a tester were short on critical thinking. Every morning the testing team was provided a list of applications to review. The assigned resource would install the applications and attempt to break the functionality.

Our performance reviews were simple: The more bugs we found, the smarter we were! There was no thought, no strategy, no motivation. Our coffee breaks were discussions filled with the number of bugs each of us found rather than the quality of those bugs.

That got me thinking. What value did we add? Should we just aimlessly test to find bugs? I had too many questions without answers.

Developing a QA Process

My next job was a life-changer. As part of testing a functionality, the QA team would also debug, analyze the stack trace, and provide the root cause of the issue to the developers. It was refreshing to see everyone collaborate as one team with a common purpose.

I realized that a tester was not a mere individual attempting to break the tool, but more a team player contributing to the overall effort. As the testers rotated into different teams, we prioritized continuous improvement of automation and in-depth knowledge about each component. I developed a totally different perspective about QA and a newfound respect about how much added value this role brings.

In my next position, when I started I was immediately paired with a QA architect. I did not know then that this mentorship would have a profound and lasting impact on me. I realized the importance of following a more structured approach to QA. With the help of the QA architect, I honed and perfected four strategies toward an improved QA process.

1. Review Design and Architectural Documents

It’s always a good idea to go in with as much knowledge about the product under test as possible If design and architectural documents are available, give them a read. You would be amazed by how much more you understand the product’s architecture, the integrated components, and the flow of data than you would from testing alone. Take notes and draw a parallel to what you are testing and how the system interacts.

2. Research Past Defects

The past informs the present. It is important to know the risky areas and the most susceptible functionality that could break your application with every change. That kind of data could come from the history of defects.

Conduct some research on your defect tool and analyze past defects reported. Any predictable pattern that came out of this analysis would help you develop more automation around those areas. If there are customer-reported defects, analyze those too. This exercise will help you make decisions about the test strategy for various releases.

3. Triage the Defects

QA finds an issue, so you report it. But your job isn’t finished—you can go above and beyond by asking some additional important questions. Is there anything else you could have done? Do you know why this issue occurred, what caused the issue, and which commit might have been the problem?

This isn’t just the job of the developers. You have access to the log file, the commits, and the code, so you can do some digging to help resolve issues. Depending on how technical you are, you can go as deep as you like. But on a high level, look at the exceptions in the log. Is it a null pointer exception? Does that have to do with specific data, or some sequence of steps?

Narrow down the issue and start a conversation with the developer. They will appreciate the detailed information and research.

4. Go beyond the Reported Issue

Don’t just focus on testing functionality. Think about the back-end and front-end interactions of your application, too.

For instance, as you test monitor the logs, the application might be functioning as expected but with some errors occurring in the back end. Are the logs detailed enough? Are the exceptions being handled? For browser interactions, open the developer tools in your browser and monitor the network component. Is the response taking longer than it should? Is there any request that is not required when accessing some parts of your application?

All these questions allow the tester to go above and beyond what they are “assigned” to test. They also encourage discussions with the product owner and developers, who may not have thought about some of these scenarios.

It is vital to be of an agile mindset when seeking product gaps and the solutions to fill them. One key lesson in testing is being proactive instead of reactive. The bugs you uncover may turn out to be issues or technical stories, but by having that answer, you have prevented errors that might have gone unnoticed or come up as more serious issues much later.

Owning Product Quality

Being a software tester is no longer just about finding bugs and trying to break the application. It is about continuous improvement, defining a clear test strategy, and going that extra mile to improve quality. Following a consistent, structured approach to QA will help you acquire more knowledge about the product you are testing, ask questions you otherwise may not have thought of, and become a true owner of quality.

User Comments

12 comments
Ashish Kumar's picture

Good article to improve qa skills.

October 23, 2017 - 11:25am
Alisha Henderson's picture

Hi Ma'am,

This is a very good article for people who are working as a QA professionals and QA need to make sure everything regarding the testing phase, they have to create the report and then they have to work on the defects solutions. 

 

October 24, 2017 - 6:59am
John Wilson's picture

I find articles that make incorrect statements hard to take seriously. The incorrect statements in this article that make me dismiss it are the following.

1)      “Being a software tester is no longer just about finding bugs.” – A tester’s role was never ever about finding bugs. A tester’s role has always been about collecting objective data that will allow others to make informed decisions.

2)      There is a difference between the role of a QA and that of a tester. In an article consistent use of a term should be used to retain clarity amongst the readers.

3)      “…become a true owner of quality” – Test has never ever owned quality and never should. Quality is owned by everyone. It is amongst the roles of test to give everyone the objective information about quality.

 

4)      A tester’s role has not evolved. A tester’s role has always covered many aspects and disciplines. The emphasis on some aspects of a tester’s role has changed.

October 26, 2017 - 3:50am
Keith Collyer's picture

Wow, way to discourage someone who makes some good points.

I find comments that make incorrect statements hard to take seriously. The incorrect statements in this comment that make me dismiss it are the following.

1) I have worked with many organizations where your 1) is (still) true as it clearly was in the author's first job.

2) to say "A tester's role has not evolved" is predicated on your evidently false statement 1).

Because you got so much wrong, I will just assume your 2) and 3) are invalid

Your pettifogging complaints in no way invalidate the general thrust of the article.

December 8, 2017 - 8:17am
Sofian Daghsen's picture

@Keith, ctiticizing something is normal and usual.

In addition, his remarks are correct.

 

Regadrs,

Sofian

December 17, 2018 - 8:26am
Keith Collyer's picture

Apologies for not responding sooner.

@Sofian, yes, criticism is normal and usual. But it has to be based in fact. I pointed out that @John's first two remarks were incorrect, based on my personal experience. To say otherwise is to say that I am lying, which I take as deeply offensive. I have personally worked in organizations were the sole role of the tester was to find bugs. I'm not saying these organizations were correct, they clearly were not, but they were real. Their very existence invalidates John's first point and hence his fourth as it relies on the first.

October 2, 2019 - 5:12am
Sofian Daghsen's picture

I totally agree with Jhon's comment ....

December 17, 2018 - 8:25am
Clifford Berg's picture

Some readers might have the reaction that Praveena's approach is not Agile. I feel that it is. In my experience, even experienced developers do not have time to think through failure scenario tests properly: an experienced testing analyst is invaluable for (1) identifying additional test scenarios, and (2) assessing completeness of the test suite. 

December 8, 2017 - 7:57am
Emily S's picture

Hi Praveena, thanks for sharing the best practices you have learned! I think all of these tips are great reminders to always own all aspects of quality, no matter what stage of QA professional you are. I especially like the point about being proactive instead of reactive. At my company, we generally favor junior QA's to be more reactive in the beginning of their career because they are still learning about software features, test planning,  and then learn about being more proacive - do you think that it's important to encourage being more reactive early on as well?

December 8, 2017 - 11:48am
Praveena Ramakrishnan's picture

Hi Emily,

I agree with you that earliy on for any new team member, it would start off as being more reactive. It really depends on how quickly they adapt and learn to take a proactive approach as they grow in their career.

Thanks

Praveena

December 8, 2017 - 7:12pm

Pages

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.