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
which pyramid is applicable in your context??
layers, even more layers!
What's important is to understand that: testing can (and sometimes should) be done "everywhere".
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.
Agree/disagree? ->forum