2

Currently I have two Scrum-Teams I'm responsible for, who did not plan a QA structure before. There were code reviews, and partly acceptance test.

Previously, the functionality was developed within a Sprint, then - even within the Sprints - was tested and released by Supporting Testers (ie DONE). Detected bugs were immediately recorded on the Scrumboard and fixed by the developers - so that at the end of the sprint you had an outfitted software.

Now it is so I am the only tester currently working for two teams. Currently in the planning is already a time with planning on the Sprint process. Exploratory tests are planned through a timebox. Functional tests are components of sprint planning. An automation happens about me, but for reasons of time I use QfS and its connection to the web framework.

Has anyone ever experiences in this regard?

What should be paid particular attention?

Can I get into capacity constraints, and how can I avoid that?

4

Now QA is not the only person responsible for the quality of the product, instead QA's are taking up the role of a person who drives the quality process inside the team. Some things which you can do/introduce to improve your and your teams efficiency are :

  1. Educate the whole team about the importance of quality and also that QA's are not the sole person responsible for it. So the entire team has to dedicate time to ensure that a high quality product is delivered.

  2. Use some extra helping hands - since you are the only QA, there can be chances that you become a bottleneck for the delivery. So highlight your capacity shortage during the sprint planning itself or asap and request other team mates help in testing activities. Agile Analysts or Scrum masters can come handy.

  3. Encourage devs to write more and precise Unit/Integration Tests. Unit tests are the cheapest tests. It will also give very early information about a defect.

  4. Request the team to adopt a services based architecture(SOA/Microbreweries). Testing APIs are easier than testing UI, especially on creating Automated tests. Automated API tests can be executed really fast and will give quick feedback.

  5. UI Automation- Automate only the stable and high ROI tests. We should be really wise while choosing the right candidates for UI automation or else we will end up spending more time in maintaining the UI automation scripts than testing it.

  • Liked the vision of QA as person responsible for the quality of the product - that's very likely to be the idea of senior management. +1! – Tiago Cardoso Feb 20 at 7:37
1

Now it is so I am the only tester currently working for two teams.

The Agile Testing Manifesto suggests Team responsibility for quality over tester responsibility

The whole team is responsible for quality, not just the tester

Traditionally it is the tester, or the test team that is responsible for quality.

...

Instead in agile the whole team is responsible for quality.

...

Read the full chapter with slides on: https://leanpub.com/AgileTesting

Having worked for multiple agile teams as their sole tester I can tell you it is impossible to keep up, don't be a bottleneck. My advice is to train team members to act as testers in their team.

  • The idea behind it I had accordingly. But a developer will always test differently than a QA person in charge. Of course, the developers write their unit test. Will the bottleneck not be handed over to the whole team? – Mornon Feb 19 at 12:41
  • 1
    I think it is the building vs testing mindset, developer switching to testing activities during a Sprint, need to acknowledge they are doing something different. They are smart enough to do it, but need something to help them focus differently. An example is stopping with testing after finding the defect, because they tend to swap to fixing it. I advice teams to discuss found defects with the team and decide if and whom will fix it instead. I do believe you can coach and train developers to have a better testing mindset. This might also improve the delivery quality in general – Niels van Reijmersdal Feb 19 at 14:37
  • Don't forget about the Definition of Done. Agreeing on a Definition of Done can act as a rallying tool for the whole team to take a backlog item to proper completion, not just whatever testing and automation there happens to be time for. – Daniel Feb 19 at 14:39
1

The role of QA on an agile environment is more to be near to business on test case proposals and understanding the requirement than implementing the actual test cases. It's up to the team to create the test cases as part of the development, if using TDD or BDD for instance.

With that in mind, the decision to reduce the QA capacity (or increase the development capacity) should have considered its impacts. Has this been discussed with the management designing the team structure? That'd be the first action: to ask the people designing teams to ask what they expect from you as a single QA supporting two teams.

From an agile perspective, you might not be able to deliver a proper QA for two whole teams, and trying to do so will only generate frustration. If you have a sound knowledge on the product(s) being delivered, I'd suggest you to participate on both teams plannings and assess with them and their POs what features are more critical, focusing on them.

Better a focused QA on critical stuff than a pile of low value test cases created.

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.