Published June 22, 2023

Are You an Agile QA or Just a QA in an Agile Team?

Blog

Blog

Are You an Agile QA or Just a QA in Agile Team

While most of us who have an experience of working in an agile team may assume that we are an agile QA by default, the truth is…

You can be a QA in an agile team and still not be an AGILE QA!

Being an Agile QA is a process of continuous enquiry and continuous improvement.

But what does that truly mean?

How do I measure my effectiveness as an Agile QA?

How can I improve as an Agile QA?

All very relevant questions!

You can answer them for yourself using the checklist that has been shared in the later part of this article.

But to understand the effectiveness of that checklist, let’s first relook at some Agile concepts on which it is based!

AGILE CONCEPTS:

The essence of the Agile Manifesto in just a couple of statements can be:

Agile proposes periodic cycles of incremental assessments and improvements to achieve a larger goal

Agile is not just a methodology, it’s a mindset of co-ownership of product deliverables that needs to be developed and practiced by each member of the Agile team.

AGILE TESTING being a sub-process of Agile, it adheres to all the principles on which Agile is based.

So in turn,

Agile testing is a mindset of measuring QA impact in all areas of product development on a periodic basis.

Using the feedback coming out of the assessment exercise in making incremental improvements in the process in every consecutive cycle.

One of the most significant contributions on Agile testing comes from Lisa Crispin and Janet Gregory who distilled Agile testing into 10 principles in their book Agile Testing: A Practical Guide for Testers and Agile Teams.

Here are those

10 Principles of Agile Testing:

1. Provide continuous feedback —The agile tester is central to providing the team with feedback: Acceptance criteria is the most concrete way to measure positive progress on an agile project. Tests also help identify issues and capture decisions on appropriate future direction.

2. Deliver value to the customer — The insistence on acceptance tests is a “reality check” on scope creep. Acceptance tests help us all understand what it means to realise a customer’s needs.

3. Enable face to face communication — Testers can often be the ones in a team responsible for bridging the communication gap between the customers (BAs, product owners, etc.) and programmers. A tester can be the one who physically brings these people together, as well as the one who drives derivation of a common language between the two parties.

4. Have courage — One of the larger challenges in Agile is in sustaining a fast-paced iterative environment, where every two weeks we need to ship quality software. This challenge demands significant courage. Yet the irony is that we also need to understand the iterations afford us opportunities to learn how to fail and adapt — something that can require an even heavier dose of courage!

5. Keep it simple — Agile testers can help push back against an insistence on overly-elaborate features. Testers can also help the customer understand how to incrementally deliver value. They must learn an appropriate balance of iterative testing — just enough to provide the right confidence in delivering software.

6. Practice continuous improvement — A key element of using iterations is to allow for learning to take place. Testers should be part of retrospectives (and if you’re not consistently adapting based on the results of retrospectives, you’re not agile enough.) Testers should also treat their career as profession by continually learning more about testing practices, tools, and the system itself.

7. Respond to change — Agile testing is dramatically different in that there are few true “cutoff points” — things keep changing and thus must be continually re-tested. This requires automation! The agile tester learns to cope with the customer changing his or her mind from iteration to iteration, and correspondingly learns how to incrementally flesh out necessary testing specifications.

8. Self-organise — In a truly agile team, everyone has the capability to act as a tester. Agile teams know how to shift focus as needed, from time to time. For example, it may be prudent for programmers to turn their attention toward helping verify a “done” but not “done done” feature.

9. Focus on people — Testers are often at the bottom of the totem pole in a non-agile software development team. Work is thrown at them, their available slice of time is continually squished, and programmers often look upon them as lesser. In an agile team, everyone shares the responsibility for ensuring that we are building quality product. Agile testers are key in bringing their testing expertise to the team.

10. Enjoy — The ability to help drive a process and be a true, equal contributor to a team can be extremely gratifying for an agile tester.

These 10 principles have been widely accepted as the foundation for Agile testing processes.

Another important concept which was refined and promoted in the same book was Agile Testing Quadrants.

This is how it can be visualised —

Agile Quadrant 1 — Emphasis is mainly on code quality.

Agile Quadrant 2 — Emphasis is mainly on business requirements.

Agile Quadrant 3 — Emphasis is mainly on building confidence in the product through testing in multiple iterations. It provides feedback to Quadrant 1 & 2.

Agile Quadrant 4 — Emphasis is mainly on non-functional qualities and expected value.

Agile QA’s Self Assessment Checklist

So, by now, you may have realised that,

Agile QA is the one who stays true to the Principles of Agile Testing and is impactful in all aspects of the Agile Testing Quadrants.

So, to assess our impact as an Agile QA we can identify some practical assessment areas based on the above concepts.

Following are some assessment areas collated for your persual.

We can call it an Agile QA’s Self Assessment Checklist:

Technical Knowledge Assessment

Do I have high level of understanding of the architecture of the project? —

e.g., do I know if my project is based on client-server architecture, service-oriented architecture or something else?

Do I have high level know how of the tools and technologies used in the project? —

e.g., React, NodeJS, MongoDB, kafka, etc. are being used in my project. Do I have high level understanding of how these work?

Can I write code in the language used for development in a specific layer of the project? —

e.g., backend services developed using Express. So can I code in JavaScript?

Do I understand the dependencies between various components and services? —

e.g., in eCommerce app, cart service is dependent on inventory service for providing product availability information.

Do I have working knowledge of the tools/libraries used for writing automated tests on a specific layer? —

e.g., Cypress for API testing in JavaScript

Do I know alternative tools/libraries for writing automated tests on same layer? —

e.g., Jest

Do I have working knowledge of testing on various layers? —

