Stubs and Drivers in Automated Software Testing - Assignment Example

Agile Software Development [Institute] In the conventional software processes, testing is the last activity carried out to determine if a program code contains errors or any unexpected behavior. This paper is divided into four sections. The first section of this paper explains what it means to test a software product like a hacker, the second section describes a catastrophic software failure that resulted from lack of testing, the third section presents an argument on the on whether it is the manual or automated testing that is more important and the final section quantifies the economics of use of drivers and stubs in automated software testing. Keywords: software testing, catastrophic failure, stubs, drivers, automated testing Agile Software Development To begin with, the state of many operating environments of software systems is such that any vulnerability is likely to attract exploits (Paul, 2012). This calls for software testers that are focused, diligent and thorough to ensure that the delivered software products do harbor any vulnerability. Just like the software testers, hackers constantly make efforts to have their hacking skills updated. With such an effort, the hackers increase their ability to identify and exploit newer system vulnerabilities. Thus, testing like a hacker means that a software tester assumes the role of a hacker to be better placed in identifying the security hitches of a system. Secondly, hackers have the main intention of doing what other people have not been able to do and this is why they able to discover system vulnerabilities. To counteract such intentions, testers have to think outside the box about the possible system weakness that attackers and hackers can find attractive. Nothing would be as paining as a tester carrying out a vulnerability assessment only for someone to come after him to find something that he failed to identify. Furthermore, the focus, time and effort spent in a testing activity will dictate the success level of a software project (Khurana, 2009). Based on these facts, testing like a hacker means that a software tester in his effort to eliminate system weaknesses might need to go beyond the testing scope specified in the Test Plan. Finally, the exploitation is known to be a mission for circumventing the security controls of a system by launching an exploit. In the software world, exploits are bugs or issues within the software code that allow hackers to execute or launch payloads against the target software system (P, 2013). Payload here refers to a means of having the target machine turned into a puppet and forcing it to make our wishes. The payloads have the danger of altering the intended software functionality and allowing hackers to do other things like opening back doors to the compromised systems. For this reason, testing like a hacker means that the tester makes numerous attempts to circumvent the security controls of the already completed system. Based on their roles in software processes, the testing phase provides the software testers with an opportune time to evade moments of catastrophic system failure, huge failure-based loss, interference with working relationship among employees and any other effect of a software failure. On the other hand, hackers continually focus on exploiting particular weaknesses in the software systems and such weaknesses could be caused by bugs in the program code. This has the implication that testers will often need to behave as hackers to ensure that maximum software security is attained and this is what it means to test a software system like a hacker. An Example of a Catastrophic Software Failure Computer systems are becoming crucial for the effective operation of organizations. Because of the world turning into a more competitive environment, the automated systems are used to aid in attaining efficiency in the operations of an organization. Based on their passion for efficient operations, organizations have been undertaking multiple software projects over the years. A number of the software products from such projects have failed with the possible full system collapse being reported in certain projects. A typical example is the London Ambulance Service (LAS) Computerized Dispatch System whose partial reason for failure was based on the lack of testing. The system was taken live on a Monday dated 26th October 1992 and by this time, there were already 81 known bugs. At that very time, the system featured 4 primary flaws by the time it was taken live; it never functioned well when fed with incomplete data about the status of the ambulances and it never accepted errors that arose in the routinely use of the computer system. Finally, this system ended up storing incident information even when it was never needed thus resulting in memory fill up and failure. Of these problems, the first one started showing up when every participating user started suspecting that things were nearly going wrong. There were many duplicate calls made since the system was losing the emergency calls that were accepted making several distraught callers to be kept waiting for up to 30 minutes in the call-queuing system. The system caused additional delays. It also failed in recognizing certain routes and roads, forcing the drivers to revert back to use of maps in navigating their way and calling for the dispatch of ambulances. The system errors resulted in two ambulances turning up simultaneously or late arrival of ambulances. By the next day afternoon, the condition worsened and the system had to be shut down so the dispatchers resorted to a combination of the computerized call talking methods and manual location of the ambulances. This resolution brought about death of individuals because of late arrival of ambulances, financial losses as well as the resignation of employees of LAS. In their report Adamu, Alkazmi, Alsufyani, Shaigy, Chapman, Chappel state that as per the directive of the LAS management, the contractors had just six months to have the entire project complete and the contract cost was also to be restricted (2008). The reduced project time period had the implication that there would be a limited time to perform all the software processes like testing, whereas the cost restrictions would mean that testing would be carried out by the developers since the hiring of independent testers would push the project budget and this would be against the wish of LAS management. Although functional testing was carried out for different components, integration testing intended to confirm the system’s interoperability was never performed. So there was no effort in testing the manner of reaction of the system to different circumstances like a growing number of incident reporting and vehicle location problems. Because the software lacked thorough test, a number of avoidable errors came into picture following the system’s implementation and all these ought to have been identified then corrected during the testing stage. An Argument on Automated and Manual Software Testing In testing a software product for errors or any unexpected behavior, a manual or automated method can be used. Manual software testing involves carrying out a test exercise without the use of automated tools or scripts. On the other hand, automated testing is one in which the tester writes scripts, then uses other software in testing the. This section of the paper presents an argument on why an automated method of software testing is more important than the manual method in the context of agile software development. First of all, the ultimate goal of every software project in agile based development is the delivery of a working piece of software product to clients early and constantly with a rapid releasing cycle. This poses a challenge for the testers for the reason that the need for rapid release cycles will call for putting fixed deadlines for testing, and this does not give maximum time for testing in case the defects found exceed the estimated number. Automated method of software testing provides a solution to this problem considering that it is faster than the manual method. Moreover, adoption of this method of testing will ensure that the fixed deadlines are met. Secondly, agile software development demands that the changing user requirements are welcomed even during the later phases of software development except for the time of delivery of the software product. The constantly changing requirements will in some way imply a continued to change the software program codes together with the associated documentation. Again, agile requires that developers first write the test cases prior to the codes so that coding is done as per the already written test cases. The changed program codes must be subjected to test for errors just like the initial code. Using the automated method of testing, it will be possible to easily carry out the rerun tests compared to the manual method where everything has to be done manually. Taking these changes into account, the automated software testing method seems to be the best approach in case the delivery of a software product is to be done within the predetermined deadlines. Finally, in spite of the need for more resources and time to be able to reap the benefits at later dates, the cost of automated software test remains low on long term tests, unlike manual software testing, which turns to be costly and more time consuming if the use of the two approaches is meant for longer periods. For this reason, automated test turns ideal for situations involving constant change in user requirements and this characteristic is common for many software projects. In view of the long term cost benefits, the convenience with which the changing user requirements can be managed together with the minimized testing time that automated test brings about, this test method remains to be more important than the manual approach of software testing. Economics of Stubs and Drivers in Automated Software Testing Programmers are normally under cost or time constraints and there is a possibility of perceiving quality tasks as blockers to delivery or a costly evil. However, past experiences with varied software projects recommend that investment in the top down efforts on software quality increases the possibilities of delivering through evasion of rework and reducing the ultimate cost plus the project’s delivery time. Many software applications feature units where the output of a single unit forms the input of another unit. Because of the existence of such interfaces, it proves difficult carrying out test exercises independently, hence the need for stubs and drivers. This section of the paper attempts to quantify the economics of use of stubs and drivers in automated software tests. Because of the ability of stubs to simulate the “missing” components, the stubs can help ensure that the delivery of a software product is done within the stipulated time because testing and program coding can be done concurrently. Again the use of stubs in the top-down approaches of system integration provides an avenue for the main flaws in system design to be detected in time. This can help avoid re-work and hence the maintenance the cost of a given software after deployment. This poses the risk of certain hitches being camouflaged during testing and discovery of such hitches after implementation would call for a re-work which can strain the project budget. Moreover, the use of stubs can create a notion among clients that the software coding and testing can precede the design activities. The clients can therefore develop have a misguided thought about the system being ready and they might not be willing to give more time for the delivery of a software product. For this reason the final software product delivered can be of low quality in case the developers decide to yield to the pressure from clients. It is tricky getting third parties to involve in the stub or drive related tests. The third parties will charge a higher amount upon realizing the test exercise involves the use of stubs so the developers end up by doing the same themselves. The implication of this is twofold. First, the high charges by the third parties will hike the software development cost and possibly strain the project’s preplanned budget. Secondly, developers testing their own codes can reduce the chances of bug identification and correction, a state that might call for re-work at any later time. Rework increases maintenance cost and so will compromise on the economic perspective of the affected software. Although the independent testing of individual components during the use of drivers increases the likelihood of more robust systems, there is a risk of the software product being delivered without completion of the test exercise because the top level components are the last to be tested. Lack of test for the top-level components can potentially cause system failure and result in huge financial losses to an affected organization. While using drives, the method used in combination of components, one at a time, can result into the slow testing requiring large amount of time. The overall time needed for the entire testing exercise be very long and possibly interfere with the predetermined delivery schedule. References Hambling, M. (2010). Software Testing. London: British Computer Society. Khurana, R. (2009). Software Engineering: Principles and Practices. Vikas Publishing House. Mukhtar Adamu, Abdulhameed Alkazmi, Abdulmajeed Alsufyani, Bedour Al Shaigy, Dominic Chapman, Julian Chappel. London Ambulance Service Software Failure. P, E. (2013). The Basics of Hacking and Penetration Testing. Amsterdan: Syngress. Paul, M. (2012). The Seven Qualities of a Highly Secure Software. CRC Press. Read More