MANUAL TESTING

1. MANUAL TESTING MANUAL TESTING

2. Agenda for the Session • Fundamentals of Testing • Why is Testing Necessary • What is Testing • Seven Testing Principles • Fundamental Test Process • Psychology of Testing • Code of Ethics • Testing throughout Software Lifecycle • Software Development models • STLC – Software Testing Life Cycles • Test Levels • Test Types • Testing Methodologies • Maintenance Testing MANUAL TESTING

3. Agenda for the Session • Static Techniques • Static techniques & the Test Process • Review Process • Static Analysis by tools • Test Design Techniques • Test Development Process • Categories of Test Design Techniques • Specification Based or Black-box Techniques • Structure-Based or White-box Techniques MANUAL TESTING

4. Agenda for the Session • Test Case Development • Test Scenario • Test Case • Traceability Matrix • Test Management • Test Organization • Test Planning • Test Strategy • Incident Management • Software Requirements • Requirement Engineering Process • Requirement Elicitation Process • Requirement Elicitation Techniques • Software requirement Characteristics MANUAL TESTING

5. Agenda for the Session • Software requirements • User Interface Requirements • Tool Support for Testing • Types of Test Tools • Effective use of Tools • Testing Definitions • IEEE 829 Standard Templates • ISTQB Foundation Exam Details MANUAL TESTING

6. Fundamentals of Testing MANUAL TESTING

7. Why Testing is Necessary • Software developed by people.  People make mistake, because of pressure. Pressure can be happened in variety ways, Such as deadline, change of new technology, complexity of organization and system and error in specification, design and software code.  Error or mistake lead defect and defect cause failure. Not only people, environment condition can effect for system failure. They are presence of radiation, magnetism, electronic field and pollution. Software failure can affect people, companies and environment. Example: • China Airlines Airbus A300 crashing due to a software bug on April 26, 1994 killing 264 innocent lives. • News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks. • In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000 erroneous tax overcharges. The problem was partly attributed to the difficulty of testing the integration of multiple systems. MANUAL TESTING

8. Why Testing is Necessary • In 1985,Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to patients ,leaving 3 people dead and critically injuring 3 others. • In April of 1999 ,a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history. • In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars. • Software bugs can potentially cause monetary and human loss, history is full of such examples. • Testing is important because software bugs could be expensive or even dangerous. MANUAL TESTING

9. Error, Fault, Bug, Failure & Defect MANUAL TESTING

10. Error, Fault, Bug, Failure & Defect • ERROR: Error is deviation from actual and expected value. It represents mistake made by people. • FAULT: Fault is incorrect step, process or data definition in a computer program which causes the program to behave in an unintended or unanticipated manner. It is the result of the error. • BUG: Bug is a fault in the program which causes the program to behave in an unintended or unanticipated manner. It is an evidence of fault in the program. • FAILURE: Failure is the inability of a system or a component to perform its required functions within specified performance requirements. Failure occurs when fault executes. • DEFECT: A defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results. A defect is said to be detected when a failure is observed. MANUAL TESTING

11. Examples of Error, Fault, Bug, Failure & Defect • As mentioned this program is required to add two numbers. • 1 #include<stdio.h> • 2 int main () • 3 { • 4 int value1, value2, ans; • 5 value1 = 5; • 6 value2 = 3; • 7 ans = value1 - value2; • 8 printf("The addition of 5 + 3 = %d.", ans); • 9 return 0; • 10 } • When you compile and run this program you see the printed statement as below: The addition of 5 + 3 = 2. MANUAL TESTING

12. Examples of Error, Fault, Bug, Failure & Defect • So after compiling and running this program we realize the program has failed to do what it was supposed to do. • The program was supposed to add two numbers but it certainly did not add 5 and 3. 5 + 3 should be 8, but the result is 2. There could be various reasons as to why the program displays the answer 2 instead of 8. For now we have detected a failure. • As the failure has been detected a defect can be raised. • Now lets go back to the program and analyze what was the fault in the program. MANUAL TESTING

13. Cost of Defects . MANUAL TESTING

14. Cost of Quality . MANUAL TESTING

15. Cost of Quality . MANUAL TESTING

16. How Much testing is Enough. • Complete testing is impossible for several reasons. They are:-  • We can’t test all the inputs to the program. • We can’t test all the combinations of inputs to the program. • We can’t test all the paths through the program. • We can’t test for all of the other potential failures, such as those caused by user interface design errors or incomplete requirements analyses. MANUAL TESTING

