Recently, I was in conversation with a developer, developing an API. We had a conversation appertaining to testing of that API, while I told him we will test the end to end flows of API using automation(rest assured), however, he refused me to do that reason being he said I ll be writing integration testing which will run on live infrastructure. My question here is, if dev team is writing integration tests which are running with live db connections with real test data, do we need to automate end to end journeys for API or should we write integration tests only ?
4 Answers
While integration testing is an approach wherein separate units are integrated and tested. End to end testing is testing in real scenarios that comprises testing with all integrated hardware/software,database, network and other interfaces simulating real User behaviour. That said, these definitions are context dependent and even if the developers are writing end to end tests it generally doesn't work.
Why it doesn't work:
- Even if developers write test cases for end to end flows, they generally write test cases for happy flows and basic flows.
- Developers have a different mindset than that of QAs.
- End to end application knowledge and impact areas are better known to QA folks in comparison to developers.
- Typically, QA should be having these test cases already written/documented and they just need to execute. The coverage of QA test cases is generally more than developer test cases.
-
But what if integration tests are being run on all the real infra ?– brijCommented Feb 11, 2019 at 4:52
-
Still doesn't thoroughly work! Check the points I've mentioned in the 'Why it doesn't work' section. Thanks! Commented Feb 11, 2019 at 5:11
-
But wouldnt it make more sense for me to write the integration tests then with the dev instead of api end to end tests ?– brijCommented Feb 11, 2019 at 5:13
-
1That could be done but inputs must be taken from someone with a QA mindset. Thanks! Commented Feb 11, 2019 at 5:16
To be honest I am not following what the exact problem you are asking about is.
You can call tests using any name you like, and anyone can develop the test or execute it, obviously as long as they do a good job.
Since you are not planning any revolutions (*) in the team here's what I suggest
- Setup a meeting with the relevant testers and developers, make sure to have a big white boards and a lot of markers
- Draw the system that you are about to test on the board
- Draw circles around parts that needs to be tested together, use different colors if there are overlaps (A, A and B, A and B and C)
- Shortly discuss what needs to be done in each test/circle
- Discuss at length about the proper naming for each kind of test (this is the hardest part !)
- Split the work between testers and developers, avoid unnecessary duplication
- Start working
- Review each others design and work before committing the actual test code
(*) Revolution- what's wrong with giving the developers more responsibility ? "QA mindset" is something we testers invented in the sake of job security. I have worked with excellent "QA minded" developers and some mediocre QA engineers.
Testing is primarily an risk driven activity.
I would ask myself in similar situation' Does this test layer covers all kind of risks which may happen in real-time usage in production'?
If not what other kind of tests I need to add more?
This question frequently arise, especially in microservices, wherein every service is independent and responsible for a specific task(s). So, one may argue that if every scenario is covered at integration level and then there are contract tests, why do we need to write end to end.
- As per test pyramid number of test cases should reside in decreasing order of Unit Tests --> Integration Tests --> End to End.
Read more details about test pyramid here
So, the focus and objective of writing tests at different layer is different. Also, in End to End where we have real user behavior, real network, real test data, end to end is still very crucial.
Also, how the UI is integrated with services is also validated as part of end to end (though we can have UI integration tests as well).
Also, typically it is easier to figure out bugs when thinking in terms of real user scenarios then thinking in terms of code (while writing integration tests).
Lastly, another way of answering thisis, after writing all the integration tests, do I need to validate the functionality once from UI (may be not in details), If yes then we need to write end to end tests.
Hope this answers.