MANUAL TESTING 2252021 MANUAL TESTING 1 Agenda for

MANUAL TESTING 2/25/2021 MANUAL TESTING 1

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 • • • 2/25/2021 Software Development models STLC – Software Testing Life Cycles Test Levels Test Types Testing Methodologies Maintenance Testing MANUAL TESTING 2

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 2/25/2021 MANUAL TESTING 3

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 Techniques Software requirement Characteristics 2/25/2021 MANUAL TESTING 4

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 2/25/2021 MANUAL TESTING 5

Fundamentals of Testing 2/25/2021 MANUAL TESTING 6

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 A 300 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. 2/25/2021 MANUAL TESTING 7

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. 2/25/2021 MANUAL TESTING 8

Error, Fault, Bug, Failure & Defect 2/25/2021 MANUAL TESTING 9

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. 2/25/2021 MANUAL TESTING 10

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 value 1, value 2, ans; • 5 value 1 = 5; • 6 value 2 = 3; • 7 ans = value 1 - value 2; • 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. 2/25/2021 MANUAL TESTING 11

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. 2/25/2021 MANUAL TESTING 12

Cost of Defects. 2/25/2021 MANUAL TESTING 13

Cost of Quality. 2/25/2021 MANUAL TESTING 14

Cost of Quality Types of Cost Description Examples Quality planning Statistical process control. Investment in quality-related information The costs of all activities specifically designed systems Prevention costs to prevent poor quality in products or services. Quality training and workforce development Product-design verification Systems development and management Test and inspection of purchased materials Acceptance testing Inspection The costs associated with measuring, Testing evaluating or auditing products or services to Appraisal costs Checking labor assure conformance to quality standards and Setup for test or inspection performance requirements. Test and inspection equipment Quality audits Field testing Scrap Failure costs occurring prior to delivery or Internal failure costs shipment of the product, or the furnishing of a Rework service, to the customer. Material procurement costs Complaints in warranty Complaints out of warranty Failure costs occurring after delivery or Product service External failure costs shipment of the product — and during or after Product liability furnishing of a service — to the customer. Product recall 2/25/2021 MANUAL TESTING Loss of reputation 15

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. 2/25/2021 MANUAL TESTING 16

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 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 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. 2/25/2021 MANUAL TESTING 17

Verification & Validation Verification Validation 1. Are we building the System Right? 1. Are we building the Right System? 2. Verification is a static practice of verifying documents, design, code 2. Validation is a dynamic mechanism of validating and testing the actual product. and program. 3. It does not involve executing the code. 3. It always involves executing the code. 4. It is human based checking of documents and files. 4. It is computer based execution of program. 5. Verification uses methods like inspections, reviews, walkthroughs, 5. Validation uses methods like black box (functional) testing, gray box testing, and white and Desk-checking etc. box (structural) testing etc. 6. Verification is to check whether the software conforms to specifications. 6. Validation is to check whether software meets the customer expectations and requirements. 7. It can catch errors that validation cannot catch. It is low level exercise. 7. It can catch errors that verification cannot catch. It is High Level Exercise. 8. Target is requirements specification, application and software architecture, high level, complete design, and database design etc. 8. Target is actual product-a unit, a module, a bent of integrated modules, and effective final product. 9. Verification is done by QA team to ensure that the software is as per 9. Validation is carried out with the involvement of testing team. the specifications in the SRS document. 10. It generally comes first-done before validation. 2/25/2021 10. It generally follows after verification. MANUAL TESTING 18

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. 2/25/2021 MANUAL TESTING 19

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. 2/25/2021 MANUAL TESTING 20

SDLC Models 2/25/2021 MANUAL TESTING 21

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. 2/25/2021 MANUAL TESTING 22

SDLC OVERVIEW 2/25/2021 MANUAL TESTING 23

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. 2/25/2021 MANUAL TESTING 24

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. 2/25/2021 MANUAL TESTING 25

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. 2/25/2021 MANUAL TESTING 26

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. 2/25/2021 MANUAL TESTING 27

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. 2/25/2021 MANUAL TESTING 28

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. 2/25/2021 MANUAL TESTING 29

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. 2/25/2021 MANUAL TESTING 30

Waterfall Model 2/25/2021 MANUAL TESTING 31

Waterfall Model 2/25/2021 MANUAL TESTING 32

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. • • • 2/25/2021 MANUAL TESTING 33

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. 2/25/2021 MANUAL TESTING 34

Iterative Model • In Iterative model, iterative process starts with a simplementation 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. 2/25/2021 MANUAL TESTING 35

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. 2/25/2021 MANUAL TESTING 36

Iterative Model 2/25/2021 MANUAL TESTING 37

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. 2/25/2021 MANUAL TESTING 38

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. 2/25/2021 MANUAL TESTING 39

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. 2/25/2021 MANUAL TESTING 40

V-Model 2/25/2021 MANUAL TESTING 41

V-Model • The Requirements phase, a document describing what the software is required to do after the software is gathered 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. 2/25/2021 MANUAL TESTING 42

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. 2/25/2021 MANUAL TESTING 43

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. 2/25/2021 MANUAL TESTING 44

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. 2/25/2021 MANUAL TESTING 45

Agile Methodology A Generic Agile Development process 2/25/2021 MANUAL TESTING 46

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. 2/25/2021 MANUAL TESTING 47

Agile Methodology • Scrum Methodology 2/25/2021 MANUAL TESTING 48

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. 2/25/2021 MANUAL TESTING 49

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. 2/25/2021 MANUAL TESTING 50

Agile Methodology • Scrum Concepts: • Burn down chart. This chart, updated every day, shows the work remaining within the sprint. The burn down chart is used both to track sprint progress and to decide when items must be removed from the sprint backlog and deferred to the next sprint. • Product backlog is the complete list of requirements—including bugs, enhancement requests, and usability and performance improvements— that are not currently in the product release. • Scrum Master. The Scrum Master is the person responsible for managing the Scrum project. Sometimes it refers to a person who has become certified as a Scrum Master by taking Scrum Master training. • Sprint backlog is the list of backlog items assigned to a sprint, but not yet completed. In common practice, no sprint backlog item should take more than two days to complete. The sprint backlog helps the team predict the level of effort required to complete a sprint. 2/25/2021 MANUAL TESTING 51

Agile Methodology • Advantages of Agile Methodology • Customer satisfaction by rapid, continuous delivery of useful software. • People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. • Working software is delivered frequently (weeks rather than months). • Face-to-face conversation is the best form of communication. • Close, daily cooperation between business people and developers. • Continuous attention to technical excellence and good design. • Regular adaptation to changing circumstances. • Even late changes in requirements are welcomed 2/25/2021 MANUAL TESTING 52

Agile Methodology • Disadvantages of Agile Methodology • In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. • There is lack of emphasis on necessary designing and documentation. • The project can easily get taken off track if the customer representative is not clear what final outcome that they want. • Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources. 2/25/2021 MANUAL TESTING 53

STLC – Software Testing Life Cycle 2/25/2021 MANUAL TESTING 54

Testing Levels 2/25/2021 MANUAL TESTING 55

Unit Testing Life Cycle 2/25/2021 MANUAL TESTING 56

