Software Testing Gujarat University Important Questions For Exam

:Unit-1 Introduction

1. What is software testing? List and explain goals of software testing.

ANS:

Testing is the process of executing a program with the intent of finding errors.

The main goal of software testing is to find bugs as early as possible and fix bugs and make sure that the software is bug-free. The goals of software testing may be classified into three major categories, as follows:

1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals

1. Immediate Goals : 

    These objectives are the direct outcomes of testing.

    Some of these are covered in detail below:

• Bug Discovery : 
  This is the immediate goal of testing to find error at any stage of software development.
  The more bugs discovered at early stage, The batter will be the success ratio of Software Testing.
• Bug Prevention : 
  This is immediate action of bug discovery, that occurs as a result of bug discovery.
  Everyone in the software development team learns how to code safely such that the same bug not repeated in the other stage or future projects.
  Though error can not be eliminated totally but they can be minimized.

2. Long Term Goals : 
These goals affect the product quality in long run
Some of them are described below :

• Reliability: 
  It is a matter of confidence that the software will not fail, and this level of confidence is increase with effective testing.
• Quality : 
  The first step of testing is to improve the quality of software products
  Though, quality depends on many factors like correctness, integrity, efficiency etc. Reliability is the major factor to achieve quality.
• Customer Satisfaction :
  Testing must be satisfied the user or all the specified requirement in user manual, as well as the unspecified requirements.
  A complete testing process to achieve reliability enhances the quality and quality increase customer satisfaction.
• Risk management :
  Risk is the probability that undesirable events will occur in a system.
  These undesirable events will prevent the organization from successfully implementing its business initiatives.
  Risk must be in control to manage them with ease. 

3. Post-Implementation Goal :

    These goals are implemented after the product released, Some of them are discussed below:

• Reduce Maintenance Cost
  The only maintenance cost in a software product is its failure due to an error.
  Post release error are costlier to fix as they are difficult to detect.
  Thus, if testing is done strictly then chances of failure is minimized which can be reduced the maintenance cost.
• Improved Software Testing Process :
  These goals improve the software testing process for future use or software project.
  These goals are known as post implementation goals.
  A project's testing procedure may not be completely successful, and there may be scope for improvement. As a result, the bug history and post implemented result can be used to improve the present testing and improve future projects.

2. What are the principles of software testing? Explain them.

ANS:
Principles of Testing are discussed further:

1. Effective Testing, not Exhaustive Testing:
   All possible combination of test became so large that it is impractical  to test them all, So considering the domain for testing as infinite, exhaustive testing is not possible.
   Therefor, the tester approach should be based on effective testing to properly cover program logic.
   
2. Testing is not a single phase performed in SDLC:
   The testing is no just activity perform after the coding in SDLC. It is a part of the whole process.
   Testing process start as soon as specification for software product is defined, and it continues till the release of product.
3. Destructive approach for constructive Testing:
   The criteria for success is to find maximum bugs and not to show that the system does not contain bugs.
   
4. Early testing is best policy :
   Testing start as soon as specification and requirements of software product is prepared.
   The cost of bugs can be reduced ten times in early stage, as bugs are harder to find in later stages.
   This policy of testing is to start as early as possible.
5. Probability of an error in a section of a program is proportional to the number of errors find already in that section.
   If some section found error-prone in testing, then the next testing effort should give priority to that error-prone section.
6. Testing strategy should start at the smallest module level and expand towards the whole program
   This principal support the idea of incremental testing.
   Testing can not be performed directly to the whole system.
   It must be started with individuals modules and slowly integrate the modules and test them, After this, the whole system should be tested.
7. Testing should also be performed by an independent team.
   Programmers are biased towards... the correct functioning of the specified requirements. And not towards detecting bugs.
   Therefore, it is always recommended that the Software tested by an independent testing them.
8. Everything must be recorded in Software Testing : 
   Testing is a planned process.
   It demands that every detail should be recorded and documented.
   It must have the record of  every test case run and the bugs reported.
   Executing the test cases in a recorded and documented way can greatly help while observing the bugs. Moreover, observation can be a lesson for other projects.
9. 
   

3. Explain Software Testing Life Cycle (STLC).

ANS:

 The testing process divided into a well-defined sequence of steps is termed as software testing life cycle (STLC).

