sien RVS TECHNICAL CAMPUS - COIMBATORE &Z AY COIMBATORE - 641 402. os INTERNAL TEST - 1, MARCH 2023 1T8076 - SOFTWARE TESTING ANSWER KEY PART-A L.List the level of Testing Maturity models. [AN] © Level 1 ~Initial-The software product must run successfully © Level 2 - Managed-Testing is integrated with sohware lifecycle. © Level 3 - Defined-Set up testing and debugging goals and policies. * Level 4~ Management & Measurement-Set up a test measurement program, © Level 5 - Optimized. 2.Compare Black Box and White Box Testing. [AP] Black Box Testing White Box Testing T Tt is mostly done by|It is mostly done by software testers software developers 2 No knowledge _of | Knowledge of implementation is needed._| implementation is required 3. Itis a functional test of the | It is a structural test of the software software 3 What is Boundary Valve Analysis. [UN] Boundary Valve Analysis is based on testing the boundary values of valid and invalid partitions. It checks for the input values near the boundary that have a higher chance of error. Every partition has its maximum and minimum values and these maximum and minimum values are the boundary values of a partition. 4, Define Code Complexity Testing. How it is related to testing? [RE] ‘A quantitative measure of the number of linearly independent paths through a program's source code... computed using the control flow graph of the program. Code complexity is a measure of how complex a piece of code is. The factors that influence the nature of code and its complexity are plenty. 5. List the Advantages of Equivalence class partitioning? [AN] Equivalence class partitioning it allows the testers to reduce the number of test cases, also it reduces the testing time of a software because of lesser number of test cases It is a software testing technique that divides the input test data of the application under test into each partition at least once of equivalent data from which test cases can be derived. Part-B 6, a.) Explain Defect Classification in detail, Defects are classified from the QA team perspective as Priority and from the development perspective as Severity (complexity of code to fix it). These are two major classifications that play an important role in the timeframe and the amount of work that goes in to fix defect Priority:ich the defects should be resolved. The priority status a ct against the dev team mentioning the based on the requirements of the end Priority is defined as the order in whi , usually set by the QA team while raising the defe timeframe to fix the defect. The Priority status is set users. Priority Listing A Priority can be categorized in the following ways Low ~ This defect can be fixed after the critical ones are fixed. Medium — The defect should be resolved in the subsequent builds. High — The defect must be resolved immediately because the defect affects the application to a considerable extent and the relevant modules cannot be used until it is fixed. Urgent — The defect must be resolved immediately because the defect affects the application or the product severely and the product cannot be used until it has been fixed. Severity: Severity is defined as the impishness of defect on the application and complexity of code to fix it from development perspective. It is related to the development aspect of the product. Severity can be decided based on how bad/crucial is the defect for the system. Severity status can give an idea about the deviation in the functionality due to the defect. Severity Listing Severity can be categorized in the following ways — Critical /Severity 1 — Defect impacts most crucial functionality of Application and the QA team cannot continue with the validation of application under test without fixing it. For example, App/Product crash frequently. Major / Severity 2 — Defect impacts a functional module; the QA team cannot test that particular module but continue with the validation of other modules, For example, flight reservation is not working. Medium / Severity 3 - Defect has issue with single screen or related to a single function, but the system is still functioning. The defect here does not block any functionality. For example, Ticket# is a representation which does not follow proper alpha numeric characters like the first five characters and the last five as numeric. Low / Severity 4 — It does not impact the functionality. It may be a cosmetic defect, UI inconsistency for a field or a suggestion to improve the end user experience from the UI side, 6(a)(ii) b) Write a note on following i)Positive and Negative Testing ii)Decision Tables + software testing is the process of verifying and validating a software application to check Whether it is working as‘expected. The intent is to find defects and improve product quality. ‘There are two ways to test software, namely Positive Testing, and Negative Testing. Positive Testing: It is a type of testing which is performed on a software application by providing the valid data sets as an input. It checks whether the software application behaves as expected with Positive inputs or not. Positive testing is performed in order to check whether the software application does exactly what it is expected to do. Example -Enter Only Numbers 99999 Positive Testing There is a text box in an application which can accept only numbers. Entering values up to 99999 will be acceptable by the system and any other values apart from this should not e acceptable. To do positive testing, set the valid input values from 0 to 99999 and checl whether the system is accepting the values. Negative Testing — i Fon ec method performed on the software application by providing invalid or improper data sets as input. It checks whether the software application behaves as expected wit : negative or unwanted user inputs. The purpose of negative testing is to ensure that the software application does not crash and remains stable with invalid data inputs. Example Enter Only Numbers Negative Testing Negative testing can be performed by entering characters A to Z or from a to z. Either software system should not accept the values or else it should throw an error message for these invalid data inputs. In both the testing, the following needs to be considered: © Input data + An action which needs to be performed © output Result Testing Technique used for Positive and Negative Testing: Following techniques are used for Positive and negative validation of testing is: + Boundary Value Analysis + Equivalence Partitioning Decision Table Testing: Decision table testing is a software testing technique used to test system behavior for different input combinations. This is a systematic appronch where the different input Combinations and their corresponding system behavior (Output) are captured in a etal form. That is why it is also called as a Cause-Effect table where Cause and effect vate captured for better test coverage eeeieeme onA Decision Table isa tabular representation of inputs versus rules/eases/test conditions. tt is avery effective tool used for both complex software testing and requirements management. A decision table helps to check all possible combinations of conditions for testing and testers can also identify missed conditions easily. The conditions are indicated as True(T) and False(F) values. 7 (a) (i) Explain Various White Box techniques with suitable test cases. White box testing techniques analyze the internal structures the uscd data structures, internal design, code structure, and the working of the software rather than just the functionality as in black box testing. It is also called glass box testing or clear box testing or structural testing. White Box Testing is also known as transparent testing, open box testing. White box testing is a software testing technique that involves testing the internal structure and workings of a software application. The tester has access to the source code and uses this knowledge to design test cases that can verify the correctness of the software at the code level. White box testing is also known as structural testing or code-based testing, and it is used to test the software’s internal logic, flow, and structure. The tester creates test cases to examine the code paths and logic flows to ensure that they meet the specified requirements. Working process of white box testing: + Input: Requirements, Functional specifications. design documents, source code, + Processing: Performing risk analysis for guiding through the entire process. + Proper test planning: Designing test cases so as to cover the entire code. Execute rinse~ repeat until error-free software is reached. Also, the results are communicated. + Output: Preparing final report of the entire testing process. Testing technique: Statement coverage: In this technique, the aim is to traverse all statement at least once. Hence, each line of code is tested. In case of a flowchart, every node must be traversed at least once. Since all lines of code are covered, helps in pointing out faulty code.+ Branch Coverage: In this technique, test cases are designed so that each branch from all decision points are traversed at least once. In a flowchart, all edges must be traversed at least once.In this technique, all individual conditions must be covered as + Condition Coverage: shown in the following example: . READX,Y Ol Y ==0) IF(X PRINT * weeny Multiple Condition Coverage: In this technique, all the possible combinations of the possible outcomes of conditions are tested at least once. Let’s consider the following example: . READ X,Y OLY ==0) aepe nay Basis Path Testing: In this technique, control flow graphs are made from code or flowchart and then Cyclomatic complexity is calculated which defines the number of independent paths so that the minimal number of test cases can be designed for each independent path. Steps: 1. Make the corresponding control flow graph 2. Calculate the cyclomatic complexity 3. Find the independent paths 4. Design test cases corresponding to each independent path 5. V(G)=P + 1, where P is the number of predicate nodes in the flow graph 6. V(G)=E—N +2, where E is the number of edges and N is the total number of nodes 7. V(G) = Number of non-overlapping regions in the graph 8. -2-4-7-8 -2-3-5-7-8 -2-3-6-7-8 -2-4-7-1-...-7-8 + Loop Testing: Loops are widely used and these are fundamental to many algorithms hence, their testing is very important, Errors often occur at the beginnings and ends of loops. 1. Simple loops: For simple loops of size n, test cases are designed that: + Skip the loop entirely * Only one pass through the loop «2 passes +m passes, where m You test software to identify problems so you can fix them before you deploy the software to production environments. However, this process doesn't mean that there aren't any bugs in the product. It just means that there may be bugs, but you didn't find them.v v v > There could be any number of reasons that you didn't uncover every bug including the fact that the test cases didn't cover every scenario. > This principle, which helps to set stakeholder expectations, means that you shouldn't guarantee that the software is error-free. Exhaustive testing is impossible . © The truth is that you can't test everything, i.c., every combination of preconditions and inputs. And if you try to do so you'll waste time and money, but it won't affect the overall quality of the software, What you need to do is assess risk and plan your tests around these risks so you can be sure you're testing the key functions. Careful planning and assessment ensures your test coverage is good so you can have confidence in your final Product — and you don't even have to test every individual line of code. Early testing When it comes to the software development lifecycle, testing early identifying any defects in the requirements or design phase as soon It’s much easier and less expensive to fix bugs in the ear ly stages of te: the end of the software lifecycle as then you functionality. And that likely means missed dea * Defect clustering Defect clustering is the idea that a small number of software modules or components contain the most defects — sort of applying the Pareto Principle to software testing, i.e., approximately 80% of the issues are found in 20% of the components. Understanding this can help in your testing because if you find one defect in a Particular area, you'll likely find more in that same module. If you identify the complex areas that are changing the most or the ones that have more dependencies, you can focus your testing on these key areas of risk. * Pesticide paradox This principle centers around the theory that if you repeatedly use a particular Pesticide on your crops, the insects you're trying to kill or repel will eventually become immune to the pesticide and it will no longer be effective. Likewise, if you continuously run the same tests, eventually they'll fail to find new defects, even though they'll probably confirm the software is working, Consequently, is the key to as possible. ‘sting than at ight have to rewrite entire areas of idlines and cost overruns. you must continue to review your tests as well as add to your scenarios or modify them to help prevent this pesticide paradox. For example, you could use a variety of testing techniques, methods, simultaneously. Testing is context dependent Software testing is all about the context, which means that no one strategy will fit every scenario. The types of testing and the methods you use totally depend on the Context of the systems or the software, e.g., the testing of an iOS application is different from the testing of an e-commerce website. Put simply, will always affect the approach you use. * Absence-of-errors fallacy maybe and. approaches what you're testing> If your software is 99% 7 it 7 y 99% error-free but it doesn't follow your user's requirements, it's ae Laan That's why it’s critical to run tests that pertain to the requirements of a ystem. Software testing isn't just about finding bugs, it’s about ensuring that the software meets the user's needs and requirements, As such, you should also test your software with the users. You can test against early prototypes at the usability testing phase so you can get feedback from the users that you can use to ensure the software is usable, Even though your software might have relatively few issues, doesn't mean it is ready to ship; it also has to meet your customer's requirements and expectations. 8. (a)Explain about the following i) Compatibility testing ii) Document testing i) Compat Compatibility is nothing but the capability of existing or living together. In normal life, Oil is not compatible with water, but milk can be easily combined with water. Compatibility Testing: Compatibility Testing is a type of Software testing to check whether your software is capable of running on different hardware, operating systems, applications, network environments or Mobile devices. > Compatibility Testing is a type of Non-funetional testing ility testing types Compati > Hardware: It checks software to be compatible with different hardware configurations. > Operating Systems: It checks your software to be compatible with different Operating Systems like Windows, Unix, Mac OS ete. > Software: It checks your developed software to be compatible with other software. For example, MS Word application should be compatible with other software like MS Outlook, MS Excel, VBA etc. > Network: Evaluation of performance of a system in a network with varying parameters such as Bandwidth, Operating speed, Capacity. It also checks application in different networks with all parameters mentioned earlier. > Browser: It checks the compatibility of your website with different browsers like Firefox, Google Chrome, Internet Explorer etc. > Devices: It checks compatibility of your software with different devices like USB port Devices, Printers and Scanners, Other media devices and Blue tooth. > Mobile: Checking your software is compatible with mobile platforms like Android, iOS ete. > Versions ‘of the software: It is verifying your software application to be compatible with different versions of the software. For instance checking your Microsoft Word to be compatible with Windows 7, Windows 7 SP1, Windows 7 SP2, Windows 7 SP3. ‘There are two types of Compatibility Testing :- Backward Compatibility || ——— | Testing — {|y Forward Backward Compatibility Testing is a technique to verify the behavior and compatibility of the developed hardware or software with their older versions of the hardware or software. Backward compatibility testing is much predictable as all the changes from the previous versions are known. Forward Compatibility Testing: Forward Compatibility Testing is a process to verify the behavior and compatibility of the developed hardware or software with the newer versions of the hardware or software. Forward compatibility testing is a bit hard to predict as the changes that will be made in the newer versions are not known. Tools for Compatibility Testing BrowserStack — Browser Compatibility Testing: This tool helps a Software engineer to check application in different browsers. Virtual Desktops — Operating System Compatibility: This is used to run the applications in multiple operating systems as virtual machines. n Number of systems can be connected and compare the results. Document Testing: Test documentation is documentation of artifacts created before or during the testing of software. It helps the testing team to estimate testing effort needed, test coverage, resource tracking, execution progress, etc. It is a complete suite of documents that allows you to describe and document test planning, test design, test execution, test results that are drawn from the testing activity. Achieve for Test Documentation > QA team needs to be involved in the initial phase of the project so that Test Documentation is created in parallel. > Don’t just create and leave the document, but update whenever required. > Use version control to manage and track your documents. > Try to document what is needed for you to understand your work and what you will need to produce to your stakeholders, > You should use a standard template for documentation like excel sheet or doc file. Store all your project related documents at a single location. It should be accessible to every team member for reference as well as to update when needed. > Not providing enough detail is also a common mistake while creating a test document,ges of Test Documentation The main reason behind creating test documentat uncertainties about the testing activities, Hel ion is to either reduce or remove any arises when it comes to the allocation of task: PS you to remove ambiguity which often S, 2. Documentation not only offers a systematic approach to software testing, but it also acts as training material to freshers in the software testing process, 3. It is also a good marketing & sales strategy to showcase Test Documentation to exhibit a mature testing process, 4. Test documentation helps you to offer a quality product to the client within specific time limits. 5. In Software Engineering, Test Documentation also helps to configure or set-up the program through the configuration document and operator manuals. 6. Test documentation helps you to improve transparency with the client. Disadvantages of Test Documentation 1. The cost of the documentation may surpass its value as it is very time- consuming. 2. Many times, it is written by people who can’t write well or who don’t know the material. Keeping track of changes requested by the client and updating corresponding documents is tiring. Poor documentation directly reflects the quality of the product as a misunderstanding between the client and the organization can occur.