The break software testing methodology is a new modern software test methodology.
It does not rule out anything currently existing like ISTQB, ISEB or TMap, you can use it whenever and how much you like.
It is a layer on top of the currently known processes like Tmmi and Cmmi. The BREAK software testing methodology gives direction to your test process.
Break software testing is in favor of the usage of Artificial Intelligence used in software testing.
Break software testing is in favor of using Agile as the basis, however, it is developing its own Agile method under the Agile umbrella.
This Agile method is aiming to get more attention to software testing in general within the Agile process.
More attention, more control, more funding for software testing.
What are the main points that the Break methodology intents:
1. The understanding that assumes that people realize that there is a human side to software testing, and a computer side (in the form of (test)tools, a.i., etc)
human side of software testing? what do you mean? Well... in the basis a human is always "the software tester". But companies want to check fast for certain functionalities being okay and there comes automation into the picture. Automated checking. However false positives and such lay on the lure... so whatever a PC states, PASS / Not Okay... there's always need for a human to do the actual verification. Whether it's a test tool an a.i. or even...a future thing, the principle stays the same. an interesting Youtube.
2. The understanding that assumes that one realizes that finding bugs can happen at different layers, from hardware to the acceptance layer.
Different layers, what do you mean? If your energy company is down and a whole city block is without power. Does your System Under Test work? Well yeah maybe if you have a generator but in general 'no' If the battery of your laptop is empty, can you test? If the hardware that your System Under Test needs is not functioning, can you test? And so on and so forth.... layers
3. The understanding that there is a test pyramid, how and why it is put together and why this layering exists.
- Unit, Integration, E2E
- or
- Unit, Integration, Component, E2E
4. There may be absolutely no ambiguity of any kind in the designation of Priority and Severity...
- Priority: High, Medium and Low
- and also
- Severity: High, Medium and Low?
Severity = Impact on the system or users if the requirement is not implemented (e.g., critical vs. nice-to-have).
Severity describes the consequence or damage caused by omission or failure, not the business ordering.
Priority = The order in which the business wants the requirement to be addressed (e.g., “we need this for release X”).
Priority reflects stakeholder scheduling, deadlines and business value.
Use both — and keep their terms distinct.
Suggested severity scale (examples): Critical / Major / Minor / Cosmetic.
Suggested priority scale (examples): P0 (release-blocker) / P1 (high — next sprint) / P2 (medium) / P3 (low/backlog).
Rule of thumb: Never reuse the same labels for both fields. Severity = impact; Priority = business order.
6. The understanding that assumes that ISTQB, ISEB or TMap test methods and/or techniques are only tools. Tools in the toolbox.
Experience (also empirical) is at least as important.
7. The understanding that assumes that these tools can be used on both the functional side and the code side...
8. The doctrine that assumes that one knows what entry or exit criteria are. When has enough testing been done?...
9. Software testing should never be neglected. If it is skipped, risks grow faster than the project can handle.
10. Software testers work together and form 1 front, regardless of background, method, or tooling preference.
11. The concept that software testing is so broad that there must always be room to grow, specialize, and innovate.
12. It always starts from the basic principle that software testing is a super hard thing at its core, even if tools or automation sometimes make it look easy.
13. Break assumes that adherence to a drawn up test policy, is just as important as drawing it up. Policy without execution is meaningless.
14. Social skills or soft skills are context dependent, but they always determine how effective a tester can be in a team.
15. Break software testing underlines the functioning of the left and right sides of the human brain...
16. Break software testing embraces the usage of *BlockChain in the software testing process, where transparency and trust are essential.
17. NEW! When doing software testing you must attain a point of view sometimes — step back and evaluate from a distance to see risks and opportunities more clearly.
18. NEW! When TOGAF is applied, Break Software Testing fits as an element in the wider architecture framework, providing testing doctrine across layers.
19. NEW! If (Agile) Scrum is practiced, Break Software Testing emphasizes that testing must be deeply integrated into the ceremonies, artifacts, and the definition of done — not treated as a side activity.
20. NEW! The understanding that assumes that digital sovereignty, data location, and secure ownership of information are essential in software testing — testers must be aware of where data resides, who can access it, and under which regulations it falls.
Agree/disagree? ->forum