The major contribution of STLC is to involve the testers at early stages of development. This has a significant benefit in the project schedule and cost. 

The STLC also helps the management in measuring specific milestones. 

STLC consists of the following phases : 

Test Planning : 

The goal of test planning is to take into account the important issues of testing strategy, viz. resources, schedules, responsibilities, risks, and priorities, as a roadmap.

Broadly, the following are the activities during test planning: 

„ Defining the test strategy. 

„ Estimate the number of test cases, their duration, and cost. 

„ Plan the resources like the manpower to test, tools required, documents required.

„ Identifying areas of risks. 

„ Defining the test completion criteria. 

„ Identification of methodologies, techniques, and tools for various test cases. 

„ Identifying reporting procedures, bug classification, databases for testing, bug severity levels, and project metrics.

The major output of test planning is the test plan document. Test plans are developed for each level of testing.

Test Design : 
One of the major activities in testing is the design of test cases. However, this activity is not an institutional process rather, it is a well-planned process. 

The test design is an important phase after test planning. 

It includes the following critical activities. 

• Determining the test objectives and their prioritization.
• Preparing a list of items to be tested.
• Mapping items to test cases.
• Selection of test case design techniques.
• Creating test cases and test data.
• Setting up the test environment and supporting tools.
• Creating test procedure specification

test case design steps

4. What is V-testing life cycle model ? How is it used? Explain in detail.

ANS:

The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It is also known as Verification and Validation model. It is based on the association of a testing phase for each corresponding development stage. Development of each step directly associated with the testing phase. The next phase starts only after completion of the previous phase i.e. for each development activity, there is a testing activity corresponding to it.

Verification: It involves static analysis technique (review) done without executing code. It is the process of evaluation of the product development phase to find whether specified requirements meet.

Validation: It involves dynamic analysis technique, testing done by executing code. Validation is the process to evaluate the software after the completion of the development phase to determine whether software meets the customer expectations and requirements.

So V-Model contains Verification phases on one side and Validation phases on the other side. Verification and Validation phases are joined by coding phase in V-shape. Thus it is called V-Model.

Design Phase:

Requirement Analysis: This phase contains detailed communication with the customer to understand their requirements and expectations. This stage is known as Requirement Gathering.
System Design: This phase contains the system design and the complete hardware and communication setup for developing product.
Architectural Design: System design is broken down further into modules taking up different functionalities. The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood.
Module Design: In this phase the system breaks down into small modules. The detailed design of modules is specified, also known as Low-Level Design (LLD).

Testing Phases:

Unit Testing: Unit Test Plans are developed during module design phase. These Unit Test Plans are executed to eliminate bugs at code or unit level.
Integration testing: After completion of unit testing Integration testing is performed. In integration testing, the modules are integrated and the system is tested. Integration testing is performed on the Architecture design phase. This test verifies the communication of modules among themselves.
System Testing: System testing test the complete application with its functionality, inter dependency, and communication.It tests the functional and non-functional requirements of the developed application.
User Acceptance Testing (UAT): UAT is performed in a user environment that resembles the production environment. UAT verifies that the delivered system meets user’s requirement and system is ready for use in real world.

Advantages:

• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle thereby enhancing the probability of building an error-free and good quality product.
• It enables project management to track progress accurately.

Disadvantages:

• High risk and uncertainty.
• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and contains high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events

5. State the difference between static and dynamic testing?

ANS:

Static Testing:

Undes static testing, code is not executed, rather it mamurally checks the code, requrement document,  and design documents to find errors, Hence the name "Static".

The main objective of this testing in to improve the quality of software products by finding essors in the early stages of the development cycle.

This testing is also called a non executions technique or varification Testing.

Dynamic Testing : 

Under dynamic testing, a code is executed.

It checks for functional behavior of software system, memory/CPU used and Overall Performance  of the system.

The main objective of these testing is to confirm that the software product works as per the business requirements.

These testing is also called an execution technique or validation testing.

Dynamic testing executes the software and validates the output with the expected result

Dynamic testing is performed at all levels of testing, and it can be either black and white box testing.

 

