The difference between agile approaches and traditional approaches is the sequence of project phases – requirements gathering, planning, design, development, testing and UAT. In old development approaches, the sequence of the phases in which the project is developed is linear whereas in Agile, it is iterative

I have worked on few of the interesting projects that followed the agile approach. The project had a strong focus on clear and constant communication, team responsibility and most of all, speed of delivery within the scrum team. The dynamic way of working suddenly made non-agile projects look like they were progressing in slow motion. The Scrum Team in Agile has given me a new perspective on software development.

But not all agile teams are successful and many test engineers experience different challenges integrating their work with a scrum team. So how do you unleash the full power of scrum? The team members must know their roles and responsibilities within the team. Once the roles and responsibilities are clear, there are some additional tips and tricks that can help you take your first steps ensuring a successful scrum process. The following tips will help you get the most out of scrum rituals.

The refinement session

The Refinement session is usually when the test engineer first hears about any new features or user stories /PBIs. It’s very important to understand exactly what is going on in the team. Don’t be afraid to ask!

Once the product owner or business analyst has presented the idea for the new feature to you, PO(Product owner) or BA(Business analyst) should be able to answer all of your questions. This will be the your chance and big challenge you encounter. People will be too shy to ask for additional information which they do not know. Don’t be shy: this is the stage at which bug fixing is the cheapest. Once the idea phase has been implemented, it will be much more expensive to fix problems.

Also, this is where you estimate how complex your user stories are. Don’t forget to include testing effort when you are discussing the complexity. More often than not, what looks like an easy fix or a small feature will require significant testing.

The planning session

At this point you should know which user stories are suitable for testing; decide which ones are for manual testing, automation, or both. Good practice is to tag user stories that are suitable for testing with labels specifying if tests should be tested manually or can automate the script. Then, create sub-tasks for both and you will be confident that no user story will slip without testing. At the end of this session, you need to decide what you will take into your next sprint.

The sprint

When you are still new to agile methodology, do not get surprised if the user story you are working on turns out to be more complex than anticipated. With experience, you will be able to estimate the complexity more accurately. Until that time comes, don’t be afraid to tell your scrum master and team if the work is taking longer than you expected. Software development is a team game and someone might be able to help you with that. The worst thing you could do is to wait until the end of the sprint and only then notify them that you were not able to finish your tasks.

It’s very important that the testing and development of a user story happens simultaneously. As a test engineer, you can prepare test plans, test scenarios and test automation scripts while the user story is in development. You must ask for examples (such as request and response payloads for service level in Swagger or locators and wireframes on UI levels) or even mock services and continue with development of your tests before the developer has finished.

It’s good practice to open bugs under the user story as story bugs, which is making it easier for tracking. The team can then discuss which bugs must be fixed and which can go into the backlog.

Morning stand-ups

Be prepared for your morning meetings. I have heard people say in morning stand-ups that they worked on a user story or a bug but don’t remember the user story ID. The scrum master then has to search through the board while the whole team is waiting. Do not let that happen. Do not be that person: have your story and bug IDs ready for the meeting.

These meetings will be held for 30, even 40 minutes, taking precious time from everyone. There are only 3 questions you should be answering: What did you do yesterday, what are you planning on doing today and do you have any blockers? Write down the answers on a sheet of paper and have them ready for the morning stand-up.

It’s OK to have a question, but any further discussion that does not concern the whole team should be left for after the morning stand-up and only for people who are affected by it. 

The retrospective

Don’t ignore this meeting! The best-performing teams foster open and honest communication. Hence, it is very important to say what could be improved in your team’s work. Do not focus solely on bad things (although that is the main focus). Remember to say that, what was good and to praise those who did well. Also, don’t wait until the day of the meeting to think about what you are going to say. Keep your notes close by during the sprint and whenever you notice something good or bad about your – or your team’s – work, write it down.

Only then will you be able to contribute effectively to the retrospective meeting and constant improvement of your team. In particular, if there are significant gaps between estimated and actual complexity, your notes will help you uncover any patterns and improve your planning estimates.

Beyond Scrum

It costs to invest in continuous integration and delivery – and your automated test scripts are a crucial part of that. A sprint usually lasts two weeks. There is not enough time for functional testing of each new deploy, or for waiting for someone to start the script and deliver test results. Your smoke and regression scripts should have Jenkins plans that are connected to deploy plans in the pipeline. There should be no deploying happening on any environment that is not followed by an automated test plan and test scripts for that environment. This makes you know if the deployment is stable and suitable for further testing quickly. And, results of the tests also can be collected and mailed.