Component (Unit) Testing • Unit testing, a testing technique using which individual modules are tested to determine if there any issues by the developer himself. It is concerned with functional correctness of the standalone modules. • The main aim is to isolate each unit of the system to identify, analyze and fix the defects. Advantage of Unit Testing: • Reduces Defects in the Newly developed features or reduces bugs when changing the existing functionality. • Reduces Cost of Testing as defects are captured in very early phase. • Improves design and allows better refactoring of code. • Unit Tests, when integrated with build gives the quality of the build as well. 2/25/2021 MANUAL TESTING 57

UNIT Integration Testing • UNIT Integration Testing Approaches: • Top-down Integration Testing • Bottom-up Integration Testing • Sandwich Integration Testing • UNIT Integration Testing Types: • Incremental Integration Testing. • Big-bang Integration Testing 2/25/2021 MANUAL TESTING 58

Top Down Integration testing • Top-down integration testing is an integration testing technique used in order to simulate the behavior of the lower-level modules that are not yet integrated. Stubs are the modules that act as temporary replacement for a called module and give the same output as that of the actual product. • The replacement for the 'called' modules is known as 'Stubs' and is also used when the software needs to interact with an external system. Stub - Flow Diagram: 2/25/2021 MANUAL TESTING 59

Top Down Integration testing • The above diagrams clearly states that Modules 1, 2 and 3 are available for integration, whereas, below modules are still under development that cannot be integrated at this point of time. Hence, Stubs are used to test the modules. The order of Integration will be: 1, 2 1, 3 2, Stub 1 2, Stub 2 3, Stub 3 3, Stub 4 2/25/2021 MANUAL TESTING 60

Top Down Integration testing Testing Approach: • Firstly, the integration between the modules 1, 2 and 3 • Test the integration between the module 2 and stub 1, stub 2 • Test the integration between the module 3 and stub 3, stub 4 2/25/2021 MANUAL TESTING 61

Bottom UP Integration testing • Each component at lower hierarchy is tested individually and then the components that rely upon these components are tested. Bottom Up Integration - Flow Diagram 2/25/2021 MANUAL TESTING 62

Bottom UP Integration testing • The order of Integration by bottom up approach will be: 4, 2 5, 2 6, 3 7, 3 2, 1 3, 1 Testing Approach: • Firstly, Test 4, 5, 6, 7 individually using drivers. • Test 2 such that it calls 4 and 5 separately. If an error occurs we know that the problem is in one of the modules. • Test 1 such that it calls 3 and If an error occurs we know that the problem is in 3 or in the interface between 1 and 3 2/25/2021 MANUAL TESTING 63

Hybrid Integration testing • We know that Integration Testing is a phase in software testing in which standalone modules are combined and tested as a single entity. During that phase, the interface and the communication between each one of those modules are tested. There are two popular approaches for Integration testing which is Top down Integration Testing and Bottom up Integration Testing. • In Hybrid Integration Testing, we exploit the advantages of Top-down and Bottom-up approaches. As the name suggests, we make use of both the Integration techniques. 2/25/2021 MANUAL TESTING 64

Big Bang Integration testing • Big Bang Integration Testing is an integration testing strategy wherein all units are linked at once, resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate any errors found, because attention is not paid to verifying the interfaces across individual units. Big Bang Integration - Workflow Diagram 2/25/2021 MANUAL TESTING 65

Big Bang Integration testing Disadvantages of Big-Bang Testing • Defects present at the interfaces of components are identified at very late stage as all components are integrated in one shot. • It is very difficult to isolate the defects found. • There is high probability of missing some critical defects, which might pop up in the production environment. • It is very difficult to cover all the cases for integration testing without missing even a single scenario. 2/25/2021 MANUAL TESTING 66

System Testing • System Testing (ST) is a black box testing technique performed to evaluate the complete system the system's compliance against specified requirements. In System testing, the functionalities of the system are tested from an end-to-end perspective. • System Testing is usually carried out by a team that is independent of the development team in order to measure the quality of the system unbiased. It includes both functional and Non-Functional testing. • System testing involves testing the software code for following • Testing the fully integrated applications including external peripherals in order to check how components interact with one another and with the system as a whole. This is also called End to End scenario testing. . • Verify thorough testing of every input in the application to check for desired outputs. • Testing of the user's experience with the application. 2/25/2021 MANUAL TESTING 67

System Testing • Entry Criteria for System Testing: Unit Testing should be finished. Integration of modules should be fully integrated. As per the specification document software development is completed. Testing environment is available for testing (similar to Staging environment). Types of System Testing: • Usability Testing - Usability testing mainly focuses on the user's ease to use the application, flexibility in handling controls and ability of the system to meet its objectives • Load Testing - Load testing is necessary to know that a software solution will perform under real life loads. • Regression Testing - Regression testing involves testing done to make sure none of the changes made over the course of the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new software modules over time. • Recovery Testing - Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes. 2/25/2021 MANUAL TESTING 68

System Testing • Migration Testing - Migration testing is done to ensure that the software can be moved from older system infrastructures to current system infrastructures without any issues. • Functional Testing - Also known as functional completeness testing, functional testing involves trying to think of any possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it during functional testing. • Hardware/Software Testing - IBM refers to Hardware/Software testing as "HW/SW Testing". This is when the tester focuses his/her attention on the interactions between the hardware and software during system testing. 2/25/2021 MANUAL TESTING 69

User Acceptance Testing • User acceptance testing, a testing methodology where the clients/end users involved in testing the product to validate the product against their requirements. It is performed at client location at developer's site. • For industry such as medicine or aviation industry, contract and regulatory compliance testing and operational acceptance testing is also carried out as part of user acceptance testing. • UAT is context dependent and the UAT plans are prepared based on the requirements and NOT mandatory to execute all kinds of user acceptance tests and even coordinated and contributed by testing team. 2/25/2021 MANUAL TESTING 70

User Acceptance Testing in SDLC 2/25/2021 MANUAL TESTING 71

Acceptance Test Plan - Attributes • The Acceptance test plan has the following attributes • • • Introduction Acceptance Test Category operation Environment Test case ID Test Title Test Objective Test Procedure Test Schedule Resources • The acceptance test activities are designed to reach at one of the conclusions : • Accept the system as delivered • Accept the system after the requested modifications have been made • Do not accept the system 2/25/2021 MANUAL TESTING 72

Acceptance Test Plan – Report Attributes • The Acceptance test Report has the following attributes: • • • 2/25/2021 Report Identifier Summary of Results Variations Recommendations Summary of To-Do List Approval Decision MANUAL TESTING 73

Testing Types 2/25/2021 MANUAL TESTING 74

Functional Testing • Functional Testing is a testing technique that is used to test the features/functionality of the system or Software, should cover all the scenarios including failure paths and boundary cases. • Functional Testing Techniques: 2/25/2021 MANUAL TESTING 75

Functional Testing • The other major Functional Testing techniques include: • • • 2/25/2021 Unit Testing Integration Testing Smoke Testing User Acceptance Testing Localization Testing Interface Testing Usability Testing System Testing Regression Testing Globalization Testing MANUAL TESTING 76

