Software Testing & Other Concepts

7/30/2019 Software Testing & Other Concepts

1/27

Basic Concepts

Prepared By: Lajish Lakshmanan | Page1

What is a Software Methodology?

A methodology is a package of methods. In simple words, its a bundle of practical ideas and proven

practises which help in efficient software project management.

Software Test Methodology: The important Software Test Methodologies are discussed below

Waterfall model

What is it?

In the waterfall model, software development progress through various phases like Requirements Analysis,

Design etc. - sequentially.

In this model, next phase begins only when the earlier phase is completed.

What Is The Testing Approach?

The first phase in waterfall model is the requirements phase in which all the project requirements are

completely defined before starting the testing. During this phase, the test team brainstorms the scope of

testing , test strategy and drafts a detailed test plan.

Only once the design of software is complete, the team will move on to execution of the test cases to

ensure that the developed software behaves as it expected.

In this methodology, the testing team proceeds to the next phase only when the previous phase is

completed.


2/27

Basic Concepts


Advantages

This model is very simple to plan and manage. Hence, projects where requirements are clearly defined and

stated beforehand can be easily tested using waterfall model.

Disadvantages

In the waterfall model, you can begin with the next phase only once the previous phase is completed.

Hence, this model cannot accommodate unplanned events and uncertainty.This methodology is not suitable

for projects where the requirements change frequently.

Iterative development

What is it?

In this model, a big project is divided into small parts, and each part is subjected to multiple iterations of

the waterfall model. At the end of iteration, a new module is developed or an existing module is enhanced.This module is integrated into the software architecture and the entire system is tested all together

What is the testing Approach?

As soon as iteration is completed, the entire system is subjected to testing. Feedback from testing is

immediately available and is incorporated in next cycle. The testing time required in successive iterationcan be reduced based on the experience gained from past iterations.

Advantages

The main advantage of iterative development is the test feedback is immediately available at the end ofeach cycle.

Disadvantages

This model increases communication overheads significantly since at the end of each cycle, feedback about

deliverables, effort etc. must be given.


3/27

Basic Concepts


Agile methodology

What is it?

Traditional software development methodologies work on the premise that software requirements remain

constant throughout the project. But with increase in complexity, the requirements undergo numerous

changes and continuously evolve. At times, the customer himself is not sure what he wants. Though

iterative model addresses this issue, its still based on the waterfall model.

In Agile methodology , software is developed in incremental, rapid cycles. Interactions amongst

customers, developers and client are emphasized rather than processes and tools. Agile methodology

focuses on responding to change rather than extensive planning.


Incremental testing is used in agile development methods and hence, every release of the project is testedthoroughly. This ensures that any bugs in the system are fixed before the next release.

Advantages

It is possible to make changes in the project at any time to comply with the requirements.This incrementaltesting minimizes risks.


4/27

Basic Concepts


Disadvantages

Constant client interaction means added time pressure on all stake holders including the client themselves ,

software development and test teams .

Extreme programming

What is it?

Extreme programming is a type of agile methodology which believes in short development cycles. A

project is divided into simple engineering tasks. Programmers code a simple piece of software and get back

to customer for feedback. Review points from the customer are incorporated and the developers proceed

with the next task.

In extreme programming developers usually work in pairs. Extreme

Programming is used in places where customer requirements are constantly changing.


Extreme programming follows a Test-driven development which is described as follows

1. Add a test case to the test suite to verify the new functionality which is yet to be developed2. Run the all tests and obviously the new test case added must fail since the functionality is not coded yet3. Write some code to implement the feature/functionality4.

Run the test suite again .This time , the new test case should pass since the functionally has been coded


5/27

Basic Concepts


Advantages

Customers having a vague software design in mind could use extreme programming

Continuous testing and continuous integration of small releases ensure software code is delivered is of high

quality

Disadvantages

Meetings amongst the software development team and clients add to time requirements.

How to setup software testing methodologies?

Software testing methodologies should not be setup just for the sake of testing software code. The big

picture should be considered and the prime goal of the project should be satisfied by the testingmethodology.

Scheduling

Realistic scheduling is the key to the implementation of successful testing methodology and the schedule

should meet the needs of every member of the team.

Defined deliverables

In order to keep all the members of the team on the same page, well defined deliverables should be

provided. The deliverables should contain direct content without any ambiguity.

Test approach

Once scheduling is complete and defined deliverables are made available, the testing team should be able

to formulate the right test approach. Definition documents and developer meetings should indicate the team

about the best test approach that can be used for the project.

Reporting

Transparent reporting is very difficult to achieve, but this step determines the effectiveness of the testing

approach used in the project.

What Is Software Testing?