Static Testing	Dynamic Testing
Testing is done without executing the code	Testing is done by executing the program
Does Verification process	Does Validation process
It is about prevention of defect.	It is about finding and fixing the defects.
It gives an assessment of code and documentation	It gives bugs in the software system
Involves checklist and process to follow.	It involves test cases for execution
Can be performed before compilation	It will perform after compilation.
Static Testing covers structural statement coverage testing.	Dynamic Testing covers the executable file of code
Cost of finding and fixing the defect is less	Cost of finding and fixing the defect it comparatively high
ROI is high as these process takes place at early stage	ROI will be low as these process takes place after the SDLC.
More reviews are highly recommended for good quality	more defects, highly recommend for good quality.
Require loads of meetings	Comparatively, requires lesser meetings.

Conclusion:

Verification & validation are to measures used to check that the software Product  meets the requirements specifications.

Static testing involves varification whereas dynamic testing involves Validation.

Together they help in improvingsoftware quality.

Unit-2 Types of Testing

1. What is black box testing? List its different techniques. Explain anyone in detail.

ANS)

Black-box technique is one of the major techniques in dynamic testing for designing effective test cases. This technique considers only the functional requirements of the software or module. 

In other words, the structure or logic of the software is not considered. 

Therefore, this is also known as functional testing. The software system is considered as a black box, taking no notice of its internal structure, so it is also called as black-box testing technique.

Techniques used in black box testing : 

• Boundry Value Analysis (BVA)
• Boundry Value Checking  (BVC)
• Robustness Testing Method 
• Worst Testing Method 
• Equivalence Class Testing 
• Dicison Table based Testing 

2. List methods of BVA and explain any two in detail.

ANS)

3. How equivalence class testing is used in black box testing? Explain it in detail.

ANS)

Equivalence partitioning is a method for deriving test cases wherein classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur. 

Thus, instead of testing every input, only one test case from each partitioned class can be executed. 

It means only one test case in the equivalence class will be sufficient to find errors. 

This test case will have a representative value of a class which is equivalent to a test case containing any other value in the same class. 

If one test case in an equivalence class detects a bug, all other test cases in that class have the same probability of finding bugs.

Therefore, instead of taking every value in one domain, only one test case is chosen from one class. 

In this way, testing covers the whole input domain, thereby reduces the total number of test cases.

In fact, it is an attempt to get a good hit rate to find maximum errors with the smallest number of test cases. 

Equivalence partitioning method for designing test cases has the following goals: 

Completeness 

Without executing all the test cases, we strive to touch the completeness of testing domain. 

Non-redundancy 

When the test cases are executed having inputs from the same class, then there is redundancy in executing the test cases. Time and resources are wasted in executing these redundant test cases, as they explore the same type of bug. Thus, the goal of equivalence partitioning method is to reduce these redundant test cases.

To use equivalence partitioning, one needs to perform two steps: 

 1. Identify equivalence classes 

 2. Design test cases 

4. Explain decision table in detail.

ANS)

Boundary value analysis and equivalence class partitioning methods do not consider combinations of input conditions. 

These consider each input separately. There may be some critical behaviour to be tested when some combinations of input conditions are considered. 

Decision table is another useful method to represent the information in a tabular method. 

It has the specialty to consider complex combinations of input conditions and resulting actions.

Decision tables obtain their power from logical expressions. 

Each operand or variable in a logical expression takes on the value, TRUE or FALSE

Condition stub 

It is a list of input conditions for which the complex combination is made. 

Action stub 

It is a list of resulting actions which will be performed if a combination of input condition is satisfied. 

Condition entry 

It is a specifi c entry in the table corresponding to input conditions mentioned in the condition stub. When we enter TRUE or FALSE for all input conditions for a particular combination, then it is called a Rule.

Action entry 

It is the entry in the table for the resulting action to be performed when one rule (which is a combination of input condition) is satisfi ed. ‘X’ denotes the action entry in the table

TEST CASE DESIGN USING DECISION TABLE : 

For designing test cases from a decision table, following interpretations should be done: 

„ Interpret condition stubs as the inputs for the test case. 

„ Interpret action stubs as the expected output for the test case. 

„ Rule, which is the combination of input conditions, becomes the test case itself.

„ If there are k rules over n binary conditions, there are at least k test cases and at the most 2n test cases

5. What is white box testing? Why we need it?

ANS)

