0

Let's suppose a developer begins working on a new feature. They create a new branch. The team also has a CI server where they build and test new features.

While the developer is writing code, QA-engineers need to write automated acceptance tests for this feature (we work by Scrum). Do these tests need to be added to the branch in which the developer implements the feature? If yes, then how is it technically done - does the developer merge tests into his branch (from a QA-engineer's branch for the feature) or what? If no, then how CI knows which tests for which branch to run? (For example, how does CI knows that these new tests should only be run for that branch where the feature is being implemented, and should not be run for all other branches?)

2
  • Note that ¨While the developer is writing code, QA-engineers need to write automated acceptance tests¨ is not a necessary statement. E.g., BDD whole idea is to drive the development based on automated acceptance checks - defining them before production code. Jul 12 at 8:50
  • Thank you for this notice! But they happen at the same time anyways - why wait for ready Acceptance tests if we can write code while QA write acceptance tests? We just need to collaborate.
    – Daniel
    Jul 12 at 18:25
1

The answer of the question depends on few factors:

  • If the acceptance tests are written in the same technology stack as the software under test and if the framework is testing only one product and not multiple products, then maybe it's better those tests to be part of the project repo and devs merges the qa branch into their feature branch.

  • If the acceptance test framework is using different technology stack than the product's code or the framework includes tests for different products, then those tests should be written in a separate repository. Now to answer the question "how does CI knows that these new tests should only be run for that branch" => by creating a separate pipeline for this feature brach where you define a fb from the repo containing acceptance tests for it. Or somehow add a condition to existing pipeline if the fb is this then run those tests from that repo/fb.

While for some people creating a separate repo for acceptance tests might sound wrong, I would say that even the things depends from the QAs opinion who are writing the tests. If they feel more happy with a separate repo then go ahead and try it.

2
  • Thank you! Currently we use a separate repo for acceptance tests. And we always do features in branches. I'm not sure that making a separate pipeline every time is a good idea, right?
    – Daniel
    Jul 11 at 11:57
  • @Daniel the separate pipeline was just an example. I'm not an expert in CI systems but if have to solve some problems related to it I would just create a meeting with senior dev, qa and DevOps to figure out together the optional solution. Things which sounds too complex or impossible to be done usually are solved in the end of the meeting or at least have common agreement on the chosen approach.
    – chesthar
    Jul 11 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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