Have test cases evaluated by everyone in the Scrum team? Including the developers?

Question

I am currently assigned to a new project, on a Scrum team that didn't have a tester integrated before. There are no test cases yet, but the project is more advanced.

So I'm busy defining test cases myself right now. I would like to have my test cases checked by the developers within the Scrum team.

Even though it's always very time consuming, I have to be sure at the beginning that my test cases are correctly defined and that I'm up to date. My test cases have to be up-to-date, right from the start.

The project owner sees it differently and thinks that the developers are just too close to their development to decide whether a test case is set up correctly.

I see it differently, because wrong test cases are worse than time problems within a sprint. Wrong test cases that are not reviewed also blow up projects.

Problems

• A review of all new test cases would take too long for me as the only tester in the Scrum team.
• A bad review can lead to bottlenecks.
• If the test cases are not removed, I have to work constantly to adapt them.
• In my opinion the Project Owner does not see the problem that the test depends on these test cases.

Answer 1

Use tests to drive code design.

This is the difference between using tests as quality checks, post development instead of using tests to uncover and drive the design up-front.

"Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Managing the Unmanageable. Steve Mcconnell

When you write tests up-front, with the application code, you create testable code. When you write the tests afterwards you do not.

To use this knowledge to promote change I recommend not trying to persuade folks to change (usually doesn't work) but instead start promoting and presenting TDD and BDD

One way to think of this: "Wait - the developers are writing code without test cases up-front to make sure they pass! omg, how do they know they are writing code that does the right think? Because they are professionals? Because we trust them? C'mon folks we've learned how to do this a while ago.

Write tests up-front !!!!

Another take - are they already writing unit tests? Are you just talking about UI tests? Based on the Agile testing pyramid perhaps you could detail what is being done for Unit, Integrated, UAT and Exploratory testing.

Use the Three Amigos approach

Another good idea is to use the three amigos approach. This way whenever new functionality is being proposed, talked about, decided, etc. you have 3 representatives - product, development and test. That way you can have conversations that include all three parties. So the product owner can say "no, we don't need to test example xyzabc (for example) or a developer can say, 'yes, we have that covered in unit test case xyq123 and the test person can ask if it includes condition A683, etc.

I have personally seen 2 weeks of test work be determined through 6 minutes of such a conversation.

Don't try and persuade this in a hallway conversation though. Present to management, ensure buy-in and then present formally to the team. Could also be offered during a retrospective.

When you feel "I would like to have my test cases checked by the developers within the Scrum team." think "test cases MUST checked by the developers within the Scrum team." Just be aware that a formal practice will require buy-in up-front, not persuasion for a given instance.

Answer 2

I agree with the previous response - when I was working in a Scrum team I found the Three Amigos approach invaluable for bringing up issues that were considered differently by devs / test / product owner.

Have it as a column on your board if at all possible so that it is a formal part of the development process. Even for eg very minor issues that may not need it, having to pass it through the column ensures that you do consider it.

Answer 3

Adding to the above answers,nowadays top software testing companies also follow below approach: Whenever a new functionality is implemented in a product, the product owner creates a design document for the changes that gives QA the details about the changes that will be getting implemented! Moreover, in scrum as we have daily stand-up calls, asking queries about new features will definitely help.

Additionally one suggestion for tracking/log work is that you can ask your scrum master to create a QA Analysis task where you can log hours for the time spent on going through and understanding design document for the new feature.

Answer 4

Yes - It is recommended, that you should write test cases and share with every one in the team and when developers write the code, they must go through it and then develop. In this way, there would be lesser chance of last minute or understanding issues.

But, practically it is a bit difficult to achieve.

Good luck.