I was going through some old files today and found an article he had written February 7, 2002, shortly after becoming director of training for Microsoft test. While a bit dated, reflecting many thoughts I keep to this day about the role and challenges of software testing.
Software testing was once an afterthought in commercial software communities. Product managers and even novice developers looked at the software testing as a discipline out of focus that almost anyone could perform. Some popular books on the topic of software testing to include words such as art and art in their titles, which may have led some people in the software industry to the conclusion that quality testing was not a real discipline software engineering. By contrast, the actual test is a software engineering discipline and a critical component of the development cycle software to help improve software quality and reliability through the identification of defects, error prevention, observation and reporting. Essentially, the evidence provides information for rational risk analysis and analytical.
A philosophical view of proof-
From the beginning of time, humans have participated in the various forms of evidence to question the designs of tools and processes. This constant re-evaluation aimed at improving the quality and significant gains in effectiveness and efficiency. But the test based purely on trial and error is laborious and slow. In 1962, the philosopher Sir Karl Popper came the growth of knowledge in a more scientific process. In his book Conjectures and Refutations, Popper's hypothesis that science progresses by reducing falsehood. Essentially, the progress is achieved through the formulation of theories (conjecture - reasoning that involves the formation of conclusions from incomplete data) into testable hypotheses (refutation - any document that helps to establish the falsity of something).
Testing as a science-
The software is similar to a scientific hypothesis, both are inherently fallible. The basic framework of the software debugging process is analogous to that trial and error, a practice that advances scientific hypotheses. Conjecture C computer software is merely technical. Test engineers attempt to refute the hypothesis of perfect software through rigorous testing mostly designed to prove that the existing defects (forgery). The falsification process contrasts with data-driven approaches such as induction and deduction, which seek to justify their validity based on the repetition of facts. Approaches to justify any attempt to support the claims through confirmation. Confirmation of the effort, especially to validate the error-free from the uncertainty by using specific data that demonstrates the proper functionality. This approach clearly demonstrates that only the software functions correctly under certain conditions, it does not prove that the software is error free.
The establishment of confidence in the software-
The best way to build confidence in the reliability of software is not just to prove that a program of works within the limits of the specification of the product but also to expose potential flaws in design or functionality of the software. However, any conjecture can endure countless hours of extensive testing and still contains errors. Refutation cannot guarantee the perfect software, because there are many hypotheses, just to prove in a reasonable amount of time. William Hazel explains the futility of exhaustive testing and the limitations of rebuttal in The Complete Guide to Software Testing. He writes, "there are more test cases in a program with 70 branches there are teaspoons of water in the Pacific Ocean." When a tester successfully refutes the software (you find an error), reported the defect. The developer (hopefully) solve the problem and assume that the software works correctly and repeat the process of refutation. Although tests can not demonstrate that the software is without errors, error detection highlights the problems, which ultimately results in high reliability and software quality, or at least offers a crucial perspective for analysis and risk mitigation.
What really testers-
When we ask for test engineers describe their work, most say, "Breaking software. Maybe that's why some people mistakenly view the role of the tester as a destructive process. However, testers do not really "break" software. Testers simply exposing the errors for it to refute or falsify the hypothesis that the software is flawless through the test results observed structured, logical deduction, and experiments. However, the search for errors is only one aspect of software testing. Test engineers add tremendous value in the process of development through software validation, error detection in software, providing developers with information to prevent errors in reporting to management for assessing risk and acting as an advocate for clients.
0 comments:
Post a Comment