Introduction to software testing Presentation

Software Testing

1. GITAM CSE DEPARTMENT SUBJECT: SOFTWARE TESTING Course Code: PEC-CSE-413G B. Tech CSE 7 TH SEM LECTURE DELIVERED BY: RITIKA SAROHA ASSISTANT PROFESSOR CSE DEPT.

2. SYLLABUS Unit 1 Introduction: Overview of Software Development Life Cycle (SDLC), Significance of Software Testing in SDLC, Objectives and Limitations of software testing. Difference between an Error, Fault and Failure (Software Bug), Software Testing Life Cycle (STLC) and Seven Principles of Software Testing, Role of Software Testing in Software Quality

3. UNIT 2 Test Case Design: Test Cases and Test Suite, Test Case Planning and Designing, Characteristics of Good Test Case Design, Format of test case. Testing Activities: Levels of Testing- Unit, Integration Testing and System Testing. V Model for Software Testing.

4. SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE) WHAT IS SDLC? It is also called as Software Development Process. Software development life cycle (SDLC) is a structured process that is used to design, develop, and test good-quality software. OR SDLC is a methodology that defines the entire procedure of software development step-by-step.

5. INTRODUCTION Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software’s.  The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

6. STAGES OF SDLC

7. Stage 1 Planning and Requirement Analysis Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry.

8. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational and technical areas. Risk Identification is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

9. Stage 2: Defining Requirements Define and document the product requirements This is done through an  SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.

10. Stage 3: Designing the Product Architecture Based on the requirements specified in SRS , usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification . DDS is reviewed by all the important stakeholders. on the basis of various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.

11. Stage 4: Building or Developing the Product(CODING) Actual development starts and the product is built.  During this stage. The programming code is generated as per DDS. The programming language is chosen with respect to the type of software being developed.

12. Stage 5: Testing the Product  This is testing stage of the product. Here product defects are reported, tracked, fixed and retested.

13. Stage 6: Deployment in the Market and Maintenance Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment ( UAT- User acceptance testing). Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base.

14. SDLC MODELS These models are also referred as “Software Development Process Models”: Waterfall Model Iterative Model Spiral Model V-Model  Agile Model, RAD (Rapid Application Development) Model Prototyping Models.

15. Waterfall Model The Waterfall Model was the first Process Model to be introduced.  It is also referred to as a  linear-sequential life cycle model . It is very simple to understand and use.

16. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases .

17. STAGES OF WATERFALL MODEL STAGE1: Requirement Gathering and analysis   − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document (SRS) . STAGE2: System Design   − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.

18. WATER MODEL(CONTD.) STAGE3:Implementation  − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing. STAGE4: Integration and Testing   − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

19. WATER MODEL(CONTD.) STAGE5: Deployment of system  − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market. STAGE6:Maintenance  − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

20. Waterfall Model - Application Requirements are very well documented, clear and fixed. Product definition is stable. Technology is understood and is not dynamic. There are no ambiguous requirements. Ample resources with required expertise are available to support the product. The project is short.

21. Waterfall Model - Advantages Simple and easy to understand and use Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. Phases are processed and completed one at a time.

22. Advantages [contd.] Works well for smaller projects where requirements are very well understood. Clearly defined stages. Well understood milestones. Easy to arrange tasks. Process and results are well documented.

23. Waterfall Model - Disadvantages No working software is produced until late during the life cycle. High amounts of risk and uncertainty. Not a good model for complex and object-oriented projects. Poor model for long and ongoing projects.

24. Waterfall Model - Disadvantages Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model. It is difficult to measure progress within stages. Cannot accommodate changing requirements. Adjusting scope during the life cycle can end a project. Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

25. OBJECTIVES OF SOFTWARE TESTING Here are five main objectives of software testing: Verification and Validation Identification of Defects Defects Prevention Ensuring Quality Attributes in the Product : Some of the quality attributes tested with software testing include functionality, performance, usability, security, compatibility, and scalability, among others. Risk Management  

26. LIMITATIONS OF SOFTWARE TESTING It’s impossible to test for all conditions. Testing usually gives no insight into the root causes of errors. Time and resource constraints. Reliance on test data. Inability to guarantee absolute correctness.