17. What is Software Testing Software testing is the process of evaluation a software item to detect differences between given input and expected output. Also to assess the feature of A software item. Testing assesses the quality of the product. Software testing is a process that should be done during the development process. In other words software testing is a verification and validation process. • Verification Verification is the process to make sure the product satisfies the conditions imposed at the start of the development phase. In other words, to make sure the product behaves the way we want it to. • Validation Validation is the process to make sure the product satisfies the specified requirements at the end of the development phase. In other words, to make sure the product is built as per customer expectations. MANUAL TESTING

18. Verification & Validation MANUAL TESTING

19. Testing Principles • Principle 1: Testing shows Testing can show that defects are present: presence of defects but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness. • Principle 2: Exhaustive testing: Testing everything (all combinations of is impossible inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts. • Principle 3: Early testing: Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives. • Principle 4: Defect clustering A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures. • Principle 5: Pesticide paradox: If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects. MANUAL TESTING

20. Testing Principles • Principle 6: Testing is context: Testing is done differently in different dependent contexts. For example, safety-critical software is tested differently from an e-commerce site. • Principle 7: Absence-of-errors: Finding and fixing defects does not help if fallacy the system built is unusable and does not fulfill the users' needs and expectations. MANUAL TESTING

21. SDLC Models MANUAL TESTING

22. SDLC OVERVIEW • SDLC is the acronym of Software Development Life Cycle. • It is also called as Software development process. • The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process. • SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process. MANUAL TESTING

23. SDLC OVERVIEW MANUAL TESTING

24. SDLC OVERVIEW 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. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas. • Planning for the quality assurance requirements and identification of the risks associated with the project 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. MANUAL TESTING

25. SDLC OVERVIEW Stage 2: Defining Requirements • Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through .SRS. . Software Requirement Specification document which consists of all the product requirements to be designed and developed during the project life cycle. MANUAL TESTING

26. SDLC OVERVIEW Stage 3: Designing the product architecture • SRS is the reference for product architects to come out with the best architecture for the product to be developed. 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. • This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity , budget and time constraints , the best design approach is selected for the product. • A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS. MANUAL TESTING

27. SDLC OVERVIEW Stage 4: Building or Developing the Product • In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle. • Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers etc are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed. MANUAL TESTING

28. SDLC OVERVIEW Stage 5: Testing the Product • This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. MANUAL TESTING

29. SDLC OVERVIEW 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. Sometime product deployment happens in stages as per the organizations. business strategy. 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. MANUAL TESTING

30. Waterfall Model • It is also called as linear sequential model. • In this model whole application is developed in a sequential approach. • In this model each phase must be completed fully before the next phase begin. • Provides structure to inexperienced staff. Where to Use Waterfall Model: • 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. MANUAL TESTING

31. Waterfall Model MANUAL TESTING

32. Waterfall Model MANUAL TESTING

33. Waterfall Model Advantages • A waterfall model is easy to implementation. • It helps to find errors earlier • Easy to understand, easy to use. • Works well when quality is more important than cost or schedule • Documentation is produced at every stage of a waterfall model allowing people to understand what has been done. • Testing is done at every stage. MANUAL TESTING

34. Waterfall Model Disadvantages • It is only suitable for the small size projects. • Constant testing of the design is needed. • If requirements may change the Waterfall model may not work. • Difficult to estimate time and cost for each stage of the development process. • Adjust scope during the life cycle can kill a project. • High amount of risk and uncertainty. • This model is not suitable to handle dynamic changes in the requirements. MANUAL TESTING

35. Iterative Model • In Iterative model, iterative process starts with a simple implementation of a small set of the software requirements and iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed. • An iterative life cycle model does not attempt to start with a full specification of requirements. • Instead, development begins by specifying and implementing just part of the software, which is then reviewed in order to identify further requirements.  • This process is then repeated, producing a new version of the software at the end of each iteration of the model. • The key to successful use of an iterative software development lifecycle is rigorous validation of requirements, and verification & testing of each version of the software against those requirements within each cycle of the model. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software. MANUAL TESTING

36. Iterative Model • Requirements of the complete system are clearly defined and understood. • Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time. • There is a time to the market constraint. • A new technology is being used and is being learnt by the development team while working on the project. • Resources with needed skill set are not available and are planned to be used on contract basis for specific iterations. • There are some high risk features and goals which may change in the future. MANUAL TESTING

37. Iterative Model MANUAL TESTING

38. Advantages of Iterative Model • Some working functionality can be developed quickly and early in the life cycle. • Results are obtained early and periodically. • Parallel development can be planned. • Progress can be measured. • Less costly to change the scope/requirements. • Testing and debugging during smaller iteration is easy. • Risks are identified and resolved during iteration; and each iteration is an easily managed milestone. • Easier to manage risk - High risk part is done first. • With every increment operational product is delivered. • Issues, challenges & risks identified from each increment can be utilized/applied to the next increment. • During life cycle software is produced early which facilitates customer evaluation and feedback. MANUAL TESTING

39. Disadvantages of Iterative Model • More resources may be required. • Although cost of change is lesser but it is not very suitable for changing requirements. • More management attention is required. • System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle. • Defining increments may require definition of the complete system. • Not suitable for smaller projects. • End of project may not be known which is a risk. • Highly skilled resources are required for risk analysis. • Project progress is highly dependent upon the risk analysis phase. MANUAL TESTING

40. V-Model V-Model Objectives: • Requirements are well defined, clearly documented and fixed. • Product definition is stable. • Technology is not dynamic and is well understood by the project team. • There are no ambiguous or undefined requirements. • The project is short. MANUAL TESTING

41. V-Model MANUAL TESTING

42. V-Model • The Requirements phase, a document describing what the software is required to do after the software is gathered and analyzed and the corresponding test activity is user acceptance testing. • The Architectural Design phase, where a software architecture is designed and building the components within the software and the establishing the relationships between the components and the corresponding test activity is System Testing. • The High Level Design phase, breaking the system into subsystems with identified interfaces; then gets translated to a more detailed design and the corresponding test activity is Integration testing. • The Detailed Design phase, where the detailed implementation of each component is specified. The detailed design broken into Data structures, Algorithm used and the corresponding test activity is unit Testing. • Coding in which each component of the software is coded and tested to verify if faithfully implements the detailed design. MANUAL TESTING

43. Advantages of V-Model • Emphasize for verification and validation of the product in early stages of product development. • Each stage is testable. • Project management can track progress by milestones. • Easy to understand implement and use. MANUAL TESTING

44. Disadvantages of V-Model • Does not easily handle events concurrently. • Does not handle iterations or phases. • Does not easily handle dynamic changes in requirements. • Does not contain risk analysis or Mitigation activities. MANUAL TESTING

45. Agile Methodology • Agile development model is also a type of incremental Model. • Software is developed in incremental, rapid cycles.  • This results in small incremental releases with each release building on previous functionality. • Each release is thoroughly tested to ensure software quality is maintained. • It is used for time critical applications. When to Use Agile Methodology: • When new changes are needed to be implemented. The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced. • To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it. • Unlike the waterfall model in agile model very limited planning is required to get started with the project. MANUAL TESTING

46. Agile Methodology A Generic Agile Development process MANUAL TESTING

47. Agile Methodology • Methods of Agile software development • DSDM (Dynamic System Development Methodology) • Extreme Programming (XP) • Scrums • TDD (Test Driven Development) • Lean • Kanban • Mostly now we use in Scrum methodology. MANUAL TESTING

48. Agile Methodology • Scrum Methodology MANUAL TESTING

49. Agile Methodology • Scrum: In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. Scrum for software development came out of the rapid prototyping community because prototypes wanted a methodology that would support an environment in which the requirements were not only incomplete at the start, but also could change rapidly during development. • Scrum management: At the center of each Scrum project is a backlog of work to be done. This backlog is populated during the planning phase of a release and defines the scope of the release. • After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints. Each sprint aims to implement a fixed number of backlog items. Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress. MANUAL TESTING

50. Agile Methodology • During a sprint, the team has a daily meeting called a scrum. Each team member describes the work to be done that day, progress from the day before, and any blocks that must be cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone in the same room—standing up for the whole meeting. • When enough of the backlog has been implemented so that the end users believe the release is worth putting into production, management closes development. The team then performs integration testing, training, and documentation as necessary for product release. • SCRUM DEVELOPMENT: The Scrum development process concentrates on managing sprints. Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review, and adjust each of the backlog items. • During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary. MANUAL TESTING