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?

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
8
  • 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
    Commented Jul 11, 2021 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
    Commented Jul 11, 2021 at 13:31
  • 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
    Commented Jul 11, 2021 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-
    Commented Jul 11, 2021 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
    Commented Jul 12, 2021 at 3:36
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.

Improve this answer
2
  • 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
    Commented Jul 11, 2021 at 11:47
  • You need to ignore failing tests in the relevant QA branch until the corresponding implementation branch is pushed.
    – nvogel
    Commented Jul 11, 2021 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.