Non Functional Testing • Non-Functional testing is a software testing technique that verifies the attributes of the system such as memory leaks, performance or robustness of the system. Non-Functional testing is performed at all test levels. • Non-Functional Testing Techniques: • • • • 2/25/2021 Baseline testing Compatibility testing Compliance testing Endurance testing Load testing Localization testing Internationalization testing Performance testing Recovery testing Resilience testing Security testing Scalability testing Stress testing Usability testing Volume testing MANUAL TESTING 77

Definitions • Smoke Test and Sanity Test: Smoke Sanity Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. 2 A smoke test is scripted--either using a written set of tests or an automated test A sanity test is usually unscripted. 3 A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide. A Sanity test is used to determine a small section of the application is still working after a minor change. 4 Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification). Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. 5 Smoke testing is normal health check up to a build of an application before taking it to testing in depth. sanity testing is to verify whether requirements are met or not, checking all features breadth-first. 1 2/25/2021 MANUAL TESTING 78

Definitions • Regression Testing and Retesting: Regression Testing: Testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software. Retesting: After a defect is detected and fixed, the software should be retested to confirm that the original defect has been successfully removed. This is called Confirmation Testing or Re-Testing. 2/25/2021 MANUAL TESTING 79

Testing Methodologies 2/25/2021 MANUAL TESTING 80

Black box Testing or Specification Based • Black-box testing is a method of software testing that examines the functionality of an application based on the specifications. It is also known as Specifications based testing. Independent Testing Team usually performs this type of testing during the software testing life cycle. • This method of test can be applied to each and every level of software testing such as unit, integration, system and acceptance testing. Behavioral Testing Techniques: • There are different techniques involved in Black Box testing. • • 2/25/2021 Equivalence Class Boundary Value Analysis Orthogonal Arrays Decision Tables State Models Exploratory Testing All-pairs testing MANUAL TESTING 81

Equivalence Partitioning • Equivalence Partitioning also called as equivalence class partitioning. It is abbreviated as ECP. It is a software testing technique that divides the input test data of the application under test into each partition at least once of equivalent data from which test cases can be derived. • An advantage of this approach is it reduces the time required for performing testing of a software due to less number of test cases. Example: • Assume that the application accepts an integer in the range 100 to 999. • Valid Equivalence Class partition: 100 to 999 inclusive. • Non-valid Equivalence Class partitions: less than 100, more than 999, decimal numbers and alphabets/non-numeric characters. 2/25/2021 MANUAL TESTING 82

Boundary Value Analysis • Boundary value analysis is a type of black box or specification based testing technique in which tests are performed using the boundary values. Example: • An exam has a pass boundary at 50 percent, merit at 75 percent and distinction at 85 percent. The Valid Boundary values for this scenario will be. • 49, 50 - for pass • 74, 75 - for merit • 84, 85 - for distinction 2/25/2021 MANUAL TESTING 83

Orthogonal Arrays • Orthogonal array testing is a systematic and statistical way of a black box testing technique used when number of inputs to the application under test is small but too complex for an exhaustive testing. Orthogonal Array Testing Characteristics: • OAT, is a systematic and statistical approach to pairwise interactions. • Executing a well-defined and a precise test is likely to uncover most of the defects. • 100% Orthogonal Array Testing implies 100% pairwise testing. Example: • Let us consider you have to identify the test cases for a Web Page that has 5 sections: Headlines, details, references and Comments, that can be displayed or not displayed or show Error message. You are required to design the test condition to test the interaction between different sections. 2/25/2021 MANUAL TESTING 84

Orthogonal Arrays • 1. Number of independent variables (factors) are = 4 • 2. Value that each variable can take = 3 values( displayed, not displayed and error message) • 3. Orthogonal array would be 34. 2/25/2021 MANUAL TESTING 85

Orthogonal Arrays • 5. Now, map this array with our requirements as below: • • 1 will represent “Is Displayed” value 2 will represent “not displayed” value 3 will represent “error message value” Factor A will represent “ Headlines” section Factor B will represent “Details” section Factor C will represent “references ”section Factor D will represent “Comment” section. Experiment no will represent “Test Cases #” • 6. After mapping, the table will look like: 2/25/2021 MANUAL TESTING 86

Orthogonal Arrays • Testing will fail if we fail to identify the good pairs. • Probability of not identifying the most important combination which can result in losing a defect. • Applying only this technique will not ensure the complete coverage. • It can find only those defects which arise due to pairs, as input parameters. 2/25/2021 MANUAL TESTING 87

Decision Table Testing • Decision Table Testing is a good way to deal with a combination of inputs, which produce different results. It helps reduce test effort in verifying each and every combinations of test data, at the same time ensuring complete coverage. • Example: To understand the importance of Decision Table Making we will see an example, let's consider the behavior of Flight Button for different combinations of Fly From & Fly To. • Rule 1: When destination for both Fly From & Fly To are not set the Flight Icon is disabled. In the decision table, we register values False for Fly From & Fly To and the outcome would be False, which is Flights Button will be disabled. Likewise, you can decide different outcome for different situation. 2/25/2021 MANUAL TESTING 88

Decision Table Testing 2/25/2021 MANUAL TESTING 89

Decision Table Testing • Rule 2: When Fly From destination is set but Fly to is not set, Flight button is disabled. Correspondingly, you register True for Fly from destination in the decision table, and the rest of the entries are false. • Rule 3: When Fly from destination is not set but Fly to destination is set, Flight button is disabled and you make entries in the decision table. • Rule 4: only when Fly to and Fly from destinations are set, Flights button is enabled and you make the corresponding entry in the decision table. 2/25/2021 MANUAL TESTING 90

Decision Table Testing • If you observe the outcomes for Rule 1, 2 & 3 it remains the same. So you can select any one of them and rule 4 for your testing. • The significance of this technique becomes immediately clear as the number of inputs increases. Number of possible Combinations is given by 2 ^ n , where n is the number of Inputs. For n = 10, which is very common in the web based testing, having big input forms, the number of combinations will be 1024. Obviously, you cannot test all but you will choose a rich sub-set of the possible combinations using decision based testing technique. 2/25/2021 MANUAL TESTING 91

State Transition Testing • State Transition testing, a black box testing technique, in which outputs are triggered by changes to the input conditions or changes to 'state' of the system. In other words, tests are designed to execute valid and invalid state transitions. • When to Use this Technique: • When we have sequence of events that occur and associated conditions that apply to those events. • When the proper handling of a particular event depends on the events and conditions that have occurred in the past. • It is used for real time systems with various states and transitions involved. • Deriving Test cases: • Understand the various state and transition and mark each valid and invalid state • Defining a sequence of an event that leads to an allowed test ending state • Each one of those visited state and traversed transition should be noted down • Steps 2 and 3 should be repeated until all states have been visited and all transitions traversed 2/25/2021 MANUAL TESTING 92

State Transition Testing • For test cases to have a good coverage, actual input values and the actual output values have to be generated. • Advantages: • Allows testers to familiarize with the software design and enables them to design tests effectively. • It also enables testers to cover the unplanned or invalid states. • Example: • A System's transition is represented as shown in the below diagram: 2/25/2021 MANUAL TESTING 93

