One day, one of my ex-colleagues called me. He has encountered a common issue in each sprint, somehow a few SBI are not done due to an incomplete or failure of acceptance testing.
I believe this is one of the challenging tasks of development in a self-organizing team. And when you see SBI not DONE because of testing left or an acceptance test has failed, that gives a clear message that shows your skills to resolve it as a scrum master.
When we develop any software, we are actually communicating two worlds, both the T-world testing world and the D-world developer world.
Traditionally, testing activities have happened at the end of the development (coding) effort because a tester's responsibilities have included proving the requirements were met, ensuring the software worked and finding bugs in the nearly finished product.
And when you enter in Agile development, you are an individual and a part of a team with no tag or title. There are collaborative responsibilities, whether you are a tester or a developer. Only one world exists in the agile scrum planet.
Agile processes mean testers are part of the delivery team and should try to be involved from the beginning of the project. For you, as a tester, there is a need to work as a member of the team and to engage with others within the team, regardless of titles. If you see a task that needs doing and you have the skills to do that task, then just do it.
If developers are already testing their own code (and maybe even pairing up to review code as it is written), then what do you need testers for? Some organizations compel testers to learn to code, for continuous delivery and automating testing, this trend goes against a tester. One of the top banking organizations is switching to a selenium tester. They do code like developer testing of their unit or integration testing. If such a trend is compiled, there will be no more testers in the future that are against the software engineering law. It is better to change the word to a unit or selenium test developer. Now the question becomes, do you need Testers? Yes, we need testers but with significant changes in their behavior (ignore selenium testers). Yes, we need testers because even the best, most responsible and experienced developers make mistakes.
The following are some factors that make better agile teams.
Agile-Test, we look forward and speak to the tester. Tell them to change the behavior. Continue with less talking and more asking. For example, I would ask the tester to ask, “Is there a bug here?” Instead of stating, “There is a problem bug.” This drives my team to look deeper into the items by asking significant questions. In Agile in general, we have PO, SM and teams. Initially or between sprints, a tester can become a sprint business analyst. I keep asking testers to explore each sprint. I do not mind to silly questions. You should keep asking and helping the developer or PO. My personal view is “The developer does the code, checking the code should not fail, either unit or integration testing. The tester is a functional analyst or business analyst of the team. The tester assists developers to check the various scenarios in unit and integration testing. The test can ask in each sprint meeting to PO, for example what if the customer adds an item to a wish list and after 10 days the item is no longer in the active sate?”. For this, I suggest the tester create their own model (using a pencil and paper). I believe you must involve the tester in the start until the end. Prepare the tester to be involved in each SBI and allow their own design. They must share and ask what they think should cover. They should create daily notes of where they keep sharing with the team what they discover on that day. In the next day's daily meeting, all are informed of what they are doing today. It helps the developer and the team to reduce bugs. And increase the accepting criteria. Stories and Items are short, the chances for understanding can be differ. The testers are very familiar with the old way and style that helps the team to discover more by asking (by the tester) in the sprint meeting.
It doesn't matter how you are working, what method you follow, Agile or Waterfall, it doesn't change the need for testers.
In Agile, change the way you look. Do not just find the bug, it is only your responsibility, be a reporter, assistant, discoverer and explorer. Be a Team Player, you will see you are part of a self-organizing team.
As a Scrum Master, you need to develop such profiling in your team.