Every Agile ALM presentation the same question is asked: How do I get testing done in a sprint?
There isn’t a one solution/ practices/ to do/ how to fits all for this. So, I made a small list of tips you could do (or recommended to do, or must do… ), which can help to get testing done in a sprint.
Tip 1: Have testing knowledge in the team.
Actually not a tip, it is a must. This is a kind of obvious but not common and I think the hardest thing to accomplish. It is: get testing knowledge available in your team. When you don't have it, you will fail.
Now, it isn’t that easy to accomplish this collaboration. Test and dev are different, a nice quote from this ‘test’blog:
In the D-world, the world of the Developers, we think Generalist Testers are pencil-pushing, nit-picky quality geeks. Mostly they are beside the point and are easily replaced. They seems to like making much noise about little defects, as if we made those errors deliberately....
In the T-world we don't hate the Developers for their perceptions. We are disappointed about the poor quality of the software.
Bad assumptions on the part of Developers are more to blame for the problems than are software weaknesses.
We never(or seldom) get software what will work right the first time. No, in the T-world we think that developers forget for whom they are building software, it looks like they are building for themselves......
Try to combine these two worlds in one team, you definitely need to come up with a Collaborative Culture:
The three most important concerns are:
- a topic closely associated with trust when it refers to people is Identity.
- Collaborative culture.
- A collaborative culture consists of many things, including:
- Collaborative leadership;
- Shared goals;
- Shared model of the truth; and
- Rules or norms.
- a “reward” for successful collaboration is most often of a non-financial nature.
Show me the value, seems to be the magic word.
Test adds knowledge, knowledge during the grooming the backlog. Helping the product owner with defining proper acceptance criteria. And, help find improper written backlog items with inconsistencies for example. (this is my favorite test activity I didn’t know about before started reading TMap, Assessing the Test Base). In both ways helping the product owner and the team to focus on value.
Tools support, Visual Studio 2010
Tools can help, when using the VS2010 TMap Testing Process template you will notice that the test activities get an important place, helping the tester to get on board.
The ‘Testing’ Tab with test activities, next to the implementation tab.
Still two different worlds, test and dev in this way… but it give a good visual reward of being connected. Probably many teams won’t need an additional visualization of testing effort and can use the scrum process template in combination with their testing methodology, but this will help them to get started.
Interesting topic is the introduction of the manual test tool ‘Test Manager’ with Visual Studio in the current release. It helps teams to get more connected, it shows the pain points where the collaboration isn’t seamless. So, adopting MTM can be a good start for agile teams to get testing aboard. But, be aware the interactions are more important as tools. The tools won’t fix bad collaboration, mismatching identities, lack of trust and won’t give any reward.
02. Getting Testing Done in the Sprint – Regression Test Sets
03. Getting Testing Done in the Sprint – Test Automation
04. Getting Testing Done in the Sprint – Undone Backlog Item
05. Getting Testing Done in the Sprint – No Double, Triple Testing
06. Getting Testing Done in the Sprint – PBI Implementation Sequence
07. Getting Testing Done in the Sprint – Risk and Business driven Tests
08. Getting Testing Done in the Sprint – Write Logical Acceptance Tests
09. Getting Testing Done in the Sprint – Test Tasks on the Board
10. Getting Testing Done in the Sprint – Done
11. Getting Testing Done in the Sprint - The Customer Test Team
12. Getting Testing Done in the Sprint – The Test Branch