5

Let's suppose a Scrum team needs to implement a new feature.

Do QA engineers write automated tests for the feature at the same time as developers write code for the feature? In other words, QA engineers don't have anything to test yet, but are they already writing automated tests? So it's like the TDD practice (where we first create a test, and then write code), right?

Peter Mortensen
  • 155
  • 7
Daniel
  • 2,729
  • 13
  • 36

3 Answers3

8

Do QA-engineers write automated tests for the feature at the same time as developers write code of the feature?

Ideally yes. You need the two activities to be performed by a collaboration between developers and testers. TDD is another techniques that can be used. The idea is to move away from the behavior many are used to, which is for developers to write the code and then pass it of to testers, in stages.

If you cannot achieve the collaboration I mentioned above from the beginning, or test first, or use TDD, and you are still in a transition phase from the old approach, you should at least try to reduce as much as possible the time between writing the code and testing it and avoid the testing to pile up at the end of the sprint.

Bogdan
  • 15,216
  • 27
  • 48
  • 1
    Thank you! But if QA-engineers add new tests before the feature is implemented, then CI rejects all the other developer's builds (because the feature is missing). Right? What do we do with this? – Daniel Jul 11 '21 at 11:24
  • I think you still think about it in the old way. Developers and testers don't work at the same time on an implementation, but separately still. It's a collaboration. They write tests and implementation together in a tight loop, so there are tests that exercise some code, then more tests and more code, and so on. They go together. As such, there shouldn't be cases when tests get pushed on the CI branch without its accompanying implementation. – Bogdan Jul 11 '21 at 13:31
  • You mean they share the same git branch? – Daniel Jul 11 '21 at 14:22
  • 2
    Yes. Ultimately, in Scrum, it's the team who decides how they organize the work, including what branches they use, etc. But I don't really see the advantage of different branches for the implementation and the tests. Normally you should have a Definition of Done that must be respected. If you have tests then those tests are most likely part of that Definition of Done, so one branch without the other doesn't reflect a "Done" feature. – Bogdan Jul 11 '21 at 15:55
  • 1
    @Daniel In the most successful operations I've participated in, using a form of BDD, the test scenarios were developed specifically enough (in English) before implementation that the developers had no ambiguity in translating them into code, and I even had non-technical stakeholders directly review the test cases in PR to confirm that the software did what they wanted. – chrylis -cautiouslyoptimistic- Jul 11 '21 at 22:28
  • 3
    @Daniel Just like with feature development, automated tests shouldn't be pushed until they've been tested locally and/or in a branch and they're working (and they pass, and they will pass on master/main when pushed). If QA engineers are pushing tests in a way that affects all branches, just to be able to test a single branch, something has gone very wrong. QA engineers probably don't need to work in the same branch the development happens in before the ticket gets to the QA phase (although doing so may work best for certain teams and individuals with certain setups). – NotThatGuy Jul 12 '21 at 03:36
  • @NotThatGuy I didn't mean that QA engineers are pushing their tests in trunk and break all other branches. But QA engineers can commit their tests in the feature branch (where the feature is being developed), right? – Daniel Jul 12 '21 at 18:38
  • @Daniel I wouldn't recommend that a QA engineer commits tests that makes the build fail to a branch a developer is currently working on. That can make the developer's life more difficult because seeing whether the build works can be a valuable signal and a failing build can make developer testing of the changes more difficult (even in some cases where it just fails due to tests). It might also make review more cumbersome and cause merge conflicts. They can work on the same branch the developer/team is okay with it, ideally while they avoid the above problems. – NotThatGuy Jul 12 '21 at 20:21
5

In the Scrum framework it is up to the team to decide how to deliver backlog items. Many teams do adopt a TDD / BDD style approach although this is usually accompanied by exploratory testing and UAT as well.

When it comes to managing TDD with continuous integration, the answer to your question is branching. Developers are normally expected to create a new branch for to-be incremented code and then a pull request for tested code (including the tests) for peer review. All depends on how your team works, so this is ultimately a question for your development team to work out.

nvogel
  • 6,295
  • 1
  • 9
  • 28
  • 1
    Thank you! But what if developers and QA-engineers work in different repositories (code is in one repository, tests are in another repository)? How do we manage CI in this case? – Daniel Jul 11 '21 at 11:47
  • You need to ignore failing tests in the relevant QA branch until the corresponding implementation branch is pushed. – nvogel Jul 11 '21 at 16:51
0

The answer to this will depend upon the story and the definition of done for your organization. You could develop the test for a feature in one sprint and the feature in another. Likewise if your definition of done doesn’t include a test a test may or may not be added later.

I would recommend that you focus on what you want to get done, and use scrum to help you get that, than focus on what scrum allows or doesn’t.

jmoreno
  • 189
  • 5