State Transition Testing Tests Test 1 Test 2 Test 3 Start State Off On On Input Switch ON Switch Off Switch off Output Light ON Light Off Fault Finish State ON OFF On 2/25/2021 MANUAL TESTING 94

All-pairs testing • All-pairs also known as pairwise testing is a testing approach taken for testing the software using combinatorial method. It's a method to test all the possible discrete combinations of the parameters involved. Example • An application with simple list box with 10 elements (Let's say 0, 1, 2, 3, 4, 5, 6, 7, 8, 9) along with a checkbox, radio button, Text Box and OK Button. The Constraint for the Text box is it can accept values only between 1 and 100. Below are the values that each one of the GUI objects can take: • • • 2/25/2021 List Box - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 Check Box - Checked or Unchecked Radio Button - ON or OFF Text Box - Any Value between 1 and 100 Exhaustive combination of the application is calculated. MANUAL TESTING 95

All-pairs testing • • • List Box = 10 Check Box = 2 Radio Button = 2 Text Box = 100 Total Number of Test Cases using Cartesian Method : 10*2*2*100 = 4000 Total Number of Test Cases including Negative Cases will be > 4000 • Now, we will calculate the number of cases using software testing technique is 2*2*2*3 = 24 (including negative cases). • Now, we can still reduce the combination further into All-pairs technique. • Step 1 : Order the values such that one with most number of values is the first and the least is placed as the last variable. • Step 2 : Now, start filling the table column by column. List box can take 2 values. • Step 3 : The next column under discussion would be check box. Again, Check box can take 2 values. • Step 4 : Now, we need to ensure that we cover all combinations between list box and Check box. 2/25/2021 MANUAL TESTING 96

All-pairs testing • Step 5 : Now, we will use the same strategy for checking the Radio Button. It can take 2 values. • Step 6 : Verify if all the pair values are covered as shown in the table below. • Exhaustive Combination results in > 4000 Test Cases. • Conventional Software Testing technique results in 24 Test Cases. • Pair Wise Software Testing technique results in just 6 Test Cases. 2/25/2021 MANUAL TESTING 97

White box Testing or Structure Based • White box testing is a testing technique, that examines the program structure and derives test data from the program logic/code. The other names of glass box testing are clear box testing, open box testing, logic driven testing or path driven testing or structural testing. White Box Testing Techniques: • Statement Coverage - This technique is aimed at exercising all programming statements with minimal tests. • Branch Coverage - This technique is running a series of tests to ensure that all branches are tested at least once. • Path Coverage - This technique corresponds to testing all possible paths which means that each statement and branch is covered. 2/25/2021 MANUAL TESTING 98

Cyclomatic Complexity • Cyclomatic complexity is a source code complexity measurement that is being correlated to a number of coding errors. It is calculated by developing a Control Flow Graph of the code that measures the number of linearly-independent paths through a program module. • • • Cyclomatic complexity = E - N + P where, E = number of edges in the flow graph. N = number of nodes in the flow graph. P = number of nodes that have exit points 2/25/2021 MANUAL TESTING 99

Cyclomatic Complexity • • • IF A = 10 THEN IF B > C THEN A = B ELSE A = C ENDIF Print A Print B Print C 2/25/2021 MANUAL TESTING 100

Cyclomatic Complexity Flow Graph The Cyclomatic complexity is calculated using the above control flow diagram that shows seven nodes(shapes) and eight edges (lines), hence the cyclomatic complexity is 8 - 7 + 2 = 3 2/25/2021 MANUAL TESTING 101

Statement, Branch/Decision & Path Coverage • Statement Coverage: (Find shortest path such that all nodes are covered at-least once) In this, the test case is executed in such a way that every node is traversed at-least once. Branch/Decision Coverage: (Find shortest path such that all the Edges are covered at-least once) Test coverage criteria requires enough test cases such that each condition in a decision takes on all possible outcomes at least once, and each point of entry to a program or subroutine is invoked at least once. That is, every branch (decision) taken each way, true and false. It helps in validating all the branches in the code making sure that no branch leads to abnormal behavior of the application. • Path Coverage: (Find all the paths from source to destination) In this the test case is executed in such a way that every path is executed at least once. All possible control paths taken, including all loop paths taken zero, once, and multiple (ideally, maximum) items in path coverage technique, the test cases are prepared based on the logical complexity measure of a procedural design. In this type of testing every statement in the program is guaranteed to be executed at least one time. Flow Graph, Cyclomatic Complexity and Graph Metrics are used to arrive at basis path 2/25/2021 MANUAL TESTING 102

How to calculate Statement Coverage, Branch Coverage and Path Coverage? • Example: Read P Read Q IF P+Q > 100 THEN Print “Large” ENDIF If P > 50 THEN Print “P Large” ENDIF 2/25/2021 MANUAL TESTING 103

How to calculate Statement Coverage, Branch Coverage and Path Coverage? 2/25/2021 MANUAL TESTING 104

How to calculate Statement Coverage, Branch Coverage and Path Coverage? • Statement Coverage (SC): • To calculate Statement Coverage, find out the shortest number of paths following which all the nodes will be covered. Here by traversing through path 1 A-2 C-3 D-E-4 G-5 H all the nodes are covered. So by traveling through only one path all the nodes 12345 are covered, so the Statement coverage in this case is 1. 2/25/2021 MANUAL TESTING 105

Statement Coverage Testing • The statement coverage is also known as line coverage or segment coverage. • The statement coverage covers only the true conditions. • Through statement coverage we can identify the statements executed and where the code is not executed because of blockage. • In this process each and every line of code needs to be checked and executed. Advantage of statement coverage: • It verifies what the written code is expected to do and not to do • It measures the quality of code written • It checks the flow of different paths in the program and it also ensure that whether those path are tested or not. • Disadvantage of statement coverage: • It cannot test the false conditions. • It does not report that whether the loop reaches its termination condition. • It does not understand the logical operators. 2/25/2021 MANUAL TESTING 106

Statement Coverage Testing • The statement coverage can be calculated as shown below: 2/25/2021 MANUAL TESTING 107

How to calculate Statement Coverage, Branch Coverage and Path Coverage? Branch Coverage (BC): • To calculate Branch Coverage, find out the minimum number of paths which will ensure covering of all the edges. In this case there is no single path which will ensure coverage of all the edges at one go. By following paths 1 A-2 C-3 D-E-4 G-5 H, maximum numbers of edges (A, C, D, E, G and H) are covered but edges B and F are left. To covers these edges we can follow 1 A-2 B-E-4 F. By the combining the above two paths we can ensure of traveling through all the paths. Hence Branch Coverage is 2. The aim is to cover all possible true/false decisions. 2/25/2021 MANUAL TESTING 108

How to calculate Statement Coverage, Branch Coverage and Path Coverage? Path Coverage (PC): Path Coverage ensures covering of all the paths from start to end. All possible paths are 1 A-2 B-E-4 F 1 A-2 B-E-4 G-5 H 1 A-2 C-3 D-E-4 F So path coverage is 4. Thus for the above example SC=1, BC=2 and PC=4. Memorize these…. 100% LCSAJ coverage will imply 100% Branch/Decision coverage 100% Path coverage will imply 100% Statement coverage 100% Branch/Decision coverage will imply 100% Statement coverage 100% Path coverage will imply 100% Branch/Decision coverage Branch coverage and Decision coverage are same. 2/25/2021 MANUAL TESTING 109

