Timeline for Are development and testing of a feature done at the same time in Scrum?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 12, 2021 at 20:21 | comment | added | NotThatGuy | @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. | |
| Jul 12, 2021 at 18:38 | comment | added | Daniel | @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? | |
| Jul 12, 2021 at 3:36 | comment | added | NotThatGuy | @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). | |
| Jul 11, 2021 at 22:28 | comment | added | chrylis -cautiouslyoptimistic- | @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. | |
| Jul 11, 2021 at 15:59 | vote | accept | Daniel | ||
| Jul 11, 2021 at 15:55 | comment | added | Bogdan | 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. | |
| Jul 11, 2021 at 14:22 | comment | added | Daniel | You mean they share the same git branch? | |
| Jul 11, 2021 at 13:31 | comment | added | Bogdan | 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. | |
| Jul 11, 2021 at 11:24 | comment | added | Daniel | 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? | |
| Jul 11, 2021 at 11:07 | history | answered | Bogdan | CC BY-SA 4.0 |