Software testing is a process used to identify the correctness, completeness, and quality ofdeveloped computer software. It includes a set of activities conducted with the intent of finding errors in

software so that it could be corrected before the product is released to the end users.

In simple words, software testing is an activity to check whether the actual results match the

expected results and to ensure that the software system is defect free .


6/27

Basic Concepts


Fundamental Principles of Software Testing

Consider a scenario where you are moving a file from folder A to Folder B. Think of all thepossible ways you can test this.

Apart from the usual scenarios, you can also test the following conditions Trying to move the file when it is Open You do not have the security rights to paste the file in Folder B Folder B is on a shared drive and storage capacity is full. Folder B already has a file with the same name, in fact the list is endless Or suppose you have 15 input fields to test ,each having 5 possible values , the number of

combinations to be tested would be 5^15

If you were to test the entire possible combinations project EXECUTION TIME & COSTSwill rise exponentially.

Hence, one of the testing principle states that EXHAUSTIVE testing is not possible. Instead weneed optimal amount of testing based on the risk assessment of the application .

And the million dollar question is, how do you determine this risk? To answer this lets do an exercise In your opinion, which operations are most likely to cause your Operating system to fail? I am sure most of you would have guessed Opening 10 different application all at the same time. So if you were testing this Operating system you would realize that defects are likely to be found in

multi-tasking and needs to be tested thoroughly which brings us to our next principle Defect

Clustering which states that a small number of modules contain most of the defects detected. By experience you can identify such risky modules. But this approach has its own problems If the same tests are repeated over and over again , eventually the same test cases will no

longer find new bugs

This is the another principle of testing calledPesticide Paradox To overcome this, the test cases need to be regularly reviewed & revised, adding new &

different test cases to help find more defects.

But even after all this sweat & hard work in testing, you can never claim you product is bug free.To drive home this point , lets see this video of public launch of Windows 98

You think a company like MICROSOFT would not have tested their OS thoroughly & would risktheir reputation just to see their OS crashing during its public launch!

Hence, testing principle states that - Testing shows presence of defects i.e. Software Testingreduces the probability of undiscovered defects remaining in the software but even if no

defects are found, it is not a proof of correctness.

But what if , you work extra hard , taking all precautions & make your software product 99% bugfree .And the software does not meet the needs & requirements of the clients.

This leads us to our next principle, which states that- Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is

unusable and does not fulfil the users needs & requirements

To fix this problem , the next principle of testing states that Early Testing - Testing should start as early as possible in the Software Development Life

Cycle. so that any defects in the requirements or design phase are captured as well more on this

principle in a later training tutorial.

And the last principle of testing states that the Testing is context dependent which basicallymeans that the way you test a e-commerce site will be different from the way you test a

commercial off the shelf application


7/27

Basic Concepts


Summary of the Seven Testing Principles

Principle 1 Testing shows presence of defects

Principle 2 Exhaustive testing is impossible

Principle 3 Early Testing

Principle 4 Defect Clustering

Principle 5 Pesticide Paradox

Principle 6 Testing is context dependent

Principle 7 Absence of errors - fallacy

Integration Testing

In Integration Testing, individual software modules are integrated logically and tested as a group.

A typical software project consists of multiple software modules, coded by different programmers.

Integration testing focuses on checking data communication amongst these modules.

Hence it is also termed as I & T (Integration and Testing), String Testing and sometimes ThreadTesting.

Need of Integration Testing:

Although each software module is unit tested, defects still exist for various reasons like

A Module in general is designed by an individual software developer who understanding andprogramming logic may differ from other programmers. Integration testing becomes necessary to

verify the software modules work in unity

At the time of module development, there wide chances of change in requirements by the clients.These new requirements may not be unit tested and hence integration testing becomes necessary.

Interfaces of the software modules with the database could be erroneous External Hardware interfaces, if any, could be erroneous Inadequate exception handling could cause issues.

Integration Test Case:

Integration Test case differs from other test cases in the sense it focuses mainly on the interfaces & flow

of data/information between the modules. Here priority is to be given for the integrating links rather

than the unit functions which are already tested.

Sample Integration Test Cases for the following scenario: Application has 3 modules say Login Page,

Mail box and Delete mails and each of them are integrated logically.

Here do not concentrate much on the Login Page testing as its already being done. But check how its

linked to the Mail Box Page.


8/27

Basic Concepts


Approaches/Methodologies/Strategies of Integration Testing:

The Software Industry uses variety of strategies to execute Integration testing , viz.

Big Bang Approach : Incremental Approach: which is further divided into following

o Top Down Approacho Bottom Up Approacho Sandwich Approach - Combination of Top Down and Bottom Up