White box Testing or Structure Based Advantages of White Box Testing: • Forces test developer to reason carefully about implementation. • Reveals errors in "hidden" code. • Spots the Dead Code or other issues with respect to best programming practices. Disadvantages of White Box Testing: • Expensive as one has to spend both time and money to perform white box testing. • Every possibility that few lines of code are missed accidentally. • In-depth knowledge about the programming language is necessary to perform white box testing. 2/25/2021 MANUAL TESTING 110

Static Techniques 2/25/2021 MANUAL TESTING 111

Static Techniques • Static Testing, a software testing technique in which the software is tested without executing the code. It has two parts as listed below: • Review - Typically used to find and eliminate errors or ambiguities in documents such as requirements, design, test cases, etc. • Static analysis - The code written by developers are analyzed (usually by tools) for structural defects that may lead to defects. 2/25/2021 MANUAL TESTING 112

Types of Reviews: • The types of reviews can be given by a simple diagram: 2/25/2021 MANUAL TESTING 113

Types of Reviews Informal Review: • No Formal Process. • Results may be documented • Main Purpose is Inexpensive way to get some benefit. Walkthrough: • Meeting led by author. • May take the form of scenarios, dry runs, peer group participation. • Open ended sessions • Main Purpose is Learning, gaining understanding , finding defects. 2/25/2021 MANUAL TESTING 114

Types of Reviews Technical Review: • Documented, defined defect detection process. • May be performed as a peer review without management participation. • Led by trained moderator not the author. • Optional use of checklists. • Preparation of review report which includes the list of findings. • Main Purpose is discussing , making decisions, evaluating alternatives, finding defects, solving problems, and checking conformance to specifications , plans, regulations and standards. 2/25/2021 MANUAL TESTING 115

Types of Reviews Inspection: • Led by trained moderator not the author. • Usually conducted as a peer examination • Defined roles. • Includes metrics gathering. • Formal process based on rules and checklists. • Specified entry and exit criteria for acceptance of the software product. • Pre Meeting preparation. • Inspection report including list of findings. • Formal follow up process. • Optional Reader. • Main Purpose is finding defects. 2/25/2021 MANUAL TESTING 116

Types of Reviews • Formal review consists of 6 main steps 1. 2. 3. 4. 5. 6. Planning Kick-Off Preparation Review Meeting Rework Follow-Up 2/25/2021 MANUAL TESTING 117

Reviews Roles and Responsibilities • The moderator (or review leader) leads the review process. He or she deter-mines, in cooperation with the author, the type of review, approach and the composition of the review team. The moderator performs the entry check and the follow-up on the rework, in order to control the quality of the input and output of the review process. The moderator also schedules the meeting, disseminates documents before the meeting, coaches other team members, paces the meeting, leads possible discussions and stores the data that is collected. • The author : As the writer of the document under review, the author's basic goal should be to learn as much as possible with regard to improving the quality of the document, but also to improve his or her ability to write future documents. The author's task is to illuminate unclear areas and to understand the defects found. • The scribe : During the logging meeting, the scribe (or recorder) has to record each defect mentioned any suggestions for process improvement. In practice it is often the author who plays this role, ensuring that the log is readable and understand-able. If authors record their own defects, or at least make their own notes in their own words, it helps them to understand the log better during rework. However, having someone other than the author take the role of the scribe (e. g. the moderator) can have significant advantages, since the author is freed up to think about the document rather than being tied down with lots of writing. 2/25/2021 MANUAL TESTING 118

Reviews Roles and Responsibilities • The reviewers : The task of the reviewers (also called checkers or inspectors) is to check any material for defects, mostly prior to the meeting. The level of thoroughness required depends on the type of review. The level of domain knowledge or technical expertise needed by the reviewers also depends on the type of review. Reviewers should be chosen to represent different perspectives and roles in the review process. In addition to the document under review, the material reviewers receive includes source documents, standards, checklists, etc. In general, the fewer source and reference documents provided, the more domain expertise regarding the content of the document under review is needed. • The manager : The manager is involved in the reviews as he or she decides on the execution of reviews, allocates time in project schedules and determines whether review process objectives have been met. The manager will also take care of any review training requested by the participants. Of course a manager can also be involved in the review itself depending on his or her background, playing the role of a reviewer if this would be helpful. 2/25/2021 MANUAL TESTING 119

Static Analysis by Tools 2/25/2021 MANUAL TESTING 120

Test Case Development 2/25/2021 MANUAL TESTING 121

2/25/2021 MANUAL TESTING 122

2/25/2021 MANUAL TESTING 123

Use Case Name Basic Flow Request for Password Reset 1 User navigates to Sign in Page on the Portal. 2 User clicks on Forgot Password. 3 User is prompted to enter his registered Email Address. . [Alt-3 A 1 ], 4 System authenticates the Email Address and displays three security questions which user setup earlier at the time of Self registration. 5 User enters correct answers for all security questions. 6 System authenticates the answer to three Security Questions. 7 User enters New Password and reenter it to confirm the same while System prepopulates the user email address. [Alt 4 A 3] 8 System validates new password as per the password policy. 9 System resets the password and asks user to Sign in again. 3 A 1. Incorrect Email Address Alternative Flows 1 System displays an error message for invalid Username and asks User to reenter the Username. 2 Go to step 3 of Basic Flow. 5 A 2. Incorrect Answers to Security Questions. 1 System displays an error message for incorrect answer for any of three security questions and asks User to re-enter it. 2 Go to Step 5 of Basic Flow. 7 A 3. New Password is non complaint to Password Policy 1 System displays an error message for non-complaint password and also displays password guidelines for user to follow. 2 Go to Step 7 of Basic Flow. 7 A 4. New Password and Confirmed Password don’t match. 1 System displays an error for unmatched New and Confirmed Password and asks User to re-enter both of them. 2 Go to Step 7 of Basic Flow. Exception Flows 2/25/2021 3 E 1. User Account is disabled 1 System displays an error message to confirm that User account is disabled. 2 Use Case Ends MANUAL TESTING 124

Enter Temporary Password Page 2/25/2021 MANUAL TESTING 125

Create New Password Page 2/25/2021 MANUAL TESTING 126

Security Question Page 2/25/2021 MANUAL TESTING 127

Confirmation email Notification 2/25/2021 MANUAL TESTING 128

Scenario 2 Organization , User and Department creation 2/25/2021 MANUAL TESTING 129

Scenario 2 Upload a Document 2/25/2021 MANUAL TESTING 130

Scenario 2 Upload a Document 1 2 E 1. Size Exceed 1. 1 When the size of the uploaded document exceeds the limit specified on the site. 1. 2 Present the user with appropriate error message 1. 3 Bring control back to the page 1. 4 Allowing them to upload a document again 2 3 E 1 - Mandatory fields 2. 1 Display an exception message indicating which fields are mandatory 2. 2 User cannot proceed without filling all the mandatory fields. 2/25/2021 MANUAL TESTING 131