White Box Testing
It is software testing technique in which internal structure, design and coding of software are tested to verify flow of input-output and to improve design, usability and security. In white box testing, code is visible to testers so it is also called Clear box testing, Open box testing, Transparent box testing, Code-based testing and Glass box testing.
It is one of two parts of the Box Testing approach to software testing. Its counterpart, Blackbox testing, involves testing from an external or end-user type perspective. On the other hand, White box testing in software engineering is based on the inner workings of an application and revolves around internal testing.

White box testing involves the testing of the software code for the following:

• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis

We need White Box testing for:

• It is executed at different levels such as system, integration and unit level of software development.
• One primary goal of White Box Testing is to verify the working of an application. 
• Addressing broken paths in the coding processes.
• Verifying the flow of specific inputs through the code.
• It involves testing a series of predefined inputs against expected or desired outputs so that specific input does not result in the expected output, then the bug obtained and to work on those bugs.
• Testing every function and statement individually.
• The functionality of conditional loops.
• Testing each statement.
• Testing of each object.
• Testing of function individually.
• Detection of Internal Security holes.
• Broken or poorly structured paths in a coding process.
• The flow of specific inputs through a code.
• It is executed at early stages and does not wait for GUI(Graphical User Interface) availability.
• Testing is done in such a way that it covers most of the paths.

6. Explain Logic coverage criteria with its various forms.

ANS)

Structural testing considers the program code, and test cases are designed based on the logic of the program such that every element of the logic is covered. 

Therefore the intention in white-box testing is to cover the whole logic. 

Discussed below are the basic forms of logic coverage. 

Statement Coverage 

The fi rst kind of logic coverage can be identifi ed in the form of statements. It is assumed that if all the statements of the module are executed once, every bug will be notified.

Consider the following code segment shown in below figure

If we want to cover every statement in the above code, then the following test cases must be designed:

Test case 1: x = y = n, where n is any number 

Test case 2: x = n, y = n¢, where n and n¢ are different numbers. 

Test case 1 just skips the while loop and all loop statements are not executed. Considering test case 2, the loop is also executed. 

However, every statement inside the loop is not executed. So two more cases are designed: 

Test case 3: x > y 

Test case 4: x < y 

These test cases will cover every statement in the code segment, however statement coverage is a poor criteria for logic coverage. We can see that test case 3 and 4 are sufficient to execute all the statements in the code. But, if we execute only test case 3 and 4, then conditions and paths in test case 1 will never be tested and errors will go undetected. 

Thus, statement coverage is a necessary but not a sufficient criteria for logic coverage

Decision or Branch Coverage 

Branch coverage states that each decision takes on all possible outcomes (True or False) at least once.

In other words, each branch direction must be traversed at least once. 

In the previous sample code shown, while and if statements have two outcomes: True and False. So test cases must be designed such that both outcomes for while and if statements are tested. 

The test cases are designed as: 

Test case 1: x = y 

Test case 2: x != y 

Test case 3: x < y 

Test case 4: x > y

Condition Coverage 

In this technique, all individual conditions must be covered as shown in the following example:
READ X, Y
IF(X == 0 || Y == 0)
PRINT ‘0’

In this example, there are 2 conditions: X == 0 and Y == 0. Now, test these conditions get TRUE and FALSE as their values. One possible example would be:
#TestCase 1 – X = 0, Y = 55
#TestCase 2 – X = 5, Y = 0

Decision/condition Coverage 

Condition coverage in a decision does not mean that the decision has been covered. If the decision 

is being tested, the condition coverage would allow one to write two test cases: 

Test case 1: A is True, B is False. 

Test case 2: A is False, B is True.

But these test cases would not cause the THEN clause of the IF to execute (i.e. execution of decision). The obvious way out of this dilemma is a criterion called decision/condition coverage. It requires suffi cient test cases such that each condition in a decision takes on all possible outcomes at least once, each decision takes on all possible outcomes at least once, and each point of entry is invoked at least once

Multiple condition coverage

 In case of multiple conditions, even decision/ condition coverage fails to exercise all outcomes of all conditions. 

The reason is that we have considered all possible outcomes of each condition in the decision, but we have not taken all combinations of different multiple conditions. 

Certain conditions mask other conditions. For example, if an AND condition is False, none of the subsequent conditions in the expression will be evaluated.

Similarly, if an OR condition is True, none of the subsequent conditions will be evaluated.