Below are the different strategies, the way they are executed and their limitations as well advantages.

Big Bang Approach:

Here all component are integrated together at once, and then tested.

Advantages:

Convenient for small systems.Disadvantages:

Fault Localization is difficult. Given the sheer number of interfaces that need to be tested in this approach, some interfaces links to

be tested could be missed easily.

Since the integration testing can commence only after all the modules are designed, testing teamwill have less time for execution in the testing phase.

Since all modules are tested at once, high risk critical modules are not isolated and tested onpriority. Peripheral modules which deal with user interfaces are also not isolated and tested on

priority.

Test Case ID Test Case ObjectiveTest Case

DescriptionExpected Result

1

Check the interface

link between theLogin and Mailbox

module

Enter login

credentials andclick on the Login

button

To be directed to the Mail Box

2

Check the interface

link between the

Mailbox and Delete

Mails Module

From Mail box

select the an email

and click delete

button

Selected email should appear in the

Deleted/Trash folder


9/27

Basic Concepts


Incremental Approach:

In this approach, testing is done by joining two or more modules that are logically related. Then the other

related modules are added and tested for the proper functioning. Process continues until all of the modules

are joined and tested successfully.

This process is carried out by using dummy programs calledStubs and Drivers. Stubs and Drivers do not

implement the entire programming logic of the software module but just simulate data communication with

the calling module.

Stub: Is called by the Module under Test.

Driver: Calls the Module to be tested.

Incremental Approach in turn is carried out by two different Methods:

o Bottom Upo Top Down

Bottom up Integration

In the bottom up strategy, each module at lower levels is tested with higher modules until all modules are

tested. It takes help of Drivers for testing

Diagrammatic Representation:

Advantages:

Fault localization is easier. No time is wasted waiting for all modules to be developed unlike Big-bang approach

Disadvantages:

Critical modules (at the top level of software architecture) which control the flow of application aretested last and may be prone to defects.

Early prototype is not possible


10/27

Basic Concepts


Top down Integration:

In Top to down approach, testing takes place from top to down following the control flow of the software

system.

Diagrammatic Representation:

Advantages:

Fault Localization is easier. Possibility to obtain an early prototype. Critical Modules are tested on priority; major design flaws could be found and fixed first.

Disadvantages:

Needs many Stubs. Modules at lower level are tested inadequately.

Integration Testing ProcedureThe integration test procedure irrespective of the test strategies (discussed above):

1. Prepare the Integration Test Plan2. Design the Test Scenarios, Cases, and Scripts.3. Executing the test Cases followed by reporting the defects.4. Tracking & re-testing the defects.5. Steps 3 and 4 are repeated until the completion of Integration is successfully.


11/27

Basic Concepts


Brief Description of Integration Test Plans:

It includes following attributes:

Methods/Approaches to test (as discussed above). Scopes and Out of Scopes Items of Integration Testing. Roles and Responsibilities. Pre-requisites for Integration testing. Testing environment. Risk and Mitigation Plans.

Entry and Exit Criteria

Entry and Exit Criteria to Integration testing phase in any software development model

Entry Criteria:

Unit Tested Components/Modules All High prioritized bugs fixed and closed All Modules to be code completed and integrated successfully. Integration test Plan, test case, scenarios to be signed off and documented. Required Test Environment to be set up for Integration testing

Exit Criteria:

Successful Testing of Integrated Application. Executed Test Cases are documented All High prioritized bugs fixed and closed Technical documents to be submitted followed by release Notes.

Best Practices/ Guidelines for Integration Testing

First determine the Integration Test Strategy that could be adopted and later prepare the test casesand test data accordingly.

Study the Architecture design of the Application and identify the Critical Modules. These need tobe tested on priority.

Obtain the interface designs from the Architectural team and create test cases to verify all of theinterfaces in detail. Interface to database/external hardware/software application must be tested in

detail.

After the test cases, its the test data which plays the critical role. Always have the mock data prepared, prior to executing. Do not select test data while executing the

test cases.


12/27

Basic Concepts


Smoke and Sanity Testing - Introduction and Differences

To appreciate the above diagram, lets first understand -

What is a Software Build?

If you are developing a simple computer program which consists of only one source code file, you merelyneed to compile and link this one file, to produce an executable file. This process is very simple.

Usually this is not the case. A typical Software Project consists of hundreds or even thousands of sourcecode files. Creating an executable program from these source files is a complicated and time-consuming

task.You need to use "build" software to create an executable program and the process is called "Software

Build"

Whatis Smoke Testing?

Smoke Testing is performed after software build to ascertain that the critical functionalities of theprogram is working fine. It is executed"before" any detailed functional or regression tests are executed

