Suppose we want to develop a small module (time needed: two weeks of one developer). Then what about this new (maybe?) pipeline:
- 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.
- 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.
- The test engineer checks that the modification of tests does not throw away things he wants to test.
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? Thanks for any ideas and suggestions!