Abstract
Some definitions have been given to tell what software testing really is. It’s not universally acceptable that this is the real definition but it shall be adopted and used for this paper. Software testing can, therefore, be defined as an enquiry into the quality and reliability of software before its adoption and consequently its use. It’s a procedure that allows the potential and more so intended users to make decisions on whether or not they are to adopt the software. This process gives unbiased views on the credibility of the software that is also objective. It covers both the advantages and disadvantages of the concerned software hence allowing the users to make an informed decision. The main aim of software testing is to find errors that may have been done during coding and may have not been detected during the design process. Such errors are to be detected and then corrected for the software to be implemented (Hutcheson, 2003).
Other aims and objectives of software testing is to verify whether the software is up to the requirements of the design and development guide that has standards that have been acceptable universally. It also serves a major purpose of ensuring that the software works as required and stated in the requirement specifications. The process goes to an extra mile to ensure that the software is good and acceptable for use and implementation just as it is, this to mean with the same characteristics it bears before being subjected to any type of change. Lastly, software testing is a process that aims at ensuring the developed and to be implemented software meets the needs of the company and is accepted to the stakeholders.
Introduction
There is no one such stipulated time when the software testing process is to be carried out on the contrary; such a process can be done at any stage of the software development process. This, however, must be done before implementation of the software and possibly its accreditation as being reliable. As it has been happening in the past, software testing as a process is done just after coding has been done and all requirements have been set I place. However, this is not the case in the agile approach to software development. From the above argument it can be stated that the stage at which testing is conducted almost or rather entirely depends on the approach used during design and implementation of the software.
Despite the advancement in technology refining reliability in software, it remains factual that almost all software used at least contains risks. The smartest thing is that most of such risks are not too complicated, and hence can be moderated, or rather eliminated. This is true especially as regards complexities related to the requirement specifications, which presents the most dangerous and hard to deal with risks, if not handled early in the development stages. Commonly made mistakes that subjects most projects to risks of failure or stagnation include having requirements that are not clear; failure to involve the customers and other stakeholders in the requirements specification process; having so many malfunctioning and unrealistic requirements that may never be realized and that are not in line with the goal and an utmost focus of the project (Hoboken, 2012).
For instance, the project manager and other team members should ensure that the specified requirements are as clear as possible; to avoid mistakes that may arise from a failure to understand what is genuinely needed for the project to progress smoothly. All stakeholders should also be involved when defining the requirements, and more especially the potential customers who understand exactly what they require more deeply than the project manager and designers. It’s also pertinent to ensure that the set objectives and specified requirements are realistic and achievable, to avoid spending resources on unrealistic goals that only serve to stretch both the human and other resources and consume so much time, but still remain unachievable (Hutcheson, 2003).
Different models focus on different points of the software. This differs more especially between the waterfall model also referred to as the traditional model and the modern or agile model. With the modern model, the system testing process is vested with the developer before the system is surrendered to external quality testers for final verification. On the other hand, software testing is done after the requirements specification and coding is done and finished.
Defects and Failure
There is a common belief among software users that I seek to dispute; that all software defects are caused at the coding stage. There are loopholes in other development stages that can lead to defects and failures. Key to these is the possibility that most of the software defects are caused by missing gaps during the requirements specification. This leads to many codes being overlooked and omitted by the designers. Most gaps are a result of some specifications that cannot apply in the real world and are thus rendered non-functional as concerns usability, performance and security issues. Defects occur and are caused due to so many processes but the most common is that caused during coding (Hoboken, 2012).
Research shows that a lot is incurred in a bid to detect and correct defects at an advanced stage. Research further reveals that the waterfall model works best with rigid projects, in terms of requirements and design. By saying rigid I mean the projects whose requirements and design are static as originally designed and are entirely unchanging. They also should be designed in a manner that in the event of development, the designers and developers are able to predict and oversee some defects in critical areas and at the same time be able to provide for solutions. Such should be keenly studied and corrected early in time, and more so at the design stage before the actual implementation of the project commences.
Conclusion
One outstanding standard provided for by the waterfall model, and one that must be followed by its users to the latter calls for all preceding phases to be fully completed before the next phase is started. This is so because if bugs are noted and corrected in the early stages where the process is less time consuming and cheaper, the post-processes will be a walk through just as a formality. For instance if a program turns out so difficult to integrate with other systems in the organization at the implementation phase, it is a clear show that the preceding phases were not exploited and perfected quite. This is so since a exemplary project that follows the standards and requirements of the waterfall approach should note such a bug at the design stage. If detected at the design stage, less effort and minimal resources could be applied in making the necessary corrections, as opposed in the implementation phase where the whole project may be phased out. Consequently, the design should be perfected before it is implemented if the end product is to be perfect or as expected (Hutcheson, 2003).
Works Cited
Hutcheson, Marnie L.. Software testing fundamentals methods and metrics. Indianapolis, Ind.: Wiley, 2003. Print.
The IFPUG Guide to IT and Software Measurement. Hoboken: CRC Press, 2012. Print.
