An idea about cooperation between development engineers and test engineers

Question

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?

Answer 1

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.)

Answer 2

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.