Internet Explorer browsers are not fully supported

QA in an Agile Environment

Dušan Panić, Software QA Tester

7 min readMay 07, 2021.

The Shift from Waterfall to Agile

Ever since the traditional software development methods started failing, adaptation to the agile approaches seemed not only to minimize the damage but offer a sustainable alternative. And since practically the whole world is turning agile now, and the agile mindset is what successfully led many companies through the Covid-19 crisis, agile is here to stay, for good.


The waterfall method is fine for projects which have an explicit and fixed project scope, minimal requirements, and only one stakeholder, but let’s be honest, when’s the last time you had one of these? In this ever-changing world, where the competition will crush you if you fail to keep up with all the innovative solutions just popping out of nowhere, you’ll probably have to add some new features on the go, and your app is most likely to undergo some fundamental changes and many design tweaks during the lengthy development stage. And that’s where agile comes in.

Agile method, as an iterative and an incremental approach, will offer enough flexibility to your project to ensure easy transitions from: ‘This is what we made last week’ to ‘But now, we need something else, or ‘We need the same thing but implemented differently’.

However, the problem we are facing here is that the QA role doesn’t really fit in with agile, at least in its traditional sense.


Agile Testing Practices

Traditionally, the QA team operates separately from the dev team and their part of the job comes when the project is near completion. Hence, there is no direct involvement of the QAs in the whole development process. But, with agile, testers are burdened with a variety of new responsibilities. And for those who do not adopt the agile mindset, the burden will only become heavier with time. New accountabilities, and potentially new roles, can only consolidate your professional growth and development, as well as expand your field of expertise. Some even consider a role of a QA in the agile teams a stepping stone to somewhat more thrilling jobs, such as Scrum Master or a Project Manager. So, being a tester in an agile environment could potentially help you climb the corporate ladder, if that is something you strive to achieve. And if you manage to rise to the challenge.


There are many ways in which the traditional QA role differs from the one in agile, but the most notable is definitely the constant collaboration factor that is paramount for the success of every agile team. All the team members, including the testers, work together during the development phase and the roles in the agile teams, if deemed necessary, can be interchangeable, which actually means that you cannot separate testing from the development. And that can sometimes be a daunting task, especially if you are not comfortable with getting out of your comfort zone at work. Expanding your work tasks to the areas you are not an expert in may sound laborious, but it is fundamental for every team member to understand not only the product but each functionality and its purpose thoroughly.

7 Steps to a Successful Agile Development

Of course, there are many ways to accomplish this, but here are some that are foolproof.

I One of the ways to ensure as smooth as possible increments and iterations is to attend all Scrum ceremonies. Sitting in on all the Daily Standups, Plannings, Groomings, and Retrospectives will certainly give you all the heads-up you might have not got otherwise. I know this is already implied in many companies, but since many of us are working remotely now, don’t be lazy to hop on the call for every ceremony of every project you are on, since this will allow you to spot potential development or organizational problems early on. Time and effort needed for testing should always be accounted for since it will affect the length of the whole sprint.


II You should tend to divide all the workload equally throughout the sprint to prevent finding a lot of bugs closer to the end of the sprint. Also, meet with the dev team frequently and ask them to demonstrate how each feature in the sprint works, so you can get a better understanding of the functionalities and maybe detect latent issues that may cause problems later on.

III Automation is also something that can come in handy simply because it’s faster than testing everything manually. So, if there is an opportunity to automate your tests and deployment scripts, or to create test automation frameworks, go for it.

IV Always verify the fixes. Well, this probably resonates a lot with what you have been doing so far, but a bug that you identify now belongs to the same sprint you are in and is not made a while ago, meaning that the user story cannot be labeled as done until each and every bug is verified. Before, the order of reporting bugs and verifying them didn’t mean much, but now it’s something that cannot be neglected.

V Track the metrics. Not only velocity, sprint burndown, and release burndown (which are fundamental agile charts) but code complexity, defect cycle time, number of running tested features, and cumulative flow are also some of the things you should familiarize yourself with and learn how to follow their metrics, for best possible sprint outcome.

VI Fail. This definitely isn’t a part of the traditional method, but learning to embrace the change is essential in Scrum. So, if you learned something from your mistakes, and what you learned prevents you from making the same or similar mistakes again, all good. Adopting the new practices and responsibilities may be tough at firsts, and sometimes san include failure, but that’s okay.

VII Making sure that you have documented all the test cases in detail can be of great help when something changes (and we all know that in software development that is bound to happen). So when the shift from one team to another happens, the documentation you have kept in perfect order will make a big difference and add value to the whole development process.


By and large, the whole agile process underlines the importance of teamwork, which is the underpinning force of the agile method, thus it is also vitally important to educate the whole team about Scrum and its three pillars (transparency, inspection, and adaptation). And if the company fails to do so, you must get yourself familiar with Scrum on your own, if you plan to have a prosperous QA career in the agile environment. I was lucky and got the opportunity to learn about it from experienced Scrum Masters in my company, but I know that not everyone gets that chance. Luckily, all the literature is easily obtainable online, and a simple google search on Scrum will provide many handy results. Of course, it’s always good to learn something firsthand, if possible.


The Agile Challenge

There are certainly some demerits of testing in an agile environment, such as too much time spent on rolling out new releases for every slight malfunction, creating test strategies that have quite a short lifecycle, attaining licensed automation tools that will benefit your process the most, and of course cooperation with non-agile teams. And let’s not forget that every company has its own version of agile, as well as the tools they use to implement it. But in the end, the advantages outweigh the disadvantages, and once you go agile, everything else will seem disorganized.

Just keep in mind that everyone is responsible for delivering the team's user stories at the end of the sprint. And for timely deliveries, an agile team should function like a well-oiled machine. So for everything to work well, each team member must think and act agile, not just the testers.