In the last couple of years I have been involved in a number of interesting projects that followed the agile approach. Each project had a strong focus on clear and constant communication, team responsibility and, perhaps most of all, speed of delivery within the scrum team. This dynamic way of working suddenly made non-agile projects look like they were progressing in slow motion. Scrum Team in Agile has given me a new perspective on software development.
A Scrum Team in Agile
It became clear to me that I could never go back to the waterfall approach again. But how do you unleash the full power of a scrum? Firstly, team members must be aware of their role and responsibility within the team. Once that is clear, there are some additional tips and tricks that could help you take your first steps in the scrum.
Grooming Session
The grooming session is usually when the QA engineer first hears about any new features or user stories. Before the session ends, it is very important to make sure you understand exactly what is going on. Don’t be afraid to ask!
After the product owner or business analyst has presented the idea for the new feature to you, they should be able to answer all of your questions. This will be the first big challenge you encounter. Often people will be too shy to ask for additional information. Don’t be: this is the stage at which bug fixing is the cheapest. Once something has gone beyond the idea phase and has been implemented, it becomes much more expensive to fix problems.
Planning Session
This is where you estimate how complex your user stories are and ultimately, what you will take into your next sprint. At this point you should know which user stories are suitable for testing; 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 they are manual or auto QA. Then, open sub-tasks for both and you will be confident that no user story will slip without testing.
The Sprint
When you are still new to agile methodology, don’t be 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 it more accurately. Until that time comes, don’t be afraid to tell your scrum master and team. Software development is a team game and someone might be able to help you. The worst thing you could do is wait until the end of the sprint and only then notify them that you were not been able to finish your tasks.
It is very important that the testing and development of a user story happens simultaneously. As a test engineer, you can prepare 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 levels or locators and wireframes on UI levels), or even mock services and continue with development of your tests before developer has finished.
It is good practice to open bugs under the user story as story bugs, making it easier for tracking. The team can then discuss which bugs must be fixed and which can go to 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 ID. The scrum master then has to search through the board while the whole team is waiting. Don’t be that person: have your story and bug IDs ready for the meeting.
I have seen these meetings lasting for 30, even 40 minutes, taking precious time from everyone. There are only three questions you should be answering: What did you do yesterday, what are you planning on doing today and do you have any blockers? Write the answers down on a sheet of paper and have them ready for the morning stand-up.
It is 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.
Retrospective
Don’t ignore this meeting! The best-performing teams foster (brutally) open and honest communication. Therefore, it is very important to say what could be improved in your team’s work. Don’t focus solely on bad things (although that is the main focus). Remember to say what was good and to praise those who did well. Also, don’t wait until the day of the meeting to think about what are you going to say. Keep your notes close 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 ultimately, the constant improvement of your team.
Beyond Scrum
It pays off to invest in continuous integration and delivery – and your automated test scripts are a crucial part of that. Sprints usually lasts two weeks. There simply is not enough time for manual 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 or Bamboo plans that are connected to deploy plans. There should be no deploy on any environment that is not followed by an automated test plan for that environment. That way you will know if the deploy is stable and suitable for further testing in a matter of minutes. And, of course, results of the tests should be automatically delivered by mail.
I hope this will help you understand how a Scrum team in Agile works and save you some time.
And, how was your sprint?
