𝐓𝐞𝐬𝐭 𝐏𝐫𝐨𝐜𝐞𝐬𝐬 𝐌𝐚𝐭𝐮𝐫𝐢𝐭𝐲 𝐌𝐨𝐝𝐞𝐥
Testing is not stagnated activity,
the context, definition, objective of testing is dynamic in nature. It’s vital
to understand this which can be seen in Boris Beizer’s Test Maturity Model which
describes five levels of testing maturity.
𝐋𝐞𝐯𝐞𝐥 0 : 𝑻𝒆𝒔𝒕𝒊𝒏𝒈 = 𝑫𝒆𝒃𝒖𝒈𝒈𝒊𝒏𝒈
"There's no difference between
testing and debugging. Other than in support of debugging, testing has no
purpose." Defects may be stumbled upon but there is no formalized effort
to find them.
𝐋𝐞𝐯𝐞𝐥 1: 𝑷𝒖𝒓𝒑𝒐𝒔𝒆 𝒐𝒇 𝑻𝒆𝒔𝒕𝒊𝒏𝒈: 𝒔𝒉𝒐𝒘 𝒕𝒉𝒂𝒕 𝒔𝒐𝒇𝒕𝒘𝒂𝒓𝒆 𝒘𝒐𝒓𝒌𝒔
"The purpose of testing is to
show that software works." This approach, which starts with the premise
that the software is (basically) correct, may blind us to discovering defects.
𝐋𝐞𝐯𝐞𝐥 2: 𝑷𝒖𝒓𝒑𝒐𝒔𝒆 𝒐𝒇 𝑻𝒆𝒔𝒕𝒊𝒏𝒈: 𝒔𝒉𝒐𝒘 𝒕𝒉𝒂𝒕 𝒔𝒐𝒇𝒕𝒘𝒂𝒓𝒆 𝒅𝒐𝒆𝒔 𝒏𝒐𝒕 𝒘𝒐𝒓𝒌
"The purpose of testing is to
show that the software doesn't work." This is a very different mindset. It
assumes the software doesn't work and challenges the tester to find its
defects. With this approach, we will consciously select test cases that
evaluate the system in its nooks and crannies, at its boundaries, and near its
edges, using diabolically constructed test cases.
𝐋𝐞𝐯𝐞𝐥 3: 𝑷𝒖𝒓𝒑𝒐𝒔𝒆 𝒐𝒇 𝒕𝒆𝒔𝒕𝒊𝒏𝒈: 𝒓𝒆𝒅𝒖𝒄𝒆 𝒓𝒊𝒔𝒌 𝒅𝒖𝒆 𝒕𝒐 𝒔𝒐𝒇𝒕𝒘𝒂𝒓𝒆
"The purpose of testing is not
to prove anything, but to reduce the perceived risk of not working to an
acceptable value." To do so would require us to test every possible valid
combination of input data and every possible invalid combination of input data.
Our goals are to understand the quality of the software in terms of its
defects, to furnish the programmers with information about the software's
deficiencies, and to provide management with an evaluation of the negative
impact on our organization if we shipped this system to customers in its
present state.
𝐋𝐞𝐯𝐞𝐥 4: 𝑻𝒆𝒔𝒕𝒊𝒏𝒈 𝒊𝒔 𝒎𝒆𝒏𝒕𝒂𝒍 𝒅𝒊𝒔𝒄𝒊𝒑𝒍𝒊𝒏𝒆 𝒕𝒐 𝒅𝒆𝒗𝒆𝒍𝒐𝒑 𝒉𝒊𝒈𝒉-𝒒𝒖𝒂𝒍𝒊𝒕𝒚 𝒔𝒐𝒇𝒕𝒘𝒂𝒓𝒆
"Testing is not an act. It is a
mental discipline that results in low-risk software without much testing
effort." At this maturity level we focus on making software more testable
from its inception. This includes reviews and inspections of its requirements,
design, and code. In addition, it means writing code that incorporates
facilities the tester can easily use to interrogate it while it is executing.
Further, it means writing code that is self-diagnosing, that reports errors
rather than requiring testers to discover them
𝘌𝘹𝘤𝘦𝘳𝘱𝘵
𝘧𝘳𝘰𝘮
𝘵𝘩𝘦
𝘣𝘰𝘰𝘬
"𝘈
𝘗𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳'𝘴 𝘎𝘶𝘪𝘥𝘦
𝘵𝘰
𝘚𝘰𝘧𝘵𝘸𝘢𝘳𝘦
𝘛𝘦𝘴𝘵
𝘋𝘦𝘴𝘪𝘨𝘯"
𝘣𝘺
𝘓𝘦𝘦
𝘊𝘰𝘱𝘦𝘭𝘢𝘯𝘥