New work routines, new mates, new technologies …
I’ve come from a chapter were I was the responsible for test automation, test specification, functional test, review specifications… and so on.
Now, I have a spectacular team.
We refine stories, the developers code solution and implement unit and integration test (I review and give my suggestion of scenarios and some improvements).
Our product rely on Kafka messages and some http request as inputs, so, who is better equipped to implement automation that the developers with my help?
After this point I join all the microversives and test the flow…
Now what?
What should I do?
I don’t see that a new automation layer will bring value to our boundary - I implemented a simple Karate solution to test http request and response from our system, but kafka? How could I give value to the test already implemented by the team ?
If I understand correctly, the solution has a suite of tests created by developers with feedback and review from testers. There is another layer to evaluate Kafka transactions. Based on your description, there is no UI which makes sense if there is just data going between endpoints.
It sounds like you are asking if there should be more tests around Kafka. My answer would be no since Kafka is a vendor solution.
In my opinion, implementations like the solution you describe (e.g., APIs that provide for data transactions between endpoints) should be evaluated mostly through unit tests with testers providing scenario suggestions and feedback (just as you did).
The next level (I might call it an integration level) evaluates configurations, connectivity, and security. I would not explore a lot of behavior if the unit tests already do that (I presume they do). It might be that the integration tests execute transactions just to meet the information objective (configuration, connectivity, security) but the behavioral component is minimal if not ignored.
Yes, I’m joining all the microservices and run a automation test suits that goes e2e between most of the microservices, testing configuration, and at the end provide a demo to product owner - well, is a little bit difficult to show the product because all the actions goes behind the houd.
In the future we will have a UI… on that time I can growth automation to include UI, but for now that stimulation from the UI is being done with API testing.
The production result have been good, no major issue detected… Besides some performance issues that we tackling now, creating a performance environment for our product.
But sometimes I think that there is nothing more I can do and I fell a little lost and with that feeling " my kids don’t need me anymore, maybe is time to go for another adventure"
I think you are on the right track. The UI testing could be minimal since the bulk of the behavior is evaluated in the API tests. If the UI merely reflects the information in a database, a few smoke tests could suffice. If there is some transformation between the database and the presentation of the data, that could be added to tests beneath the UI.
Enjoy the time you have and perhaps dream of possibilities!