Scenario 2 Upload a Document 1 2 E 1. Size Exceed 1. 1 When the size of the uploaded document exceeds the limit specified on the site. 1. 2 Present the user with appropriate error message 1. 3 Bring control back to the page 1. 4 Allowing them to upload a document again 2 3 E 1 - Mandatory fields 2. 1 Display an exception message indicating which fields are mandatory 2. 2 User cannot proceed without filling all the mandatory fields. 2/25/2021 MANUAL TESTING 132

2/25/2021 MANUAL TESTING 133

Test Management 2/25/2021 MANUAL TESTING 134

Test Planning • Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a baseline plan to track the progress of the project. It also defines the size of the test effort. • It is the main document often called as master test plan or a project test plan and usually developed during the early phase of the project. Test Planning Activities: • To determine the scope and the risks that need to be tested and that are NOT to be tested. • Documenting Test Strategy. • Making sure that the testing activities have been included. • Deciding Entry and Exit criteria. • Evaluating the test estimate. • Planning when and how to test and deciding how the test results will be evaluated, and defining test exit criterion. • The Test artefacts delivered as part of test execution. • Defining the management information, including the metrics required and defect resolution and risk issues. 2/25/2021 MANUAL TESTING 135 • Ensuring that the test documentation generates repeatable test assets.

Test Plan Identifier S. No. Parameter Description 1. Test plan identifier Unique identifying reference. 2. Introduction A brief introduction about the project and to the document. 3. Test items A test item is a software item that is the application under test. 4. Features to be tested A feature that needs to tested on the testware. 5. Features not to be tested Identify the features and the reasons for not including as part of testing. 6. Approach Details about the overall approach to testing. 7. Item pass/fail criteria Documented whether a software item has passed or failed its test. 8. Test deliverables The deliverables that are delivered as part of the testing process, such as test plans, test specifications and test summary reports. 9. Testing tasks All tasks for planning and executing the testing. 10. Environmental needs Defining the environmental requirements such as hardware, software, OS, network configurations, tools required. 11. Responsibilities Lists the roles and responsibilities of the team members. 12. Staffing and training needs Captures the actual staffing requirements and any specific skills and training requirements. 13. Schedule States the important project delivery dates and key milestones. 14. Risks and Mitigation High-level project risks and assumptions and a mitigating plan for each identified risk. Approvals Captures all approvers of the document, their titles and the sign off date. 15. 2/25/2021 MANUAL TESTING 136

Test Strategy • A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document. • The Test Strategy document is a static document meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents such as the Test Plan draws its contents from those standards set in the Test Strategy Document. • Components of the Test Strategy document • • • Scope and Objectives Business issues Roles and responsibilities Communication and status reporting Test deliverability Industry standards to follow Test automation and tools Testing measurements and metrics Risks and mitigation Defect reporting and tracking Change and configuration management Training plan 2/25/2021 MANUAL TESTING 137

Incident Management • While reporting the bug to developer, your Bug Report should contain the following information • While executing test cases you may find that actual results vary from the expected results. This is nothing but a defect also called incident , bug , problem or issues. • Defect_ID - Unique identification number for the defect. • Defect Description - Detailed description of the defect including information about the module in which defect was found. • Version - Version of the application in which defect was found. • Steps - Detailed steps along with screenshots with which the developer can reproduce the defects. • Date Raised - Date when the defect is raised • Reference- where in you Provide reference to the documents like. requirements, design, architecture or may be even screenshots of the error to help understand the defect • Detected By - Name/ID of the tester who raised the defect • Status - Status of the defect , more on this later • Fixed by - Name/ID of the developer who fixed it 2/25/2021 MANUAL TESTING 138

Incident Management • Date Closed - Date when the defect is closed • Severity which describes the impact of the defect on the application • Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively 2/25/2021 MANUAL TESTING 139

Tool Support for Testing 2/25/2021 MANUAL TESTING 140

Tool Support for Testing 1. 2. 3. 4. 2/25/2021 Tools that are directly used in testing such as test execution tolls, test data generation tools and result comparison tools. Tools that help in managing the testing process such as those used to manage tests, test result data, requirements, incidents, defects etc. Tools are used in reconnaissance or in simple terms exploration (e. g. : tools that monitor file activity for an application). Any tool that aids in testing. MANUAL TESTING 141

Test Tool Classification 1. 2. 3. There are number of tools that support different aspects of testing. Tools can be classified based on several criteria such as purpose/ Commercial/Free/Open Source / Shareware and Technology Used. Some tools clearly support. Tool Support Test Management for Testing: 1. Test Management tools: These tools provide interfaces for executing tests, tracking defects and managing requirements. They also have version control. 2. Requirement management tools: These tools store requirement statements, store the attributes for the requirements, provide unique identifiers and support tracing the requirements to individual tests. These tools also help with identifying inconsistent or missing requirements. 3. Incident management tools (Defect Tracking tools): These tools store and manage incident reports. 4. Configuration Management tools: These are necessary for storage and version management of test ware and software. 2/25/2021 MANUAL TESTING 142

Test Tool Classification Tool Support for Static Testing: Static testing tools provide a cost effective way of finding more defects at an earlier stage in the development process. Review Tools: These tools assists with the review process, Checklists, Review guidelines and are used to store and communicate review comments. Static Analysis Tools: These tools help developers and testers find defects prior to dynamic testing by providing support for enforcing coding standards. Modelling Tools: These tools are used to validate software models by enumerating inconsistencies and finding defects. These tools can often aid in generating some test cases based on the model. 2/25/2021 MANUAL TESTING 143

Test Tool Classification Tool Support for Test Specification: Test Design Tools: These tools are used to generate test inputs or executable tests, graphical user interfaces, design models or code. Test Data preparation tools: Test data preparation tools manipulate databases, files to set up a test data to be used during the execution of tests to ensure security through anonymity. Tool Support for test execution and Logging: These tools enable tests to be executed automatically or semi automatically using stored inputs and expected outcomes , through a use scripting language and usually provide a test log for each test run. They can also be used to record test. Test Harness/Unit Test Framework tools: A unit Test harness or framework facilitates the testing of components or parts of system by simulating the environment in which that test object will run, through the provisions of mock objects as stubs or drivers. Test Comparators: Test Comparators determine differences between files, databases or test results. 2/25/2021 MANUAL TESTING 144

Testing Definitions 2/25/2021 MANUAL TESTING 145

Definitions • Smoke Test and Sanity Test: Smoke Sanity Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep. 2 A smoke test is scripted--either using a written set of tests or an automated test A sanity test is usually unscripted. 3 A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide. A Sanity test is used to determine a small section of the application is still working after a minor change. 4 Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification). Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. 5 Smoke testing is normal health check up to a build of an application before taking it to testing in depth. sanity testing is to verify whether requirements are met or not, checking all features breadth-first. 1 2/25/2021 MANUAL TESTING 146

