Essay: Software testing and software testing processes

Objectives
The objective of this chapter is to introduce software testing as well as the software testing processes. On completion of this chapter, the reader will:
• understand the stages of testing, from development testing to acceptance testing by system Users.
• introduce the methods which helps choose from several test cases that are geared to learning program faults.
• understand test-first development, in which the design test is before writing code and run these tests automatically.
• know the significant modifications between system, component and release testing and be aware of user testing processes and techniques.
Figure 21
4.1.2 An input-output model of program testing
• Validation: Is the right product being built?
• Verification: Is the product being built right?
Verification and validation processes are concerned about ensuring the developed software meets its requirement and its able to deliver the full functionality estimated by the people paying for the software. These checking processes start as soon as requirements become available and this continues through all stages involved in the development process. The aim of verification is to check that the software meets its functional and non-functional requirements. Validation, however, is a more general process. The aim of validation is to ensure that the software meets the user’s expectations. It goes beyond testing with the description to demonstrating that the software does what is required by the customers. Requirements conditions do not always redirect the real wishes or needs of system users.
The ultimate goal of verification and validation developments is to establish assurance that the software system is ‘fit for purpose’. Meaning the system must be good enough for its proposed use. The system’s purpose depends on the level of required confidence, the expectations of the system users as well as the existing promoting environment for the system
4.1.3 Inspections and testing
Figure 22
Both the verification and validation process involves a general software inspections and analyses. Inspections and analyses examines the system requirements, software tools, UML modelling, frame work and prototype UX as well as the code interface.
The above shows software inspections and testing support V & V at different stages in the software process. The arrows show the phases in the process where the methods are used. Inspections usually emphasis on the source code of a system and the representation of the software, such as its requirements, can be reviewed. A system inspection allows the use of information of the system, as well as its application domain and the programming language to determine faults.
4.1.4 A model of the software testing process
Figure 23
Usually, the development of a commercial software system undergoes three stages of testing:
1. Development testing: This stage requires a system testing during development to discover bugs and defects. The System programmers are possibly involved in the testing process.
2. Release testing: This stage requires a whole different test which involves another testing team completing the version of the system before unrestricted to users. The aim of this test is to check that the organisation meets the requirements of system stakeholders.
3. User testing: This stage requires the users of a system test the system in own environment. For software products, the ‘user’ might be a core marketing group who choose if the software can be promoted, unrestricted, and sold.
Acceptance testing is a type of user testing which requires practice, the testing development generally involves a combination of manual and automated testing. In manual testing, a program is being run by a tester with some test data and it involves comparing the results to their potentials. The test it to note and report inconsistencies to the program developers. In automated testing, the tests are programmed in a database that runs anytime the under developed system is to be tested. This form of testing is usually faster than the manual testing specifically when it involves regression testing—re-running previous tests to ensure the changes to the program have not hosted new bugs. The use of automated testing has improved significantly over the past few years. However, testing can’t be entirely automated as automated tests are known to only check that a programme follows the right instruction. It is nearly impossible to use automated testing to test systems that depend on physical looks (e.g., a graphical user interface), or to test that a program does not have unwanted side effects.
4.2 Development testing
This phase involves the testing activities being carried out by the developing team. The software tester who is usually the programmer who developed the software, although this varies depending on the case. Some development processes use programmer/tester pairs (Cusamano and Selby, 1998)
Debugging
This process involves fixing errors and problems discovered during testing. The use of information from the program tests allows the debuggers use their data programming language and the proposed outcome of the test locates and repairs the program error. This process is usually supported by interactive debugging tools which provides extra data about the program execution.
Programmer generally have an associated tester who develops tests and contributes to the testing process. In the case of critical systems, a recognised process may be used alongside a separate testing group within the development team. They are liable for different developing tests and also the maintenance of detailed records of test results. Testing may be carried out at three levels of granularity during development:
1. Unit testing: This phase involves the testing of individual program units or object classes. It also emphasis on testing the functionality of objects or methods.
2. Component testing: This phase involves testing several individual units integrated to create composite components. It also emphasis on testing component interfaces.
3. System testing: This phase involves testing some or all of the components in a system which are fully integrated and the system is tested completely. System testing emphasis on testing component interactions.
Development testing is mainly a defect testing process in which the aim of testing is to discover software bugs. It is therefore enclosed with debugging— the process of discovering problems with the code and also changing the program to fix these problems.
4.2.1 Unit testing
This process involves testing program components, such as methods or object classes. Individual functions are the modest type of component. Tests should be named to these procedures with different input parameters.
During object classes testing, the test should be designed to run report of all the features of the object. This allows features like:
• Testing all operations connected to the object;
• locating and checking the value of all attributes connected to the object;
• setting the object into all promising states. This means simulating all events that cause a state change.
It’s always best to change the testing to automated testing. This testing allows automation framework (such as JUnit) to write and run program tests. Unit testing frameworks run generic test classes that allows extension to creating specific test cases. They run all of the tests that has been executed and reported on the success or failure of the tests. The whole test suite can repeatedly be run in a few seconds so execution is made possible for all the tests every time a change is made to the program.
An automated test has three phases:
1. Setup phase: This phases initializes the system with the test case, specifically the inputs and expected outputs.
2. Call phase: This phase allows you call the object or method to be tested.
3. Assertion phase: This phase allows the comparison of results, i.e. comparison of the call to the estimated result. When the assertion value evaluates to true, the test is successful; if false, then it has failed.
Occasionally the object tested has dependences on other objects that may not have been written or slows down the testing process if used. For example, if your object calls a database, this may comprise a slow setup process before use. In similar cases, mock objects can be introduced. Mock objects are objects with same interface as well as the external objects being used to simulate its function. So, a mock object simulating a database might contain a few data items that’s organized in an array. They can then be accessed quickly without the outlays of calling a database and accessing disks. Likewise, mock objects can also be used to simulate abnormal operation or rare events.
4.2.2 Choosing unit test cases
The mobile app for learning C# was designed to meet some requirements. The test has been done and all requirement met in the development of mobile app for learning has been successful by using an effective unit test cases as such:
• The test shows that the project has met its requirements.
• Knowing the problems of the project.
The testing is done based on two kinds of testing cases. The first testing should be able to show the operation of a project and should show the actual work done based on the requirements tested on.The second testing should be done based on testing of the problems of where the project failed to meet its requirements.
The effective unit test is done based on some strategies that can be effective in choosing a test cases.
Partition testing: this identify sets of inputs that have the set features and that should be processed in the same way.
Guideline-based testing: this is used to select test cases. These guidelines show the earlier knowledge of errors that developer make when building the project.
4.2.3 Module testing
The Software modules are complex and is built up of numerous interacting objects such as the reconfiguration module which includes objects that deal with the reconfiguration and the functionality of the object through the defined module interface. Testing composite modules should now focus on displaying the module interface requirement.
Interface testing
Figure 24
The memory interface are interfaces in which the blocks of memory is shared between modules. Information is placed in the memory by a subsystem and regained from there by a different sub-system.
Procedural interfaces: This is an interfaces in which one module encapsulates of procedures that can be called by other components. The Objects and reusable modules have this form of interface.
Message passing interfaces: This is interfaces in which one module desires a service from another existing component by passing a message to it. A return message includes the results of executing service. Some object-oriented systems have this form of interface, the Interface errors are one of the error in complex systems (Lutz, 1993). These errors fall into three classes:
• Interface misuse error: The calling module calls other module and makes an error in the use of its interface. This type of error is common with parameter interfaces, where parameters may be of the wrong type of parameters.
• Interface misunderstanding error: The calling module misunderstands the requirement of the interface of the called module and gives an expectation of its behaviour. The called module does not behave as projected which then causes unanticipated behaviour in the calling module.
• Timing errors: the timing errors are errors that happen in real-time systems that use a shared memory. The producer of data and the consumer of data may function at different level.
Testing the interface is difficult due to some interface faults that may be show uncommon situations. The calling object may accept that the line is implemented as a countless information structure and may not check for line overflow when an item is entered. This situation can only be identified during testing by building a test cases that makes the line overflow. Which causes the overflow to corrupt the object behaviour in some detectable way and other problem can occur between the faults of interactions in different modules. The Faults in one object can be detected when other object behaves in an unexpected way.
There are general guidelines for interface testing are:
1. Inspecting the code to be tested and clearly list each call to an outside module. Design is the group of test in which the values of the parameters to the outside modules are at the end of their ranges.
2. These values are most likely to disclose interface irregularities. Where pointers are passed across an interface, always test the interface with null pointer parameters and when a module is called through a procedural interface, design tests that purposely cause the module to fail. Opposing failure expectations are the common requirement that are misunderstood.
3. Where several modules relate through shared memory, design tests that differ the order in which the modules are stimulated. The tests may disclose unspoken expectations made by the developer regarding the order in which the shared information is produced and consumed.
4.2.4 System testing
The System testing during the development process includes the integration of the modules to build a form of the system and then carry out a test on the integrated system. The System test checks that modules are well-suited, relate correctly and transfer the right information during the process across its interface. There are two important kinds’ overlaps with module testing
The system testing, reuse modules which have been independently developed may be integrated with a new developed modules and this can occur when the test has been fully completed.
When modules are integrating to create a system. This means that some elements of system functionality become clear the components are put together. This may be planned emergent behaviour that has to be tested.
The function of the tests is to check that the system has met all its requirements. Then the system test should concentration more on the testing of the interactions between modules that builds up the system and a test should be carried on the returnable modules to check confirm it has met its requirement when its integrated with new modules. The interaction testing should see the module errors that are shown when a module is used by a different module in the system.
4.3 Test-driven development
Test-driven development is a method to program development in which testing and code de-velopment are included (Beck, 2002; Jeffries and Melnik, 2007). when developing the code incrementally with a test for that increment. Till the developed code passes its test increment-ing won’t be able to go to the next stage. Test-driven development is a part of agile methods such as Extreme Programming.
Figure 24
The fundamental Test-driven development method is displayed in the above figure. The steps in the method are:
• Knowing the increment of functions that are essential. This should be small and im-plementable in a few code.
• Structure the test for the function and implement it as automated test showing the test can be implemented and know if the test been successful or not.
• The test should be running with all other tests that have been implemented.
• Implement the function and re-run the test.
• when test is successful, the next steps of function will be implemented.
As the code is developed in little increments, all test can be carried out any time a function is added to the project so the tests are implanted separately which runs the tests and calls the system that are tested.
A strong argument for test-driven development is that it helps developer explain the ideas of a code segment and what its required to do. test-driven development benefits:
• Code coverage: all code segment written should have at least one connected test. Therefore, not all the code in the system has been implemented. Codes are tested as it is written in the development process.
• Regression testing: A test set is developed incrementally as a project is built. regres-sion tests can also be done to check that changes of the project have not presented new bugs.
• When the debugging test fails it shows that there is an error in the code written. The code written has to be checked and improved.
• System certification The tests act as a form of certification that shows what the code is required to do.
The important benefits of test-driven development are that it reduces the costs of regression testing. Regression testing includes running a test that has been successfully implemented af-ter changes have been made. The regression test checks that the changes have not presented new bugs into the system and that the new code interacts as projected with the existing code. The test-driven development needs a system test method to validate the system, to check that it meets all the requirements of the system.
4.4 Release testing
Release testing is the method of testing a specific system that is projected for the use of the development team. the system release is for users. There are two differences between release testing and system testing during the development process:
• The system development should be responsible for release testing.
• The System testing should emphasis on ascertaining errors in the system. The aim of release testing is to check that the system meets its requirements and is good for validation testing.
The aim goal of the release testing method is to persuade the provider of the system that it is good to be used. Release testing shows that the system meets its requirements, performance and that it does not fail during use. Release testing is testing method where tests are gotten from the system requirements.
4.4.1 Requirements-based testing
The main aim of the requirements is that requirements should undergo testing to see if the requirements have been met and are full functional. the requirement should be written so that test can be built for that requirement. A test carried out can then check the requirement has been fulfilled. The Requirements-based testing is a regular method for testing the case design where all requirement and develop a set of test. Requirements-based testing is based on the validation rather than fault testing showing that the system has been executed its requirements.
To check if these requirements have been fulfilled based on the tests carried out:
• A login page for registered users.
• A list of course topics for users to learn from.
• A book mark content which allows users bookmark course topics.
• A messaging system between the users and the Admin.
• The users should be able to take exams and quizzes.
• The users should be able to view the grades of the exams and quizzes taken.
• The users should be able to log out at the end of the day after learning.
4.4.2 Performance testing
After a complete system integration, emergent properties testing makes it possible for performance and consistency. Performance tests are designed to warrant the system can develop its intended load. This involves running a series of tests allowing an increase in load until the system performance becomes improper. performance testing demonstrates the system meets its requirements and determining problems in the other types of testing. For performance requirements testing to be achieved, an operational profile must be created. Practice has revealed that an effective way to discover defects is by designing tests around the system limit. In performance testing, emphasising the system by making demands that are outside the design makes software limited. This is known as ‘stress testing’
This testing comprises of two functions:
1. System behaviour failure testing: unexpected situations might arise through unforeseen combination of events in which the load placed on the system surpasses the maximum anticipated load. In this condition, it’s important the system failure should not cause data corruption or unforeseen loss of user services. Stress testing ensures the congestion of the system causing it to ‘fail-soft’ instead of collapsing under its load.
2. System stressing causes unseen defects: Though it can be said that these defects are doubtful to generate system failures during normal usage, there are usually signs of unusual combinations of normal conditions that there’s always a replicate in stress testing. These systems often display degradation when heavily loaded. There’s a swamp in data coordination causing different processes exchange. The processes become slower for required data from other processes.
4.5 User Testing
The User testing is a phase in the testing method in which the users delivers the input and information on system test. Which may include carrying out a test on the system that has been an easy method where users test with the project to know if it meets its requirement and that it does what its required of it. The User testing is very necessary even after the release testing of the system have been carried out. The aim for the user testing is to influence the user’s work background, which has a main result on the reliability, performance and the usability of a system. It is difficult for a system developer to duplicate the system’s working environment as the test in the developer’s environment are certainly artificial. There are two types of user testing:
The Beta testing: the beta testing is the test that is used to release the software which is later made available to users to permit the experiment and raise problems that has been discover with the system developers. The Beta testing occurs when the release of a software system is made ready to users for evaluation.
The Acceptance testing: the acceptance testing occurs when the users test a system to know if the project is ready to be accepted from the system developers and installed into the user’s environment.
Figure 25
The software has been made ready all users wanting to use the project. It is difficult for project/software developers to know all the given environments in which the software will be used or developed in. Beta testing is very important to see the interaction difficulties between the software and structures of the environment where the project or software will be used. Beta testing can also be used to display the users learning regrading the system and what the users get from using it due to the requirements followed when buying the project.
Acceptance testing is based on the inherent bit of the custom systems development and the acceptance testing occurs after the release testing has been carried out. This includes a user’s testing the system to know if it will be accepted or if it project meets the requirements.