on the software build. The purpose is to reject a badly broken application, so that the QA team does notwaste time installing and testing the software application.

In Smoke Testing, the test cases chosen cover the most important functionality or component of the system.The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system

are working fine. For Example a typical smoke test would be Verify that the application launchessuccessfully, Check that the GUI is responsive ... etc.


13/27

Basic Concepts


What is Sanity Testing?

After receiving a software build, with minor changes in code, or functionality, Sanity testing is

performed to ascertain that the bugs have been fixed and no further issues are introduced due tothese changes. The goal is to determine that the proposed functionality works roughly as expected. If

sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing .

The objective is "not" to verify thoroughly the new functionality, but to determine that the developer

has applied some rationality (sanity) while producing the software. For instance, if your scientific

calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin

30 + cos 50.

Smoke Testing V/s Sanity Testing - Key Differences

Smoke Testing Sanity Testing

Smoke Testing is performed to ascertain that the critical

functionalities of the program is working fine

Sanity Testing is done to check the new functionality /

bugs have been fixed

The objective of this testing is to verify the "stability" of

the system in order to proceed with more rigorous testing

The objective of the testing is to verify the "rationality" of

the system in order to proceed with more rigorous

testing

This testing is performed by the developers or testers Sanity testing is usually performed by testers

Smoke testing is usually documented or scriptedSanity testing is usually not documented and is

unscripted

Smoke testing is a subset of Regression testing Sanity testing is a subset of Acceptance testing

Smoke testing exercises the entire system from end to

end

Sanity testing exercises only the particular component of

the entire system

Smoke testing is like General Health Check Up Sanity Testing is like specialized health check up

Points to note:

Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determiningwhether an application is too flawed to merit any rigorous testing.

Sanity Testing is also called tester acceptance testing. Smoke testing performed on a particular build is also known as a build verification test. One of the best industry practices is to conduct a Daily build and smoke test in software projects. Both smoke and sanity tests can be executed manually or using an automation tool. When automated

tools are used, the tests are often initiated by the same process that generates the build itself.

As per the needs of testing, you may have to execute both Sanity and Smoke Tests on the software build.In such cases you will first execute Smoke tests and then go ahead with Sanity Testing. In industry, test

cases for Sanity Testing are commonly combined with that for smoke tests, to speed up test execution.

Hence it's a common that the terms are often confused and used interchangeably.


14/27

Basic Concepts


What is Black Box Testing?

Black box testing is a software testing techniques in which functionality of the software under test

(SUT) is tested without looking at the internal code structure, implementation details and knowledge of

internal paths of the software. This type of testing is based entirely on the software requirements and

specifications.

In Black Box Testing we just focus on inputs and output of the software system without bothering

about internal knowledge of the software program.

The above Black Box can be any software system you want to test. For example : an operating system like

Windows, a website like Google ,a database like Oracle or even your own custom application. Under Black

Box Testing, you can test these applications by just focusing on the inputs and outputs without knowing

their internal code implementation.

Black box testing - Steps

Here are the generic steps followed to carry out any type of Black Box Testing.

Initially requirements and specifications of the system are examined. Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly.

Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detectthem.

Tester determines expected outputs for all those inputs. Software tester constructs test cases with the selected inputs. The test cases are executed. Software tester compares the actual outputs with the expected outputs. Defects if any are fixed and re-tested.

Types of Black Box Testing

There are many types of Black Box Testing but following are the prominent ones -

Functional testing This black box testing type is related to functional requirements of a system; it is doneby software testers.

Non-functional testing This type of black box testing is not related to testing of a specific functionality ,but non-functional requirements such as performance, scalability, usability.

Regression testing Regression testing is done after code fixes; upgrades or any other system maintenanceto check the new code has not affected the existing code.


15/27

Basic Concepts


Tools used for Black Box Testing:

A tool used for Black box testing largely depends on the type of black box testing you are doing.

For Functional/ Regression Tests you can use - QTP

For Non-Functional Tests you can use - Loadrunner

Black box testing strategy:

Following are the prominent test strategy amongst the many used in Black box Testing

Equivalence Class Testing: It is used to minimize the number of possible test cases to an optimum levelwhile maintains reasonable test coverage.

Boundary Value Testing: Boundary value testing is focused on the values at boundaries. This techniquedetermines whether a certain range of values are acceptable by the system or not. It is very useful in

reducing the number of test cases. It is mostly suitable for the systems where input is within certain ranges.

Decision Table Testing: A decision table puts causes and their effects in a matrix. There is uniquecombination in each column.

Comparison of Black Box and White Box Testing:

While White Box Testing (Unit Testing) validates internal structure and working of your software

code, the main focus of black box testing is on the validation of your functional requirements.