e.g., component testing using mocks and/or stubs, services testing, UI testing on mobile and web.

Can I work along with/guide developer on unit tests?

Can I do code review of low complexity changes in development code?

Do I know the tools/techniques to be used to implement CI/CD for automated tests?

Can I look into network and system logs to find underlying bugs/errors in the system? —

e.g., looking into GCP or Azure for underlying issues in a specific service.

Domain Knowledge Assessment

Do I know the business domain of the project? —

e.g., The product belongs to e-commerce, banking, or some other domain.

Do I know the core principle of the domain? —

e.g., 5 pillars of e-commerce

Do I know the target audience of the product? —

e.g., e-commerce app is used by retail customers, product like workflow management system is used by organisations.

Do I know the device and/or browser usage trends of the product? —

e.g., How many Android and iOS users of an e-commerce app? How many use latest OS/device and how many on legacy OS/device? Which is the preferred browser for usage by most customers?

Do I know the problem areas of the product/project? —

e.g., Most production issues are reported in which feature

Can I think of any business edge cases on my own?

Effective Communication Assessment

Do I voice my opinions/raise questions effectively, i.e., do people understand what I want to say? —

e.g., QA’s communication with team members is often too long and not precise which makes the team lose interest in the discussion or in meetings with fixed duration, team just moves on to next person

Do I raise technically relevant questions in meetings?

Do I voice my opinions/raise questions in a timely manner, i.e., neither too early nor too late? —

e.g., there is discrepancy in requirements mentioned in a user story. QA observes it but doesn’t show urgency to call it out early.

Result: No time left for the team to fix it.

Do I timely update my work progress? —

e.g., QA has taken initiative to develop a POC project on performance test automation which will help team in long run. But, never calls it out in team meetings, which means no one can give any inputs or suggestions on it.

Do I timely update the developers when I find a bug in their code, so that they are aware and get enough time to fix it? —

e.g., QA caught a bug couple of days back and assigned to a developer, but developer checked it only today. QA and developer meet in status meeting everyday but communication on the bug never happened until today.. valuable time lost?

Do I set the severity and priority of bugs currectly so that team can set a priority queue on the bug fixes? —

e.g., Multiple bugs filed this sprint but QA didn’t set priority. Developer thinks Bug 123 not priority (but it is) and hence fixes the other bugs first. Before he comes back to Bug 123 the release date is up!

Do I share test execution and bug reports regularly with all stakeholders? —

e.g., Since past few days one major test was failing repeatedly but no one in team noticed it till it was too late.

Reason – QA wrote automated regression tests and set them up in CI pipeline. But.. didn’t bother to set up auto publishing of test reports.

Do I update my availability and leave schedule to the team in advance? —

e.g., QA was aware that he needs to take leave for personal reasons on date of release but informs only couple of days before release. Intimating the team a week ago would have helped the team fill up the void.

Proactiveness Assessment

Do I spend enough effort trying to learn/understand the tool, technology, and/or architecture used in the project if I lack knowledge of it? —

e.g., QA lacks experience in microservices architecture. So always looks out for more work on front-end testing and automation where this lack of knowledge might not be a hindrance.

Do I spend enough effort on trying to learn/understand the domain, user segment and/or usage trends of the project if I lack knowledge on it? —

e.g., QA lacks experience on eCommerce applications. So always looks out for tagging along with more experienced QAs, so that this lack of knowledge might not be a hindrance.

Do I voice my opinion in meetings wherever necessary OR do I prefer others to do the talking on my behalf? —

e.g, QA thinks that the team is not doing estimation correctly since every sprint some backlog gets carried over to next sprint. But avoids calling this out during sprint retrospective so as to not hurt team sentiments.

Do I proactively approach any team mate be it Developer, QA, BA, DevOps Specialist or others to understand the technical OR business requirements better? —

e.g., QA hasn’t worked before on discount coupons feature in the e-commerce app. But tries to somehow manage rather than approaching any SME in the team or outside.

Do I ever give feedback if the documentation of requirements is not clear OR a story can be broken further? —

e.g., QA finds the requirements written in the story to be verbose but doesn’t give the feedback to the BA about it.

Do I ever give suggestions to add/update requirements in the user story based on my technical/business understanding of the feature? —

e.g., in an e-commerce app, the case where discount coupon is enabled when user adds more than 5 items to cart is missed in requirements. QA doesn’t call it out.

Do I ever conduct/participate in a brainstorming session with Developers, QA, Tech Lead etc., to see if there is any scope for technical refinements? —

e.g., a specific microservice has high failure rate. QA can help identify the root cause and suggest possible solutions.

Note: Depending on your team dynamics some questions might not be relevant/exercisable OR some questions might have to be added to the list. So take these as pointers for self assessment of Agile QA skills, but not as commandment.

Once we are done with the assessment then what?

Where assessment ends, improvement should begin!

Taking the next step

The day you finish the assessment can be the day your journey to Agile QA greatness begins.. It’s all about applying oneself to the improvement tasks as early as possible.

Self improvement steps may involve (but not limited to)

Self study on areas of weakness
Knowledge gaining/sharing sessions with other QAs, Developers, BAs, etc.
Taking help from seniors/leads to work on certain task/perform a certain role
Keeping a tab on current and emerging software technology trends
Participation in tech seminars/meet ups/hackathons etc.

Carrying out this exercise of self assessment and self improvement as an Agile QA would not only help your team, but also yourself. It will affect both your contributions and confidence..

And only then will you be able to experience in your role as Agile QA the final principle of Agile Testing. That is to…

Enjoy!

Share This Article

FEATURED Article

The Future of Software Testing

CATEGORIES