3

I'm working in an "Agile" environment and as the developer, I have been asked by QA to write some test cases and to extensively review existing ones. This seems very backwards to me. Am I missing something?

  • 1
    Out of curiosity, how many developers, analysts and testers are in this team? – FDM Apr 23 '15 at 15:13
  • It's going to sound insane, but this is the team setup: 4 BAs 2 PMs 2 Architects 1 Solution Architect 3 QA 1 Developer (me) 1 Scrum Master 3 "Product Support/Implementation" – Samuel Elrod Apr 23 '15 at 15:17
  • 1
    That is a 18 people team!?! Teams work best in groups up to 10, and for development teams lower that to 7 :) – Niels van Reijmersdal Apr 23 '15 at 15:28
  • 1
    Yeah, it's a complete joke, there are actually 25 people on the team and only one dev. – Samuel Elrod Apr 23 '15 at 21:22
3

As Agile teams need to be cross-functional, its handy if the team members itself are also cross-functional in their Agile skills including testing.

One thing you want to prevent is having a mini-waterfall within a sprint. This leads to all the testing to be pushed into the end of the sprint, which could in turn bring your sprint commitments in danger. Start testing as soon as possible and prevent testing bottle-necks in the team is a must.

The developer role is more then just stamping out code, personally I think there is a 33% rule, where work is spread out over your time in these three main groups:

  • Requirements
    • Understand why and for who you are building it
  • Coding
  • Testing
    • Unit-tests
    • Exploratory testing sessions
    • Automated integration / GUI tests

The order can be mixed, certainly if you apply XP practices like TDD.

Now I get the feeling you are asked to write and review manual test-cases. Focus on automating all test-cases (if possible), this is necessary to have a potential ship-able product after each iteration.

So creating test-cases in a TDD or BDD like manor to be able to automate them during the sprint seems like something everyone in the team should do.

Reviewing older test-cases might also be necessary. Just like you have good reasons to clean and re-factor older code, do the same with your test-cases. Similar to code-reviews, review if the test-cases make sense, just like everything made by humans it will have a mistake here and there.

And last but not least: Quality is owned by the team, not just your QA person in the team.

0

It is unusual, but then so is the composition of your team.

You didn't say how much detail you are expected to include in your test cases. It may be enough to write each test case as a single, declarative sentence, and then leave it up to your QA team to execute. That way, you give your QA team a sense for what to test but you don't spend too much of your scarce time on test cases. (You also avoid writing details that may change in the next release.)

The question title asks whether the dev team should ever review test cases in depth. It think it's reasonable for the dev team to review the goal of every test case. If the dev team is reviewing step-by-step, click this then type that, kind of instructions, it may be time to think about changing the process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.