You've successfully adopted the Agile methodology, and you are making your way through the learning and growing...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
phases as a Scrum team. Typically, the focus starts out nearly 100% on new development with little emphasis on testing tasks.
As a QA manager, how do you get the team to focus on quality and testing as well as new code development? Is your test team able to focus on testing, or is it involved in multiple projects that also take time and attention?
In the long and short run, testing is extremely important in Agile because of its quick response time and frequent changes to both code and requirements as a product is developed in iterations or sprints. We know the need for speed and flexibility are business realities, but how do you balance those with effective, focused testing? Your Scrum team needs to accept and promote the importance of building in quality while testing as effectively and thoroughly as possible. Your Scrum team needs to communicate; make the testing flexible, quick and effective; and allow your test team to focus on testing.
In this article, we'll review three ways to improve both the Scrum and your test team's abilities to produce a quality product. We'll focus on testing by building strong communication lines, ensuring test timing remains flexible and by improving test value using quick, effective testing methods that improve as the product develops.
Building strong communication
What constitutes strong communication? Is it people chatting in the kitchen or picking up the phone and discussing their weekend plans? Although interpersonal communication is helpful, you need to foster your team's business communication. When the developer gets requirements and begins coding and makes changes, those changes need to be communicated to your test team at the outset, not after a defect is reported. For example, perhaps the developer discovers an unknown workflow or the implementation just doesn't work with or breaks existing functionality. It's actually a good thing to discover these issues and fix them during an iteration -- that's what makes it Agile.
Next, pay attention to how changes are communicated to the rest of the team. When a team is learning and transitioning its thinking from a Waterfall development cycle to Agile, the team typically continues to perform the same actions and communication but in a more compact time frame.
Put your Scrum team at ease
How do you get a team to be comfortable enough to talk to each other? Some companies do team building activities, which can be helpful or painful.
First, introduce team members to each other. It doesn't matter if your team is remote or in the same office. During your daily Scrum meeting, take two minutes and have every team member describe an activity or hobby they like. As a manager, be prepared to initiate, build and nurture the conversation without taking it over. Perhaps a daily trivia question will help break the monotony and get people talking. The important thing is to add an element of fun or less-than-serious information to spur conversation.
When team members feel more comfortable with each other it's more natural for them to share important details. They begin to think not only about how an issue or change affects their work, but also how it affects others. It's easier to share information once a team learns to communicate.
Flexible test timing
As a test team manager, spend the time to attend stand up, planning and design meetings. Don't distract your test team by sending them daily email requesting updates. Go get the information directly. Get to know the Scrum master and become familiar with the tasks your test team members perform within the Scrum team.
In Agile, some form of testing should occur continuously throughout the iteration. A testing task should exist as part of each user story. Be flexible; don't mandate that each user story must have a separate test case. Some user story tests are merged together, so separate tests are redundant or cause rework with takes the focus off testing and on cleaning up test cases. Trust your test team. Give it the flexibility to decide when and how a test case is written.
Nothing impairs testing more than losing focus or being forced to squeeze testing between brainstorming sessions and noncritical projects. When your team members are testing during an iteration, it's critical that they focus on testing. Don't set up meetings to brainstorm about the next release or assign them to "special" projects that have little or no bearing on testing the actual code available now. It's your job as a test manager to innovate and improve, but not to create distractions. Leave those projects to periods between releases or when iterations are complete and new planning starts.
Take the time to observe your testers. Do they conduct testing during the beginning, middle or end of the iteration cycle? Or does it always occur during the last three days of the iteration? If testing always occurs the last three days, then your Scrum team is still holding onto its Waterfall apron strings. Be the mentor and coach; come up with realistic solutions that enable testing and development to occur throughout the iteration rather than just at the end.
Quick, effective test methods
First, this has nothing to do with automation. Quick and effective refers to purely manual and mental techniques testers use without realizing it. Your team has these skills. When you're observing their work, learn how they create their tests. What parts of the workflow are they including? How deep are they going during the iteration? Are they just skimming now and performing more in-depth tests later?
In Agile, it's more effective to first focus on the smaller pieces of the workflow that are changing. Add fuller tests later during a regression cycle or as part of the next iteration. For example, many testers create spreadsheets to build out tests. They later merge their spreadsheet into the test tool and create formal test cases when the full iteration cycle is complete. This way, they continually add to the test case set while testing only the piece they need within the iteration.
It's like architecting a building from the ground up. The plan starts with the foundation. The foundation must be correct or the building will be flawed. Build out your foundation and then build another piece of the structure. Eventually, once each set of pieces is fully tested, the full test can be built from the pieces. In the end, you come up with a test that checks the entire structure.
Improving business communication, increasing flexibility on test timing and structure, and building up tests as each iteration progresses gives you an exceptionally well-tested product. Additionally, you'll have team members who understand how to communicate with each other. Allow your team to focus on testing rather than additional projects. Finally, build iteration tests and then use those tests as building blocks to build out regression for the final release to achieve in-depth testing that's also effective.