The problem is:

The team , I am working in has 10 developers to 2 testers ratio which means we are going to churn out code more quickly than it is "Test" done.

So, What should be the right approach to track activities in such scenarios according to agile experts?

My fear is that soon the day will come , when there is a lot of stuff which will be called as "Done" in previous sprints (with no testing done) but when it actually comes to testing, there might be some potential defects.

How can I track the efforts seamlessly? Should testing be part of "Done Definition"? What are the pitfalls if it is not?

As per me, it is sort of 'Waterfall' as you are calling stories "Done" before it is actually functionally tested.

  • 1
    scrum is practically waterfall - lots and lots of short waterfalls :-) – gbjbaanb Jul 21 '15 at 12:21

Yes, testing absolutely should be part of the definition of "Done". Without question.

From a purely agile standpoint, the right approach is for everyone on the team to contribute toward writing tests. The tester would be the one coordinating the effort, but it is the responsibility of the entire team to make sure the software is properly tested.

| improve this answer | |
  • 1
    Just came out of an Agile training and it is indeed the best-practice. As is involving the devs in the test from unit testing to as far as Test Driven Development. – Laurent S. Jul 25 '15 at 16:28

Firstly, a ratio of 10:2 is bad. From experience, a ratio of 3:1 or 4:1 developers to testers works well. You'll likely need at least one more tester therefore, otherwise the testing backlog will grow and either never get cleared, or you're cut corners somewhere.

If you test tasks in the next sprint, you are implementing mini-waterfall or "scrumfall" as you are separating out testing from development. You are right in that testing absolutely should form part of the done-definition. If a task isn't tested, how can it be declared "done"?

The right approach therefore would be:

  1. Add a tester to the team if possible, otherwise have the developers perform some testing (though they likely won't do as good a job as a professional tester).
  2. Modify your scrum/kanban board to include "ready for test" and "in test" columns and agree with the team that part of the workflow must be having all tasks go through these lanes.
  3. Tasks only make it to the "Done" column when they have been acceptable by testing.
| improve this answer | |

This is fairly common, if not typical. To answer what are several questions:

  • What should be the right approach to track activities in such scenarios?
  • Will features get done without QA but with defects?
  • How can I track the efforts seamlessly?
  • Should testing be part of "Done Definition"?
  • What are the pitfalls if it is not?

I would take an overall approach that:

  • enables the testers to add value
  • gives them authority
  • maximizes their value
  • encourages QA folks to train developers

and to do that (and answer your questions) I would:

  • make sure they can enter bugs in an easy to use bug tracking system that also contains the features such as Jira, Trello, Pivotal Tracker, etc.
  • make sure they are trained on creating good bug reports that describe:

    • steps to reproduce
    • initial/setup values
    • entered values
    • screenshots when appropriate
    • server logs when appropriate
  • make sure they see bugs get assigned, worked on and completed.
  • train them in best practices and send them to conferences.
  • train them in programming and using a test framework.
  • allow them to teach programmers on good approaches and mindset for testing.

Also, yes, some features may get done without QA but with defects. I often find QA is a second set of eyes. Sometimes this role can be filled by another developer. Personally I find this finds some errors, but not all the ones that a different QA mindset might find.

Testing should be part of done but that does not mean that the QA person has to do the testing. Given the shortness of resources and an Agile environment that eschews specs that QA can look at, QA need to be involved with learning the users domain, design meetings, point grooming meetings, standups, retrospectives, etc.

As for the big question of testing strategy, use the Agile testing quadrants to guide you:

      Integrated   |     Performance
           Unit    |     Exploratory

The developers may already be doing Unit Tests. A key area that QA may add value by covering is in Integrated testing and by using UI automation. Good exploratory testing is also very valuable - it's not just clicking every link on the page, it's about learning the end users domain and what using the application means to them.

For the ratio of QA's to testers also consider the testing triangle:

  Integrated Tests
Individual Unit Tests

whereby one exploratory or integrated test can represent dozens if not hundreds of unit tests by exercising the whole 'stack'.

Also consider that as in Agile teams there should generally be an approach of anyone can code, anyone can test. The key of course is giving folks the guidance and structure so that they can do what is needed and giving them training for the other area.

In terms of the actual ratio, I disagree about the preciseness of David's answer of 3:1 or 4:1 In some organization where developers are writing good unit and integrated tests this might be ok to be 7:1 In an organization with very little testing done by developers this might need to be 1:1 It really 'depends' on the organization, structure, knowledge, industry, etc, etc.

| improve this answer | |

When we started building our product, we also implemented Kanban, and along with that, we implemented a complete test automation strategy. As a result, today we don't have testers in our team. Instead, developers must write test cases and automate them as part of working on any user story, enhancement or defect. Our definition of Dev Complete includes unit testing and functional automation.

We still have a "Validation" stage after Dev complete - where all new dev work (features, bug fixes) is deployed on a staging server and someone - anyone who has functional understanding of the feature - must validate it. We use people from our Documentation team as well as Product Management - and sometimes Sr. Engg leads/ architects - to validate. Each release must stay a minimum of 1 week on staging before being deployed on production.

Here is a snapshot of our Kanban board -

enter image description here

The process and Kanban have worked for us. We have near 100% test automation, we have a 3-4 week production release cadence and best of all, most team members have the flexibility to work on pretty much most parts of our product!

So, while this may not meet your short term objectives, you might definitely want to look at how you can restructure your team in the long run and if not already done, then look at test-automation strategies that would definitely help your team deliver greater quality at shorter intervals.

| improve this answer | |

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.