Thus, condition coverage and decision/condition coverage need not necessarily uncover all the errors.

Therefore, multiple condition coverage requires that we should write sufficient test cases such that all possible combinations of condition outcomes in each decision and all points of entry are invoked at least once. Thus, as in decision/condition coverage, all possible combinations of multiple conditions should be considered. 

The following test cases can be there: 

Test case 1: A = True, B = True 

Test case 2: A = True, B = False 

Test case 3: A = False, B = True

Test case 4: A = False, B = False

7. Write a short note on Basis Path Testing.

ANS)

Basis path testing is the oldest structural testing technique. 

The technique is based on the control structure of the program. 

Based on the control structure, a fl ow graph is prepared and all the possible paths can be covered and executed during testing. 

Path coverage is a more general criterion as compared to other coverage criteria and useful for detecting more errors. But the problem with path criteria is that programs that contain loops may have an infi nite number of possible paths and it is not practical to test all the paths. 

Some criteria should be devised such that selected paths are executed for maximum coverage of logic. Basis path testing is the technique of selecting the paths that provide a basis set of execution paths through the program. 

The guidelines for effectiveness of path testing are discussed below: 

 1. Path testing is based on control structure of the program for which fl ow graph is prepared. 

 2. Path testing requires complete knowledge of the program’s structure. 

 3. Path testing is closer to the developer and used by him to test his module. 

 4. The effectiveness of path testing gets reduced with the increase in size of software under test [9]. 

 5. Choose enough paths in a program such that maximum logic coverage is achieved.

8. Explain Inspection process. Explain members of he inspection team with their role.

ANS)

Planning 

During this phase, the following is executed: 

„ The product to be inspected is identifi ed. 

„ A moderator is assigned. 

„ The objective of the inspection is stated, i.e. whether the inspection is to be conducted for defect detection or something else. If the objective is defect detection, then the type of defect detection like design error, interface error, code error must be specified. The aim is to defi ne an objective for the meeting so that the effort spent in inspections is properly utilized. During planning, the moderator performs the following activities: 

„ Assures that the product is ready for inspection 

„ Selects the inspection team and assigns their roles 

„ Schedules the meeting venue and time 

„ Distributes the inspection material like the item to be inspected, checklists, etc

9. Explain structured walkthrough and technical review in detail.

ANS)

Walktrough : 

The idea of structured walkthroughs was proposed by Yourdon . 

It is a less formal and less rigorous technique as compared to inspection. 

The common term used for static testing is inspection but it is a very formal process. 

If you want to go for a less formal process having no bars of organized meeting, then walkthroughs are a good option.

A typical structured walkthrough team consists of the following members: 

„ Coordinator 

Organizes, moderates, and follows up the walkthrough activities. 

„ Presenter/Developer 

Introduces the item to be inspected. This member is optional. 

„ Scribe/Recorder 

Notes down the defects found and suggestion proposed by the members. 

„ Reviewer/Tester 

Finds the defects in the item. 

„ Maintenance Oracle

 Focuses on long-term implications and future maintenance of the project. 

„ Standards Bearer 

Assesses adherence to standards. 

„ User Representative/Accreditation Agent 

Reflects the needs and concerns of the user

Walkthrough process are shown below : 

Techinial Review : 

A technical review is intended to evaluate the software in the light of development standards, guidelines, and specifications and to provide the management with evidence that the development process is being carried out according to the stated objectives. 

A review is similar to an inspection or walkthrough, except that the review team also includes management. 

Therefore, it is considered a higher-level technique as compared to inspection or walkthrough.

A technical review team is generally comprised of management-level representatives and project management. 

Review agendas should focus less on technical issues and more on oversight than an inspection. 

The purpose is to evaluate the system relative to specifi cations and standards, recording defects and defi ciencies. 

The moderator should gather and distribute the documentation to all team members for examination before the review. 

He should also prepare a set of indicators to measure the following points: 

„ Appropriateness of the problem defi nition and requirements 

„ Adequacy of all underlying assumptions 

„ Adherence to standards 

„ Consistency 

„ Completeness 

„ Documentation

The moderator may also prepare a checklist to help the team focus on the key points. The result of the review should be a document recording the events of the meeting, deficiencies identified, and review team recommendations. 

Appropriate actions should then be taken to correct any defi ciencies and address all recommendations.