27. BUG,DEFECT,ERROR BUG: When we have some coding error, it leads a program to its breakdown, which is known as  a bug . The  test engineers   use the terminology  Bug . DEFECT: When the application is not working as per the requirement is knows as  defects . It is specified as the aberration from the  actual and expected result  of the application or software. announced by the   programmer   and inside the code is called a  Defect . ERROR: The Problem in code leads to errors. Developer uses the term error .

28. FAULT, FAILURE The fault may occur in software because it has not added the code for fault tolerance, making an application act up. A fault may happen in a program because of the following reasons: Lack of resources An invalid step Inappropriate data definition Failure Many defects lead to the  software's failure , which means that a loss specifies a fatal issue in software/ application or in its module, which makes the system unresponsive or broken.

29. DIFFERENCE BETWEEN ERROR,FAULT AND FAILURE

30. SOFTWARE TESTING LIFE CYCLE (STLC) The procedure of software testing is also known as STLC (Software Testing Life Cycle) which includes phases of the testing process Characteristics of STLC STLC is a fundamental part of the  Software Development Life Cycle (SDLC)  but STLC consists of only the testing phases. STLC starts as soon as requirements are defined or software requirement document is shared by stakeholders. STLC yields a step-by-step process to ensure quality software.

31. STLC PHASES Software testing life cycle contains the following steps: Requirement Analysis Test Planning Test case development Test Environment setup Test case Execution Test Cycle Closure

32. STLC PHASES

33. STLC PHASES (PHASE 1) Requirement Analysis is the first step of the Software Testing Life Cycle (STLC).  The activities that take place during the Requirement Analysis stage include: Reviewing the software requirements document (SR S ) and other related documents(DDS). Interviewing stakeholders to gather additional information Identifying any ambiguities or inconsistencies in the requirements Identifying any missing or incomplete requirements Identifying any potential risks or issues that may impact the testing process Creating a requirement traceability matrix (RTM) to map requirements to test cases

34. PHASE 2 TEST PLANNING The activities that take place during the Test Planning stage include: Identifying the testing objectives and scope Developing a test strategy: selecting the testing methods and techniques that will be used Identifying the testing environment and resources needed Identifying the test cases that will be executed and the test data that will be used Estimating the time and cost required for testing Identifying the test deliverables and milestones Assigning roles and responsibilities to the testing team Reviewing and approving the test plan At the end of this stage, the testing team should have a detailed plan for the testing activities that will be performed, and a clear understanding of the testing objectives, scope, and deliverables. 

35. PHASE 3:TEST CASE DEVELOPMENT In this phase testing team notes down the detailed test cases. The testing team also prepares the required test data for the testing.  Identifying the test cases that will be developed Writing test cases that are clear, concise, and easy to understand Creating test data and test scenarios that will be used in the test cases Identifying the expected results for each test case Reviewing and validating the test cases Updating the requirement traceability matrix (RTM) to map requirements to test cases

36. PHASE 4 TEST ENVIRONMENT SETUP   Test environment setup is a vital part of the STLC. Basically, the test environment decides the conditions on which software is tested. This is independent activity and can be started along with test case development. In this process, the testing team is not involved. either the developer or the customer creates the testing environment.

37. PHASE 5:TEST EXECUTION   After the test case development and test environment setup test execution phase gets started. In this phase testing team starts executing test cases based on prepared test cases in the earlier step.

38. PHASE5:TEST CYCLE CLOSURE Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-related activities are completed and documented.  The main activities that take place during the test closure stage include: Test summary report:   A report is created that summarizes the overall testing process, including the number of test cases executed, the number of defects found, and the overall pass/fail rate. Defect tracking:   All defects that were identified during testing are tracked and managed until they are resolved. Test environment clean-up:  The test environment is cleaned up, and all test data and test artifacts are archived. Test closure report:   A report is created that documents all the testing-related activities that took place, including the testing objectives, scope, schedule, and resources used. Knowledge transfer :  Knowledge about the software and testing process is shared with the rest of the team and any stakeholders who may need to maintain or support the software in the future. Feedback and improvements:   Feedback from the testing process is collected and used to improve future testing processes

