Suppose we want to develop a small module (time needed: two weeks of one developer). Then what about this new (maybe?) pipeline:

  1. The test engineer starts working:
    • Think about all cases (including many edge cases) that we need to test.
    • Write them down as code using an automated testing framework.
    • At this stage, the testing code all fails, because the business code does not yet exist.
  2. After the test engineer finishes, the developer starts:
    • Develop business code. During development, run the test code above. (Now the dev does not need to use things like PostMan to manually test his code over and over again.)
    • The testing code may contain bugs, and the developer should fix it. (Since the testing code is mostly straightforward, it should be not challenging to fix)
    • When all test code passes, the code is almost done.
  3. The test engineer checks that the modification of tests does not throw away things he wants to test.
  4. Done.

P.S. We are talking about E2E tests here, not unit tests. IMHO unit tests should be done by programmers (is it correct?).

P.S. We are small teams, so maybe not able to use the methodology in big companies.

Is this methodology acceptable/wonderful/terrible/awful?

  • 1
    I challenge you to have testers write all the E2E tests in advance.
    – Euphoric
    Mar 15, 2020 at 6:19
  • @Euphoric Good question! I will think about it twice. Thanks!
    – ch271828n
    Mar 15, 2020 at 7:08
  • 1
    If it is true that the task only needs two weeks of developer time, you can iterate this. However, when picking the requirements and when writing the tests, there are no guarantees that it will actually take two weeks to complete.
    – Theraot
    Mar 15, 2020 at 7:59
  • @Theraot I will consider that. Thanks!
    – ch271828n
    Mar 15, 2020 at 8:02
  • 1
    Instead of building such a castle in the air, why not try it out (you can do this alone) to see where the problems with this approach are? Start with something like Tetris (which should perfectly fit into your time frame if you are an experienced dev). Good luck.
    – Doc Brown
    Mar 15, 2020 at 10:09

2 Answers 2


This looks like a non-iterative version of Acceptance Test Driven Development. Like all non-iterative processes, it suffers from the fact that it assumes it can perfectly predict the future, that the client never changes their mind, that requirements, markets, environments, and circumstances never change.

ATDD works in an iterative fashion: the test engineer writes one test together with the business analyst and/or client. The developer gets the test to pass. The project is built and delivered to the client, who can already play around with the product. While playing around, the client will inevitably discover that they missed some requirement or misjudged the impact of some decision they made.

Based on the feedback from the client, the test engineer then writes a second test together with the business analyst and/or client. And so on …

Note also that typically in ATDD, the test engineer and developer are the same person, although they don't have to be. (If they aren't, you could do some overlap in the phases, e.g. have the test engineer create the second test while the developer still implements the first requirement.)

  • Thanks very much for your answer! Now I know the term and more sophicicated pipeline!
    – ch271828n
    Mar 15, 2020 at 7:58

In the frames of TDD/BDD the question seems like a ... not properly defined. The testing planned and implemented upon an interface part is defined. There are a lot of Agile development teams where any class must have at least unit tests which, prove its right to live, and it is alive because of the tests. Even unimplemented methods must throw errors that they are not implemented. Furthermore, a definition of a class can contain contain non functional constraint as GC, processor, memory metrics and tests must prove that metrics inside constraints. Any module/sub project must contain the proving tests.This work can be done either by test engineers, which follow work of business analysts, but often it is done by development engineers. It has a reason because, as I believe, developers must understand what is being done and what is the role of the component,while test is a best way to feel it. In this case test engineers start working on integration and pre delivery stage, when all maven/gradle scripts run without exception and system runs in real industrial environment, and integrated system tested with test automation. This way the bound, which separates areas of responsibilities is scale of integrated components. I believe that low and middle level component must be delivered with full tests by their developers because of the reasons, are mentioned above. The second way - it is participation of testing engineers in definition and implementation of tests for all components, when development engineers just implement the defiled interfaces and contracts. From my point of view it is not a best practice, because of the to reasons: it does not further for understanding of system and business logic of what is being done, and, besides spends time of testers for small level tasks, when they have lot of work to do to test system in a real conditions.

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.