It’s Test O’Clock!
2018-06-02 | 5 min read

It’s Test O’Clock!

Nikolina Mihić

Quality Assurance

As a QA you are playing an important role, because — well, you are fixing bugs and trying to make the world a better place. And that is a big responsibility. When you think about it, your job is to actually question the product you are helping to develop. Interesting, right? Finding problem areas before the users do requires some pretty great skills and knowledge. How do to in Agile?

What’s it like to be a QA in an Agile environment?

Software Development Cycles usually have 5 phases: Requirement gathering and analysis, Design, Coding, Testing, Deployment and Maintenance. While in most traditional models testing comes at the end, in agile development, things are a bit different. Why?


Awesome illustration : by.maako.

In Agile, work is divided in phases called Sprints. Duration of one sprint is usually 2 weeks and the team has the responsibility to deliver certain tasks within this period. What makes sprints different is that during those 2 weeks, we go through all 5 phases of software development:

At the beginning of the sprint there is usually not much to test. Use that time to study the documentation and write test cases. Writing test cases may seem unnecessary at first, but it’s not! It’s actually very useful, because everything is now in one place, systematized and transparent. This document also allows you to see when a bug was created and can be therefore really helpful for the next person doing the testing, in case you switch to another project.

Testing during the sprint. At this point you test only what was newly created or bugs that have been fixed.

Testing at the end of the sprint. Now you have to test everything developers have done in this sprint.

Testing before release. Don’t forget to test the whole app to be sure that everything is okay.

And then we repeat it sprint after sprint.

Pretty cool, right? The problem is, this way of work also opens a lot of space for challenges. The biggest one is the fact that there is always so little time for everything, and QA is always the first one to be cut, which means that the product won’t be thoroughly tested. This could eventually lead to lower product quality. If developers don’t have enough time to fix all the bugs found at the end of the sprint, these bugs become part of the next sprint. How can you avoid that? Here are some tips and tricks.

What Bugs Me As a QA?

The most important thing for me as a QA is to feel like a part of the team. That means that all the other team members have to understand that testing takes time. Of course, it can sometimes be time consuming, but that doesn’t mean that we don’t have to do it. Here are my top 3 tips on how to improve your testing game in the agile development:

1. Include testing hours in planning. It’s important to calculate the time necessary for testing each feature of the sprint. Because of this, the scope of the sprint may become smaller, but we’ll get on quality. At least, developers will be sure that the product they delivered is bug free (as free as it can be, there are no applications without bugs) and ready to be used.

2. Test from day one. Testing should not be done only at the end of the sprint. As soon as developers are done with a bigger feature, they need to send it on testing. This allows the QA to catch bugs in the early phase of developing and can prevent smaller bugs from turning into a huge problem.

3. The last day of the sprint should be reserved only for testing.Developers will probably be mad about this, because that’s one day less for developing. But, in that way we will enter the next sprint without bugs! During that last day we have enough time to test everything, but also to fix all the bugs. Otherwise, bugs found in this sprint will go into the next one, because there won’t be enough time to fix everything before the end of the sprint. That means that we will lose the first day of the next sprint. In my opinion it’s better to lose the last day of the sprint and have a clean start in the next one.


Get involved!

But this is not all you can do. What has proven to be really helpful for me as a QA are daily meetings, where you can find out who is working on which task and when they will be done with that task.

It’s a great opportunity to self organize and learn what you can expect at a certain point. Communication and teamwork are essential if we want to accomplish our goals. In the end, as members of the team we all have the same goal — successful products!

Like what you read?Go on, share it with friends!
ABOUT THE AUTHOR

Nikolina Mihić

Quality Assurance
Nikolina is a master of math, QA engineer and a Scrum Master at COBE. While her responsibilities mostly focus on QA, she is strongly influencing and challenging the whole team, changing our process from scratch. As a former basketball player, she shows impeccable work habits and contagious energy that often reflects on the team.

Let's turn your idea into reality

Save money, time and energy and book the entire team today.