4

My dev team consists of:

2 developers 1 QA tester 1 Scrum master (me)

Currently the QA tester is part of the scrum team, however I do not make him follow a strict sprint from not having a lot of work. Whereas I protect the dev team from outside interference since they have a lot of work to do.

Since he is only active once work has been completed which is generally at the start or end of the day, he does other tasks when he is idle. Hence, we have just set a time at the start of the day and end of the day for 1 hour to do QA.

Is this ok?

Improve this question
1
  • Make them do regression testing. they will soon run out of time in the day
    – Ewan
    May 21, 2016 at 7:15

3 Answers 3

Reset to default
3

This is largely going to depend on your work environment.

In my experience, QA can support a team of 3-5 developers, so your QA is definitely under-utilized. This can be addressed by adding more devs to your team / spread the QA across multiple teams.

Beyond resource allocation; your QA can do more than just test the functionality delivered during the course of the sprint. They can:

  1. Write test cases for the work that is to be delivered during the sprint.
  2. Write automation tests for the application
  3. Setup test data for the current sprint
  4. (Not traditionally considered) Include QA in requirements gather / sprint preplanning as they will often be able to poke holes in the stories that aren't considered.

It may be worth asking this question on the Software Quality Assurance & Testing Q&A site as well.

Improve this answer
4
  • 1
    I agree that QA can expand their activities depends on their skills but I do not know how did you come to: "QA can support a team of 4+ developers". Each project is different from technology, requirements and people involved and I think we should not make such generalization.
    – MasterPJ
    May 19, 2016 at 7:50
  • He is a usability tester, not a tester who writes code i.e. automation tester. Meaning he can only test the functionalities once the dev team have written it.
    – bobo2000
    May 19, 2016 at 9:07
  • @bobo2000: That only rules out point 2 of the possible additional work. And you could always ask the tester if he is willing to learn that (might be easier if the test automation uses a rather high-level framework where it doesn't feel like you are writing code).
    – Bart van Ingen Schenau
    May 19, 2016 at 9:38
  • @MasterPJ The statement is based on my experience working on / with scrum teams. I've modified the statement to more accurately reflect that experience.
    – drneel
    May 19, 2016 at 12:29
2

Scrum teams should work cross-functional. If testers only test after development is done they lag behind. This could lead to situations where work is "Done" but un-tested at the end of the sprint. Now the tester is going to test it the next sprint? and the issues are fixed adhoc? This removes the whole focus on a Sprint idea.

What you are suggesting sounds like a mini-waterfall, where disciplines are waiting on each other.

Testers should work in parallel with the team preparing the tests and implementing them preferably automated. When the work is done anyone should be able to verify/test the finished work. Do this before anyone starts on new work, finish user story per user story with the whole team. Developers can also test and testers can also code, do UX, document or any other needed tasks to finish a user story. Use the tester as the test expert in the team instead of solely responsible for testing. The team is responsible for the quality not just the tester.

Read the Agile Testing book or let your testers do the Certified Agile Tester course.

Improve this answer
3
  • The tester in my team is a usability tester, he is not actually writing code i.e. automated tests etc Actually, he is not even trained in that.
    – bobo2000
    May 19, 2016 at 9:05
  • So he just tests the usability? and nothing functional? You called him a QA tester in your question, bit confused. But in his/her current down-time he could try to self-learn or else I would start looking for another tester who can. Someone who is only a manual tester has no fit in a small Scrum team if you ask me.
    – Niels van Reijmersdal
    May 19, 2016 at 11:30
  • Yep that's what I am doing. In his down time he does other tasks unrelated to the dev teams work.
    – bobo2000
    May 19, 2016 at 13:07
2

In Scrum there is no such a role as tester. In Scrum Guide it is written:

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

You should keep the QA within the Sprint to ensure that after each sprint you have a potentially releasable product. Without QA, the testing is not done and the increment is not done.

In addition, by enforcing work on features one by one rather then in parallel and finish them all at once in the end of the Sprint

  • your QA would have all time something to do,
  • Development team will find out bugs sooner and have time to fix them
  • Development team will have better control on what can be finished and what cannot

In case there will be still some free time for the QA, s/he should improve her/his skills to be more useful in other activities.

Improve this answer
5
  • having QAs raise spec changing bugs on work in progress can kill a sprint
    – Ewan
    May 21, 2016 at 7:11
  • @Ewan What do you mean? at the beginning of the sprint all people should understand What should be the outcome of each user story. Can you be a little more specific?
    – MasterPJ
    May 21, 2016 at 10:26
  • have you never been in the situation where QA raise 'bugs' which although perfectly valid comments are not in the spec. ie "should the menu be that colour it clashes with the background" when the menu colour hasnt been specified. The PO will agree they are right and the bug will be put in mid sprint, but effectively it is extra unplanned work
    – Ewan
    May 22, 2016 at 9:06
  • Sure, these things happen. Time to time we forgot to specify something, or do not realize something and it emerges during the sprint and causes additional unanticipated work. But I think that is normal, you cannot avoid that no matter what you do. In addition, every time this happens it is a potential point for learning. And the sooner the QA start to test, to sooner we know. It would not help to finish the feature according the specification if it would not work.
    – MasterPJ
    May 22, 2016 at 16:26
  • The correct way is to add the new feature to the next sprint. sure, writing the spec is hard, but the point of sprinting is to get things done in steps. If you only test completed stories that is enforced
    – Ewan
    May 22, 2016 at 16:38

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.