To conduct White Box Testing, knowledge of underlying programming language is essential. Current day

software systems use a variety of programming languages and technologies and its not possible to

know all of them. Black box testing gives abstraction from code and focuses testing effort on the

software system behaviour.

Also software systems are not developed in a single chunk but development is broken down in different

modules. Black box testing facilitates testing communication amongst modules (Integration Testing).

In case you push code fixes in your live software system, a complete system check (black box regression

tests) becomes essential.

Though White box testing has its own merits and helps detect many internal errors which may degradesystem performance


16/27

Basic Concepts


Black Box Testing and Software Development Life Cycle (SDLC)

Black box testing has its own life cycle called Software Test Life Cycle (STLC) and it is relative to

every stage of Software Development Life Cycle.

Requirement This is the initial stage of SDLC and in this stage requirement is gathered. Software testersalso take part in this stage.

Test Planning & Analysis Testing Types applicable to the project are determined. A Test Plan is createdwhich determines possible project risks and their mitigation.

Design In this stage Test cases/scripts are created on the basis of software requirement documents Test Execution- In this stage Test Cases prepared are executed. Bugs if any are fixed and re-tested.

What is a White Box Testing?

White Box Testing is the testing of a software solution's internal coding and infrastructure.

It focuses primarily on strengthening security, the flow of inputs and outputs through the application,

design and usability.

White box testing is also known as clear, open, structural, and glass box testing.

It is one of two parts of the "box testing" approach of software testing. Its counter-part, blackbox testing,

involves testing from an external or end-user type perspective. On the other hand, Whitebox testing is

based on the inner workings of an application and revolves around internal testing. The term "whitebox"

was used because of the see-through box concept. The clear box or whitebox name symbolizes the abilityto see through the software's outer shell (or "box") into its inner workings. Likewise, the "black box" in

"black box testing" symbolizes not being able to see the inner workings of the software so that only the

end-user experience can be tested

What do you verify in White Box 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 coding infrastructure Expected output The functionality of conditional loops Testing of each statement, object and function on an individual basis

The testing can be done at system, integration and unit levels of software development. One of the basic

goals of white box testing is to verify a working flow for an application. It involves testing a series ofpredefined inputs against expected or desired outputs so that when a specific input does not result in the

expected output, you have encountered a bug.


17/27

Basic Concepts


How do we perform White Box Testing?

To give you a simplified explanation of white box testing, we have divided it into two basic steps. This is

what testers do when testing an application using the white box testing technique:

Step 1) UNDERSTAND THE SOURCE CODE

The first thing a tester will often do is learn and understand the source code of the application. Since whitebox testing involves the testing of the inner workings of an application, the tester must be very

knowledgeable in the programming languages used in the applications they are testing. Also, the testing

person must be highly aware of secure coding practices. Security is often one of the primary objectives of

testing software. The tester should be able to find security issues and prevent attacks from hackers and

naive users who might inject malicious code into the application either knowingly or unknowingly.

Step 2) CREATE TEST CASES AND EXECUTE

The second basic step to white box testing involves testing the applications source code for proper flowand structure. One way is by writing more code to test the applications source code. The tester will

develop little tests for each process or series of processes in the application. This method requires that the

tester must have intimate knowledge of the code and is often done by the developer. Other methods include

manual testing, trial and error testing and the use of testing tools as we will explain further on in this

article.

White Box Testing Techniques

A major White box testing technique is Code Coverage analysis. Code Coverage analysis, eliminates gaps

in a test case suite. It identifies areas of a program that are not exercised by a set of test cases. Once gaps

are identified, you create test cases to verify untested parts of code, thereby increase the quality of the

software product

There are automated tools available to perform Code coverage analysis. Below are a few coverage analysis

techniques

Statement Coverage This technique requires every possible statement in the code to be tested at least

once during the testing process. Tools: An example of a tool that handles statement coverage for C++

applications is Cantata++

Branch Coverage This technique checks every possible path (if-else and other conditional loops) of a

software application. Tools: An example of a tool that handles branch coverage testing for C, C++ and Java

applications is TCAT-PATH

Apart from above, there are numerous coverage types such as Condition Coverage, Multiple Condition

Coverage, Path Coverage, Function Coverage etc. Each technique has its own merits and attempts to test

(cover) all parts of software code.

Using Statement and Branch coverage you generally attain 80-90% code coverage which is sufficient.


18/27

Basic Concepts


Types of White Box Testing

White box testingencompasses several testing types used to evaluate the usability of an application, blockof code or specific software package. There are listed below --

Unit Testing: It is often the first type of testing done on an application. Unit testing is performed on eachunit or block of code as it is developed.

