You made it through, welcome to the juicy part!
Short-term test planning
Interpreting the short-term Diagram
As established in previous sections, all testing activities are fundamentally based on requirements—whether they are pre-existing, new, modified, or obsolete.
The section below this illustrates the available verification methodologies, which can be either empirical or theoretical.
An effective testing strategy incorporates a suitable level of automated checks while reserving adequate time for genuine exploratory testing. Achieving this balance is contingent upon meticulous planning, which ensures that sufficient time is allocated to high-value testing activities.
It's important to aim for the TOTALL REPORT, but what's difficult in testing is the moment you want to be able to present such a totall test report. Talk about this with your team members! Plan it.
Which rules are going to be tested more, and which rules are going to be tested less is based on RISK
What is the part that we are focusing on?
What are the real risks of it?
How are we going to test that?
Imperical knowledge
Theorectical knowledge (from the books)
What are we going to automate?
E2E/Ui
Message layer (api)
unit layer
Long-term test planning (stay tuned, under construction)
Interpreting the long-term Diagram
In contrast to short-term test planning, long-term planning is much more concerned with the functionalities that will be introduced in the future. For example, if an application is going to be used not only on computers but also on mobile devices, a different type of testing tool might need to be deployed.
Suppose a System Under Test will in the future communicate with an external system that is also under internal management, and they have a high dependency on each other... then the collaboration between these two systems must also be included in the testing. Long-term planning therefore takes a holistic view of the overall testing landscape. It monitors changes in rules across different systems and spanning multiple systems.