Definitions 2. Fault Masking & Latent Masking: • Fault Masked: Masked Defect is a defect which is hiding another defect. • Latent Masked: Latent Defect is one which has been in the system for a long time; but is discovered now. Ie. A defect which has been there for a long time and should have been detected earlier is known as Latent Defect. One of the reasons why Latent Defect exists is because exact set of conditions haven’t met. 3. Data sensitivity fault: A fault that causes a failure in response to some particular pattern of data. 4. Defect density: Ratio of the number of defects to program length. 5. Mutation testing: A method whereby errors are purposely inserted into a program under test to verify that the test can detect the error. Also known as error seeding. 6. What is Test Basis and its typical types? Test basis is defined as the source of information or the document that is needed to write test cases and also for test analysis. • Test basis should be well defined and adequately structured so that one can easily identify test conditions from which test cases can be derived. 2/25/2021 MANUAL TESTING 147

Definitions Typical Test Basis: • Requirement document • Test Plan • Codes Repository • Business Requirement 7. What is Test Bed? • The test execution environment configured for testing. Test bed consists of specific hardware, software, Operating system, network configuration, the product under test, other system software and application software. • Test Bed Configuration: • It is the combination of hardware and software environment on which the tests will be executed. It includes hardware configuration, operating system settings, software configuration, test terminals and other support to perform the test. 2/25/2021 MANUAL TESTING 148

Definitions 8. What is Test case? • A test case is a document, which has a set of test data, preconditions, expected results and post conditions, developed for a particular test scenario in order to verify compliance against a specific requirement. 9. What are the Test case parameters? • Test Case ID • Test Scenario • Test Case Description • Test Steps • Prerequisite • Test Data • Expected Result • Test Parameters • Actual Result • Environment Information 2/25/2021 MANUAL TESTING 149 • Comments

Definitions 10. What is a Test Suite? • Test suite is a container that has a set of tests which helps testers in executing and reporting the test execution status. It can take any of the three states namely Active, In progress and completed. • A Test case can be added to multiple test suites and test plans. After creating a test plan, test suites are created which in turn can have any number of tests. 11. What is Test Data? • Test Data is data that is used to execute the tests on test ware. Test data needs to be precise and exhaustive to uncover the defects. 12. What is Test Driver? • Test Drivers are used during Bottom-up integration testing in order to simulate the behavior of the upper level modules that are not yet integrated. Test Drivers are the modules that act as temporary replacement for a calling module and give the same output as that of the actual product. 2/25/2021 MANUAL TESTING 150

Definitions 13. What is Test Environment? • Test Environment consists of elements that support test execution with software, hardware and network configured. Test environment configuration must mimic the production environment in order to uncover any environment/configuration related issues. 14. What is Test Execution? • Test execution is the process of executing the code and comparing the expected and actual results. Following factors are to be considered for a test execution process: • Based on a risk, select a subset of test suite to be executed for this cycle. • Assign the test cases in each test suite to testers for execution. • Execute tests, report bugs, and capture test status continuously. • Resolve blocking issues as they arise. • Report status, adjust assignments, and reconsider plans and priorities daily. • Report test cycle findings and status. 2/25/2021 MANUAL TESTING 151

Definitions 15. What is a Test Plan? • Test planning, the most important activity to ensure that there is initially a list of tasks and milestones in a baseline plan to track the progress of the project. It also defines the size of the test effort. 16. What are Test Steps? • Test Steps describe the execution steps and expected results that are documented against each one of those steps. • Each step is marked pass or fail based on the comparison result between the expected and actual outcome. 17. What is Test Strategy? • Test Strategy is also known as test approach defines how testing would be carried out. Test approach has two techniques: • Proactive - An approach in which the test design process is initiated as early as possible in order to find and fix the defects before the build is created. • Reactive - An approach in which the testing is not started until after design and coding are completed. 2/25/2021 MANUAL TESTING 152

Definitions 18. What is an Entry Criterion? • Entry criterion is used to determine when a given test activity should start. It also includes the beginning of a level of testing, when test design or when test execution is ready to start. 19. What is an Error Guessing? • Error guessing is a testing technique that makes use of a tester's skill, intuition and experience in testing similar applications to identify defects that may not be easy to capture by the more formal techniques. It is usually done after more formal techniques are completed. 20. What is an Exit Criterion? • Exit criterion is used to determine whether a given test activity has been completed or NOT. Exit criteria can be defined for all of the test activities right from planning, specification and execution. • Exit criterion should be part of test plan and decided in the planning stage. 2/25/2021 MANUAL TESTING 153

Definitions 21. What is Fuzz Testing? • Fuzz testing is a software testing technique using which a random data is given as the inputs to the system. If the application fails, then those issues/defects are to be addressed by the system. In short, unexpected or random inputs might lead to unexpected results. 22. What is Globalization Testing? • A product is said to be Globalized when that particular product can be run independent of its geographical and cultural environment. This type of testing technique validates whether the application can be used all over the world that accepts all the language texts. 23. What is Gorilla Testing? • Gorilla Testing is a testing technique in which testers, sometimes developers also join hands with testers to test a particular module thoroughly in all aspects. • Gorilla Testing, a technique in which repetitive Manual Testing process, which a tester would have done several times before, is done again to test the robustness of the system. 2/25/2021 MANUAL TESTING 154

IEEE 829 Standard Templates 2/25/2021 MANUAL TESTING 155

IEEE 829 Standard Templates 1. TEST DESIGN SPECIFICATION TEMPLATE • • Test design specification identifier Features to be tested Approach Refinements Test identification Feature Pass/Fail criteria 2. TEST CASE SPECIFICATION TEMPLATE • • Test case specification identifier Output specifications Test items Environmental needs Input specifications Special procedural requirements Inter case dependencies 2/25/2021 MANUAL TESTING 156

IEEE 829 Standard Templates 3. TEST PROCEDURE SPECIFICATION TEMPLATE • Test procedure specification identifier • Purpose • Special requirements • Procedure steps 4. TEST PLAN TEMPLATE • Test plan identifier • Test deliverables • Introduction • Test tasks • Test items • Environmental needs 2/25/2021 • Features to be tested Responsibilities • Features not to be tested Staffing and training needs • Approach Schedule • Item pass/fail criteria Risks and contingencies • Suspension and resumption criteria Approvals MANUAL TESTING 157

IEEE 829 Standard Templates 5. TEST LOG TEMPLATE • Test log identifier • Activity and event entries (execution description, procedure results, environmental information, anomalous events, incident report identifiers) • Description (items being tested, environment in which the testing is conducted) 6. TEST SUMMARY REPORT TEMPLATE • Test summary report identifier • Evaluation • Summary of activities • Variances • Approvals • Comprehensive assessment • Summary of results 2/25/2021 MANUAL TESTING 158

IEEE 829 Standard Templates 7. TEST INCIDENT REPORT TEMPLATE • Test incident report identifier • Summary • Incident description (inputs, expected • results, actual results, anomalies, • date and time, procedure step, • environment, attempts to repeat, • testers and observers) Impact 2/25/2021 MANUAL TESTING 159

ISTQB Foundation Exam Details 2/25/2021 MANUAL TESTING 160

