QA-Challenged Team - How to Improve?

Question

Both in my Scrum Team and in the IT Department as a whole, we do not have a single hired QA-personnel. In fact, it is mandated by upper management that we cannot hire one (and I do not think this likely to change). Despite this, there still exists a requirement for quality, functioning work - even before it's handed to the (internal) users for beta testing/UAT.

How this has been solved thus far is by having the PO also act as QA. However, worth noting is the fact that she also serves as PM for every project the department has, and sometimes even as a secretary. As a result, stories are often considered 'Done' only towards the end of a Sprint, or else pushed one (or more) Sprints ahead before she can find the time to QA them. Obviously, we can't just have the developers just sit around for a month to allow her to catch up.

As I see it, the only solutions I've come up with are:

1. Continue as we are.
2. Dedicate an hour of each developer's time each day to QAing each others' work.
3. Remove QA entirely and just increase testing by the developer who did the work.

I'm not terribly fond of any of these options; is there a better route to improve our process?

Answer 1

We've struggled with the same issue on my team, while there's no replacement for a quality QA on the team, we've managed to get along by wearing multiple hats.

This is our workflow:

• TDD the story until it's ready to integrate.
• Developer integrates and manually tests.
• Developer requests code review.
• 2nd dev reviews the code.
• 2nd dev pulls the changes local and QA's it.

A couple of points of interest that make this effective.

1. We're constantly expanding our automated test suite. Regressions are becoming rare beasts.

2. The "QA" is also the peer reviewer and they review the code before testing it.

   This means they get a chance to "white box" test the code. Given that they already have some understanding of the code, it's easier to find edge cases that may have been missed and generally weird ways to break the new feature. It also means that bug reports often include the line number of where the bug is and a suggestion on how to fix it. (but never an actual fix, we don't want to incentivize sloppiness.)

In all seriousness though, keep pushing for a QA. In my experience, not even the most quality minded developer can hold a candle to what a great QA can do. We've been able to get by, but not every dev is cut out to make the context switch from "make it work" to "how can I break it?"

Answer 2

There are already some good answers about how to cover the testing tasks by the team. I'm hoping to add something a little different with this response:

In my experience, the biggest skill a QA engineer brings to the team is not the ability to run tests (as other answers have covered, that's easy enough to automate or delegate). Rather, it's the perspective they bring from a career of looking for the edge cases, cracks in the plan, etc. If you can't bring on someone in that role, I recommend looking for and cultivating that skill in your developers or new hires.

I'd also recommend looking into how lean recommends building quality in. Build habits of identifying common sources of problems in your code and addressing those. Building quality development practices beats trying to catch the problems on the way out every time.

Answer 3

I think you should hire a person with a QA background, but not as someone to-do the actual testing, but as someone who infects everyone else with the test-virus. If you cannot hire a tester, hire a developer with test experience, or find someone in the team who wants to specialize a bit more into testing.

I firmly believe part of being a good software developer is being a good tester.

-- John Sonmez

Testing should be done up-front and in parallel with coding, not at the end. So it makes total sense that people from the Scrum team do the actual testing. Both automated and with exploratory testing sessions. Learn about the Agile testing quadrants and find a good balance between testing efforts.

Suggested reads:

• https://less.works/less/technical-excellence/thinking-about-testing.html
• Agile Testing, A Practical Guide for Testers and Agile Teams (Book)
• http://blog.xebia.com/are-testers-still-relevant/
• https://www.thoughtworks.com/insights/blog/agile-tester-30

Answer 4

Automated UI Tests

Require the devs to write automated tests which prove the functionality of the features they develop. ie seleninum/TestUI/CodedUI etc

This will increase load on writing specifications and decrease load on testing

Answer 5

Do testing as a group:

Unfortunately, we do not have a dedicated tester on our team, which means that we depend on the testing capabilities of all the members of the team. That might be right according to the books, but my experience is that developers don’t have the same mindset that a tester has. We try to make up for this by organizing explicit internal test sessions where the whole team tests a finished feature. We encourage each other to plan internal test sessions as much as possible. These internal test sessions are extremely valuable.

Then do a demo:

Yes; by Friday, we usually have some functionality ready to show the product owner. Therefore, I need to verify with him that the new functionality we are implementing during this sprint is doing what is expected. We write up a short scenario of how we are going to use this new functionality and add a list of questions to get any uncertainties out of the way. After the product owner sends us his answers, we can carry on with the implementation.

and finally run a copy of production data in a dress rehearsal test environment:

On Tuesday morning, our tech partner deploys our code to the UAT environment. When UAT is signed off by the product owner, the code is deployed to the Clones environment (which is a second acceptance environment that contains an exact copy of live data from the production server) on Wednesday. On the Clones environment we test to verify that the live data will not be affected by our changes and to see whether the added functionality is doing what it should do with the actual data.

References

• A Sprint in the Life of a Scrum Master

Answer 6

I second Ewan's approach: Self Testing Code and Automated Testing is the way to solve this.

Self Testing Code - will require reworking existing code and hesitation on your team's part would be understandable.

Automated Testing - would best be done by hiring another programmer - who then programs tests instead of products - and management would n't notice.

Or, as you suggest in choice #2, simply use some of the existing programmers' time to write automated tests.

A different approach - depending on your products - would be to start an Alpha-program, where the users are essentially testing and reporting bugs for free; no cost to management and you get your product tested while you are developing them.