Chapter - 04

1. Chapter - 04 Software Testing Strategies and Methods Visit to more Learning Resources

2. The process of executing the programs with the intention to find out the errors is software testing. A software engineer must develop or design software which should be flexible to test.

3. Objectives of software testing • Find out the errors and fix them. • Good test is able to find out undiscovered errors. • To fulfill customers requirement regarding software product. • To enforce standards while developing software product. • To support software quality assurance. • Check operability, flexibility,reliability of software product.

4. Characteristics / attributes:- • Operability • Observability • Controllability • Simplicity • Stability • Understandability • Reliability • Safety and security.

5. Operability Ability of getting operated easily The more is operability,more efficiently s/w can be tested. It make sure that- The system will have less number of bugs. Bugs wont block the execution of test.

6. observability It is nothing but what you can see is what you can test. Points observed are:- Different o/p is generated for each an every I/p. Check system states and variables and their values. Each an every factor that affects the o/p is clearly visible. Wrong o/p and internal errors can be easily find out.

7. Concept of Good Test A good test has a high probability of finding an error. A good test is not redundant . every test should have a unique purpose. A good test should be best of breed.(best test selected from a group of tests.) A good test should be neither too simple nor too complex.

8. Concept of Successful Test If testing is conducted successfully i.e. by following the all objectives,it will uncover almost all errors in the software. The benefit of successful testing is that software functions appear to be working according to design and specification of s/w. It leads to increase in the reliability and quality of the s/w.

9. Testing strategies Testing strategy is a way or method using which the testing is done. This strategy plays very imp role as it is a major contributor in SQA activities.As per the type and scope of the software ,the testing strategy is designed and implemented. In testing strategy we define test plan,test cases,test data.

10. Test plan A s/w test plan is a document that contains the strategy that will be used to verify as well as make sure that the s/w product or system adheres to its design specification and other requirement. Test plan may contain following test:- • Design verification test • Development or production test • Acceptance or commissioning test • Service and repair test • Regression test.

11. Test plan format varies organization to organization. Test plan should contain the three important elements like test coverage, test methods,test responsibilities.

12. Test cases Test case is a set of conditions or variables under which a testing team or testers will determine whether an application or s/w system is working correctly or not. The test case is classified inti three categories:- Formal test case -(i/p is known and o/p is expected) Informal test case-( multiple steps,not written) Typical written test case- (contain test case data in detail)

13. Test data Test data are data which have been specifically identified for use in tests. The test data may have different purpose as follows :- It can be used for inputting data to the tests to produce the expected o/p. To check an ability or behavior of a s/w program to deal with unexpected,unusual,extreme and exceptional I/p. Test data may include data which describes details about the testing strategy,i/p,o/p in general.

14. Char. Of system strategies Need to specify requirement of the product in a quantifiable way or in a measurable way before testing strategy. Testing objectives should be explicitly mentioned in the testing strategy. Develops a profile for every category of the user by understanding the users of the software. It should develop a testing plan that focuses on “rapid cycle testing” A robust software has to be built that is capable of testing itself.

15. Formal technical reviews need to be conducted to check the test strategy and test cases. For the testing process a continues improvement approach should be used by testing strategy.

16. Software Verification and Validation (V&V) Verification refers to the set of activities that ensures that s/w correctly implements a specific function. Validation refers to a different set of activities that ensures that the s/w that has been built is traceable to customer requirements. Verification- Are we building the product right? Validation- Are we building the right product?

17. V&V encompasses a wide array of SQA activities that include formal technical reviews,quality audits,performance monitoring,simulation,feasibility study,usability testing,database review,algorithm analysis,development testing, usability testing,qualification testing,installation testing etc.

19. 4.4 Testing Strategies  Unit Testing  Integration Testing  Top-Down Approach  Bottom-up Approach  Regression Testing  Smoke Testing

21. Testing Strategies • Testing begins at the component level and works outward toward the integration of the entire computer-based system. • Different testing techniques are appropriate at different points in time. • The developer of the software conducts testing and may be assisted by independent test groups for large projects. • The role of the independent tester is to remove the conflict of interest inherent when the builder is testing his or her own product.

23. Unit Testing Unit Testing is a level of the software testing process where individual units/components of a software/system are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output. In procedural programming a unit may be an individual program, function,procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.

25. The module interface is tested to ensure that information properly flows into and out of the program unit under test. Local data structures are examined to ensure that data store temporarily maintains its integrity during execution. All independent path ensures that all statements in a module have been executed at least once. Boundary conditions are tested to ensure the module operates properly at boundaries established to limit or restrict processing. Finally all error handling paths are tested.

27. Unit test procedures In most applications a driver is nothing more then a main program that accepts test case data passes to component to be tested and prints results. Stubs serves to replace modules that are called by the component to be tested. A stub or dummy sub program uses the sub ordinate modules interface, may do data manipulation, provides verification and returns control to the module under going testing. Drivers and stub are kept simple, actual over head is kept low.

