MissionMca.com
MCA SEM5 Software Testing Viva Questions & Answer 1. Errors Errors are unexpected conditions that are not part of the normal operation of a program 2. Testing Testing is a process of executing a program with intent to find an error and fix it prior to the delivery of product. 3. Debugging Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program 4. Software Quality The quality of software is assessed by a number of variables. These variables can be divided into external and internal quality criteria. External quality is what a user experiences when running the software in its operational mode. Internal quality refers to aspects that are code-dependent, and that are not visible to the end-user. External quality is critical to the user, while internal quality is meaningful to the developer only. 5. General Principles of Testing Principle 1: Testing shows the presence of defects, not their absence Principle 2: Exhaustive testing is not possible Principle 3: Testing activities should start as early as possible Principle 4: Defects tend to cluster together Principle 5: The pesticide paradox Principle 6: Test is context dependent Principle 7: The fallacy of assuming that no failures means a useful system 6. Test Metrics Test Metrics can be used to measure test coverage prior to software delivery. It provides a measure of the percentage of the software tested at any point during testing. 7. Waterfall Models The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing,Production/Implementation, and Maintenance. 8. Spiral Model The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. 9. W Model
1
MissionMca.com In the W-model the importance of the tests and the ordering of the individual activities for testing are clear. Parallel to the development process, in a tighter sense, a further process - the test process - is carried out. This is not first started after the development is complete. 10. V Model The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. 11. Agile Methodology Agile methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development. 12. Test Levels Unit Testing, Component Testing, Integration Testing, System Testing, Acceptance Testing, Generic Testing 13. Unit Testing unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use 14. Component Testing the software components are tested individually and isolated from all other software components of the system. The isolation is necessary to prevent external influences on components. If testing detects a problem, it is definitely a problem originating from the component component under test itself. 15. Module Testing Module tests are typically dynamic white-box tests. This requires the execution of the software or parts of the software. The software can be executed in the target system, an emulator, simulator or any other suitable test environment 16. Integration Testing After assembling the components, it must be confirmed through testing that all components collaborate correctly. Therefore, the goal of this integration testing is to expose faults in the interfaces and in the interaction between integrated components.
2
MissionMca.com
17. System Testing After the integration test is completed, the next test level is the system test. System testing checks if the integrated product meets the specified requirements. 18. Acceptance Testing acceptance testing is a test conducted to determine if the requirements of aspecification or contract are met. 19. Generic Testing functional testing, nonfunctional testing, testing of software structure, testing related to changes 20. Functional Testing Functional testing includes all kind of tests which verify a system's input–output behavior. To design functional test cases the black box testing methods from are used, and the test bases are the functional requirements. Functional requirements specify the behavior of the system; they describe "what" the system must be able to do. Implementation of these requirements is a precondition for the system to be applicable. Characteristics of functionality, are suitability, accuracy, interoperability, and security. 21. Non Functional Testing Nonfunctional requirements do not describe the functions, but the attributes of the functional behavior, or the attributes of the system as a whole, i.e., "how well" or with what quality the (partial) system should carry out its function. Load test, Performance Test, Volume Test, Stress test, Security test etc are non functional testing 22. Static Testing Static testing is a form of software testing where the software isn't actually used. This is in contrast to dynamic testing. It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code and/or manually reviewing the code or document to find errors. This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used. 23. Tools for Static testing Review support tools, Static analysis, Model checking tools 24. Tools for Static testing Debuggers, Simulators, Test robots 25. Control flow If the program contains a multiway branch such as a computed GO TO, can the index variable ever exceed the number
3
MissionMca.com of branch possibilities? possibilities? 26. Dynamic Testing
Dynamic testing(or dynamic analysis) is a term used in software engineering to describe the testing of the dynamic behavior of code. That is, dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time. In dynamic testing the software must actually be compiled and run; Actually Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies. Dynamic testing means testing based on specific test cases by execution of the test object or running programs. Dynamic testing is used to test software through executing it, which can be done manually by a tester or automatic by the help of tools. This is in contrast to Static testing.
27. Black Box Testing Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings This method of test can be applied to all levels of software testing: unit, integration, system andacceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well. 28. Equivalence Class Partitioning Equivalence partitioning is a software testing technique that divides the input data of a software unit into partitions of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test cases that uncover classes of errors, thereby reducing the total number of test cases that must be developed.An advantage of this approach is reduction in the time required for testing a software due to lesser number of test cases. 29. Boundary Value Analysis Boundary value analysis is a software testing(Black Box) technique in which tests are designed to include representatives of boundary values 30. State Transition Test State transition testing is used where some aspect of the system can be described in what is called a “finite state machine”. This simply means that the system can be in a (finite) number of different states, and the transitions from one state to another are determined by the rules of the “machine”. This is the model on which the system and the tests are based. Any system where you get a different output for the same input, depending on what has happened before, is a finite state system. 31. Cause Effect Graphing and Decision Table Technique
4
MissionMca.com This is basically a hardware testing technique adapted to software testing. It considers only the desired external behaviour of a system. This is a testing technique that aids in selecting test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases. 32. Used Case Testing UCBT addresses phases where the tester is interested in exploring behavior that flows through multiple use cases, which are typically the late function, system, and solution phases of the test life cycle. In late function level test, the tester has tested the use cases individually, and is now interested in looking at combinations of the use cases. 33. White Box Testing White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality . In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. 34. Statement Coverage In this the test case is executed in such a way that every statement of the code is executed at least once. 35. Branch Coverage Test coverage criteria requires enough test cases such that each condition in a decision takes on all possible outcomes at least once, and each point of entry to a program or subroutine is invoked at least once. That is, every branch (decision) taken each way, true and false. It helps in validating all the branches in the code making sure that no branch leads to abnormal behavior of the application. 36. Path Coverage In this the test case is executed in such a way that every path is executed at least once. All possible control paths taken, including all loop paths taken zero, once, and multiple (ideally, maximum) items in path coverage technique, the test cases are prepared based on the logical complexity measure of a procedural design. In this type of testing every statement in the program is guaranteed to be executed at least one time. Flow Graph, Cyclomatic Complexity and Graph Metrics are used to arrive at basis path 37. Gray Box Testing Gray-box testing is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects if any due to improper structure or improper usage of applications. Gray-box testing is also known as translucent testing.
38. Intuitive and Experience Based Testing Experience-based techniques are those that you fall back on when there is no adequate specification from which to derive specification-based test cases or no time to run the full
5
MissionMca.com structured set of tests. They use the users' and the testers' experience to determine the most important areas of a system and to exercise these areas in ways that are both consistent with expected use (and abuse) and likely to be the sites of errors—this is where the experience comes in. n the Heuristic testing (also known as Intuitive Testing) approach, the tester separately reviews a program, categorizing and justifying problems based on a short set of heuristics. 39. Test Plan A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be. 40. Test Exit Criteria Criteria comes in every phase of testing( Static & Dynamic testing) They are 4 types of criteria. 1. Enter Criteria 2. Suspension Criteria 3. Resuspension Criteria & 4. Exit Criteria 1. Enter criteria: This is the first stage and starting of the Phases2. Suspension Criteria: when your sending the document to verify by developer& Test lead.at that time Suspension Criteria comes screen3. Resuspension Criteria: there is any changes want to done in your document . at that time Resuspension Criteria comes on Screen.4. Exit Criteria: You completed your testing .at that time Exit Criteria comes on Screen 41. Preventive versus Reactive Approach a. Preventative testing is always analytical; reactive testing is always heuristic. b. Preventative tests are designed after the software production; reactive tests are designed early in response to review comments. c. Preventative tests and reactive tests are designed as early as possible. d. Preventative tests are designed early; reactive tests are designed after the software has been produced.
42. Analytical versus heuristic Approach Test planning is founded on data and analysis of these data. Amount and intensity of testing are then chosen such that individual or multiple parameters are optimized. Heuristic Approach:- Test planning is founded on experience of experts and/or on rules of thumb. Reasons might be that no data are available, mathematical modeling is too complicated, or because know-how is missing. The approaches used in practice are often between these extremes and use both analytical and heuristic elements:43. Test Activity Management Every cycle through the test process commonly generates change requests or fault correction requests to the developers. If faults are corrected or changes are implemented, a new version of the software emerges, and it must be tested again. Thus, in every test level the test process is executed repeatedly or cyclically. The test manager is responsible
6
MissionMca.com for initiating, supervising, and controlling these test cycles. Depending on the project size, a separate test manager might be responsible for each test level. 44. Incident Management An incident is any essential, unplanned event that happens at the time of software testing that requires posterior investigation and amendment.
Incidents are increased in the case when expected and actual test results are differ from each other. Incidents may be raised against documentation as well as code or a system under test. 45. Configuration Management Configuration management (CM) is the detailed recording and updating of information that describes an enterprise's computer systems and networks, including all hardware and software components. 46. Performance Testing Measuring of the processing speed and response time for particular use cases, usually dependent on increasing load 47. Load Testing Measuring of the system behavior for increasing system loads (e.g., the number of users that work simultaneously, number of transactions) 48. Stress Testing Observation of the system behavior when it is overloaded 49. Security Testing Testing of security against unauthorized access, denial of service attacks etc. 50. Automation of Test Execution In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.Commonly, test automation involves automating a manual process already in place that uses a formalized testing process. 51. Types of test Tools Test management tool, Test specification tool, tools for static testing, tools for dynamic testing, tools for non functional test 52. OO testing concepts
Unit testing in OO context:- When object oriented software is considered, concept of the unit testing changes. Encapsulation drives the definition of classes and objects. This means that each class and each instance of a class packages attributes (data) & the 7
MissionMca.com
operations that manipulate these data. Rather than testing on individual module, the smallest testable unit is the encapsulated class or object. Integration Testing in OO Context:- There are two strategies for integration testing. a. Thread based testing, integrates the set of class required to respond to one input or event for the system. b. Use –based testing: - Begins the construction of the system by testing the classes (called independent class) that use very few of server class. c. Validation testing in an OO context:- At the validation or system level, the details of class connections disappear. The validation of OO s/w focuses on user –visible actions and inner –reorganization output from the system. To assist in the derivation of validation test, the tester should draw Upon the use-cases that are part of analysis model.
55. What is the difference between white box, black box, and gray box testing? Black box testing is a testing strategy based solely on requirements and specifications. Black box testing requires no knowledge of internal paths, structures, or implementation of the software being tested. White box testing is a testing strategy based on internal paths, code structures, and implementation of the software being tested. White box testing generally requires detailed programming skills. There is one more type of testing called gray box testing. In this we look into the "box" being tested just long enough to understand how it has been implemented. Then we close up the box and use our knowledge to choose more effective black box tests.
8
MissionMca.com The above figure shows how both types of testers view an accounting application during testing. Black box testers view the basic accounting application. While during white box testing the tester knows the internal structure of the application. In most scenarios white box testing is done by developers as they know the internals of the application. In black box testing we check the overall functionality of the application while in white box testing we do code reviews, view the architecture, remove bad code practices, and do component level testing. 56. What is the purpose of exit criteria? To define when a test level is complete. 57. What is beta testing? Testing performed by potential customers at their own locations.
58. Rapid Application Development ? Rapid Application Development (RAD) is formally a parallel development of functions and subsequent integration. Components/functions are developed in parallel as if they were mini projects, the developments are time-boxed, delivered, and then assembled into a working prototype. This can very quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements. Rapid change and development of the product is possible using this methodology. However the product specification will need to be developed for the product at some point, and the project will need to be placed under more formal controls prior to going into production. 59. What is the difference between Testing Techniques and Testing Tools? Testing technique: – Is a process for ensuring that some aspects of the application system or unit functions properly there may be few techniques but many tools. Testing Tools: – Is a vehicle for performing a test process. The tool is a resource to the tester, but itself is insufficient to conduct testing
1. 2. 3. 4. 5. 6. 7.
1. 2. 3. 4.
60. What are the different Methodologies in Agile Development Model? There are currently seven different Agile methodologies that I am aware of: Extreme Programming (XP) Scrum Lean Software Development Feature-Driven Development Agile Unified Process Crystal Dynamic Systems Development Model (DSDM) 61. What are the phases of a formal review ? In contrast to informal reviews, formal reviews follow a formal process. A typical formal review process consists of six main steps: Planning Kick-off Preparation Review meeting
9
MissionMca.com 5. 6.
Rework Follow-up. 62. What is the role of moderator in review process? The moderator (or review leader) leads the review process. He or she deter-mines, in cooperation with the author, the type of review, approach and the composition of the review team. The moderator performs the entry check and the follow-up on the rework, in order to control the quality of the input and output of the review process. The moderator also schedules the meeting, disseminates documents before the meeting, coaches other team members, paces the meeting, leads possible discussions and stores the data that is collected. 63. What is an equivalence partition (also known as an equivalence class)? An input or output range of values such that only one value in the range becomes a test case. 64. What are the Structure-based (white-box) testing techniques ? Structure-based testing techniques (which are also dynamic rather than static) use the internal structure of the software to derive test cases. They are com-monly called 'whitebox' or 'glass-box' techniques (implying you can see into the system) since they require knowledge of how the software is implemented, that is, how it works. For example, a structural technique may be concerned with exercising loops in the software. Different test cases may be derived to exercise the loop once, twice, and many times. This may be done regardless of the functionality of the software. 65. What are the Experience-based testing techniques ? In experience-based techniques, people's knowledge, skills and background are a prime contributor to the test conditions and test cases. The experience of both technical and business people is important, as they bring different perspectives to the test analysis and design process. Due to previous experience with similar systems, they may have insights into what could go wrong, which is very useful for testing. 66. Given the following code, which statement is true about the minimum number of test cases required for full statement and branch coverage? Read p Read q IF p+q> 100 THEN Print "Large" ENDIF IF p > 50 THEN Print "p Large" ENDIF 1 test for statement coverage, 2 for branch coverage 67. What is the difference between re-testing and regression testing?
10
MissionMca.com Re-testing ensures the original fault has been removed; regression testing looks for unexpected side-effects. 68. What is test coverage? Test coverage measures in some specific way the amount of testing performed by a set of tests (derived in some other way, e.g. using specification-based techniques). Wherever we can count things and can tell whether or not each of those things has been tested by some test, then we can measure coverage. 69. Why is incremental integration preferred over “big bang” integration? Because incremental integration has better early defects screening and isolation ability 70. What are Test comparators ? Is it really a test if you put some inputs into some software, but never look to see whether the software produces the correct result? The essence of testing is to check whether the software produces the correct result, and to do that, we must compare what the software produces to what it should produce. A test comparator helps to automate aspects of that comparison.
**And all other topics from syllabus** All the Best
11