ISTQB Foundation Exam Details 1. Criteria for foundation Level Exam • Candidates for the Foundation Level certification have at least six months’ practical experience in a professional testing role. 2. General Guidelines for Preparing ISTQB Exam • 40 Questions • 65% pass mark • 75 minutes • Multiple choice questions • Only one correct answer • No negative marking • All questions from syllabus • Read the syllabus very carefully 2/25/2021 MANUAL TESTING 161

ISTQB Foundation Exam Details 3. Question breakup • 50% K 1 (remember, recall type) • 30% K 2 (Compare, contrast type) • 20% K 3 (Analyze, apply type. Numerical type as well) 4. Number of Questions Expected from each chapter – The principles of testing = 7 – Testing throughout the life-cycle = 6 – Static testing = 3 – Test design techniques = 12 – Test management = 8 – Tool support for testing = 4 2/25/2021 MANUAL TESTING 162

2/25/2021 MANUAL TESTING 163

What is an Internationalization Testing? Internationalization testing is the process of verifying the application under test to work uniformly across multiple regions and cultures. The main purpose of internationalization is to check if the code can handle all international support without breaking functionality that might cause data loss or data integrity issues. Internationalization Checklists: • Testing to check if the product works across settings. • Verifying the installation using various settings. • Verify if the product works across language settings and currency settings. 2/25/2021 MANUAL TESTING 164

What is Localization Testing? Localization testing is performed to verify the quality of a product's localization for a particular target culture/locale and is executed only on the localized version of the product. Localization Testing - Characteristics: • Modules affected by localization, such as UI and content • Modules specific to Culture/locale-specific, language-specific, and region-specific • Critical Business Scenarios Testing • Installation and upgrading tests run in the localized environment • Plan application and hardware compatibility tests according to the product's target region. Localization Testing - UI Testing: • Check for linguistic errors and resource attributes • Typographical errors • Verify the systems adherence to the input, and display environment standards • Usability testing of the User interface • Verify cultural appropriateness of UI such as color, design, etc. 2/25/2021 MANUAL TESTING 165

What is Globalization Testing? A product is said to be Globalized when that particular product can be run independent of its geographical and cultural environment. This type of testing technique validates whether the application can be used all over the world that accepts all the language texts. What needs to be Tested ? • Sensitivity to the language vocabulary • Date and time formatting • Currency handling • Paper sizes for printing • Address and telephone number formatting • Zip Code Format Advantages of Globalization Testing • It reduces overall testing and support costs • It helps us to reduce time for testing which result faster time-to-market • It is more flexible and product is easily scalable 2/25/2021 MANUAL TESTING 166

S. NO 1 2 3 Client Server Application Web Based Applications This type of testing usually done for 2 tier applications (usually developed for LAN) This is done for 3 tier applications (developed for Internet / intranet / xtranet) Here we will be having front-end and backend. Here we will be having Browser, web server and DB server. The applications accessible in browser would be developed in HTML, The application launched on front-end will be having forms and reports DHTML, XML, Java. Script etc. (We can monitor through these which will be monitoring and manipulating data. applications). 4 5 6 Applications developed in VB, VC++, Core Java, C, C++, D 2 K, Power. Builder etc Applications for the web server would be developed in Java, ASP, JSP, VBScript, Java. Script, Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help of these programs developed). The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql, Quadbase. The DBserver would be having oracle, sql server, sybase, mysql etc. The tests performed on these types of applications would be – User interface testing – Manual support testing – Functionality testing – Compatibility testing & configuration testing – Intersystem testing The tests performed on these types of applications would be – User interface testing – Functionality testing – Security testing – Browser compatibility testing – Load / stress testing – Interoperability testing/intersystem testing – Storage and data volume testing 2/25/2021 MANUAL TESTING 167

Questions Write test cases of fan? • Test case 1: Check whether it moves or not. • Description: Ensure that fan should moves properly. • Expected result: Fan should be moving. • Test case 2: Check it should have minimum 3 blades. • Description: Ensure that length of fan blades should be considered to 3 blades. • Expected result: Length of fan blades should not be shorter than 3 blades. • Test case 3: Check it should be on when electric button (switch) is on. • Description: Ensure that fan should start working when electric switch is on. • Expected result: Fan should be on when electric button (switch) is on. • Test case 4: Check whether Speed of the fan definitely be controlled by the regulator. • Description: Ensure that speed of fan should be controlled. • Expected result: Fan speed should be controlled by the regulator. 2/25/2021 MANUAL TESTING 168

Questions Test case 5: Check it should be stop working once the electric switch off. Description: Ensure that fan should stop working once the electric switch is off. Expected result: Fan should be off once electric switch is off. Test case 6: Check the proper “company name” should be displayed on fan or not. Description: Always ensure that name of company should be properly displayed on fan. Expected result; Proper name of company should be displayed on fan. Test case 7: Check Fan should always work in clock-wise direction. Description: Ensure that direction of fan should be in clock-wise. Expected result: Fan should work in clock-wise direction. Test case 8: Check the color of the fan blades. Description: Always ensure that all the blades of fan have same color. Expected result: Color of all the blades of fan should be of same color. Test case 9: Check the fan during (while) in motion should not vibrate. Description: Ensure that the fan during (while) in motion should not vibrate. Expected result: Fan should not vibrate. 2/25/2021 MANUAL TESTING 169

Questions Test case 10: Check whether the blades should have decent distance from the ceiling. Description: Ensure that fan blades should have decent distance from the ceiling. Expected result: Fan blades should have decent distance. Test case 11: Check the size of the fan blades. Description: Always ensure that all the blades of fan have same size. Expected result: Size of all the blades of fan should be of same size. Test case 12: Check whether it operates in low voltage. Description: Ensure that fan should properly operate in low voltage. Expected result: Fan should be properly operated on low voltage. Test case 13: Check whether speed varies when regulator adjusted. Description: Ensure that speed of fan varies when we adjust the regulator. Expected result: Speed of fan varies while adjusting the regulator. 2/25/2021 MANUAL TESTING 170

Distinction among BRS, FRS and SRS FRS BRS 1. It means “Software Requirement 1. It means “Functional Requirement Specification” 1. It means “Business Specification” (SRS). (FRS). Requirement Specification” (BRS). 2. It deals with resources provided by Company. 2. It deals with requirements given by client. 3. It always includes Use cases to 3. In this Use cases are not included. describe the interaction of the system. 4. It is developed by System Analyst. 4. It is always developed by developers and And it is also known as User engineers. Requirement Specifications. 5. In SRS, we describe all the 5. In FRS, we describe the particular functionalities business functionalities of the of every single page in detail from start to end. application. 6. SRS tells means explains all the functional and non functional requirements. 7. SRS is a complete document which describes the behavior of the system which would be developed. 2/25/2021 6. FRS tells means explains the sequence of operations to be followed on every single process. 2. It deals with aspects of business requirements. 3. In this Use cases are also not included. 4. It is always developed by Business Analyst. 5. In BRS, we defines what exactly customer wants. This is the document which is followed by team from start to end. 6. BRS tells means explains the story of whole requirements. 7. FRS is a document, which describes the 7. BRS is a simple document, Functional requirements i. e. all the functionalities of which describes the business the system would be easy and efficient for end user. requirements on a quite broad level. MANUAL TESTING 171