28. Example of Stubs and Drivers is given below:- For Example we have 3 modules login, home, and user module. Login module is ready and need to test it, but we call functions from home and user (which is not ready). To test at a selective module we write a short dummy piece of a code which simulates home and user, which will return values for Login, this piece of dummy code is always called Stubs and it is used in a top down integration. Considering the same Example above: If we have Home and User modules get ready and Login module is not ready, and we need to test Home and User modules Which return values from Login module, So to extract the values from Login module We write a Short Piece of Dummy code for login which returns value for home and user, So these pieces of code is always called Drivers and it is used in Bottom Up Integration Conclusion:- So it is fine from the above example that Stubs act “called” functions in top down integration. Drivers are “calling” Functions in bottom up integration.

29. Suppose you have a function (Function A) that calculates the total marks obtained by a student in a particular academic year. Suppose this function derives its values from another function (Function b) which calculates the marks obtained in a particular subject. You have finished working on Function A and wants to test it. But the problem you face here is that you can't seem to run the Function A without input from Function B; Function B is still under development. In this case, you create a dummy function to act in place of Function B to test your function. This dummy function gets called by another function. Such a dummy is called a Stub. To understand what a driver is, suppose you have finished Function B and is waiting for Function A to be developed. In this case you create a dummy to call the Function B. This dummy is called the driver.

30. Integration Testing It is a systematic technique for constructing software architecture while at the same time conducting testing to uncover errors with interfacing. The objective is to take unit tested components and build program structure that has been dictated by design. The entire program is tested as a whole.

33. Top down integration It is an incremental approach to construction of the s/w architecture. Modules are integrated by moving downward ,beginning with the main control module(main program). Modules subordinate to the main control module are incorporated into the structure in either a DFS or BFS manner.

34. Steps to perform top down integration:- The main control module is used as a test driver,stubs are substituted one at a time for all components directly subordinates to the main module. Tests are conducted as each component is integrated. On completion of test,another stub is replaced with real components.

35. Bottom up integration As its name implies,begins construction and testing with lowest level component in the program structure. Components are integrated bottom up, the need for stub is eliminated.

36. Steps for bottom-up integration:- Low level components are combined into clusters.(builds- performs specific s/w sub function) A driver is written to coordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upward in structure.

38. Components are combined to form a clusters. Each of clusters is tested using a driver shown as a dashed block.components in clusters 1,2 are subordinate to Ma. Drivers D1,D2 are removed and clusters are interfaced directly to Ma. As integration moves upward, the need for separate test drivers are less.

40. Regression testing Each time a new module is added as part of integration testing,the s/w changes. New data flow paths are established,new i/o may occur,new control logic is invoked. These changes may cause problems with functions that previously worked flawlessly. Regression testing is the re execution of some subsets of tests that have already been conducted to ensure that changes have not propagated unintended side effects.

41. It is the activity that helps to ensure that changes do not introduce unintended behavior and additional errors. Regression testing may be conducted manually or by using automated tools. As integration testing proceeds, the number of regression tests can grow quite large.

42. Smoke testing Smoke testing is an integration testing approach that is commonly used when software products are being developed. It is designed as pacing(a single step in process)mechanism for time critical projects ,allowing the s/w team to test their projects on frequent basis. • S /w components that have been translated into code are integrated into a “Build” - build includes all data files,libraries,reusable modules,engineered components that are required to implement one or more product functions. • A series of tests is designed to expose errors that will keep the build from performing its function.

43. The build is integrated with other build and the entire product is smoke tested daily. It does not have to be exhaustive,but it should be capable of exposing major problems. If the build passes ,you can assume that it is stable enough to be tested more completely.

44. Benefits of s/w testing:- • Integration risk is minimized. • The quality of the end product is improved. • Error diagnosis and correction are simplified. • Progress is easier to assess.

45. Validation Testing Alpha testing:- This test takes place at the developer’s site. Developers observe the users and note problems. Alpha testing is testing of an application when development is about to complete. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers.

46. Alpha testing is final testing before the software is released to the general public. It has two phases: In the first phase of alpha testing, the software is tested by in-house developers. The goal is to catch bugs quickly. In the second phase of alpha testing, the software is handed over to the software QA staff, for additional testing in an environment that is similar to the intended use.

47. Beta Testing It is also known as field testing. It takes place at customer’s site. It sends the system to users who install it and use it under real-world working conditions. A beta test is the second phase of software testing in which a sampling of the intended audience tries the product out. (Beta is the second letter of the Greek alphabet.) Originally, the term alpha test meant the first phase of testing in a software development process. The first phase includes unit testing, component testing, and system testing. Beta testing can be considered “pre-release testing.

48. The goal of beta testing is to place your application in the hands of real users outside of your own engineering team to discover any flaws or issues from the user’s perspective that you would not want to have in your final, released version of the application.

50. System testing System testing is a actually a series of different tests whose primary purpose is to fully exercise the computer based system. Although each test has a different purpose,all work to verify that system elements have been properly integrated and perform allocated functions.