Unit testing is essentially done by the programmer. As a software developer, you develop a few lines of

code, a single function or an object and test it to make sure it works before continuing

Unit testing helps identify majority of bugs, early in the software development lifecycle. Bugs identified in

this stage are cheaper and easy to fix.

Testing for Memory Leaks:Memory leaks are the leading cause of slower running of applications. A QA specialist who is experienced

at detecting memory leaks is essential in cases where you have a slow running software application.

There are many tools available to assist developers/testers with memory leak testing, example, Rational

Purify for windows application

Apart from above a few testing types are part of both black box and white box testing. They are listed as

below

White Box Penetration Testing: In this testing, the tester/developer has full information of the

applications source code, detailed network information, IP addresses involved and all server information

the application runs on. The aim is to attack the code from several angles to expose security threats

White Box Mutation Testing: Mutation testing is often used to discover the best coding techniques to use

for expanding a software solution.

Ending Notes:

White box testing can be quite complex. The complexity involved has a lot to do with the application beingtested. A small application that performs a single simple operation could be white box tested in minutes,

while larger programming applications take days, weeks and even longer to fully test. White box testing should be done on a software application as it is being developed, after it is written and

again after each modification.


19/27

Basic Concepts


Some Interview Questions:

1. What is the MAIN benefit of designing tests early in the life cycle?

Ans: It helps prevent defects from being introduced into the code.

2. What is risk-based testing?Ans: Risk-based testing is the term used for an approach to creating a test strategy that is based on

prioritizing tests by risk. The basis of the approach is a detailed risk analysis and prioritizing of risks by

risk level. Tests to address each risk are then specified, starting with the highest risk first.

3. A wholesaler sells printer cartridges. The minimum order quantity is 5. There is a 20% discount

for orders of 100 or more printer cartridges. You have been asked to prepare test cases using various

values for the number of printer cartridges ordered. Which of the following groups contain three test

inputs that would be generated using Boundary Value Analysis?Ans: 4, 5, 99

4. What is the KEY difference between preventative and reactive approaches to testing?

Ans: Preventative tests are designed early; reactive tests are designed after the software has been produced

5. What is the purpose of exit criteria?Ans: To define a level when testing gets completed.

6. What determines the level of risk?

Ans: The likelihood of an adverse event and the impact of the event

7. When is used Decision table testing?Ans: Decision table testing is used for testing systems for which the specification takes the form of rules or

cause-effect combinations. In a decision table the inputs are listed in a column, with the outputs in the same

column but below the inputs. The remainder of the table explores combinations of inputs to define the

outputs produced.

8. What is the MAIN objective when reviewing a software deliverable?Ans: To identify defects in deliverable software product.

9. Which of the following defines the expected results of a test? Test case specification or test design

specification.

Ans: Test case specification.

10. Which is a benefit of test independence?Ans: It avoids author bias in defining effective tests.

11. As part of which test process do you determine the exit criteria? Ans: Test planning.

12. What is beta testing?

Ans: Testing performed by potential customers at their own locations.

13. Rapid Application Development?Ans: 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


20/27


21/27

Basic Concepts


22. Which activity in the fundamental test process includes evaluation of the testability of the

requirements and system?

Ans: Test analysis and design.

23. What is typically the MOST important reason to use risk to drive testing efforts?

Ans: Because testing everything is not feasible.

24. Which is the MOST important advantage of independence in testing?

Ans: An independent tester may be more effective at finding defects missed by the person who wrote the

software.

25. Which of the following are valid objectives for incident reports?

i. Provide developers and other parties with feedback about the problem to enable identification,

isolation and correction as necessary.

ii. Provide ideas for test process improvement.

iii. Provide a vehicle for assessing tester competence.

iv. Provide testers with a means of tracking the quality of the system under test.Ans: i. Provide developers and other parties with feedback about the problem to enable identification,

isolation and correction as necessary,

ii. Provide ideas for test process improvement,

iv. Provide testers with a means of tracking the quality of the system under test

26. Consider the following techniques. Which are static and which are dynamic techniques?

i. Equivalence Partitioning.

ii. Use Case Testing.

iii.Data Flow Analysis.

iv.Exploratory Testing.

v. Decision Testing.vi. Inspections.Ans: Data Flow Analysis and Inspections are static; Equivalence Partitioning, Use Case Testing,

Exploratory Testing and Decision Testing are dynamic.

27. Why static testing and dynamic testing are described as complementary?Ans: Because they share the aim of identifying defects but differ in the types of defect they find.

28. What are the phases of a formal review?Ans: In contrast to informal reviews, formal reviews follow a formal process. A typical formal review

