QA - who tests what and when in SCRUM

There have been many approaches to testing computer systems over the years:

  • Do not test. The project lead might test a little bit, or the developers themselves. Then the software is looked at by the customer, and someone switches the software live and hopes. This approach is still very common - and depending on the quality of the team works more or less well.
  • Unplanned test phase. The software goes into a user acceptance phase, and some more or less qualified group of people check it does what it is supposed to do. Often it was discvered during this phase that while the software met the requirements on the paper, it did not actually do what was needed. This approach is for good reason disappearing.
  • Testing based on Test Cases. A group of "experts" defined test cases in such detail that anyone could carry them out. In our modern agile word, these should now be defined as acceptance criteria and then be automated as part of the user story. The problem, of course, was the things that nobody had thought about. It is completely unrealistic to define test cases in detail for every sequence, so that there were always things that went wrong not covered by the test cases.

Now we are using SCRUM and we all know that at the end of the sprint the story must be finished so that it can go live. We are using code review with requirements to check that the code is clean, that all acceptance criteria are met and generally that it works well.

So I claim that software developers are usually pretty good about getting the software to do what it should do. So why do we need the tester? I can think of the following:

1) To think what could go wrong. What are the edge cases that should be covered. This should idealy be done before the development starts and defined as acceptance criteria. These do not then really have to be tested separately by QA, because the developer and reviewer have checked them, so this is then a low risk area.

2) To check that there were no misunderstandings. Even in our modern world where we try to have face to face conversation, things still get misunderstood and requirements that are obvious do not get written down. As these corrections can be very expensive, this should be done during the sprint.

3) Carrying out large scale system tests. Even though each user story should be independent, we know that a feature will often involve lots of elements working together. So we have to have tests of the whole thing - take a bigger look.

I think it should not need mentioning that ALL tests should be automated. It just does not make any sense to have manual regression testing.

So my biggest message is - if test cases have been defined, we should not need testers to test them. Who agrees?


Lorant Zambori

Co-Founder and Managing Director | Generative AI, Cloud Migration

5 年

I agree with you David, we should not need testers to run the test cases. But having a tester mindset in the team is highly valuable: challenging assumptions from the early phase of the project, asking questions from the perspective of the user and getting everyone "quality infected" has many benefits besides a "bug-free code".

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了