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 tools and or a.i.)
2. The understanding that assumes that one realizes that finding bugs can happen at different layers, from hardware to the acceptance layer.
3. The understanding that there is a test pyramid, how and why it is put together and why this layering exists.
4. The understanding that whatever project approach you take is never 100% perfect because in everything you do, you always leave something else. Waterfall is neither perfect nor Agile.
5. 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.
6. The understanding that assumes that these tools can be used on both the functional side and the code side. (Not all bugs manifest themselves in code, sometimes they can only be seen through a certain way of using the website or application).
7. The doctrine that assumes that one knows what entry or exit criteria are. When has enough testing been done? That there are things (documents or agreements) that describe when sufficient testing has been done. It may also contain a sign-off.
8. Software testing should never be neglected. Developers are not more important than testers to give an example. As a software tester on a project, you must also ensure that this does not happen.
9. Software testers work together and form 1 front to the outside world, 1 voice. They have regular consultations but will contradict each other as little as possible once an agreement has been reached. This is a joint responsibility.
10. The concept that software testing is so broad that there must always be room to grow in a niche or corner, for example gaining more knowledge of performance testing or security testing. With the use or introduction of the Break methodology,
the condition is that testers in particular understand this among themselves.
11. It always starts from the basic principle that software testing is a super hard thing at its core, it never makes the field seem easier than it is.
12. Break assumes that adherence to a drawn up test policy within a project or organization is at least as important as drawing it up.
13. Social skills or soft skills are context dependent. But a basic knowledge of certain subjects such as argumentation or critical thinking is considered to be present.
14. Break software testing underlines the functioning of the left and right sides of the human brain and that they differ from each other.
In the field of software testing, you need proper development of both. Both creative and analytical.
Since an apple never cuts exactly in half and a person can never have 51% on both sides,
Break also assumes that team members within the test team can complement or reinforce each other if necessary.
15. Break software testing embraces the usage of *BlockChain in the software testing process.
16. There may be absolutely no ambiguity of any kind in the designation of Priority and Severity of items.
There is a strict systematic approach to this and this approach is written in a document 'test policy' which is shared with all teams within the company.