process consists of six main steps:1. Planning2. Kick-off3. Preparation4. Review meeting5. Rework6. Follow-up.

29. What is the role of moderator in review process?Ans: The moderator (or review leader) leads the review process. He or she determines, in co-operation 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 ofthe review process. The moderator also schedules the meeting, disseminates documents before the meeting,


22/27

Basic Concepts


coaches other team members, paces the meeting, leads possible discussions and stores the data that is

collected.

30. What is an equivalence partition (also known as an equivalence class)?

Ans: An input or outputs range of values such that only one value in the range becomes a test case.

31. When should configuration management procedures be implemented?Ans: During test planning.

32. A Type of functional Testing, which investigates the functions relating to detection of threats,

such as virus from malicious outsiders.Ans: Security Testing

33. Testing wherein we subject the target of the test, to varying workloads to measure and evaluate

the performance behaviours and ability of the target and of the test to continue to function properly

under these different workloads.

Ans: Load Testing

34. Testing activity which is performed to expose defects in the interfaces and in the interaction

between integrated components is:Ans: Integration Level Testing

35. What are the Structure-based (white-box) testing techniques?Ans: Structure-based testing techniques (which are also dynamic rather than static) use the internal

structure of the software to derive test cases. They are commonly called 'white-box' 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.

36. When should be performed Regression testing?Ans: After the software has changed or when the environment has changed.

37. When should testing be stopped?Ans: It depends on the risks for the system being tested.

38. What is the purpose of a test completion criterion?

Ans: To determine when to stop testing.

39. What can static analysis NOT find?Ans: For example memory leaks

40. What is the difference between re-testing and regression testing?Ans: Re-testing ensures the original fault has been removed; regression testing looks for unexpected side-

effects

41. What are the Experience-based testing techniques?

Ans: 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, asthey 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.


23/27

Basic Concepts


42. What type of review requires formal entry and exit criteria, including metrics?

Ans: Inspection

43. Could reviews or inspections be considered part of testing?

Ans: Yes, because both help detect faults and improve quality.

44. An input field takes the year of birth between 1900 and 2004 what are the boundary values for

testing this field? .Ans: 1899,1900,2004,2005

45. Which of the following tools would be involved in the automation of regression test? a. Data

tester b. Boundary tester c. Capture/Playback d. Output comparator.Ans: d. Output comparator

46. To test a function, what has to write a programmer, which calls the function to be tested and

passes it test data?Ans:Driver

47. What is the one Key reason why developers have difficulty testing their own work? Ans: Lack of Objectivity

48. How much testing is enough?Ans: The answer depends on the risk for your industry, contract and special requirements.

49. When should testing be stopped?

Ans: It depends on the risks for the system being tested.

50. Which of the following is the main purpose of the integration strategy for integration testing in

the small?

Ans: To specify which modules to combine when, and how many at once.

51. What is the purpose of a test completion criterion?

Ans: To determine when to stop testing

52. What is the difference between re-testing and regression testing?Ans:Re-testing ensures the original fault has been removed; regression testing looks for unexpected side-

effects.

53. Which review is normally used to evaluate a product to determine its suitability for intended use

and to identify discrepancies?

Ans: Technical Review.

54. Why we use decision tables?Ans: The techniques of equivalence partitioning and boundary value analysis are often applied to specific

situations or inputs. However, if different combinations of inputs result in different actions being taken, this

can be more difficult to show using equivalence partitioning and boundary value analysis, which tend to be

more focused on the user interface. The other two specification-based techniques, decision tables and state

transition testing are more focused on business logic or business rules. A decision table is a good way todeal with combinations of things (e.g. inputs). This technique is sometimes also referred to as a 'cause-


24/27

Basic Concepts


effect' table. The reason for this is that there is an associated logic diagramming technique called 'cause-

effect graphing' which was sometimes used to help derive the decision table.

55. Faults found should be originally documented by whom?

Ans: By testers.

56. Which is the current formal world-wide recognized documentation standard?Ans: There isnt one.

57. Which of the following is the review participant who has created the item to be reviewed? Ans: Author

58. A number of critical bugs are fixed in software. All the bugs are in one module, related to

reports. The test manager decides to do regression testing only on the reports module.

Ans: Regression testing should be done on other modules as well because fixing one module may affectother modules.

59. Why does the boundary value analysis provide good test cases?

Ana: Because errors are frequently made during programming of the different cases near the edges of the

range of values.

60. What makes an inspection different from other review types?

Ans: It is led by a trained leader, uses formal entry and exit criteria and checklists.

61. Why can be tester dependent on configuration management?Ans: Because configuration management assures that we know the exact version of the test ware and the

test object.

62. What is a V-Model?Ans: A software development model that illustrates how testing activities integrate with software