39. 7 PRINCIPLES OF SOFTWARE TESTING

40. Application of Software Testing in Quality Planning: Quality planning is the development of a series of measures and steps to ensure the high quality of a software product. Determine the test objectives and scope Determine the test strategies and methods Make a test plan Evaluate test coverage

41. Software testing can help identify software defects and problems, prevent software errors, and ensure that software quality meets user needs and standards. Standardized management of software testing can improve test efficiency and test quality, and can also reduce test cost and test risk. In the software testing process, we need to have certain skills and knowledge, and need to pay attention to communication and collaboration to ensure that the test tasks can be completed on time.

42. Software testing should be a whole-process activity, including test plan, test design, test execution, test evaluation and test improvement. In conclusion , software testing plays a vital role in software quality management, and only continuous improvement in the testing process can ensure the stability and reliability of software quality.

43. Test case design: test cases and test suits Test Case The test case is defined as a group of conditions under which a tester determines whether a software application is working as per the customer's requirements or not. Test case designing includes preconditions, case name, input conditions, and expected result. A test case is a first level action and derived from test scenarios.

44. TEST CASES (CONTD.) These are executed during the testing process to check whether the software application is performing the task for that it was developed or not. Test case helps the tester in defect reporting by linking defect with test case ID.  Detailed test case documentation works as a full proof guard for the testing team because if developer missed something, then it can be caught during execution of these full-proof test cases.

45. TEST CASES (CONTD.) To write the test case, we must have the requirements to derive the inputs, and the test scenarios must be written so that we do not miss out on any features for testing.  Generally, we will write the test case whenever the developer is busy in writing the code.

46. When do we write a test case? When the customer gives the business needs then, the developer starts developing and says that they need 3.5 months to build this product. And In the meantime, the testing team will  start writing the test cases . Once it is done, it will send it to the Test Lead for the review process. And when the developers finish developing the product, it is handed over to the testing team. The test engineers never look at the requirement while testing the product document because testing is constant and does not depends on the mood of the person rather than the quality of the test engineer.

47. Why we write the test cases? We will write the test for the following reasons: To require consistency in the test case execution To make sure a better test coverage It depends on the process rather than on a person To avoid training for every new test engineer on the product To require consistency in the test case execution:   we will see the test case and start testing the application. To make sure a better test coverage:   for this, we should cover all possible scenarios and document it, so that we need not remember all the scenarios again and again.

48. TEST CASE TEMPLATE The primary purpose of writing a test case is to achieve the efficiency of the application.

49. we know, the  actual result  is written after the test case execution, and most of the time, it would be same as the  expected result . But if the test step will fail, it will be different. So, the actual result field can be skipped, and in  the Comments  section, we can write about the bugs. Test case type It can be functional, integration or system test cases or positive or negative or positive and negative test cases.

50. EXAMPLE OF TEST CASE FOR ICIC’s APPLICATION LOGIN

51. TYPES OF TEST CASES We have a different kind of test cases, which are as follows: Function test cases Integration test cases System test cases The functional test cases Firstly, we check for which field we will write test cases and then describe accordingly.

52. Rules to write functional test cases: In the expected results column, try to use  should be  or  must be . Highlight the Object names. We have to describe only those steps which we required the most; otherwise, we do not need to define all the steps. To reduce the excess execution time, we will write steps correctly. Write a generic test case; do not try to hard code it.

53. PROCESS TO WRITE TEST CASES

54. TEST CASE A test case is a set of instructions determining whether a software or system behaves as expected. A test case generally outlines the various inputs and outputs for a particular scenario and provides step-by-step instructions on executing that scenario. It can also include information about the expected result after executing those steps. Test cases are essential because they help identify bugs and issues early, saving time and money in the long run. Ensuring high-quality software products that meet customer requirements would be much harder without them.

55. Importance of Test Case They help identify defects and bugs in the software application. Test cases assist in verifying whether the software application meets its functional and non-functional requirements . They help in validating the accuracy and completeness of the software application. Test cases help establish quality standards for the software application. They assist in tracking the progress of software testing activities. Test cases act as a guide for developers to fix defects and errors. They help reduce software development costs by detecting defects early in the development lifecycle. Therefore , creating complete Test cases is essential to ensure the software application performs as expected and delivers an excellent user experience without errors or defects.

