Before any program ships, software developers need to invest substantial time in quality assurance. Quality assurance is the aspect of software design that revolves around taking something presumed to be working just fine and hammering away using quality techniques to try and break the program. Only after a thorough and exhaustive search can quality assurance individuals release their approval.
In the world of hardware design and electronics, quality assurance is indicated by little white dot stickers that read “QA by:” and are usually stamped with either initials or an associate id number. A failure to conduct thorough quality assurance in hardware projects can ultimately cost lives from glaring defects that cause overheating or strangulation hazards.
Quality software design
While you may think my software isn’t going to choke any babies, you probably are right. However, this doesn’t mean that bad software can’t cost lives. If NASA used software to drive shuttles that failed to identify and properly regulate fuel flow, well…guess what would happen? Imagine if all the sudden you deposited your paycheck into an online bank and the quality assurance guys didn’t bother to test basic mathematic functions.
You would quickly find that the lack of quality assurance would bounce your checkbook if for every 1000 you added, the driving software subtracted. These things happen. And it’s the job of engineers to make products, technicians to fix them, and quality assurance to find them before someone else does. Similarly, in software, the programmers have a role that generally provides for at least the making and repair of their products.
However, for all but the smallest of projects, quality assurance is best handled by outside individuals.
The reasoning behind using quality assurance software is to look at programs from a variety of angles thus eliminating a lot of the tunnel vision that occurs in programmers. While a programmer is usually very good at fixing changes that a compiler will fail to work on, they generally subconsciously feed only appropriate sequences of commands at software and thus make poor quality assurance.
This doesn’t mean that programmers are bad at quality assurance. Instead, the assumption that programmers are usually poor at quality assurance means that there is a tendency to overlook glitches unless a willfully, consciously, and logical approach is adopted to provide quality assurance. In fact, when performing quality assurance on other people’s works, programmers can be the absolute best quality assurance professionals available.
This is because not only do they understand what tends to break from past experience, programmers also know enough about the fundamental aspects of programming to provide valuable speculations in quality assurance. Simply put, programmers know how programs work, and can effectively write instructions on how to reproduce a glitch or bug in a quality assurance report.
Quality assurance software
What kinds of problems do quality assurance people catch before release? A thorough approach to quality assurance will test all available options. For PHP based applications, quality assurance people may write or manually step through all possible permutations of form input drop downs. For games, a quality assurance person may level all the way to the top, walk back to the beginning of the game, and begin slamming their character into walls all over again.
For all applications, quality assurance people generally catch the majority of overflow errors and glaring mathematic problems – but even the best quality assurance teams may end up missing subtle bugs like the math bug that was found in Excel 2007.
Only after proving your software actually works through quality assurance teams, going through and making corrective changes and then repeating the quality assurance to programmer dance until there simply are no more problems that affect your software product will you know that your software program is finally ready to ship.
Shipping prior to quality assurance completion can prove disastrous for any software developer regardless of disclaimers of limited liability due to individual regulating authorities which may have policies prohibiting the release of liability.
Comentaris
Publica un comentari a l'entrada