Introduction to Software Testing and Quality Assurance Introduction to Software Testing : Nature of errors and the need for testing Definition of Quality and Quality Assurance : Understanding quality in software development, Distinction between Quality Assurance (QA), Quality Control (QC), Quality Management (QM), and Software Quality Assurance (SQA) Software Development Life Cycle (SDLC) : Overview of SDLC phases and their relationship to. testing, Role of testing in each phase, Software quality factors and their impact on testing Verification and Validation (V&V) : Definition of V&V and its significance in software development, Different types of V&V mechanisms, Concepts of Software Reviews, Inspection, and Walkthrough 11 Introduction to Software Testing ‘Dec.'18, 1 Mark * ‘When we are testing something we are checking whether + Software testing is a process used to identify the correctness; completeness and quality of developed software, includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users. * Insimple words, software testing is an activity to check that the software system is defect free. * Testing is necessary because we all make mistakes. Some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check everything and anything we produce because things can always go wrong ~ humans make mistakes all the time. *. Software bugs can potentially cause monetary and even human loss. * Itis important to ensure that the application should not result into any failures.11.1 Nature of Errors ST ig known as error. An Error is a human action that produces an 9 : A mistake made in codin: incorrect result. 1.1.2 _ Types of Errors Types of errors » —_ iti 9) Run-time Errors Fig. 1.1.1: Types of errors (2) Syntax Errors «These are the errors related to syntax of the code. For Eg. : Missing semicolon at the end of a statement in C programming language. Every statement in C language ends with a semicolon, a statement ending without a semicolon will lead to an error while running the program and this type of error is known as syntax error. A syntax error can be identified at the time of compiling by the.compiler. These errors are easy to find and correct as the compiler finds them. (2) Logical or Semantic Errors ok . : ee mistake in the source code of the software that results in unexpected output which is differer ‘nt than the actual output expected. It is an error that produces wrong output oF may even lead the program to crash, For E.g.: Using wro Ing I “HELLO” 5 times 9 eeping condition. Consider the below code which is used to_print int is0; while(i>5) {ST&QA 13 Intro. to Software Testing and Quality Printf(“HELLO"); itt; ¥ . The loop condition given is i>5 instead of.i<5. The loop condition becomes false as value ized to zero which is not greater than’ as in the loop condition and hence the of jini loop will not be executed. This code will compile successfully, however the expected result will to be achieved. Logical errors are difficult to find as the compiler does not recognize them and it can be found only at the run time when the expected output is not achieved. To find such type of error user needs to debug the code. (3) Run-time Errors 113 ‘These errors are identified at the rum time when the program executes, These errors are generally anticipated by the coder but there is nothing that the coder can do. For E.g. : Running out of memory will cause a run-time error. In such cases coder tries to resolves such errors by throwing a run-time error to the user. These errors are given by software not by the operating system. Exampie of Testing «Suppose there is a company manufacturing study & office chairs. Before the chairs are Sent to the market for-sale it should be tested for Steps of Testing | a) Functionality b) Saloty ©) Usability 4) Performance e) Acceptance ] d Fig. 1.1.2: Steps of testinga Intro. to Software Testing and Quay -ST&QA (a), Functionality Whether it fulfills the basic requi irement of being 4 chair i.e. it provides place to sit. (b) Safety Tested to see whether i \ it can bear the weight of a person (©) Usabi shape and color should be such that is can be used in The chair should be usable ie. the size, office, school & colleges. (d) Performance Consider the chair cal should move accordingly every sing} in. Every time it is either moved up or down, it n be seated up and dow! fhe performance of seat up down is measured, le time i.e. tl (©) Acceptance The chair manufactured shoul eptable to the final customer i.e. Even if the above all Id be acc mfortable then it conditions are satisfied but while sitting on the chair if the posture is not co! will not be accepted by the user. 1.2. Definition of Quality PEeerenens @. Define : Quality Dec. 18, 5 Marks @. Explain any five desirable software qualities. lem or process meets specified requirements and/or we are actually The degree to which a component, syst and expectations. When we talk about software quality, user/customer needs talking about the evaluation of the software based on certain attributes. A software quality. is defined based on the study of external and internal features of the software. The external quality is defined based on how software perfo operational mode and how useful it is for its users. rms in real time scenario in The internal quality on the other hand focuses on the intrinsic aspects that are dependent 0” the quality of the code written. The user focuses more on how the software works at the external level, but the quality at external level can be maintained only if the coder has wiitten a meaningful good quality cod®ST&QA 15 Intro. to Software Testing and Quali oe 2.1 Factors of Quality for user Explain any five desirable software quali Factors of quality for user 1. Functionality | 2. Reliability | 3. Performance 4, Flexibility 5. Usability ty 6. Securit Fig. 1.2.1 : Factors of quality for user 1. Functionality : Functionality is the conformity of the software with actual requirements and specifications. An application should provide all the required functionality as specified in the requirements. 2. Reliability : The ability of an application or system to consistently perform its intended or required function on demand and without degradation or failure 3. Performance : Performance is mostly about response time of the software. This response time should be in acceptable intervals: (e.g. max. a few seconds), and should not increase if transaction count increases. 4. Flexibility : It normally refers to the ability of the application or system to adapt to possible or future changes in its requirements. Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Change is inevitable so flexibility become an important aspect of quality. 5. Usability : Usability is the ease of use and learning ability of an application or system 6. Security : The degree to which the application is protected against malicious attacks and other potential risks. Security is very important especially when the application is dealing with sensitive user data like bank details.ST&QA 1.3 Quality Assurance and Quali @ Define : Quality Assurance Q.__ Define the following term : QA, QC, OM. CECE L Quality Assurance (QA) * Quality Assurance (QA) is the maintenance of a desired level of quali software by means of giving attention to every stage of the s process. ity in an application or oftware development © It ensures that the approaches, techniques, methods and processes are designed for the projects are implemented correctly. * Quality assurance activities monitor and verify that the processes used to manage and create the deliverables have been followed and are operative, * tis a procedure that focuses on providing assurance that quality requested will be achieved. Its process oriented and mainly focuses on defect prevention, 2. Quality Control (Qc) * — Quality Control (QC) ensures that the approaches, techniques, methods and processes are designed in the project is following correctly, tis a procedure or set of procedures intendéd to ensure that an application or system adheres to a defined set of quality criteria or meets the requirements of the client or customer, QC activities monitor and verify that the project deliverables meet the defined quality Standards. It is product oriented and focuses on defect identification. 13.1 Difference between Quality Assurance and Quality Control Quality Assurance (QA) Quality Control (Qc) It focuses on assuring that the product Tt focuses on ensuring that the quality of the delivered will be of best quality. Product assured is delivered. It is implemented during the development phase of the software development, Ttis not involved during the development phase. It isnot involved during the execution It is involved during the execution phase of the phase. . software,ST&QA Intro. to Software Testing and Quality 17 Quality Assurance (QA) Quality Control (QC) It is used to check mistakes during early phases of the development. It is used“during the end phase to. confirm that the software is defect free. It is a proactive measure, which means that the developer controls the software along with the development. It is a reactive measure, which means: that the testing team reacts, at the end phase to rectify the mistakes. It is process oriented. It is product oriented. QA involves design of processes such as SOPs (Standard Operating Procedures) and project documentations. QC involves testing of products to make sure they meet the provided standards. It focuses on preventing quality issues. It focuses on identifying quality issues. QA focuses on the intermediate process in Software Development. ‘ QC pays main focus on final products. The result of QA activities is a roadmap for creating high quality products. involves verification of products post Qc manufacture and before distribution to the users. QA involves all team members of the project. QC generally. involves the testing team of the project. . QAis a preventive technique. QC is a corrective technique. QA makes sure that what you are doing is right. QC makes sure that there is not much difference between the expected output (software that the user expected) and actual output (software that has been produced). QA jis the technique of managing the Quality of the product. QC is a technique to verify the quality of the product. 7 QA is involved in. the full software development life cycle. QC is involved in the software testing phase of software development life cycle. Example of QA is verification. Example of QC is validation. TeaST ROA 18 Intro. to Software Testing and Quali 1.4 — Software Quality Assurance (SQA) Software Quality Assurance (SQA) is @ process that ensures that developed software meets ang complies with defined or standardized quality conditions. Itis an ongoing process within the software development life cycle (SDLC) that routinely checks the developed software to ensure it meets desirect quality measures. SQA is an umbrella activity that is applied throughout the software process. * Rather than checking for quality after completion, SQA processes test for quality in each phase of development until the software is complete. * It is implemented in all types of software development project regardless of which software development Life cycle model is used. SDLC moves to the next phase only when the Current or the previous phase complies with all the quality standards. SQA Questions © Does the software.adequately meet its quality factors? * Has software development been conducted according to pre-established standards? ‘* “Have technical disciplines performed their SQA roles properly? 1.4.1 - Quality Assurance Elements Quality Assurance Elements. a) Standards b) Reviews and audits ¢) Testing 9) Error/dofect collection and analysis ©) Change management 1) Education tt 9) Vendor management b) Security management J) Risk management Fig: 1.4.1 : Quality assurance elementsST &OQA 1-9 Intro. to Software Testing and Quality “@) (b) © ) © (0) @) (h) @ oO Standards : Ensure that standards are adopted and followed Reviews and audit : Audits are reviews performed by SQA personnel to ensure that quality guidelines are followed for all software engineering work Testing : Ensure that testing is properly planned and conducted Error/defect collection and analysis : Collects and analyses error and-defect data to better understand how errors are introduced and can be eliminated Change management : Ensures that adequate change management practices have been instituted Education : Takes lead in software procéss improvement and educational program Vendor management : Suggests specific quality practices vendor should follow and incorporate quality mandates.in vendor contracts “ Security management : Ensures use of appropriate process and technology to achieve desired security level : Safety : Responsible for assessing impact of software failure and initiating steps to reduce risk Risk management : Ensures risk management activities are properly conducted and that contingency plans have been established Software Quality Assurance Tasks Prepare SQA plan for the project. Participate in the development of the project's software-process description. Review software engineering activities to verify compliance with the defined software process. Audit designated software work products to verify compliance with those defined as part of the software process. Ensure that any deviations in software or work products are documented and handled according to a documented procedure. Record any evidence of noncompliance and reports them to management. 1.4.2 Software Quality Assurance Goals L Requirements quality * Ambiguity * CompletenessST&QA 19 Intro. to Software Testing and Quality * (@) Standards : Ensure that standards are adopted and followed {b) Reviews and audits : Audits are reviews performed by SQA personnel to ensure that quality guidelines are followed for all software engineering work (©) Testing : Ensure that testing is properly planned and conducted (d) Error/defect collection and analysis : Collects and analyses error and defect data to better understand how errors are introduced and can be eliminated (e) Change management : Ensures that adequate change management practices have been instituted () Education : Takes lead in software procéss improvement and educational program (g) Vendor management : Suggests specific quality practices vendor should follow and incorporate quality mandates in vendor contracts (h) Security management : Ensures use of appropriate process and technology to achieve desired security level (Safety : Responsible for assessing impact of software failure and initiating steps to reduce risk @ Risk management : Ensures risk management activities are properly conducted and that contingency plans have been established : Software Quality Assurance Tasks * Prepare SQA plan for the project, * Participate in the development of the project's software-process description. * Review software engineering activities to verify compliance with the defined software process. * Audit designated software work products to verify compliance with those defined as part of the software process. * Ensure that any deviations in software or work products are documented and handled according to a documented procedure. Record any evidence of noncompliance and reports them to management. 14.2 Software Quality Assurance Goals 1. Requirements quality * Ambiguity * Completeness pee ee ee1:10 Intro. to Software Testing and Qa STEQA . : © Volatility * Traceability * Model darity 2 Design quality * Architectural integrity * Component completeness * Interface complexity © = Pattems ¢ 3. Code quality aps : * Complexity © Maintainability + Understandability * Reuszbility * Documentation 4. Quality control effectiveness * Resource allocation © Completion rate * Review effectiveness * Testing effectiveness 142 Quality Management (QM) * Quality management is the act of overseeing all activities and tasks needed to maintain:a desired level of excellence. It ensures that a required level of Quality is achieved. The Software Quality Management comprises of Quality Planning, Quality Assurance and Quality Control Processes, : eve them. Once the standards are defined and building the product starts, + tis very important to have Processes to evaluate the project performance and aim to assure that the Quality standards are being followed and the final product will be in compliance."s It is a framework that defines acti ST &QA Ll Intro. to Software Testing and Quality Once the software components are built the results are monitored to determine if they comply with the standards. The data collected helps in measuring the performance trends and as needed help in identifying defective pieces of code. 15 Software Development Life Cycle (SDLC) Write a note on SDL ities that are performed throughout the software development process. «The development process adopted for a project will deperid on project aims and goals. There are numerous development life cycles that have been developed in order to achieve different required objectives. + Thé most appropriate development process should be applied to each project. The models specify the various stages of the process and the order in which they are carried out. 1.5.1 Phases of SDLC Phases of SDLC are as follows Requirements Maintenance Testing Development Fig. 1.5.1 : Phases of SDLC Teaa. STR QA 1-12 Intro to Software Testing ang a ua Requirement Gathering * This is the most important phase in software development life cycle. In this hi; Phisg requirement forthe software are collected from the customer/clint. These reqy, < are provided in a document called Business Requirement Specification (aRsy wy oe Requirement Specification (SRS). * All details and specifications of the product must be discussed with the cug development team analyses the requirements keeping in view the design an; the software. tomer. coding of * The requirements so gathered are then analyzed for their validity and possi incorporating them into the software system. The’ aim of requirement analy: capture the detail “of each requirement so that everyone understands bility of Sis is to OW each requirement is to be worked. 2. Design It has two steps : @ (2) LLD-Low Level Design HLD ~ High Level Design (2) HLD - High Level Design™ TF gives the architecture of, the software product to be developed and is done by architects and senior developers (2) LLD - Low Level Design Itis done by senior developers. It describes how each and every feature in the produc should work and how every component should work. Here, only the design will be there and not the code. The outcome from this phase is High Level Document and Low Level Document which works as an input to the next phase. ‘ 3: Coding Itmeans translating the design into a computer readable language. Development team does the actual coding based on designed software and writes unit tests for each component to tt the new codes written by them. This is the longest phase of the software development Ife oycle, iST &QA g and Quali 4, Testing Alter the code is developed, testing is carried out to verify the entire requirement specified by customer has been implemented. The aim of tester is to find out the gaps or defects within the system and also to verify that the software works as expected according to the requirements. It includes Unit testing, Integration testing and System testing. 5, Deployment ‘After successful testing, the product is delivéred/deployed to the customer for their use. The size of the project will determine the complexity of the deployment. The users can be trained on, or aided with the documentation on how to operate the software, A small round of testing is also performed on production to make sure of any environmental issues and any impact of new release. 6. Maintenance ‘Once when the customers start using the developed system then the actual problems will come up and needs to be solved from time to time. Fixing the issues found by the customer’ comes in the maintenance phase. 15.2 Role of Testing in Each Phase In the software testing life cycle, there are usually five phases of testing: L._ Static testing : During static testing, developers work to avoid potential problems that might atise later. Without executing the code, they perform manual or automated reviews of the supporting documents for the software, such as requirement specifications, searching for any potential ambiguities, errors or redundancies. The goal is to preempt defects before introducing them to the software system. : 2. Unit testing : The next phase of software testing is unit testing. During this phase, the software undergoes assessments of its specific units, or its functions and procedures, to ensure that each works properly on its own. The developers may use white box testing to evaluate the software's code and internal ‘structure, commonly before delivering the software for formal testing by testers. Unit testing can occur whenever a piece of code undergoes change, which allows for quick résolution of issues. 3. Integration testing : Integration testing involves testing all the units of a program as a grouP to find issues with how the separate software functions interact with one another. Through integration testing, the developers can determine the overall efficiency of the units as they run*ST& QA 1-14 Intro. to Software Testing and Quality the program's overall functionality relies on the units together. This phase is important because 1 stem, not as isolated procedures. operating simultaneously as a complete sy: : System testing : In the system testing phase, the software undergoes its first test as a complete, integrated application to determine how well it carries out its purpose. For this, the developers pass the software to independent testers who were not involved in its development to ensure that the testing results stem from impartial evaluations. System testing is vital because it ensures that the software meets the requirements as determined by the client. . of software testing. Its purpose is to g : Acceptance testing is the last phase se. Testers may perform acceptance Acceptance testin: e software's teadiness for release and practical u: testing alongside individuals who represent the software's target audience. Acceptance testing aims to show whether the software meets the needs of its intended users and that any changes the software experiences during development are appropriate for use. The representative because they can offer insight into what customers may evaluate the individuals are crucial to this phase want from the software. Once the software passes acceptance testing, it moves on to production. 3 Software Quality Factors and their Impact on Testing Functionality : Functionality is the conformity of the software with actual requirements and specifications. An. application should provide all the required functionality as specified in the requirements. : Reliability : The ability of an application or system to consistently perform its intended or required function on demand and without degradation or failure Performance : Performance is mostly about response time of the software. This response time should be in acceptable intervals (e.g. max.'a few seconds), and should not increase if transaction count increases. Flexibility : It normally refers to the ability of the application or system to adapt to possible oF future changes in its requirements. Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Change is inevitable so flexibility become.an important aspect of quality. Usability : Usability is the ease of use and leaning ability of an application or system Security : The degree to which the application is protected against malicious attacks and other potential risks. Security is very important especially when the application is dealing with sensitive user data like bank details.ST&QA 1-15 Intro, to Software Testing and Quality 1.6 Definition of V and V 1. Verification © Verification is a process of evaluating the work products of phases. of software development lifecycle to check if we are in the right track of creating the final product. © These work products can include the documents which are produced during the development phases like, requirements specification, design documents, data base table design, ER diagrams, test cases, traceability matrix etc. + Verification is a static practice of verifying documents, design, code and program. It includes processes like inspection, design analysis and specification analysis. * Verification will help to: determine whether the software is of high quality, but it will not ensure that the system is useful. ‘ 2. Validation Validation is the process of evaluating the final product to check whether the software meets the customer expectations and requirements. Activities involved in this is Testing the software application. It is a dynamic mechanism of validating and testing the actual product. 1.6.1 Difference between Verification and Validation Distinguish between Verification and Validation. jov. 22, 5 Marks: ‘Sr. Verification “Validation No. 1. | Verification is to check whether. the | Validation is to check whether software software conforms to the specifications | meets the customer expectations and requirements, 2. | Verifying process includes checking | It is a dynamic mechanism of testing and documents, design, code and program _| validating the actual product 3. | It does not involve executing the code It always involves executing the code 3. | Verification uses methods like reviews, |-It uses methods like Black Box Testing White walkthroughs, inspections and desk- | Box Testing techniques checking etc,ST &QA 1-16 Intro. to Software Testing ang oe | Verification ; Validation No. 4 | Checks “Are we building the product | Checks “Are we building the right produ right"? : 5. QA team does verification and make | With the involvement of testing tey sure that the software is as per the | validation is executed on software code Fequirement in the SRS document. 1.6.2 V-Model (V&V Model) V-Model Dae Acceptance Test Plan Expl User Requirements | Higti Level Design _ Acceptance Testing. System Test Pian System Testing Integration Testing Integration Test Pian — = Fig-1.6.1 : V-Model V-model is also known as Validation & Verification model. V-model was developed tc address some of the problems experienced in the traditional software development life cycle Defects were found too late as the testing was not involved until the end of the project. V-model provides the guidelines that testing should begin as early as possible in the life cycle this is also one of the important principles of testing. There are many activities related to testing that can be performed before the completion of coding phase. These activities can be carried out in parallel with the other development activities, By starting testing early we will be able to find defects and resolve them early as well.ares ST&QA 1.17 Intro, to Software Testing and Quality «Like SDLC, V-model is also sequential model. Each phase must be completed before the next phase begins. «Testing of the product is planned in parallel with a corresponding phase of development in v-model. The various phase of V-model are: (a) Requirements * In V-Model when the requirements are gathered in the form of BRS or SRS from Customer/Client for development of the project, the same requirements are provided to | the testing team to create an acceptance and system test plan. «The test plan focuses on meeting the functionality specified in the requirements gathering. (b) High-level Design + In this phase, based on the high level design, software architecture is created. The modules, their relationships and dependencies, architectural diagrams, database tables, technology details are all finalized in this phase. * An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. (Q) Low-level Design: * In this phase each and every module or the software ‘components are designed individually. Methods, classes, interfaces, data types etc are all finalized in this phase. * It defines the actual logic for each and every component of the system: In this phase component tests are created. : (@) Coding * In this phase actual coding is done. Unit tésts are created in-this phase. * The actual code is tested using the tests written during different phases of this model. 17 __ Software Reviews Give the concept of Software reviews, Inspection and Walkthrough. [EECSEM\ APP AMET What is software review?Explain types of review. [EEE eT Reviews can be formal or informal. In an informal review there are no fixed phases or process. It is “conducted to get a feedback from colleagues about a work product. Mineatiensa ST&QA 118 Intro. to Software Testing and us * In contrast to informal review, formal review has a fixed process. A typical formal review 1. Planning ] 2. Kick-off ] consists of six main steps: 3. Preparation 4. Roviow Meating a) Logging phase ) Discussion Phase i ©) Decision Phase 5. Rework 8. Follow-up ] Fig. 1.7.1 : Software reviews steps 2) Planning * Planning is the first step of formal review. Review is generally initiated by author who put in a request for review of a document or any other artifacts. Moderator has to take care ¢ the schieduling like date, time, place and invitation of the review. Moderator also performs the entry check on the document and also determines ‘the ex criteria for this phase. Entry check is very important to determine whether the document ready to go for the formal review otherwise moderator time is wasted. * Some of the entry checks are as follows: () "There should be any major defect in the document (i) The document pages should be numbered (ii) All automated check that are available should be run on the document like sp! check © Once the document passes the entry check the moderator and the author decide ¢ which part of the document is to be tested, Since the human mind can understand only limited set of pages at one time so in a review the maximum size is between 10 and! pages. AST &QA 1-19 Intro. to Software Testing and Quali LS dou, 2) Kick-off This is an optional step. The main aim of this meeting is to get everybody on the same page regarding the document and decide on the time to be sent on reviewing. Entry and exit criteria are also discussed, In general a kick-off-is highly recommended since there is a strong positive effect of a kick-off meeting on the motivation of reviewers and thus the effectiveness of the review . process. Document under review and other related documents are distributed to the team. 3) Preparation The participants work individually on the document under review using : the related documents, procedures, rules and Checklists provided. In this phase the participants find defect, issues, questions and comments on the document under review. All issues and defects are recorded in a logging form. Success factor of the review is measured by the checking rate i.e, No. of pages checked per hour. The optimum checking rate is the mix of factors such as type of document, its complexity, experience of the reviewer etc. ideally the checking rate should range from five to ten pages per hour. 2 4) Review Meeting This stage consists of 3 phases: da) (b) ©) Logging phase : All the defects andissues that have been identified during the Preparation step are recorded page by page by the author or the scribe. Every defect and its severity should be logged: Three severity classes should be considered while logging every defect ice. Critical, Major, Minor. Meeting the good logging rate in the formal review should be between one to two defects logged per minute. Discussion Phase : If any issue needs discussion than that issue is handled in this phase. It is the responsibility of the moderator to take care of peoples issue and prevents the discussion from getting personal and aggressive. The outcome of the discussion is documented for future references: Decision Phase : A decision has to be made by the participants on the document under review at the end of the meeting, sometimes based on exit criteria (average number of critical defects found per page). pennentiensST & a 5) 6) Qa | 1:20 Intro. to Software Testing and, Rework In this stage, if the number of defects found in each page exceeds the certain level than the document has to be reworked, Its the responsibility of the author to judge whether the dteg needs to be fixed because not every defect leads to rework. Follow-up The moderator is responsible for ensuring that satisfactory actions have been taken on all (logged) defects, process improvement suggestions and change requests. Although the moderator checks to make sure that the author has taken action on all known defects, it is not necessary for the moderator to check all the corrections in detail. If it is decided that all participants will check the updated document, the moderator takes care of the distribution and collects the feedback. = 1.7.1 Types of Reviews : a. Q. L Give the concept of Software reviews, Inspection and Walkthrough. ECSREM EAP? ASR eto S ‘What is software review?Explain types of review. Nov.22,5 Marks) Types of Reviews 1, Walkthrough 2. Technical Review 8. Inspection | Fig. 1.7.2 Walkthrough ‘© This is a process where the authors of the document as well as other associates a gathered at one place to discuss the document to achieve a common understanding and gather feedback. ' In walkthrough the author does most of the study of the document and the participan’ are not expected to know the document in advance. The participants are selected fo") different departments and background so that they can bring in different viewpoints. : ‘i i . ae Questions are made, comments are given, answers are given to all the’ queries pe°P* havé regarding the software. With all the members’ satisfaction, conclusions are made.T A sT&xQ 1-21 Intro. to Software Testing and Quality Quy 2. Technical Review . This, review is done to achieve technical consensus about the document. In technical review defects are found by experts. «Its performed by peer review without management. Use of checklist and logging lists are optional. Technical review can be Informal or very formal. | 3. Inspection | «It is the most formal type of review. During inspection the documents are prepared and | checked thoroughly by the reviewers before the meeting. « A separate preparation is carried out during which the product is examined and the defects are found. The defects found are documented in a logging list or issue log. Review Que! @.1 Explain different types of errors @.2 While checking for quality of software what are the different aspects to be considered? @.3 Differentiate between QA and QC : ° @.4 Whatis testing and why do we need to test software? @.5 Whatis an error? Explain its types. @.6 Define Software quality. @.7 — Write a short note on SQA. : @.8 — Whatis SDLC. Explain its phases. 2.9 Explain the importance of testing in a software development life cycle: » @.10 Differentiate between Verification and Validation. @.11 Whyis V model known as verification and validation model? @.12 What is a review? List and explain its types. @.13 What are the phases of a formal review? aaaSoftware Testing Techniques & Strategies Testing Fundamentals : Basics’ of software testing process, Test case design principles and techniques, Test execution, reporting, and documentation White Box Testing and Black Box Testing : Functional/Specification based Testing as Black Box, Black box: Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, State Transition Testing. Structural Testing as White Box, White Box: Statement testing, Branch testing. Experience-based: Error guessing, Exploratory testing, Checklist-based testing. Software Testing Strategies : Strategic approach to software testing Unit Testing: purpose, techniques, and best practices, Integration Testing: approaches and challenges, Validation Testing: ensuring adherence to user requirements, System Testing: comprehensive end-to-end testing : Concept of software metrics and their importance, Developing and utilizing Software Metrics different types of metrics, Complexity metrics and their significance in testing 2.1 Whats testing ? Explain testing principles. Testing is the process of finding all the possible defects or discovering a software product's deficiencies. It is also a process of executing a program with the intention of logging a defect against the software product. The primary benefit of testing is to make-a workable software product better, to improve the quality of deliverables. It also provides a good indication of software reliability and reduces the risk of failures during deployment. 2.1.1 Principle of Testing Following are the principles of testingST &QA 2-2 Software Testing Strategies Principles of testing 1. Testing shows presence of defects } 2. Exhaustive testing is not possible 3. Early Testing 4. Defect clustering . Pesticide Paradox | 6. Testing is contoxt dependent | Fig. 2.1.1 Principle of Testing 1. Testing shows presence of defects Testing shows that there are defects present but it does not imply that there are no defects. 2. Exhaustive testing is not possible Testing everything ie. all the combinations of inputs is not possible. Testing the product should be accomplished considering the risk factor and priorities ; 3. Early Testing Early testing helps identify issues prior to the development stage, which eases error correction and helps reduce cost 4. Defect clustering Normally a defect is clustered around a set of modules or functionalities: Once they are identified, testing can be focused on the defective areas, and yet continue to find defects in other modules simultaneously. 5. Pesticide Paradox If the same tests are repeated over and over again then eventually the test will no longer find and defects, To overcome this the tests should be regularly revised. Testing is context dependent Testing is done differently depending on’ the type of software. For e.g. software which deals with money should be tested keeping security in mind. TechKnewledgest nen 23 Software Testing Strategig 7. Absence of errors fallacy Just identifying and fixing issues does not really help in setting user expectations. Even i testing is performed to showcase the software's reliability, the software products are bug-free. is better to assume that none of 2.1.2 Testing Team Testing Team j a) Program Manager b) QA Lead | d) Test Engineer Fig. 2.1.2 : Testing team (a) .Program Manager He is responsible for planning and execution of the project and to ensure the success of a project by minimizing risk throughout the lifetime of a project: He is also responsible for writing the product specification, managing the schedule and making critical decisions. (b) QA Lead He is mentors team members to improve QA effectiveness. He implements industry's best _ practices. (©) Test Analysts s He is responsible for executing tests, gathering and managing test data and evaluates the outcome of each test. (d) Test Engineer He is responsible for writing anid executing test cases and reporting test defects. They are als0 responsible for determining the best way'a test can be performed in order to achieve 100% test coverage. Tocakaaalelf peace 4 |Software Testing Strategies sT QA 2-4 2.2 Test Case Design Write in brief about test case design. lar feature or functionality Test Case is a set of actions executed to verify a par Test case: of your software application. Test Case Design Techniques ‘Test case Design Techniques Black box White box testing testing | Fig. 2.2.1 : Test case design techniques Black box testing and white box testing are two testing techniques that are quite commonly used by software testers. 2.2.1 Black Box Testing 'Q. _List Black Box Testing types. Explain any two. Q. _ Differentiate between White Box and Black box testing. Q.__ Write note on black box testing. eee It is also known as specification based testing or input/output driven testing techniques. The tester thinks of the software as a black box with only inputs and outputs and they do not have any knowledge of how the system is implemented. I 00%. of Black Box |. 2.2.2 : Black box testing Outbox =P * Requirements Document or Functional Specification Document forms the basis of this testing. It includes both functional and non-functional testing. Functional testing is concerned with What the system: does and non-functional. testing deals with performance, usability, maintenance etc How to write Test Cases for Black Box Testing? * The tester examines requirements and specifications of the system. . The tester explores the system's Ul and functionality to understand how the processes on the system are expected to work : He designs test cases with valid inputs and the corresponding expected outputs. peatteationsST&QA 2 Software Testing State Test case template Attest case must contain below field. Fields of Test case template 1) Module name L__§— 2) Test case ID 3) Test case title } 4) Test Description 5) Pre-condition 6) Test Steps 7) Expected result ] Fig. 2.2.3 : Fields of test case template 1) Module name Name of the module the test case is part of 2). Test case ID It is a unique id given to every test case 3) Test case title Itis a title which describe the test case in a single line 4) Test Description Describes the test objectives in detail 5) Pre-condition ‘Any prerequisites that must be fulfilled before execution of the test case 6) Test Steps Detailed description of the test steps in the order they have to be executed 7) Expected result The output expected after execution of the step Ted peaST &QA software Testing Strategies 2.2.2. Techniques of Black Box Te: Technique of black box testing 1. Equivaleuce partitioning 2. Boundary value analysis 8. Decision table testing 4, State transition testing Fig. 2.2.4 : Technique of black box testing 1, Equivalence partitioning ften a good technique to use first. The idea ) a set of test conditions into groups or .quivalently), n be appliedat any level of testing and.is of partition) the system should handle them e « Itcar behind this technique is to divide (i.e. to sets that can be considered the same (ie. tl hence ‘equivalence partitioning’. + If we want to test a text box which can accept number in the range of «For Eg. a into 3 partitions as below: (0-100 then we would divide test date ____ Valid Partition Valid Partition Valid Partition wiow bos Invalid Partition os ie ce Invalid Partition ase (1 digit) 2 digits) @ digits) : 0-9 10-99 100 above 100 Negative values We have identified 3 valid partitions and 2 invalid partitions such that any value taken from these partitions would produce the same result. ition while testing. This is «One test value is picked from each equivalence class or parti ill be treated in the same because we are assuming ‘that all the values in one partition wi way by the software. we assume all of the values in that partition will work and © Ifone value in a partition works, tition will fail and there if the test fails for one value it is assumed that all others in the pat is no point in testing others. 2. Boundary Value Analysis of the partitions. It is also called as * In this technique testing is'done at the boundaries ysis are linked to each | Range checking”. Equivalence Partitioning and Boundary value anal | other and are generally used tagether at all levels of testing. TST&QA 27 Software Testing Strategies Consider the testing of a software program that takes the integers ranging between the values of -100 to +100. In such a case, three sets of the valid equivalent partitions are taken, which are - the negative range from -100 to -1, zero (0), and the positive range from 1 to 100. Each of these ranges has the minimum and maximum boundary values. The Negative range has a lower value of -100 and the upper value of -1. The Positive range has a lower value of 1 and'the upper value of 100. So, the test cases for the input box that accepts the integers between -100 and + 100 through BVA are : 0 _Test cases with the data same as the input boundaries of input domain : - 100 and +100 in our case. 101 and 99 99 and 101 o_ Test data having values just below the extreme edges of input domain : © Test data having values just above the extreme edges of input domain With this technique, it is quite easy to test a small set of data in place of testing the whole lot of data sets. 3. Decision table testing ‘A decision table is a good way to deal with different combinations of inputs and their associated outputs. It is also called Cause- Effect table. It provides a systematic way of pers as well as for testers. stating complex business rules, which is useful for develo e effects of Decision tables can be used in test design as they help testers to explore tht combinations of different inputs. Let's take an example scenario of airline ticket booking where decision table would b use. In this example only when both from and to city is selected then next button is enabled. ye of Conditions RL RZ R3 From City T (Selected) T (Selected) F (Not Selected) To City T (Selected) | F (Not Selected) T (Selected) Action. Next Enabled | T (Enabled) F (Disabled) F (Disabled)| st &QA 2:8 Software Testing Strategies In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the table corresponds to a rule in the business logic that describes the unique combination of circumstances that will result in the actions. The above example contains three different business rules "Next is enabled if from and to city is selected”, "Next is disabled if from city is selected and to city is not selected”, “Next is disabled if from city is not selected and to city is selected”. Decision table makes it easy to systematically select effective test cases. 4, State transition testing Here system can be in a finite number of different states, and with transitions from one state to another. We get a different output for the same input, depending on what has happened prior. You can derive test cases to test every transition drawn in state transition diagram. Test conditions can be derived from the state transition diagram in various ways. Each state or transition can be noted as a‘test condition. We can use state transition table to derive all possible combinations of valid and invalid transitions. Transition need not change to a different state it can stay in the same state. Invalid input would display an error message as the action, but the transition would be back to the same state the system was in before. For Eg : A simple electronic clock has four modes display time, change time, display date and change date. The change mode button switches between display time and display date. The reset button switches from display time to adjust time or display date to adjust date. The set button returns from adjust time to display time or adjust date to display date. reset Display time: Change modeST.&QA 2-9 Software Testing st STEP 177°} * “STEP 2 TEST 1 | START STATE | DISPLAY TIME | DISPLAY TIME INPUT CHANGE MODE | CHANGE MODE OUTPUT DISPLAY TIME | DISPLAY TIME FINISH STATE | DISPLAY TIME _ | DISPLAY TIME 2.2.3 White Box Testing It is also known as glass box testing, clear box testing or structural testing. In this testing, tester is well aware of the internal structure, design and implementations of the software being tested. Programming know-how and the implementation knowledge is esse + Itcan test paths within a unit, paths between units during integration, and between subsystems during a system-level test. It is a method of testing the application at the level of the source code. © We perform white box testing to test © That all independent paths within a module have been exercised at least once. ‘© All logical decisions verified on their true-and false values. “0 All loops executed at their boundaries and within their operational bounds internal data structures validity. Application Code jest Case Output Fig. 2.2.6 2.2.4 . White Box Testing Techniques © 1. Statement Coverage 2. Branch Coverage Fig. 2.2.7: Technique of white box testingSe 1 Statement coverage Ina programming language, a statement is nothing but the line of code or instruction for the computer to understand and act accordingly. A statement becomes an executable statement when it gets compiled and converted into the object code and performs the action when the program is in a running mode. Hence “Statement Coverage”, as the name itself suggests, itis the method of validating whether each and every line of the code is executed at least once. For E.g.; Consider the sample code int AB; if A>B then C=O End if * 4 statement coverage only 1 test case is required where the value of A is To ensure 100 nt C=0 will not be greater than B, however if the value is A is less than B then statemer executed and hence 100% statement coverage will not be achieved. 2. Branch Coverage “1 Print C is Greater”, i quirement that, for each branch in the program (e.g. if statements, Branch coverage is a re sometimes also rach have been executed at least once during testing. It is loops), each bra .en true at least once and described as saying that each branch condition must have be false at least once during'testing. from each decision point is It aims to ensure that each one of the possible branch le code is executed. It helps in executed at least once and thereby ensuring that all reachabl validating that every branched code based on decision is executed at least once. ‘onsider the following code Read C Read D IF C>D Then Print “D is Greater” ELSE