development phases.

63. What is maintenance testing?Ans: Triggered by modifications, migration or retirement of existing software.

64. What is test coverage?Ans: 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 andcan tell whether or not each of those things has been tested by some test, then we can measure coverage.

65. Why is incremental integration preferred over big bang integration?

Ans: Because incremental integration has better early defects screening and isolation ability.

66. When do we prepare RTM (Requirement traceability matrix), is it before test case designing or

after test case designing?

Ans: That would be before. Requirements should already be traceable from Review activities since you

should have traceability in the Test Plan already. This question also would depend on the organisation. If

the organisation does test after development started then requirements must be already traceable to their

source.

67. What is called the process starting with the terminal modules?


25/27

Basic Concepts


Ans: Bottom-up integration

68. During which test activity could faults be found most cost effectively? Ans: During test planning

69. The purpose of requirement phase isAns: To freeze requirements, to understand user needs, to define the scope of testing

70. How much testing is enough?Ans: The answer depends on the risks for your industry, contract and special requirements

71. Why we split testing into distinct stages?

Ans: Each test stage has a different purpose.

72. Which of the following is likely to benefit most from the use of test tools providing test capture

and replay facilities? a) Regression testing b) Integration testing c) System testing d) User acceptance

testingAns:Regression testing

73. How would you estimate the amount of re-testing likely to be required?Ans: Metrics from previous similar projects and discussions with the development team

74. What studies data flow analysis?Ans: The use of data on paths through the code.

75. What is Alpha testing?

Ans: Pre-release testing by end user representatives at the developers site.

76. What is a failure?Ans: Failure is a departure from specified behaviour.

77. What are Test comparators?Ans: 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.

78. Who is responsible for document all the issues, problems and open point that were identified

during the review meeting

Ans:Scribe

79. What is the main purpose of Informal Review?Ans: Inexpensive way to get some benefit

80. What is the purpose of test design technique?Ans: Identifying test conditions and Identifying test cases

81. When testing a grade calculation system, a tester determines that all scores from 90 to 100 will

yield a grade of A, but scores below 90 will not. This analysis is known as:Ans:Equivalence partitioning


26/27

Basic Concepts


82. A test manager wants to use the resources available for the automated testing of a web

application. The best choice is..

Ans: Tester, test automated, web specialist, DBA

83. During the testing of a module tester X finds a bug and assigned it to developer. But developer

rejects the same, saying that its not a bug. What X should do?Ans: Send to the detailed information of the bug encountered and check the reproducibility

84. A type of integration testing in which software elements, hardware elements, or both are

combined all at once into a component or an overall system, rather than in stages. Ans: Big-Bang Testing

85. In practice, which Life Cycle model may have more, fewer or different levels of development and

testing, depending on the project and the software product? For example, there may be component

integration testing after component testing, and system integration testing after system testing.Ans: V-Model

86. Which technique can be used to achieve input and output coverage? It can be applied to human

input, input via interfaces to a system, or interface parameters in integration testing.Ans: Equivalence partitioning

87. This life cycle model is basically driven by schedule and budget risks This statement is best

suited forAns: V-Model

88. In which order should tests be run?

Ans: The most important tests first

89. The later in the development life cycle a fault is discovered, the more expensive it is to fix. Why? Ans: The fault has been built into more documentation, code, tests etc.

90. What is Coverage measurement?Ans: It is a partial measure of test thoroughness.

91. What is Boundary value testing?Ans: Test boundary conditions on, below and above the edges of input and output equivalence classes.

92. What is Fault Masking?Ans: Error condition hiding another error condition.

93. What does COTS represent?

Ans: Commercial off The Shelf.

94.The purpose of which is allow specific tests to be carried out on a system or network that

resembles as closely as possible the environment where the item under test will be used upon release? Ans: Test Environment

95. What can be thought of as being based on the project plan, but with greater amounts of detail?

Ans: Phase Test Plan


27/27

Basic Concepts

96. What is exploratory testing?Ans: Exploratory testing is a hands-on approach in which testers are involved in minimum planning and

maximum test execution. The planning involves the creation of a test charter, a short declaration of thescope of a short (1 to 2 hour) time-boxed test effort, the objectives and possible approaches to be used. The

test design and test execution activities are performed in parallel typically without formally documenting

the test conditions, test cases or test scripts. This does not mean that other, more formal testing techniqueswill not be used. For example, the tester may decide to use boundary value analysis but will think through

and test the most important boundary values without necessarily writing them down. Some notes will be

written during the exploratory-testing session, so that a report can be produced afterwards.

97. What is failure?Ans: Deviation from expected result to actual result.

Documents

Software Testing & Other Concepts