Vobobelyh, MU *7'_ INFORMATION TECHNOLOGY = 1(Comte 1 THO7014) Software’ Testing & Quality Assurance Dr. Pankaj Agarkar_ | Yogesh Mali Strictly as per the New Syllabus is (REV-2029 6 8 heme) o Mumbai University F 2022-2023 M7-440, iin Tl | Scanned with CamScannerSyllabus =—— Mumbai University - Information Technology ‘Code Course | Course | Theory | Practical | Tutorlal | Theory | Practical | Tutorial | Total Name 10ral 17007014 | Software 03 - : 03 . : 03 Testing and QA Course ‘Code Examination Scheme Course Theory Marks | Name Tnternalassosement [EndSem.| yirm™ | Practical) Oral ) Towa Exam Test 1 | Test2 | Avg. of 2 Tests !TDO7014 Software Testing | 20 | 20 20 a0 fro 5 - | 100 land QA | Course Objectives Sr. No. ‘Course Objectives ‘The course aims : 1 To provide students with knowledge in Software Testing techniques. “To provide knowledge of Black Box and White Box testing techniques. To provide skills to design test case plans for testing software. To prepare test plans and schedules for testing projects. To understand how testing methods can be used in a specialized environment. olalaleo|r To understand how testing methods can be used as an effective too! in providing quality assurance concerning software. Course Outcomes Sr. No. Course Outcomes Cognitive levels of attainment as per Bloom's Taxonomy ‘On successful completion, of course, leamer/student will be able to : | ]imvestigate the reason for bugs and analyze the principles in |L1,L2,L3. software testing to prevent and remove bugs. 2 Understand various software testing methods and strategies. | L1,L2 ‘Manage the testing process and testing metrics. Li,Labs ‘Understand fundamental concepts of software automation and | L1,L2 use automation tools & | Apply the software testing techniques in the real time L1L2.L3 environment. © [Use practical knowledge of a variety of ways to test software and | L1,L2 quality attributes. Prerequisite: Programming Language (C++, Java) ), Software Engineering Scanned with CamScannerDETAILED SYLLABUS ‘Module. q : Detaled Content. Prerequisite | Software Engineering Concepts, Basics of programming Language Testing Introduction, Goals of Software Testing, Software Testing Methodology | Definitions, Model for Software Testing, Effective Software Testing vs Exhaustive Software Testing, Software Failure Case Studies, Software Testing Terminology, Software Testing Life Cycle (STLC), Software Testing methodology, Verifc and Validation, Verification requirements, Verification of high level design, Verification of low level design, validation, Self-learning Topies : Study any systenv/application, find | fequirement specifications and design the system. Select software testing methodology suitable to the application. (Refer Chapter 1) Dynamic Testing : Black Box Testing : Boundary Value Analysis, Equivalence Class Testing, State Table Based testing, Cause-Effect Graphing Based Testing, Error Guessing. Testing Techniques White Box Testing Techniques : Need, Logic Coverage Criteria, Basis Path Testing, Graph Matrices, Loop Testing, Data Flow testing, Mutation testing, Static Testing. Validation Activities : Unit validation, Integration, Function, System, Acceptance Testing. Regression Testing : Progressive vs. Regression Testing, Regression Testability, Regression Testing, Regression Testing Types, Testing Techniques. Self-learning Topics : Select the test cases (positive and Negative scenarios) for the selected system and Design Test cases for the system using any two studied testing techniques (Refer Chapter 2) Regressive, Objectives of Define Problem, Regression Managing the Test Process Test Management : Test organization, stricture and of sting group, test planning, detailed test design and test Specification, Software Metri software matrices, Testing Metrics Testing Process : + Need, definition and Classification of for Monitoring and Controlting the Attributes and corresponding metrics, Fulmation model for testing effort, architectural design, information flow matrix used for testing, function point and test point analysis, Scanned with CamScannerEfficient Test Suite Management : Minimizing the test site and its benefits, test suite minimization problem, test suite prioritization its type, techniques and measuring effectiveness, Self-learning Topics : Design quality matrix for your selected system. (Refer Chapter 3) Test Automation Automation and Testing Tools : Need, categorization, selection and cost in testing tool, guidelines for testing tools. Study of testing tools : JIRA, Bugzilla, TestDirector and IBM Rational Functional Tester, Selenium etc. Self-learning Topics : Write down test cases, execute and manage using studied tools. (Refer Chapter 4) | | 0s cos Testing for specialized environment Agile Testing, Agile Testing Life Cycle, Testing in Scrum phases, Challenges in Agile Testing, ‘Testing Web based Systems : Web based system, web technology evaluation, traditional software and web based software, challenges in testing for web based software, testing web based testing | Self-learning Topics : Study the recent technical papers | on software testing for upcoming technologies (Mobile, | Cloud, Blockchain, IoT) (Refer Chapter 5) cos vl Quality Management Software Quality Management, McCall's quality factors and Criteria, 1S09000:2000, SIX sigma, Software quality management. Self-learning Topics : Case Studies to Identify Quality Attributes Relationships for different types of Applications (Web based, Mobile based ete.) (Refer Chapter 6) 04 co6 Assessment Internal Assessment (1A) for 20 marks * IA will consist of Two Compulsory Internal Assess: syllabus content must be covered in First IA Tes content must be covered in Second IA Test, > Question paper format Question Paper will comprise of a total of six questions each carrying 20 marks, compulsory and should cover maximum contents of the syllabus, Remaining questions will be mixed in nature from different modules, For example, if Q.2 has any other Module randomly selected from all th A total of four questions need to be answered, \emodules), ‘ment Tests. Approximately 40% to 50% of st and remaining 40% to 50% of syllabus Q1 will be (Part (@) and part (b) of each question must be Part (a) from Module 3 then part (b) must be from Scanned with CamScanner‘=> Chapter 1 : Module 2 | £ Chapter 2 : Module 3° g Chapter 3 : Module 4° g Chapter 4 : Module 5 | g Chapter 5 : Module 6 => Chapter 6 2 Testing Methodology .......sssssssereesstesssesseeeres Testing Techniques Managing the Test Process seoteeceeee Test Automation 4-1 to 4-28 Testing for Specialized Environment...............5¢4 to 5-17 Quality Management rity Scanned with CamScanner14 12 13 CHAPTER Testing Methodology Testing Methodology Introduction, Goals of Software Testing, Software Testing Definitions, Model for Software Testing, Effective Software Testing vs Exhaustive Software Testing, Software Failure Case Studies, Software Testing Terminology, Software Testing Life, Cycle (STLC), Software Testing methodology, Verification and Validation, Verification requirements, Verification of high level design, Verification of low level design, validation. Self - learning Topics : Study any system application, find requirement specification and design the system. Select software testing methodology suitable to the application. Introduction aa Goals of Software Testing. 1.2.1 Short-term or Immediate Goals 1.2.2 Long-term Goals... 1.2.3 Post-implementation Goals.. 1.2.4 Software Testing Definitions. 7 UQ. — Whatis software testing ? 1.2.5 Model for Software Testing... ua. ua is software testing ? Describe software testing model with a neat diagram? 1.2.5.1 ema Testing Summarization 1.2.5.2 Software Testing Overview. are, Effective Software Testing vs. Exhaustive Software Testing.. UQ. Explain effective and exhaustive software testing. 4.3.1 Difference between Effective Testing and Exhausting Teating. e 1-10 111 1.3.2 Domain of Input Data.. Scanned with CamScannerSoftware Testing & Quality Assurance (MI 14 15 1.6 W7 18 1.9 1.42 (New Silabus v.04 academic year 22.2) (7-67) Testing Methodology)...Page no (1. Software Failure Case Studies. 1.4.1 Top 8 Mega Software Failures... Software Testing Terminology... 4.5.1 The Most Common Software Testing Terminology Testing Lite Cycle (STLO)... RaueeeEn ere i details. 4.6.1. Requirement Phase Testing... 1.6.2 Test Planning in STLC. 1.6.3 Test Case Development Phase... Test Environment Setup .. Test Execution Phase... 1.6.6 Test Cycle Closure... Classification of Software BUgS...nnn x UG. Classity different types of bugs based on Software development lifecycle. UQ. Classify bugs based in SDLC ? Defect/Bug Life Cycle in Software Testing UG. Whats Life cycle of Bug? Explain Life Cycle of Bug and Defect states of bug 7 CEA ere. 1.8.1 Whatis Defect Life Cycle ? 182 Defect Life Cycle Testing Process Software Testing Methodology... 1.9.1 Waterfall Method. 1.9.2 Agile Methodology... 1.9.3 Iterative Development. Verification and Validation... Ua. Discuss the benefits of verification and validation ina project. (UEITENEI) ua. Discuss verification and validation activities. (TE May 16, May 18, Dec. 19) 1.10.1. Verification and Validation... 1.10.2. Verification vs Validation : ua. sesssees 119 [eeerat-al ‘ey Ditterence , es Differentiate between verification and validation, (MU - Dec. 17. Dec. 19) 1.10.3 Verification Requirements... 1.10.3.1. Verification Requirement Properties Verification of High Level Desi ua, ‘gn and Low Level Design Validation. Explain Verification in high level and low level design. (TEIIENEE) . 1-111 Difference between High Level Design and Low Level Design... Self Learning Topics... > Chapter Ends Bl Tech-Neo Publications... SACHIN SHAH Ventu'® Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT) (Testing Methodology). ..Page no (1-3) i TT z d 1.1 INTRODUCTION on ie 2 ya Introduction to Testing Methodologies «Testing methodologies in software engineering are testing strategies, approaches or methods used to test a specific product to ensure its usability, «+ It makes sure that product works as per the given specifications and has no side effects when used outside the design parameters. + Software testing methodologies encompass everything from unit testing to integration testing and specialized form of testing like security or performance testing. De? GOALS OF SOFTWARE TESTING Ta The goals of software testing may be classified into three major categories, as shown. in Fig. 1.2.1. YS 1.2.1 Short-term or Immediate Goals These goals are immediate results after performing testing. These goals may be set in the individual phases of SDLC. Bug discovery : The immediate goal of testing is to find errors at any stage of software development. More the bugs discovered at an early stage, better will be the suecess rate of software testing. Immediate goals fe Reliability |» Quality Customer satisfaction Risk management ‘Software testing Post-implementation goals “s Reduced maintenance cost | ++ Improved testing process © Bug prevention (anFig. 1.2.1 : Software Testing Goals pcotware Reliability Quality (a2JFig. 1.2.2 : Testing produces reliability and quality (New syabs wot ccdemieyar22.23u757) Rl rach-soPusteatns..A SACHIN SHAR Vento a ‘Scanned with CamScannerSoftware Testing & Qu ity Assurance (MU-Sem 7-IT) (esting Methodology)...Page no G BH 1.2.2 Long-term Goals These goals affect the product quality in the long run when one cycle of the SDLC is complete. Some of them are discussed here. (2) Quality * Since the software is also a product, its quality is primary from the users’ point of view. Thorough testing ensures superior quality. Therefore, the first goal of ‘understanding and performing the testing process is to enhance the quality of the software product. Though quality depends on various factors, fficiency, ete., reliability is the major factor Should be passed through a rigorous reliabili such as correctness, integrity, to achieve quality. The software ty analysis to attain high-quality tum, increases the quality, as shown in Fig. 1.2.2, (11) Customer Satisfaction testing should be complete and thor Testing should be complete j specified requirements ‘ough, , : Te brocess achieves reliability, which e quality, in turn, increases customer sati nhances the quality, and tisfaction, as sho (11) Risk management wn in Fig. 1.2.3, Successfully initiatives, basically concerned 1 SS Perspective of Organization, = (New Sy Seademic your 22.05) (yy, 7) Tech-Neo Publications... ‘SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem (Testing Methodolog + Risks must be controlled to manage them with ease. Software testing may | “CSlag_ J-—* Relat act as a control, which can help in eliminating or minimizing risks (Refer Fig. 1.2.4), + Thus, managers depend on software |:ime testing to assist them in controlling [¢Sriteal features } their business goals Controlled by Risk factors (1agFig. 1.2.4 : Testing controlled by risk factors YW 1.2.3 Post-implementation Goals ‘These goals are important after the product is released. Some of them are discussed here. (1) Reduced Maintenance Cost © The maintenance cost! of any software product is not its physical cost, as the software does not wear out. ‘e The only maintenance cost in a software product is its failure due to errors. Post- release errors are costlier to fix, as they are difficult to detect. «Thus, if testing has been done rigorously and effectively, then the chances of failure are minimized and, in turn, the maintenance cost is reduced. (II) Improved software testing process «A testing process for one project may not be successful and there may be scope for improvement. «Therefore, the bug history and post-implementation results can be analyzed to find out snags in the present testing process, which can be rectified in future projects. Thus, the long-term post-implementation goal is to improve the testing process for future projects. (11) Bug prevention + Ibis the consequent action of bug discovery. «From the behavior and interpretation of bugs discovered, everyone in the software development team gets to learn how to code safely such that the bugs discovered are not repeated in later stages or future projects. «Though errors cannot be prevented to zero, they can be minimized. In this sense, bug prevention is a superior goal of testing. (New Syllabus w.ef academic year 22-23) (M7-67) [Bal roch-Noo Publications. SACHIN SHAH Venture Scanned with CamScanner| Software Testing & Quality Assurance (MU-Sem 7:17 (Testing Methodology) ..Page no ( ) WW 1.2.4 Software Testing Definitions q UQ. Whatis software testing ? May 17, May 19 Software testing is nothing but an art of investigating software to ensure that its quality under test is in line with the requirement of the client. Software testing is carried out in a systematic manner with the intent of finding defects in a system. It is required for evaluating the system. As the technology is advancing we see that everything is getting digitized. ‘You can access your bank online, you can shop from the comfort of your home, and the options are endless. Have you ever wondered what would happen if these systems turn out to be defective? One small defect can cause a lot of financial loss. It is for this reason that software testing is now emerging as a very powerful field in IT. Although like other products software never suffers from any kind of wear or tear or corrosion but yes, design errors can definitely make your life difficult if they go undetected. Regular testing ensures that the software is developed as per the requirement of the client. However, if the software is shipped with bugs embedded in it, you never know when they can create a problem and then it will be very difficult to rectify defect because scanning hundreds and thousands of lines of code and fixing a bug is not an easy task. You never know that while fixing one bug you may introduce another bug unknowingly in the system. © Uniderstand the requirements which Pan business. {alti the features fo fulfil the customer ‘requirements, /Dibign and Sede the solution to produce = the features, ‘Unittast and integrate the solution to enable _ builsn quality, ‘customer and successful Validate functional business ‘and non-funetional ‘aspects of solution, Deliver te ee piare ‘and reap the benefits of ‘ce088 In your business, (wsWFig. 1.2.5 : Software Testing Process (Now Syilabus v.04 acadomle year 22-23) 7.67) ‘Tech-Neo Publications...A SACHIN SHAH Vonture | Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT) (Testing Methodology)...Page no (1-7) WA 1.2.5 Model for Software Testing at is software testing? Describe software testing model with a neat diagram? ' Ua Wh Software testing is now a very significant and integral part of software development. Ideally, it is best to introduce software testing in every phase of software development life cycle. Actually, a majority of software development time is now spent on testing. Technical) understanding ‘and analytical] Passion _ for testing (1a6)Fig. 1.2.6 : Software Testing Model diagram ‘The software development models are the various processes or methodologies that are being selected for the development of the project depending on the project's aims and goals. There are many development life cycle models that have been developed in order to achieve different required objectives. Model based testing is a software testing technique where run time behavior of software under test is checked against predictions made by a model. A model isa description of a system's behavior. Behavior can be described in terms of input sequences, actions, conditions, output and flow of data from input to output. Software Testing is an integral part of the software development life cycle. There are different models or approaches you can use in the software development process where each model has its own advantages and disadvantages. So, You must choose a particular model depending on the project deliverables and complexity of the project. 1.2.5.1 Software Testing Summarization * Software testing is required to check the reliability of the software, Software testing ensures that the system is free from any bug that can cause any kind of failure, + Software testing ensures that the product is in line with the requirement of the client. It is required to make sure that the final product is usor friendly. * At the end software is developed by a team of human developers all having different viewpoints and approach. Even the smartest person has the tendency to make an (New Syllabus w.e academic year 22-23) (M7-67) la) ‘Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-1D (Testing Methodology)..Page no (1-8) error. It is not possible to create software with zero defects without incorporating software testing in the development cycle. * No matter how well the software design looks on paper, once the development starts and you start testing the product you will definitely find lots of defects in the design, You cannot achieve software quality without software testing. * Even if testers are not involved in actual coding they should work closely with developers to improve the quality of the code. For best results it is important that software testing and coding should go hand in hand. WB 1.2.5.2 Software Testing Overview (1) Defects * Defects arise in software due to many reasons. As a matter of fact it is said that every software application has some defects embedded in it but not every defect is a threat to the system. * There is a lot that can be accomplished with the help of software testing. Testing helps in evaluating the quality of software. «There are many reasons why software testing has gained so much of importance in the field of information technology. * Firstly, testing helps in reducing the overall cost of the software development project. If testing is ignored in the initial development stages to save a small amount of money then it may turn out to be a very expensive matter later because as you move on with development process it becomes more and more difficult to trace back defects and rectifying one defect somewhere can introduce another defect in some other module. (2) Requirement +. When software is delivered to the client there are no arguments about the variation from the original requirements. Software testing helps in strengthening the market reputation of a company. Well tested software is of good quality and good quality means better feedback and reviews. * In order to achieve best results it is important to organize all your testing efforts and this is what this Software Testing Training provided by International Software Test Institute is all about. Software testing cannot be fruitful without proper planning. * To live up to the expectations of the client it is important to plan every steP carefully. A lot of things need to be considered in order plan your testing efforts. + Software testing should be planned keeping budget, schedule and performance in mind in order to achieve best results. (New Syllabus w.e.f academic year 22-23) (M7-67) [al Tech-Neo Publications... SACHIN SHAH Vente Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-17) {Testing Methodology). Page no (1-9) (3) Planning + All testing activities require planning. It is important to outline a test plan that will give in details about how each activity will be carried out. * Test plan is also required to ensure that all aspects of the software are covered thoroughly and there is no repetition of testing process so that time and effort is not wasted. * The latest trend now is to involve the testing team in specification writing process. It is important that the testing team understands the requirements of the client clearly as the entire development is based on the requirement defined by the client. + Anything that is not in line with the requirement is a defect. So, the testing team should have a clear idea about what the final outcome of running software should be like. As a matter of fact it is important to start writing test cases in parallel to specification writing. * This will help the testers analyze whether all the requirements are testable or not. When you write test cases in parallel to specification writing process you will think critically about the specifications and you will know if there is an issue with the requirement or if there is something that cannot be developed. eee ey + a 4 1] Exhaustive or complete software testing means that every statement in the program and every possible path combination with every possible combination of data must be executed. * However, soon, we will realize that exhaustive testing is out of scope. That is why the questions arise : (When are we done with testing? or (ii) How do we know that we have tested enough? * There may be many answers to these questions with respect to time, cost, customer, quality, etc. This section will explore why exhaustive or complete testing is not possible. 2] We should concentrate on effective testing that emphasizes efficient techniques to test the software so that important features will be tested within the constrained resources. (New Syllabus w.e.f academic year 22-23) (M7-67) fl ‘Tech-Neo Publications... SACHIN SHAH Venture Scanned with CamScanner* The testing process should be understood as a domain of possible tests (see Fig. 1.3.1) there are subsets of these possible tests.| However, the domain of possible | ¢ tests becomes infinite, as we | cannot test every possible combination. (w7Fig. 1.3.1 : Testing domain This combination of possible tests is infinite, that is, the processing resources and time are not sufficient for performing tests. Computer speed and time constraints limit the possibility of performing all the tests. Complete testing requires the organization to invest a long time, which is not cost- effective. Therefore, testing must be performed on selected subsets that can be performed within the constrained resources. This selected group of subsets (not the whole domain of testing) makes software testing effective. Effective testing can be enhanced if subsets are selected based on the factors that Wis are required in a particular environment. Difference between Effective Testing and Exhausting Testing Effective testing emphasizes efficient techniques to test the s/Ws/w so. that important features will be tested within the constrained resources. Exhaustive or complete testing means that energy statement in the program of every possible path combination with every possible combination of data must be executed. It is a practical method It is not possible to perform complete testing It is feasible because: a) It checks for s/w reliability and no Bugs in the final product b) It tests in each phase c) It ‘uses constrained resources It is not feasible because: a) Achieving deadlines b) Various possible outputs c) Timing constraints d) No. of possible test environments. It is cost effective It is not cost effective It is less complex and less time consuming It is complex and time consuming It is adopted such that critical test cases are concerned first It corners all the test cases (New Syllabus w.e academic year 22-23) (M7-67) (0 Bal recnnco Publications...A SACHIN SHAH Vent! — Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT) (Testing Methodology)...Page no (1-11) © Domain of Possible Inputs to the Software Is too Large to Test Even if we consider the input data as the only part of the domain of testing, we are not able to test the complete input data combination. YW 1.3.2 Domain of Input Data The domain of input data has four sub-parts : 1. Valid inputs 2. Invalid inputs 3. Edited inputs 4. Race condition inputs (Refer Fig. 1.3.2) > 1. Valid inputs + It seems that we can test every valid input on the software. Let us look at a very simple example of adding two-digit two numbers. + Their range is from — 99 to 99 (total 199). So the total number of test case combinations will be 199 x 199 = 39601.199 x 199 = 39601 + Further, if we increase the range from two digits to four-digits, then the number of test cases will be 399,960,001. Most addition programs accept 8 or 10 digit numbers or more. How can we test all these combinations of valid inputs? + When we test software with valid data, it is known as positive testing. Positive testing is always performed keeping in view the valid range or limits of the test data in test cases. > 2, Invalid inputs + Testing the software with valid inputs is only one part of the input sub-domain. * There is another part, invalid inputs, which must be tested for testing the software effectively, * When we test software with invalid data, it is known as negative testing. + Negative testing is always performed keeping in view that the software must work properly when it is passed through an invalid set of data. + Thus, negative testing basically tries to break the software. The important thing, in this case, is the behavior of the program as to how it responds when a user feeds invalid inputs. * Asset of invalid inputs is also too large to test. (New Syllabus w.o.f academic year 22-23) (M7-67) Tel rech.ieo Publications... SACHIN SHAH Venture re Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem ‘esting Methodolo, If we consider again the example of adding two numbers, then the following possibilities may occur: @ Numbers out of range (ii) Combination of alphabets and digits Gii) Combination of all alphabets (iv) Combination of control characters (v) Combination of any other key on the keyboard. [+-— Domain of testing | input domain (usFig. 1.3.2 : Input domain for testing > 3, Edited inputs If we can edit inputs at the time of providing them to the program, then many unexpected input events may occur. For example, you can add many spaces in the input, which are not visible to the user. It can be a reason for the non-functioning of the program. In another example, it may be possible that a user is pressing a number key, then Backspace key continuously and finally after some time, presses another number key and Enter. Its input buffer overflows and the system crashes. ‘The behavior of users cannot be judged. They can behave in a number of ways, causing a defect in testing a program, That is why edited inputs are also not tested completely, > 4, Race condition inputs (Now Syllabus w.e.t academic year 22-23) (M7-67) The timing variation between two or more inputs is also one of the issues that limit the testing. For example, there are two input events, A and B. According to the design, A precedes B in most of the cases, However, B can also come first in rare and restricted conditions. There is the race condition, whenever B proceeds A. Tabrecn see Pustesions. SACHIN SHAN Vero — Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-1 ‘esting Methodology)... Page no (1-13) * Usually the program fails due to race conditions, as the possibility of preceding B in restricted condition has not been taken care, resulting in a race condition bug. * In this way, there may be many race conditions in the system, especially in multiprocessing and interactive systems. Race conditions are among the least tested. * Software systems have become the backbone of almost all the organizations worldwide and how much ever you try to avoid them you end up using software systems in your daily life as a person and as an organization. * With over 2.9 billion* of world population on Internet and rapid modernization of countries across the world, it has become inevitable to avoid the software footprint in your everyday life, Adoption of smart phones has made access to software applications more of a convenience and necessity. * With mission critical and high-risk applications which’ have human lives and resources on risk depending on software applications, testing not only for expected but aiming for zero defects is required. We have listed the Top 10 Mega software failures which resulted in severe disruption and loss of resources in the current year which could have been avoided. 1.4.1 Top 8 Mega Software Failures (1) Amazon Christmas Glitch (2) Air traffic control centre NATS (3) Microsoft Azure Crashes (4) Bitcoin Exchange Collapse (5) Screwfix £34.99 Price Glitch (6) HMRC’s Big Tax Blunder (7) UK border and immigration system (8) Sony Pictures Entertainment > (@) Amazon Christmas Glitch * It was quite a surprise for vendors to see their products on sale for just One penny in Amazon marketplace. «It was a festive bonanza for shoppers and many picked up items as expensive as mobile phones for just 1 penny. © This glitch was attributed to a bug in Amazon price comparison software and resulted in $100,000 for the vendors. > (2) Air traffic control centre NATS Another Christmas incident which affected the travel plans of more than 10000 passengers and leading to heavy delays was attributed to one line of software code which was unaltered since late 1960 and written in defunct language Jovial. (New Syllabus w.ef academic year 22-23) (M7-67) [el recto Pubteatons..A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (M Sotw 2 y jem 7-(T) Costing Methodology)...Page no (1-14) > (8) Microsoft Azure Crashes * Microsoft's office 365, Xbox live gaming and Websites using the Azure platform crashed due a bug in the famous cloud computing platform. Many customers were unable to access the service due to this glitch which was following a performance update. On the Azure blog, Microsoft stated : “The configuration change for the Blob [Binary Large Object] front-ends exposed a bug in the Blob front-ends, which had been previously performing as expected.” Service was down for more than 11 hours, > (4) Bitcoin Exchange Collapse Not implementing a feature which keeps track of the transactions proved costly for Mt. Gox, a Bitcoin exchange when lost $500 million of its virtual currency when someone hacked the exchange. > (6) Screwfix £34.99 Price Glitch + A price glitch at screwfix’s website was the reason for customer’s joy as all the items went on Sale for just £34.99. From garden tractors to expensive power tools, all the items priced to the delight of the shoppers. All this was attributed to a Data validation error and requires a redo at the testing and validation solutions used by the business. Automation testing could have avoided this glitch as the script would have flagged the glitch immediately. > (@) HMRC’s Big Tax Blunder * Her Majesty's Revenue and Customs (HMRC) which is responsible for collection of taxes in UK was hit by a bug in its PAYE (Pay As You Earn) system which has affected more than 5.7 million people. Error in PAYE resulted in wrong tax code allotted to tax payers due to which many paid more than the actual tax and many ended up paying less tax for the last 2 financial years. > (7) UK border and immigration system One of the costliest software failure which is estimated to cost up to £1 billion. The system was incapable of dealing with backlog cases and resulted in 29000 applications backlog. The department also failed to locate 50000 people when was asked to find about them. What they needed was a comprehensive system wide IT strategy with skilled staff to avoid such issues. (Now Syllabus w.e.f academic year 22-23) (M7-67) ‘Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem (Testing Methodoloy age no (1-15) > (8) Sony Pictures Entertainment * The computer network infiltration of one of the major Hollywood movie studio, Sony Pictures entertainment where hundreds of confidential documents were stolen and uploaded on file sharing sites highlights the need of more investment in the network security and thoroughly testing the security aspects. * This incident could cost Sony millions of dollars and some embarrassment if some hidden data is revealed. * Businesses spend an average of €514,000 per IT failure, but 50% of these incidents occurred because of software coding errors or failed IT changes and are “avoidable”, according to KPMG research. * At Cigniti, we assist organizations to achieve defect free software applications, accelerate the software life cycle while assuring quality. Global businesses rely on Cigniti’s proprietary IP (BETAS) and colocated software testing expertise to avoid software failures, % 1.5.1 The Most Common Software Testing Terminology There is so much information out there about software testing that it can be hard to know where to start. First time testers need to learn the terminology as fast as possible but there are so many different sources of information. We have attempted to take the top software testing terminology, alphabetize it, and define it in simple terms. While a doozy of info, hopefully this can be a guide while learning the ropes of the trade. | Se | | No. ) | Acceptance The predefined and described set of requirements or criteria conditions that must be met in order for the feature to be released to the public. @) | Ad-hoc testing Informal testing that does not have any documentation, tickets or planning. @) | Agile Not a person who moves quickly, but rather software development that focuses on tasks at hand to be broken down into short phases of work with frequent reappraisals of the work and adaption of the work. (New Syllabus w.ef academic year 22-23) (M7-67) [bl recn.eo Publications...A SACHIN SHAH Venture Scanned with CamScannerSottware Tes! mig & Quality Assurance (MU-Sem 7-IT) Clesting Mothodology)...Page no ( 8) | Sr. |: Parameter c Description <>.) No. | : é ; (4)_| Automated testing | A testing technique that uses an automation testing tool to write test scripts and automate any of the repetitive tasks, comparing the actual outcome with the expected outcome, () | Black-box testing | A testing technique that is conducted by a tester not knowing the structure or design of the product whatsoever. (6) | Blocker This is a bug that is deemed absolutely critical to fix before release of the product. If it is not fixed, it can possibly ruin the entire product or feature launch. (=| Bugs Bugs are problems, issues, or defects that operate in the program code. These can be minor or major errors, but regardless they need to be fixed before the release. (8) | Bug reports This is a formal way to document bugs, but each testing company will have their own version. They will need these reports to be able to give details about the issue to the developers. (9) | Component Component testing is a testing technique that focuses testing separately on small elements of a system. (10) | Configuration testing Another testing technique that ensures that the system or product can operate under various software and hardware conditions, such as a web application being able to properly work in different browsers. (11) | Defects Defects are issues that do not meet the acceptance criteria. It might not be a bug, but rather a design or content issue that does not match the requirements set forth by the client. (12) | Expected outcome | This is what the system feature or product is supposed to be doing. The observed or actual outcome is then compared against the expected outcome to show any deviations from the acceptable criteria. 3) | Exploratory Exploratory testing means that there is not a test written, testing rather a tester checks the system based on theif knowledge of the system and will execute tests based 0” that. (New Syllabus w..f academic year 22-23) (M7-67) Tl rech-veo Publications...A SACHIN SHAH Vent4’? _—_—a Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7:17) (Testing Methodology)...Page no (1-17) Parameter Description Fail/Failure/Failed | The feature or component did not meet the expected outcome. (15) | Feature Changes made to a system or product in order to add new functionalities or modify already existing ones. (16) | Life-cycle testing | Life-cycle testing is a range of activities that are implemented during the testing process to ensure that the software quality goals are achieved. (17) | Load testing Load testing is a type of testing that measures the performance of the system under a certain load. (18) | Manual testing Manual testing is the testing process of manually testing software for bugs and defects where a tester is the ‘end- user’. (19) | Mobile-Device Mobile-Device testing is software testing on mobile testing devices to ensure that works on both the hardware and software. (20) | Negative testing Negative testing is the method of testing where invalid information is inputted into the system in order to see if it can handle incorrect or unwanted results. (21) | Observed outcome | Observed outcome is what the tester encounters within the system or product. It is compared to the expected outcome to see if it matches or deviates away from it. (22) | Pass/Passed The feature or component meets the expected outcome. (23) | Positive testing Positive testing is a testing technique that shows that the system/product in a test does what it is supposed to do. (24) | Priority The level that is assigned to the ticket. Each company will have their own rating system but usually is along the lines of critical being the highest priority and low being the lowest priority. (25) | Performance Performance testing is the type of testing conducted to testing determine the systems strength under a_ specific workload. It checks the responsiveness and security of the system. (New Syllabus w.o.f academic year 22-23) (M7-67) [Bal rech-veo Publications...A SACHIN SHAH Venture Scanned with CamScannerParameter Description (26) Quality Quality measures the design of the software, how well the actual application conforms to that software, and how the software executes its purpose. (27) Quality Assurance Quality Assurance is the methodical monitoring and evaluation of the software system to ensure that the minimum requirements and standards are being met. (28) Regression testing A full system testing usually conducted before the new release of a system in order to find any new bugs or defects or see if previous ones were fixed. (29) Release Release is the new version of the software system that can either be for the testers or for the clients. (80) Requirements Requirements is all of the evidence that contains information about the feature. This allows for software developers to build and the testers to be able to test the right functionalities. 1) Smoke testing Smoke testing is a quick testing form that allows testers to quickly check major features and functions either right before or after a release. (82) Sprint s Sprint s is the amount of time that is given for the QA process, usually has to do with the number of tasks that a team needs to complete. (33) Stress testing Stress testing is testing that is showing how the system reacts to certain workload situations that will exceed the systems specified requirements. It shows where the system will fail in its resources, (84) Test case Test cases are a set of structured steps or script that tell the tester exactly how the feature of function of the system should work. It should usually contain expected results and the conditions associated with these. (35) Test environment Test environment is the technical environment in which the software tester will be conducting and running the tests. (36) Test suites Test suites are the test cases that are compiled together for the system testing, _— (New Syllabus w.e.f academic year 22-23) (M7-67) fal Tech-Neo Publications... SACHIN SHAH Ver tre nd Scanned with CamScanner(Testing Methodoloy Assurance (MU-Sem 7. Pago no Software Testing & Qué Parameter Description (3?) | Users Users are the people who will end up using the software. (38) | User acceptance | User acceptance testing also known as UAT, is one of the testing last phases of testing. It is the process of ensuring that the software works for the user in the real world. (89) | User experience | User experience comes from the experience of the person that is using the software or product and focuses on various aspects, but especially how the usability, overall design, and functionality. (40) | White-box testing | White-box testing occurs when the tester has previous Knowledge of the system that is being tested and is familiar with the structure. The opposite of this is black- box testing. Note : (Refer Section 1.6.1 to 1. * Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. STLC involves both verification and validation activities. * Contrary to popular belief, Software Testing is not just a single/isolate activity, ie. testing. It consists of a series of activities carried out methodologically to help certify your software product. "= STLC Phases There are following six major phases in every Software Testing Life Cycle Model (STLC Model) : 1 Requirement Analysis 2. Test Planning 3. Test case development 4, Test Environment setup 5. Test Execution 6. Test Cycle closure (New Syllabus w.e.f academic year 22-23) (M7-67) la) ‘Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7- esting Methodology) .--Page no 1-20) Test planning Environment setup Test cycle closure l (1a9Fig. 1.6.1 : STLC Model Phases Each of these stages has a definite Entry and Exit criteria, Activities and Deliverables associated with it. © what is Entry and Exit Criteria in STLC ? + Entry Criteria : Entry Criteria gives the prerequisite items that must be completed before testing can begin. « Exit Criteria : Exit Criteria defines the items that must be completed before testing can be concluded You have Entry and Exit Criteria for all levels in the Software Testing Life Cycle (STLC). In an Ideal world, you will not enter the next stage until the exit criteria for the previous stage is met. But practically this is not always possible. So, for this tutorial, we will focus on activities and deliverables for the different stages in STLC life cycle. Let's look into them in detail. ®_ 1.6.1 Requirement Phase Testing Requirement Phase Testing also known as Requirement Analysis in which test team studies the requirements from a testing point of view to identify testable requirements and the QA team may interact with various stakeholders to understand requirements in detail, Requirements could be either functional or non-funetional- Automation feasibility for the testing project is also done in this stage. Venture (New Syllabus w.e.f academic year 22-23) (M7-67) Tech-Neo Publications...A SACHIN SHAH —ad/ Scanned with CamScanner(Testing Methodology)... Page no (1-21 Software Testing & Quality Assurance (MU-Sem 7: (1) Activities in Requirement Phase Testing Identify types of tests to be performed. Gather details about testing priorities and focus. * Prepare Requirement Traceability Matrix (RTM). Identify test environment details where testing is supposed to be carried out. * Automation feasibility analysis (if required). (I) Deliverables of Requirement Phase Testing + RIM ‘+ Automation feasibility report. (if applicable) 1.6.2 Test Planning in STLC Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along with efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations and the testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase. (1) Test Planning Activities + Preparation of test plan/strategy document for various types of testing © Test tool selection © Test effort estimation + Resource planning and determining roles and responsibilities. © Training requirement iverables of Test Planning + Test plan /strategy document. * Effort estimation document. % 1.6.3 Test Case Development Phase ‘The Test Case Development Phase involves the creation, verification and rework of test casos & test scripts after the test plan is ready. Initially, the Test data is identified then created and reviewed and then reworked based on the preconditions. Then the QA team starts the development process of test cases for individual units. (I) Test Case Development Activities * Create test cases, automation scripts (if applicable) «Review and baseline test cases and scripts © Create test data (If Test Environment is available) (New Syllabus w.e.f academio year 22-23) (M7-67) [eb ech.neo Pubtctons A SACHIN SHAH Venture Scanned with CamScanner— Software Testing & Quality Assurance (MU-Sem 7-7) esting Methodology) ..Page no (1 2) (12) Deliverables of Test Case Development Test cases/scripts ° Test data A 1.6.4 — Test Environment Setup Test Environment Setup decides the software and hardware conditions under which a work product is tested. It is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development Phase. Test team may not be involved in this activity if the development team provides the test environment. The test team is required to do a readiness check (smoke testing) of the given environment. (1) Test Environment Setup Activities (1) Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment. (2) Setup test Environment and test data (3) Perform smoke test on the build (ZI) Deliverables of Test Environment Setup (1) Environment ready with test data set up (2) Smoke Test Results. %& 1.6.5 Test Execution Phase ‘Test Execution Phase is carried out by the testers in which testing of the software build is done based on test plans and test cases prepared. The process consists of test script execution, test script maintenance and bug reporting. If bugs are reported then it is reverted back to development team for correction and retesting will be performed. (1) Test Execution Activities (1) Execute tests as per plan (2) Document test results, and log defects for failed cases (3) Map defects to test cases in RTM (4) Retest the Defect fixes (5) Track the defects to closure (11) Deliverables of Test Execution (1) Completed RTM with the execution status (2) Test cases updated with results (3) Defect reports (New Syllabus we academic year 22-23) (M7-67) [Bal soci-oo Publication. SACHIN SHAH Vent#® _ aff Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT) (Testing Methodology)... Page no (1-23) WW 1.6.6 Test Cycle Closure * Test Cycle Closure phase is completion of test execution which involves several activities like test completion reporting, collection of test completion matrices and test results. * Testing team members meet, discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from current test cycle. The idea is to remove process bottlenecks for future test cycles. (1) Test Cycle Closure Activities (1D) Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical Business Objectives, Quality. (2) Prepare test metrics based on the above parameters. (3) Document the learning out of the project. (4) Prepare Test closure report. (5) Qualitative and quantitative reporting of quality of the work product to the customer. (6) Test result analysis to find out the defect distribution by type and severity. (II) Deliverables of Test Cycle Closure (1) Test Closure report (2) Test metrics (3) STLC Phases along with Entry and Exit Criteria 11.7, CLASSIFICATION OF SOFTWARE BUGS ee ee ee eee cycle. bugs based insole?” CURSE | 2 ar = While the classifiers for the latter two are present in bug tracking systems by default, I recommend setting up a classifier for the division of bugs by their nature as well since it helps streamline the assignment of bug fixing tasks to the responsible teams. Classify different types of bugs based on Software development life (1) Software Functional defects (2) Performance defects (3) Usability defects (5) Security defects Compatibility defects > (1) Software Functional defects + Functional defects are the errors identified in caso the behavior of software is not compliant with the functional requirements. Such types of defects are discovered via functional testing. (New Syllabus w.e.{ academic year 22-23) (M7-67) [Bbrecnico Publications... SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem (Testing Methodology)...Page no For example, in one of our recent testing projects, a functional defect was found in an ecommerce website’s search engine. It didn’t return any results when a user typed in a product ID, while it was stated in the requirements that the search could be conducted by both a product's name and ID. > (2) Performance defects Performances defects are those bound to software’s speed, stability, response time, and resource consumption, and are discovered during performance testing, ‘An example of a performance defect is a system's response time being X times longer than that stated in the requirements. > (8) Usability defects Usability defects make an application inconvenient to use and, thus, hamper a user’s experience with software. ‘Acontent layout that is difficult to scan or navigate and an overly complex signup procedure are the examples of usability defects. To identify such defects, Science Soft’s test engineers and business analysts (or UX designers) validate software against usability requirements and Web Content Accessibility Guidelines (WCAG) during usability testing. > (4) Compatibility defects ‘An application with compatibility errors doesn’t show consistent performance on particular types of hardware, operating systems, browsers, and devices or when integrated with certain software or operating under certain network configurations. Compatibility testing is carried out in order to discover such issues. For instance, testing a mobile app for car insurance claim estimation, we uncovered that it failed to behave according to the requirements on Android 8.0 and 8.1. The defects were related to the changes in font size, content alignment, and scroll bar. > (6) Security defects Penetration Testing Consultant and Certified Ethical Hacker, says: “Security defects are the weaknesses allowing for a potential security attack. ‘The most frequent security defects in projects we perform security testing for are encryption errors, susceptibility to SQL injections, XSS vulnerabilities, buffer overflows, weak authentication, and logical errors in role-based access”. (New Syllabus w.e.4 academic year 22-23) (M7-67) [eal recn-Noo Pubicatons.a SACHIN SHAH Vent® ___ a Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT)_(Testing Methodology) ..Page no (1-25) 41.8 DEFECT/BUG LIFE CYCLE IN SOFTWARE TESTING "VQ. What s Life cycle of Bug? Explain Life Cycle of Bug and Defect states of bug? %® 1.8.1 What is Defect Life Cycle ? * Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect or bug goes through in its entire life. + The purpose of Defect life cycle is to easily coordinate and communicate current status of defect which changes to various assignees and make the defect fixing process systematic and efficient. Defect Status + Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect or bug in order to better track and understand the actual progress of the defect life cycle. + The number of states that a defect goes through varies from project to project. Fig. 1.8.1 shows lifecycle diagram, covers all possible states © New: When a new defect is logged and posted for the first time. It is assigned a status as NEW. © Assigned : Once the bug is posted by the tester, the lead of the tester approves ‘the bug and assigns the bug to the developer team. o Open : The developer starts analyzing and works on the defect fix © Fixed : When a developer makes a necessary code change and verifies the change, he or she can make bug status as “Fixed.” o Pending retest : Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the testers end, the status assigned is “pending retest”, o Retest : Tester does the retesting of the code at this stage to check whether the defect is fixed by the New L_ Assigned "| Duplicats Rejected | Deffered Nota bug» developer or not and changes the Closed _] status to “Re-test.” (1t0)Fig. 1.8.1 : Bug/Defect Life Cycle (New Syllabus w.e.f academic year 22-23) (M7-67) [ab recn oo Publications...A SACHIN SHAH Venture Scanned with CamScanner= Software Testing & Quality Assurance (MU-Sem 7: (Testing Methodology)...Page no (1-26) + Verified : The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified”. © Reopen : If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again the bug goes through the life cycle. © Closed : If the bug is no longer exists then tester assigns the status “Closed.” * Duplicate : If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.” * Rejected : If the developer feels the defect is not a genuine defect then it changes the defect to “rejected”. «Deferred : If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs. « Not a bug : If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”. 1.8.2 Defect Life Cycle Testing Process Developer starts | “xing the cod Testor retest the code. [Status = Re-opedy (AiFig, 1.8.2 : Defect Life Cycle Ye (New Syllabus w.e.t academic year 22-23) (M7-67) [El rech-tveo Publications... SACHIN SHAH Ver" — Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7: fasting Methodology)...Page no Tester finds the defect. Status assigned to defect- New. A defect is forwarded to Project Manager for analyze. Project Manager decides whether a defect is valid. Here the defect is not valid- a status is given “Rejected.” Sap eye So, project manager assigns a status rejected. If the defect is not rejected then the next step is to check whether it is in scope. Suppose we have function- email functionality for the same application, and you find a problem with that. But it is not a part of the current release when such defects are assigned as a postponed or deferred status. 7. Next, the manager verifies whether a similar defect was raised earlier. If yes defect is assigned a status duplicate. 8. If no the defect is assigned to the developer who starts fixing the code. During this stage, the defect is assigned a status in-progress. 9. Once the code is fixed. A defect is assigned a status fixed 10. Next, the tester will re-test the code. In case, the Test Case passes the defect is closed. If the test cases fail again, the defect is re-opened and assigned to the developer. 11. Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order that was fixed and assigned a status closed. During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened. & Three Software Testing Methodologies to Consider * In today’s tech landscape, staying ahead of your competition and delivering quality consistently are the two differentiators that make an app-first company succeed. + So it’s no surprise that teams are always on the lookout for the best possible testing approaches that will improve their QA strategy and influence the quality of their product. We all want to keep our strategies fresh and see the quality of our software get better and better as a result. + Software testing methodologies are the processes used to ensure you deliver a well- tested product at speed and keep up with lightning-quick SDLCs. «But how do you choose which software testing methodology is right for you? What does each one entail, and what are the benefits? Read on to find out. (New Syllabus w.0,f academic year 22-28) (M7-67) fl ‘Tech-Neo Publications... SACHIN SHAH Venture Scanned with CamScanner—x Software Testing & Quality Assurance (MU-Sem (Testing Methodology)...Page no (1-28) TA 1.9.1 Waterfall Method This software development model is sequential, The next step only begins after the previous step is completed. The process might look a little something like in Fig. 1.9.1. (1) Requirements: This is all about gathering the requirements for the product or update. What are the key functions? How should it behave ? (2) Design : Decide how the code will be written. Focus on the design of the product (i mentation} imple I Ls I ai2Fig. 1.9.1 : Waterfall Model (8) Implementation : Build the product. Write the code. (4) Verification : Test, Test Test. (6) Maintenance : Release the product into the wild. Then be r eady for any bug fixes, updates or changes. What are the benefits ? In reality, this method doesn’t allow a lot of wiggle room. For that reason, it is extremely useful for small projects where requirements are clearly defined, For anything bigger, like a full product launch, the waterfall methodology can actually be very restrictive. If you want to release a simple update, with a clear set of instructions behind it, however, waterfall can help. testing is only the fourth step out of fiv lst. This method does not priorities QA, and, es introduced at the design stage of the typical SDLC, | could be a costly mistake, , pushed right down the priority pecially when 80% of bugs are leaving quality as an afterthought As software testing methodologies go, it might not be your preferred option if you need to launch a high-quality product, (New Sylabus w.4 academi yoar 22-28) (47-67) BB rechseo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem, Page no Testing Methodolo, W 1.9.2 Agile Methodology Agile testing couldn't be further from the strict process of waterfall. Requirement ‘gathering Agile testing operates under the afd analysis philosophy that testing is a crucial part of development, and just as important as the coding stage. Deploy and maintenance In agile, testing is integrated directly into the development process so that bugs are discovered as early and as often as possible. As a result, testers can identify Ds ualop) problems at every point in the — development process, moving the product quickly towards release. araFig. 1.9.2 : Agile Methodology What are the benefits ? ‘The agile methodology makes your SDLC fluid and your team more able to adapt. The involvement of QA from the word ‘go’ means that your product will be well-tested and better quality as a result. A le to deliver quality at speed “Continuous testing is an integral part of the agile development process. We ship high-quality small increments and gather early customer feedback, which helps us prioritize our next steps. Thus, we minimize risks by failing fast and cheaply and avoid investing too much in the initiatives that do not benefit our customers.” “The main benefits of the agile approach are : © The ability to quickly respond to possible changes © Testing documentation is simplified, but always up to date (for example, QA-Cheeklists) © Continuous testing and, as a result, higher quality © Convenience for the work of developers and managers who are constantly in touch with a client or a product owner o Perfect for start-ups and fast-growing projects.” (New Syllabus w.0.f academic year 22-23) (M7-67) fl ‘Tech-Neo Publications... SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7. esting Methodology) ..Page no (1-39) 1.9.3 Iterative Development * In iterative development, a large project is broken down into smaller, manageable chunks. Each ‘chunk’ is subjected to a number of iterations of the waterfall model. It’s almost as if you run a number of different SDLCs within a wider project, and each iteration contains a waterfall methodology. It looks a little bit like this : (1a19Fig. 1.9.3 : Iterative Development * As soon as one iteration is completed, the entirety of the software is subjected to testing (verification). Then, feedback from the tests is incorporated into the next cycle, As the iterations progress, the time spent testing can be reduced as a result of experience gained from previous iterations. * This means that you have more flexibility to test earlier on in the process and test each iteration thoroughly, rather than conducting a huge amount of testing right at the end of your SDLC. ts What are the benefits ? * Aconsiderable benefit of using this method is that testing feedback is available at the end of each iteration. This means that you are testing more regularly than in a method like waterfall, and allowing the results to inform your further decision making. + Although iterative development does not quite abide by the rules of continuous testing, it does bear similarities to the agile methodology. You test earlier on in the SDLC and incorporate feedback from your tests into the development process. This means you are placing more emphasis on the value of QA and allowing it to influence part of your decision making. (New Syllabus w.e.f academic year 22-23) (M7-67) Te rech-teo Publications...A SACHIN SHAH Venture —— Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7: ‘esting Methodolo, Page no 5 Choosing the right software testing methodology for you There are so many methodologies to choose from when it comes to software development. When it comes to the testing part of the process, you need to consider your requirements, project size, scope and budget. For smaller projects, where the scope is clear, methods like waterfall can be extremely beneficial. That’s because your team are following a straightforward process, with a degree of understanding about where the process will lead. But typically, for bigger projects, agile methodologies can have some strong benefits. Introducing testing early into your SDLC means you will catch bugs earlier on, and enables you to incorporate testing feedback into the design and build stages. This will help you achieve a better quality product overall, as you shift your focus towards making QA a priority. Each project is unique. So consider your options, assess your scope, and use our guide to decide whether software testing methodology is right for you. ao nae | y 18, Dec. 19 & 1.10.1 Verification and Validation (2) Verification in Software Testing Verification in Software Testing is a process of checking documents, design, code, and program in order to check if the software has been built according to the requirements or not. The main goal of verification process is to ensure quality of software application, design, architecture etc. The verification process involves activities like reviews, walk-through and inspection. (11) Validation in Software Testing Validation in Software Testing is a dynamic mechanism of testing and validating if the software product actually meets the exact needs of the customer or not. The process helps to ensure that the software fulfils the desired use in an appropriate environment. The validation process involves activities like unit tosting, integration testing, system testing and user acceptance testing. (New Syllabus w.e.f academic year 22-28) (M7-67) [al reaneo Publications... SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7: esting Methodology)-_.Page no (1-32) ° Key Difference Verification process includes checking of documents, design, code and program whereas Validation process includes testing and validation of the actual product, Verification does not involve code execution while Validation involves code execution, Verification uses methods like reviews, walkthroughs, inspections and desk-checking whereas Validation uses methods like black box testing, white box testing and non. functional testing. Verification checks whether the software confirms a specification whereas Validation checks whether the software meets the requirements and expectations. Verification finds the bugs early in the development cycle whereas Validation finds the bugs that verification cannot catch. Verification process targets on software architecture, design, database, etc. while Validation process targets the actual software product. Verification is done by the QA team while Validation is done by the involvement of testing team with QA team. Verification process comes before validation whereas Validation process comes after verification. % 1.10.2 Verification vs Validation : Key Difference _ Verification The verifying process includes checking documents, design, code, and program It is a dynamic mechanism of testing and validating the actual product It does not involve executing the code It always involves executing the code Verification uses methods like reviews, walkthroughs, inspections, and desk. checking ete. Tt uses methods like Black Box Testing, White Box Testing, and non- functional testing Whether the software conforms to specification is checked It checks whether the software meets the requirements and expectations of @ customer It finds bugs early in th e development cycle Tt can find bugs that the verification (New Syllabus w.et academic year 22-29) (7-87) Process can not catch (e ) ‘Tech-Neo Publications...A SACHIN SHAH Vent! Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem. 7-IT) _(Testing Methodology)... -Page no (1-33) "Verification Validation 6. | Target is application and software | Target is an actual product architecture, specification, complete design, high level, and database design ete. 7. | QA team does verification and make | With the involvement of testing team sure that the software is as per the | validation is executed on software requirement in the SRS document. code. 8._| It comes before validation It comes after verification % 1.10.3 Verification Requirements * A verification requirement provides the rules of verification for a piece of data (verifiable data item). There are many variables included in these rules including where and how the rules apply at runtime. + For example whether the verification engine needs to apply the rules to participant level data or to a specific case. * Again using date of birth as an example of a verifiable data item, for some organizations the rules may be to verify this piece of data once and therefore verification engine applies the rules within participant manager. + For other organizations the rules may require that date of birth is verified at a program level and therefore the verification engine applies the rules to a specific case - see 3.5.4 Verification Requirement Usages for further information. %® 1.10.3.1 Verification Requirement Properties The following is an overview of the properties that can be set on a verification requirement. (1) Due Date and Warning Date * A number of properties exist for setting a due date on verification. The due days property specifies the number of days after a particular event that verification should fall due. * Administrators can also specify whether the number of due days should be calculated from the date the case was created or from the date evidence was inserted or received. (New Syllabus w.e.f academic year 22-23) (M7-67) Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-IT) (Testing Methodology) ..Page no (1 34) + The warning days property specifies how many day's prior notice a caseworker will receive before the verification due date. If no warning date is specified, caseworker will not receive a warning before the verification due date. Note that due date processing for verification requirements uses workflow functionality. For more information on expiry date and due date workflow processing, see Deadline Management. (2) Level * This property indicates the level of verification that must be achieved in order to consider data verified. Evidence will not be considered verified unless verification item with the appropriate level is received. For example, if a verification requirement specifies a level 5 verification item (such as an original birth certificate) then providing a level 1 item (a photocopy of a birth certificate) will not satisfy the verification requirement. Alternatively, a combination of verification items that form a verification group of level 5 can be provided to satisfy the verification requirement. (3) From and To Dates * These properties indicate the period during which this verification requirement is effective. Note that these properties interact with the effective dates of verification item utilizations and the effective dates of evidence in order to determine the verifications that a caseworker can perform, For example, a requirement to verify an income amount might be defined as effective from January to December. However, one verification item may be defined as effective from January to July (©-8. a payslip), while another is defined to be effective from July to December » a tax return). necessary to satisfy the verification requirement. (4) Minimum Items * This property specifies the i minimum number of verification items that must b¢ Provided before data can be considered verified, For example, if the minimum : item specified is 2, then the verificatio? requirement will be considered satisfied (New Syllabus w.ef academic year ) (7-67) Tech-Neo Publications... SACHIN SHAH Ventl® Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem ‘esting Methodolo: « A combination of verification items and groups can also be provided to satisfy the minimum number of verification items of a verification requirement. (5) Mandatory + This property indicates whether or not the verification requirement is mandatory. A mandatory verification requirement means that evidence and cases associated with the verification may not be activated until the rules defined for the verification have been met. * When the mandatory property is not set, the verification requirement is optional and therefore the evidence associated with the verification can be activated even if the evidence has not yet been verified. (6) Client-Supplied «This property indicates if it is the case participant's responsibility to supply the verification items. This property could be used during communications between the organization and the client to ensure that a client is not asked to supply a verification item that should be sourced elsewhere. + Note there is no system processing associated with this property, it is used for informational purposes only for the user. (7) Re-verification + This property allows users to specify the Ciram Verification engine's response to changes to Active evidence. + The following list provides the names and impact of the settings for this property. Note that re-verification property does not apply to participant evidence. (8) Recertify Always * If a caseworker changes Active evidence, no previously met verification requirements are carried over to the new In Edit evidence. «The new In Edit record must then be recertified. (9) Recertify If Changed «If caseworker changes Active evidence, and the value entered for the verifiable data item or any dependent data items has not changed, the existing verification information on the Active record is copied to the new In Edit record. «If the value entered for the data item or any dependent data items has changed, then no verification information is copied from the Active record. (New Syilabus w.e.4 academic year 22-23) (M7-67) [Bl recr-nco Pusictons..A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-7 Testing Methodology)... Page no (1-36) (10) Never Recertify If a caseworker changes Active evidence, the verification information on the Active record is always copied to the In Edit record. 1.11 VERIFICATION OF HIGH LEVEL DESIGN AND Low TEV EL DESIGN VALIDATION 3 = = ==, UQ. _ Explain Verification In high leve High Level Design * High Level Design in short HLD is the general system design means it refers to the overall system design. It describes the overall description/architecture of the application. It includes the description of system architecture, data base design, brief description on systems, services, platforms and relationship among modules. It is also known as macro level/system design. It is created by solution architect. It converts the Business/client requirement into High Level Solution. It is created first means before Low Level Design. 2. Low Level Design Low Level Design in short LLD is like detailin, '¢ HLD means it refers to component-level design process. actual logic for every system component and it goes deep into each modules Specification. It is also known as micro level/detailed design. It is created by designers and developers. It converts the High Level Solution into Detailed solution. It is created second means after High Level Design. at Difference between High Level Design and Low Level Design Te: 1. | High Level Design is the general System design means it refers to the overall system design, 2 ae Level Design in short called as means it refers to component-level design process, Low Level Design in short called as LLD. 3. | Itis also known a, design, '§ Macro level/system It is also known as micro level/detailed design. _J BBhrecises Publications... SACHIN SHAH Venture (New Syllabus w.e.f academic year 22-23) (M7-67) Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7: (Testing Methodology)...Page no ee High level design - Low level design fo. at 4, | It | describes the overall | It describes detailed description of each description/architecture of the | and every module. application. 5, | High Level Design expresses the brief | Low Level Design expresses details functionality of each module. functional logic of the module. 6. | It is created by solution architect. It is created by designers and developers. 7. Here _in High Level Design the | Here in Low Level Design participants participants are design team, review | are design team, Operation Teams and team and client team. Implementers. 8. | It is created first means before Low | It is created second means after High Level Design. Level Design. 9. | In HLD the input criteria is Software | In LLD the input criteria is reviewed Requirement Specification (SRS). High Level Design (HLD). 10. | High Level Solution converts the | Low Level Design converts the High Business/ client requirement into Level Solution into Detailed solution. High Level Solution. 11, |In HLD the output criteria is data | In HLD the output criteria is program pase design, functional design and | specification and unit test plan. review record. > (1) Study any system application (New Syllabus w.e.f academic year 22-23) () Study any system application (2) Find requirement specification and design the system ct software testing methodology suitable to the application. (3) Sele System Testing is a type ofsoftware testing that is performed on a complete m with the corresponding integrated system to evaluate the compliance of the syste requirements. 4 components are taken as input. The goal integration testing passe larity between the units that are In system testing, detect any irregul of integration testing is to integrated together. SACHIN SHAH Venture (7-87) Tech-Neo Publications...A Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem (lesting Methodology) ..Page no (1-39 System testing detects defects within both the integrated units and the whole system, The result of system testing is the observed behaviour of a component or a syster, when it is tested. * System Testing is carried out on the whole system in the context of either systom requirement specifications or functional requirement specifications or in the context of both, * System testing tests the design and behaviour of the system and also the expectations of the customer. It is performed to test the system beyond the bounds mentioned in ———— the software requirements specification (SRS). | Acceptance Testing * System Testing is basically performed by a testing team that is independent of the development team that helps to test the quality of the system impartial. It has both functional and non-functional testing. Begration Testing + System Testing is a black-box testing. Ea a + System Testing is performed after the integration testing and before the acceptance testing. Fig. 1.12.1 : System testing ‘System Testing = System Testing Process System Testing is performed in the following steps : * Test Environment Setup: Create testing environment for the better quality testing. * Create Test Case : Generate test case for the testing process, * Create Test Dat: Generate the data that is to be tested. + Execute Test Case : After the generation of the test case and the test data, test cases are executed. + Defect Reporting: Defects in the system are detected. + Regression Testing : It is carried out to test the side effects of the testing process. + Log Defects : Defects are fixed in this step. Retest : If the test is not successful then again test is performed. Generate esting Data Regression Defect Testing Reporting Fig, 1.12.2 : system testing process (Now Syllabus w.ef academic your 22-23) (7-67) ‘Tech-Neo Publicati Generate Test Cases 18..A SACHIN SHAH Vertu? Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 17) (Testing Methodology) ..Page no Gi 39) "Types of System Testing * Performance Testing Performance Testing is a type of software testing that is carried out to test the speed, scalability, stability and reliability of the software product or application. * Load Testing Load Testing is a type of software Testing which is carried out to determine the behavior of a system or software product under extreme load. ° Stress Testing Stress Testing is a type of software testing performed to check the robustness of the system under the varying loads. * Scalability Testing Scalability Testing is a type of software testing'which is carried out to check the performance of a software application or system in terms of its capability to scale up or scale down the number of user request load. > (2) Find requirement specification and design the system "= How to Measure Functional SRS Documents? * Well, we need to define some standard tests to measure the requirements. Once each requirement is passed through these tests, you can evaluate and freeze the functional requirements. Let’s take anexample; you are working on a web-based application. The requirement is as follows: “Web application should be able to serve the user queries as early as possible” = How will you freeze the Requirement in this case? * What will be your Requirement Satisfaction criteria? To get the answer, ask this question to the stakeholders: How much response time is ok for you? If they say that they will accept the response if it's within 2 seconds, then this is your requirement measure. + Freeze this requirement and carry the same procedure for the next requirement too. "5 We just learned how to measure the requirements and freeze those in Design, Implementation and Testing phases. + Now let’s take another example : 1 was working on a Web-Based project. Client (stakeholders) specified the project requirements during the initial phase of the project development. My manager circulated all the requirements to the team for review. When we started the discussion on these requirements, we were just shocked! (New Syllabus we.t academic year 22-23) (M7-67) [al racn iso Punsston ‘A SACHIN SHAH Venture Scanned with CamScannera Software Testing & Quality Assurance (MU-Sem 71D) Coating Methodology)..Page no (1-40) © Everyone was having his or her own conception about the requirements. We found a lot of ambiguities in the “terms” specified in the requirement documents, which later on was sent to the client for review/clarification. The client used many ambiguous terms, which had many different meanings, thoreby making it difficult for us to analyze the exact meaning. The next version of the requirement doc from the client was clear enough to freeze for the design phase. 1 From this example, we learned that the "Requirements should be clear and consistent” « The next criteria for testing the requirements specification is to “Discover missing requirements”, let’s take a look at it. * Discover Missing Requirements © Many times the project designers don’t get a clear idea about each specific module and they simply assume some requirements in the design phase. None of the requirements should be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development. © Specifications should state both the types of requirements i.e., what the system should do and what it should not. + Generally, I use my own method to uncover the unspecified requirements. When I read the Software Requirements Specification document (SRS), I note down my own understanding of the requirements that are specified, plus other requirements that the SRS document is supposed to cover. © This will help me to ask questions about the unspecified requirements thereby making it clearer. * To check the completeness of the requirements, divide the requirements into three sections: ‘Must implement’ requirements, requirements that are not specified but are ‘assumed’ and the third type is ‘imagination’ type of requirements. Check if all types of requirements are addressed before the software design phase. © Check if the Requirements are related to the Project goal * Sometimes stakeholders have their own expertise, which they expect to come into the system under development. They don’t even think about whether that requirement would be relevant to the project in hand. Make sure to identify suc requirements, + Try avoiding all irrelevant requirements during the first phase of the pric development eycle, (New Syllabus vie.f academic year 22-29) (MT-67) [al rech-neo Publications... SACHIN SHAH Vert™® Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7-7) (Testing Methodology) ..Page no (1-41) + If not possible, then ask the questions to stakeholders like why do you want to implement this specific requirement? This will describe that particular requirement in detail, thereby making it easier to design the system considering the future scope, "= But how to decide whether the requirements are relevant or not? * Simple answer: Set the project goal and ask this question: If not implementing this requirement will cause any problem in achieving our specified goal ? If not, then this is an irrelevant requirement. Ask the stakeholders if they really want to implement these types of requirements. ‘& In short, the Requirements Specification (SRS) doc should address the following : Project functionality (what should be done and what should not be done). Software & Hardware interfaces and the user interface. System Correctness, Security and performance criteria. + Implementation issues (risks) if any. > (8) Select software testing methodology suitable to the application 5 Introduction to Application Testing * Application Testing is an activity that is performed frequently by almost every software tester in his career. These two words are extremely broad in practical aspects. * However, only the core and most important areas will be discussed here. The purpose of this tutorial is to touch all the primary areas so that the readers will get all the basic briefings at a single place. "= Application Testing : Explaining The Basics Of Software Testing Categories of Applications Whether it is a small calculator software with only the basic arithmetic operations or an online enterprise solution; there are three categories of applications: Desktop © Desktop o Web © Mobile Fig. 1.12.3 : Three Category of application (New Syllabus w.e.f academic year 22-23) (M7-67) cs} ‘Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerue — Methodolo Software Testing & Quality Assurance (MU-Sem 7- — age no (1-42) * For desktop applications, testing should consider UI, business logic, databases, reports, roles and rights, integrity, usability, functionality, performance, security, hardware & software compatibility and data flow. For web applications, testers should give sufficient importance to the performance, load, and security of the application. The other main testing types covered under web application testing are functional testing, cross-browser testing, UAT, Beta testing, regression testing, compatibility testing, smoke testing, exploratory testing, compatibility & Multilanguage support testing and stress testing. For mobile applications, the main types of testing that should be done are UI testing, Rule-based testing, regression, functional and security testing. So AUT (application under test) is either a desktop software or a website or a mobile app. =F Application Testing Methodologies It is a well-known and well-discussed aspect that there are only 3 universally accepted testing methodologies: #1) Black Box : In black-box testing, the AUT is validated against its requirements considering the inputs and expected outputs, regardless of how the inputs are transformed into outputs, Testers are least concerned with the internal structure or code that implements the business logic of the application. 4 : Black box testing There are four primary techniques to design test cases for Black box Testing: © BVA (Boundary Value Analysis) © EP (Equivalence Partitioning) © Decision Tables © State Transition Tables (and diagrams) Black box testing is common] ly employed for functi -functi sion eas ional, non-functional and regres (New Syllabus Wlabus W.0f academic year 22.05) (7-67) Bhreen ‘Neo Publi cuan vent N20 Publicatinne A earn: Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem (Testing Methodolox ‘Application Code => 7-! WHITE BOX TESTING APPROACH Fig, 1.12.5 : White box Testing Approach The internal structure of the application is tested here and the techniques available to do so are: © Code Coverage © Path Coverage Both of the above-listed techniques contain several other strategies that may be discussed in some other article. Some techniques are discussed in the ‘Test Case Design Techniques’ topic. #3) Grey Box : Practically speaking, this is a mixture of the black box and white box. In this methodology, the tester mainly tests the application with the Black-box approach. However, for some business- critical or vulnerable modules of an application, testing is done through a white box. Fig. 1.12.6 : Gray Box Testing En ng 5 Application Testing Tools «There are a lot of Application testing tools available in the market today. This includes both paid and open-source tools. Moreover, some tools are purpose- specific. + For example, UI testing, Functional Testing, DB Testing, Load Testing, Performance, Security Testing, and Link validation testing. However, some tools are strong enough to provide the facility for testing several major aspects of an application. © The most important concept in ‘Application Testing’ is functional testing. Our focus will be on functional testing tools. + Here is the list of some of the most important and fundamental features that are provided by almost all of the Functional Testing’ tools. o Record and Play o Parametrize the Values (New Sylabus w.e.t academic year 22-23) (M7-67) [Ba recnieo Pubicatons.. SACHIN SHAH Ventura Scanned with CamScannerSoftware Testing & Quality Assurance (MU-Sem 7! esting Methodology) ..Page no (1-44) © Script Editor © Run (test or script with debug and update modes) © Report on Run session * Different vendors provide specific features that make their product unique when compared to the other competitor products. But the five features listed above are the ‘most common ones and can be found in almost all the functional testing tools. Given below is a list of few widely used Functional Testing tools 1) HP QTP (Quick Test Professional) 2) Selenium. 8) IBM Rational Robot 4) Test Complete 5) Push to Test 6) Telerik 'S Software Test Plan (STP) * Planning is always required for any activity and the same is applicable for software testing as well. * Without a proper plan, there is always a high risk of getting distracted during the testing. If this risk becomes a fact, Chapter Ends... Qoa Scanned with CamScannerTesting Techniques Testing Techniques Dynamic Testing : Black Box testing : Boundary value analysis, Equivalence class testing, State table based testing, Cause-effect graphing based testing, Error Guessing. White box Testing Techniques : Neod, Logic Coverage Criteria, Basis Path Testing, Graph Matrices, Loop Testing, Data Flow Testing, Mutation Testing, Static Testing. Validation Activities : Unit validation, Integration, Function, System, Acceptance Testing. Regression Testing ; Progressive vs. Regressive, Regression testing, Regression testability, Objectives of regression testing, Regression testing types, Define problem, Regression testing techniques. Self-learning Topics : Select the test cases (positive and negative scenarios) for the selected system and Design Test cases for the system using any two studied testing techniques. 24 seenes Bob Dynamic Testing ... 2.1.1 Types of Dynamic Testing . 2.1.2 Advantage and Disadvantago of Dynamic Testing .....0 2.1.3 Black Box Testing Vs. White Box Testing : Key Alterations... 2.1.4 _ Differentiate between White Box and Black Box Testing. ee UG. Differentiate between white box and black box testing 2.1.5 White Box Testing. | ee UQ. Is white box testing really necossary ? Give reasons. ((UEIENEE)) 2.1.6 White Box Testing Pros and Cond... 2.1.7 What Does White Box Testing Focus ON ? sn. 2.1.8 Black Box Testing : Borderline Value Analysis .... Scanned with CamScanner22 23 24 (New Syllabus w.c.t academic year 22-23) (M7-67) 2.1.10 Top down Integration Testing UQ. Differentiate between top down and bottom up testing. UEx. 2.1.1 (UEDERED) . UEx. 2.1.2 (EDEREE) . 2.1.11 What is Software Testing Technique ? oe UQ. Explain with example software testing. Equivalence Class Testing...... UQ. A program reads three numbers n1, n2, n3 in the range < 100 to 100 and prints the smallest number. Design test cases for this program using equivalence class testing technique. (UERIEN EDD. 2.2.1 State Table based Testing... 2.22 Cause Effect Graphing CFG based Testing wn UQ. Differentiate between Control Flow Graph [CFG] and Data Flow Graph [DFG] (MU = Dec. 18) UQ. Describe the change between failure, fault and error. ((UEDENEE) 2.2.3 Whatis Lifecycle’ UQ. Explain the software Testing Life Cycle. 2.2.4 Various Factors which Affect the Documentation of Test Con White Box Testing Techniques... 2.3.1 White Box Testing. UEx, 2.3.1 UEx. 2.3.2, 2.3.2 Loop Testing, Data Flow Testing Ua, Explain static Data Flow testing with example. {(MU = Mayi16)} 2.3.3. Mutation Testing Ua. Explain Mutation testing with the help of example. (CEE... 2.3.4 Static Testing... Ua. Whats static testing? Explain the types of static. testing. (UEUENERAUEVEED....... 2-42 2.3.5 V Model... ua. What are the features of V testing model? Explain in detai Validation Activities : Unit validation... 244 ua. ua. Integration Testing : What is, Types, Top down and Bottom up Example, Explain Unit testing and Integration testing (UEDESED). Explain various approaches in integration testing fl Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannersoftware Testing and Quality Assurance (MU-Sem 7-IT) (Testing Techniques)...Page no (2-3) ua. 242 243 244 24.5 ua. 24.6 247 248 ua. 24.9 ua. 2.4.10 ua. ua. 2.4.11 a ua. ua. 2.5.1 ua. 25.2 ua. 25.3 254 26 — Self Leaming Topics.. > Chapter Ends Perform top-down and bottom up integration procedure from the following system hierarchy. (TUEIIENEED..... Methods, Policies, Practices of Addition Testing . Bottom-up Integration Testing Top-down Integration Testing, Integration, Function, System. Explain different modules of incremental Integration Testing Methods. ? (MU - Dec. 19)} Incremental Integration Testing Approach Objective of Incremental Test sresnseies 2°55 2-56 2-56 2-58 Object Oriented Testing Issues .. What are Issues in Object Oriented Testing ? (MU - Dec. 16, Dec. 18, May 16, May 17, May 18)} Acceptance Testin: eeeesenen Acceptance testing. (UEDA CME)... Alpha and Beta Testing Explain entry and exit criteria for Alpha and Beta Testing. (USA... How Alpha testing differs from Beta testing? (UEIENSIRUENEED ... Alpha Vs Beta Testing... 2-58 2-59 2-59 2-60 2-60 2-61 2-61 2-63 2-63 Comment on regression testing process. (TUEIIENE) Regression testing produces quality software? Justify with reasons. (Mu May 19) 2-63 Progressive vs. Regressive, Regression Testing Produces Quality Software Compare progressive and regressive testing. (UEINENED) Regression Testing Tools... Explain the Regression testing types. (EPEC NCES PALLET). Difference between Re-Testing and Regression Testing... Progressive Testing (New Syllabus w.0.f academic yoar 22-23) (M7-67) el Tech-Neo Publications...A SACHIN SHAH Venture > ‘Scanned with CamScanner| Software Testing and Quality Assurance (MU-Sem 7:17) Testing Techniques)...Page no (2-4) Wi 2.1 DYNAMIC TESTING ae qi * The name itself suggests that it is “Dynamic” in nature, which means altering. Thig the kind of testing that we do with altering values or conditions by executing ¢ code, is the This includes testing the request in real time by giving inputs and groping the result, or the output value of performance, Dynamic Testing Example For instance, 8 typescripts long, distinct character, needs to must a capital letter and at least one Scanned with CamScannersoftware Testing and Quality Assurance (MU-Sem 1 Dynamic Testing is Approximately Confidential into Two Types > 1. White box testing White box testing looks at the internal mechanisms of the code. For this thoughtful of testing, the tester should know the code increasing, evaluation and be able to interpret the code. White box testing is a software evaluating method used to examine the internal structure, design, coding and inner-working of software. Developers use this testing method to verify the flow of inputs and outputs through the application, improving usability and design and strengthening security. > 2 Black box testing Black box testing features at only the functionality of the Application Under Test (AUT). This does not require the tester to recognize the application details or be able to interpret the inner devices of the code. This is the type of testing normally done by 1 QA subdivisi Black box testing is used to test the system against external factors responsible for software failures, This testing approach focuses on the input that goes into the software, and the output that is produced. The testing team does not cover the inside details such as code, server logic, and development method. Y 2.1.2 Advantage and Disadvantage of Dynamic Testing © Advantages 1, Dynamic testing is thorough, which aspects at in depth functionality of the submission so the quality is of uppermost standards. 2, Dynamic testing process is well established and hence the presentation is tested from users and business perspective thus increasing the quality standards. 3. Complex imperfections can be caught which may have runaway the review Processes. 4, Dynamic testing can be automatic using tools. "S Disadvantages 1. Since dynamic testing surveys a complex detailed procedure, it takes time. (New Syllabus w.e.t academic year 22-23) (M7-67) fl Tech-Neo Publications...A SACHIN SHAH Venture _E—— — Scanned with CamScanner— ting Techniques)...Page no Soltware Testing and Quality Assurance (MU-Sem = (2-6) . It is time consuming and it costs more money to the organizations because of the need for the resources and time. 8. Dynamic testing is usually performed after coding is completed and hence defects are discovered later in the lifecycle A 24.3 Black Box Testing Vs. White Box Testing : Key Alterations (3 mvt os In Black box testing, a sample doesn' employed of the software system. Black box difficult is a high level of testing those emphases on the performance of the Software. It includes testing from an external or end user viewpoint. Black box testing can be functional to almost every level of software testing: unit, integration, system, and takin, system. In this method, testing is based on attention of code statements, subdivisions, paths or conditions. White Box testing is measured as low level tosting. It is also called glass box, obvious box, clear box or code base testing. The white box Testing method shoulders that the path of the logic in a unit or database is known. Key Difference Scanned with CamScannerAssurance (MI * Black Box test delivers low granularity reports however the White Box test delivers high granularity reports. «Associating Black box testing vs White box testing, Black Box testing is a not time overriding process while White Box testing is a time consuming process. a 2.1.4 Differentiate between White Box and Black Box Testing Definition Tes a testing method which is used to test the software without the knowledge of the internal structure of program or application. It is a testing method in which internal structure is known to the tester. Alias It also known’s as data driven, box testing, data, and functional testing. It is also called structural testing, clear box testing, code based testing, or glass box testing. Base of Testing Testing is based on external expectations; internal performance of the application is unidentified. Internal working is known, and the tester can test consequently. Usage This type of testing is ideal for higher levels of testing like System Testing, Receipt testing. Testing is best suited for a lower level of testing like Unit Testing, Integration testing. Programming knowledge Programming knowledge is not needed to attain Black Box testing. Programming information is required to thorough White Box testing. Implementation knowledge Implementation knowledge is not necessitating doing Black Box testing. Complete understanding needs to implement White Box testing. Automation ‘Test and programmer are reliant on each other, so it is tough to automate. White Box testing is informal to automate. Objective The main objective of — this challenging is to check what functionality of the system under test. The main objective of White Box testing is done to check the excellence of the code, Basis for test cases ‘Testing can start after formulating obligation requirement document. Testing can start after formulating for Detail design document. (New Syllabus w.e.f academic year 22-23) (M7-67) [el ‘Tech-Neo Publications...A SACHIN SHAH Venture Scanned with CamScannerSoftware Testing and Quality Assurance (Mi Techniques) em 7. age no (2, Parameter Black Box testing White Box testing ; Tested by Performed by the end user, Usually done by tester and designer, and tester. developers. __ Granularity Granularity is low. Granlarity: is high, Testing method | It is based on experimental and | Data provinee and " intemal} error method. limitations can be tested, ‘Time It is less thorough and time | Comprehensive and laborious overriding. method. _ Algorithm test | Not the best method for procedure Best suited for algorithm testing, testing. Code Access | Code access is not essential for | White box tosting involves code Black Box Testing. access. Thus, the code could be stolen if testing is outsourced, Benefit Well suitable and efficient for large | Tt allows eliminating the extra code subdivisions. lines of code, which can bring in unseen imperfections, Skill level Low expert testers can test the | Need an expert tester with vast application with no knowledge of'| experience to achieve white box the operation of programming | testing. language or working system. Techniques * Correspondence separating is Black box testing procedure is used for Black box testing, + Equivalence separating divides input values into valid and invalid partitions and selecting conforming values from each divider of the test data. ° Boundary value analysis * checks limitations for input values. 7A 2.1.5 White Box Testing * Statement Coverage, Branch coverage, and Path reporting are White Box testing technique. * Statement Coverage authorizes whether every ine of the code is executed at least once. * Branch coverage legalizes whether each branch is executed at least once. * Path coverage method tests all the paths of the program, (Now Syllabus w.e.t academic year 22-23) (7-67) Tech-Neo Publications... SACHIN SHAH VentU® Scanned with CamScanner