56. A sample Test case to test whether an existing user can log in to the website successfully. Test Objective :  Confirm you can log into the website using the correct information. Pre-requisites:  A valid username and password. Steps: Launch the application under test. Enter the valid username and password. Click the ‘Login’ button. Ensure that the user logs in successfully. Expected Result:  The user should be successfully logged in to the website. So now we can see how to create a Test case using Test sigma. The image below shows you how to begin creating a Test case in Test sigma. It has all the advanced options for creating a Test case.

57. TEST CASE EXAMPLE

58. What is a Test Suite? A test suite is a set of tests designed to check the functionality and performance of the software. It collects individual test cases based on their specific purpose or characteristics.

59. Importance of Test Suite As a test suite is a collection of test cases grouped according to a specific set of criteria, we must learn the major importance of these test suits.  By organizing test cases into test suites, testers can identify and prioritize the most critical tests, ensuring that the most important aspects of the software are tested first. This helps reduce the risk of missed errors or defects during testing.

60. Test Suites- An Example a Test suite for a product means creating a Test suite with multiple Test cases. 

61. DIFFERENCE BETWEEN TEST SUITE AND TEST CASE Parameter Test Suite Test Case Definition A collection of test cases that are designed to test a specific feature or functionality of the software A set of inputs, preconditions, and expected outcomes that are designed to test a particular aspect of the software Function  Tests multiple scenarios and functionalities  Tests a single scenario or functionality Dependency It can be dependent on other Test Suites Test cases, ideally, run independently of each other Priority Can be prioritized based on the functionality they cover Can be prioritized based on the severity of the issues they uncover Purpose Validate broad functional requirements Validate specific detailed scenarios

62. TEST CASE PLANNING AND DESIGNING TEST CASE PLANNING: A test plan is a detailed document which describes software testing areas and activities. It outlines the test strategy, objectives, test schedule, required resources (human resources, software, and hardware), test estimation and test deliverables. The test plan is prepared by the Test Lead (60%), Test Manager(20%), and by the test engineer(20%).

63. Types of Test Plan Master Test Plan Phase Test Plan Specific Test Plans Master Test Plan Master Test Plan is a type of test plan that has multiple levels of testing. It includes a complete test strategy. Phase Test Plan A phase test plan is a type of test plan that addresses any one phase of the testing strategy. For example, a list of tools, a list of test cases, etc. Specific Test Plans Specific test plan designed for major types of testing like security testing, load testing, performance testing, etc. In other words, a specific test plan designed for non-functional testing.

64. How to write a Test Plan M aking a test plan is the most crucial task of the test management process. According to IEEE 829, follow the following seven steps to prepare a test plan. First, analyze product structure and architecture. Now design the test strategy. Define all the test objectives. Define the testing area. Define all the useable resources. Schedule all activities in an appropriate manner. Determine all the Test Deliverables.

65. Test plan components or attributes

66. The Different Types of Test Case Design Techniques Test case design techniques allow QA engineers to design better test cases, reduce the number of test cases to be executed, and increase testing coverage. Specific-Based Techniques (Black Box Techniques) Boundary value analysis (BVA) Equivalence partitioning (EP) Decision table testing State transition diagrams Use case testing Structure-Based Techniques (White Box Techniques) Statement coverage testing Decision testing coverage Condition testing All path testing Experience-Based Techniques

67. CHARACTERISTICS OF GOOD TEST CASE DESIGN These are the characteristics of Good Test Case. Test cases should have very good test case coverage. Test Cases should have good coverage with less no. of steps. Test Case should be written by applying test case design techniques. Test Case should be simple to understand. If test cases given to any new Tester, he/ she should be able to execute the test cases without asking any questions or clarifications.

68. Test Case should be written in test case template. Test Case should be consistent, means flow or sequence should be good. Test Case should consists of both positive and negative scenarios. Test cases should be able to catch the defects. Test cases should not be redundant, means no duplicates. Test Cases should be very easy to convert into Automation scripts.

69. THANK YOU