Test culture is not only about writing automated tests.
Test culture is not only about TDD - Test Driven Development.
Test culture is not about hiring QA engineers.
Test culture ensures your code work as expected.
Why automated tests are not enough?
You can't catch every problem/issue with automated tests. Business logic and UI/UX need to be validated by a human.
If the developer does not know the context they are building, the automated tests won't cover real use case scenarios.
Why manual tests are not enough?
Manual tests become unfeasible as your system grows.
The complexity and the number of possible test scenarios grow exponentially with each new feature.
Building a Test Culture
If I had to choose one thing to start a Test culture, it would be to write a Test Plan.
What is a Test Plan?
A Test Plan is a plan with many test scenarios that describes how you validate if your feature/improvement/bug is correct.
The Test Plan helps you visualize what is the expected behavior of a system after it is implemented.
To write a Test Plan, you need to know the business logic and gather enough context about the feature. You need to know what you are building.
Test Plan Driven Development
My proposal is to write the Test Plan before writing any software code.
The Test Plan will make you think deeply about what you are building, and how to structure the system and the code.
The developer writes the Test Plan that can be reviewed by their team to find missing test cases.
As you develop your software incrementally, you can check what test cases are already covered with automated tests and ready to be tested manually.
You still need to test manually to validate if the business logic makes sense, and that UI and UX are good. Not every "bug" can be caught with automated tests.
It also gives visibility into the progress of the task.
Test Plan Driven Development vs TDD
Using only TDD is not enough to achieve high quality. It is very common to find code that has a lot of tests but does not test the important use cases.
If you do not plan and think about the test scenarios, you will forget to cover some important ones.
Test Plan Example
We are building functionality that enables users to filter charges by a date range. It looks like a simple feature, but it can be hard to get it right because of the timezone. Here is the test plan with an incomplete set of test scenarios:
- if you are filtering day 2022-09-19 Brazil timezone
- it should not show charges on 2022-09-18 - Brazil timezone
- it should not show charges on 2022-09-20 - Brazil timezone
- it should show all charges from 2022-09-19 00:00 - 2022-09-19 23:59
Can you add a few more test scenarios?
Conclusion
Bringing the Test Plan process inside your software development can give you a lot of benefits. It will make sure that developers know what they are building.
Further, you will build the right thing with fewer bugs.
Finally, it gives visibility of what test scenarios are missing to deploy to production
If you wanna work with us, we are hiring!
Top comments (3)
True. But how to get developers onboard with business logic and sufficient context?
IMHO, this shows the importance of assembling project squads that share the same amount of information. In most cases, developers (truth to be told, not only developers) are only assigned to specific tasks without the proper care to ascertain whether or not they know the full details of what they are working on. It is a rather thin line to decide whether or not the best approach would be to involve the whole team in strategic meetings, since this could be unproductive (or even harmful).
My guess is that it would be important to match TPDD with a well designed project development process.
Cheers.
We have a strong written culture at Woovi.
If you want to get enough business logic and context, you can just read our internal documentation.
Strategic decisions can be made using writing RFCs
You can read more about it here blog.pragmaticengineer.com/scaling...
That was a nice read 🙂 Thank you