0% found this document useful (0 votes)
77 views15 pages

Testing Shows The Presence of Bugs

1. Testing reveals bugs but cannot prove a system is error-free. Exhaustive testing is impossible so risk-based prioritization is used. Early testing allows more time to prepare. Defects often cluster in a few modules. Repeated tests become less effective as a system evolves. Testing needs vary by context like industry. Absence of errors in testing does not prove a system is ready.

Uploaded by

Naveen S M
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
77 views15 pages

Testing Shows The Presence of Bugs

1. Testing reveals bugs but cannot prove a system is error-free. Exhaustive testing is impossible so risk-based prioritization is used. Early testing allows more time to prepare. Defects often cluster in a few modules. Repeated tests become less effective as a system evolves. Testing needs vary by context like industry. Absence of errors in testing does not prove a system is ready.

Uploaded by

Naveen S M
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 15

1.

Explain all principle of testing


1. Testing shows the presence of bugs
Testing an application can only reveal that one or more defects exist in the application,
however, testing alone cannot prove that the application is error free. Therefore, it is
important to design test cases which find as many defects as possible.
2. Exhaustive testing is impossible
Unless the application under test (AUT) has a very simple logical structure and limited input,
it is not possible to test all possible combinations of data and scenarios. For this reason, risk
and priorities are used to concentrate on the most important aspects to test.
3. Early testing
The sooner we start the testing activities the better we can utilize the available time. As soon
as the initial products, such the requirement or design documents are available, we can start
testing. It is common for the testing phase to get squeezed at the end of the development
lifecycle, i.e. when development has finished, so by starting testing early, we can prepare
testing for each level of the development lifecycle.
4. Defect clustering
During testing, it can be observed that most of the reported defects are related to small
number of modules within a system. i.e. small number of modules contain most of the
defects in the system. This is the application of the Pareto Principle to software testing:
approximately 80% of the problems are found in 20% of the modules.
5. The pesticide paradox
If you keep running the same set of tests over and over again, chances are no more new
defects will be discovered by those test cases. Because as the system evolves, many of the
previously reported defects will have been fixed and the old test cases do not apply anymore.
Anytime a fault is fixed or a new functionality added, we need to do regression testing to
make sure the new changed software has not broken any other part of the software. However,
those regression test cases also need to change to reflect the changes made in the software to
be applicable and hopefully fine new defects.

6. Testing is context dependent


Different methodologies, techniques and types of testing is related to the type and nature of
the application. For example, a software application in a medical device needs more testing
than a games software. More importantly a medical device software requires risk based
testing, be compliant with medical industry regulators and possibly specific test design
techniques. By the same token, a very popular website, needs to go through rigorous
performance testing as well as functionality testing to make sure the performance is not
affected by the load on the servers.
7. Absence of errors fallacy
Just because testing didnt find any defects in the software, it doesnt mean that the software
is ready to be shipped. Were the executed tests really designed to catch the most defects? or
where they designed to see if the software matched the users requirements? There are many
other factors to be considered before making a decision to ship the software.

2.What is Importance of Testing?


Lets take a look of advantages of software testing in the Software Development Life
Cycle:Testing should be introduce in the early stage of the SDLC, The cost of fixing the bug
is larger if testing is not done in early stage & bugs found in later stages.In the todays
competitive market only the quality product stays longtime firmly, so to make sure the
produce the good quality product the testing of application is key factor in SDLC.As it not
possible makes it software application is defect free but testing will be necessary.Most
important thing of testing is the development environment is different than the Testing
environment and the testing done on testing environment is similar to the Production
environment.
3.Explain Waterfall model .List advantages and disadvantages

The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed fully before the next phase can begin. This type of
model is basically used for the project which is small and there are no uncertain
requirements. At the end of each phase, a review takes place to determine if the project is on
the right path and whether or not to continue or discard the project. In this model the testing
starts only after the development is complete. In waterfall model phases do not overlap.

Diagram of Waterfall-model:
Advantages of waterfall model:

This model is simple and easy to understand and use.

It is easy to manage due to the rigidity of the model each phase has specific
deliverables and a review process.

In this model phases are processed and completed one at a time. Phases do not
overlap.

Waterfall model works well for smaller projects where requirements are very well
understood.

Disadvantages of waterfall model:

Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Not a good model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Not suitable for the projects where requirements are at a moderate to high risk of
changing.

4.Explain Exploratory and prototype model?


The exploratory model is a systems development method ( SDM ) occasionally used to
design and develop a computer system or product and basically consists of planning and
trying different designs until one of them seems to be the right one to develop. This model
works best in situations where few, or none, of the system or product requirements are
known in detail ahead of time. This model is largely based on educated guesswork.

There are several steps in the exploratory model:

A starting point is determined for the work. All the information available is gathered together
in an attempt to get an idea of what the new system will be expected to do, and how it can be
done.
A rudimentary first-generation system is put together, based on the information gathered and
the ideas formulated in the first step.
The first-generation system is tested to see how it performs, what it can and cannot do, and
what might be done to improve it.
A second-generation system is developed from the first one, based on the improvements
proposed in the previous step.
The second-generation system is tested, as was the first. Its performance is evaluated, and
possible improvements determined.
The process is repeated as many times as necessary to obtain user satisfaction, or until it is
decided that the project is unworkable.
Routine maintenance is carried out on a continuing basis to prevent large-scale failures and
to minimize downtime.

The basic idea in Prototype model is that instead of freezing the requirements before a design
or coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is a
software development model. By using this prototype, the client can get an actual feel of
the system, since the interactions with prototype can enable the client to better understand
the requirements of the desired system. Prototyping is an attractive idea for complicated and
large systems for which there is no manual process or existing system to help determining
the requirements.

6.Explain spiral /iterative model .List advantages and disadvantages?

The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spirals, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase. Requirements like
BRS that is Business Requirement Specifications and SRS that is System Requirement
specifications.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk
is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to
date before the project continues to the next spiral.

Diagram of Spiral model:


Advantages of Spiral model:

High amount of risk analysis hence, avoidance of Risk is enhanced.

Good for large and mission-critical projects.

Strong approval and documentation control.

Additional Functionality can be added at a later date.

Software is produced early in the software life cycle.

Disadvantages of Spiral model:

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Projects success is highly dependent on the risk analysis phase.

Doesnt work well for smaller projects.

7.Explain static testing?


Static testing is a software testing method that involves examination of the program's code
and its associated documentation but does not require the program be executed. Dynamic
testing, the other main category of software testing methods, involves interaction with the
program while it runs. The two methods are frequently used together to try to ensure the
functionality of a program.
Static testing may be conducted manually or through the use of various software testing
tools. Specific types of static software testing include code analysis, inspection, code reviews
and walkthroughs.
Required only source code of the product to test not the binaries or executable.
Static testing can be done by humans or with help of specialized tools.
The code works according to the functional requirement.
The code has been written in accordance with the design developed earlier in the project
lifecycle.
The code handles errors properly.

8.Explain all participants of formal reviews?


1. Planning: The first phase of the formal review is the Planning phase. In this phase
thereview process begins with a request for review by the author to the moderator (or
inspection leader). A moderator has to take care of the scheduling like date, time, place and
invitation of the review.
2. Kick-off: This kick-off meeting is an optional step in a review procedure. The goal of this
step is to give a short introduction on the objectives of the review and the documents to
everyone in the meeting. The relationships between the document under review and the other
documents are also explained.
3. Preparation: In this step the reviewers review the document individually using the related
documents, procedures, rules and checklists provided. Each participant while reviewing
individually identifies the defects, questions and comments according to their understanding
of the document and role.
4. Review meeting: The review meeting consists of three phases:

Logging phase: In this phase the issues and the defects that have been identified during the
preparation step are logged page by page.
Discussion phase: If any issue needs discussion then the item is logged and then handled in
the discussion phase.
Decision phase: At the end of the meeting a decision on the document under review has to be
made by the participants, sometimes based on formal exit criteria.

9.Explain code inspection?


Code inspection also called Fagan inspection is a method ,normally with a high degree of formalism.
To detect all faults, violations, and other side effects.
This method increases the number of defects detected by:
a. Demanding through preparation before and inspections/review;
b. Enlisting multiple diverse views;
c. Assigning specific roles to the multiple participants.
d. Going sequentially through the code in structured manner.
There are four roles in inspection
a. Author
Author of the work product
Makes available the required material to the reviewers
Fixes defects that are reported
b. Moderator
Controls the meeting(s)
c. Inspectors (reviewers)
Prepare by reading the required documents
Take part in the meeting(s) and report defects
d. Scribe
Takes down notes during the meeting
Assigned in advance by turns
Can participate to review to the extent possible
Documents the minutes and circulates them to participants

10.Explain structural testing?


Structural testing, also known as glass box testing or white box testing is an approach where
the tests are derived from the knowledge of the software's structure or internal
implementation.

Structural testing takes into account the code, code structure, internal design, and how
they are coded.
The fundamental difference between structural testing and static testing is that in
structural testing tests are actually run by the computer on the built product, whereas
in static testing the product is tested by human using just the source code and not the
executables or binaries.
Structural testing entails running the actual product against some predesigned test
cases to exercise as much of the code as possible or necessary.

11.Explain code coverages?


code coverage is a measure used to describe the degree to which the source code of a
program is executed when a particular test suite runs. A program with high code coverage,
measured as a percentage, has had more of its source code executed during testing which
suggests it has a lower chance of containing undetected software bugs compared to a
program with low code coverage.[1][2] Many different metrics can be used to calculate code
coverage; some of the most basic are the percentage of program subroutines and the
percentage of program statements called during execution of the test suite.

Code coverage was among the first methods invented for systematic software testing.
There are a number of coverage criteria, the main ones being:[5]

Function coverage Has each function (or subroutine) in the program been called?
Statement coverage Has each statement in the program been executed?
Branch coverage Has each branch (also called DD-path) of each control structure (such as
in if and case statements) been executed? For example, given an if statement, have both the
true and false branches been executed? Another way of saying this is, has every edge in the
program been executed?
Condition coverage (or predicate coverage) Has each Boolean sub-expression evaluated
both to true and false?

12.Explain the process of calculating cyclomatic code complexity with ex?


Cyclomatic complexity is a source code complexity measurement that is being correlated to
a number of coding errors. It is calculated by developing a Control Flow Graph of the code
that measures the number of linearly-independent paths through a program module.

Lower the Program's cyclomatic complexity, lower the risk to modify and easier to
understand. It can be represented using the below formula:

Cyclomatic complexity = E - N + 2*P


where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points
Example :
IF A = 10 THEN
IF B > C THEN
A=B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C
13.Differentiate between quality assurance and quality control?
Difference:

Quality Assurance Quality Control


Concentrates on the process of Concentrates on specific products.
producing the products.
Defect-prevention oriented. Defect-detection and correction
oriented.
Usually done throughout the life Usually done after the product is
cycle. built.
This is usually a staff function. This is usually a line function.
Ex: reviews and audits. Ex: software testing at various
levels.

14.Explain different development phases of V-model with diagram?

V-Model means Verification and Validation model. Just like the waterfall model, the V-
Shaped life cycle is a sequential path of execution of processes. Each phase must be
completed before the next phase begins. Testing of the product is planned in parallel with a
corresponding phase of development.

Diagram of V-model:
The various phases of the V-model are as follows:

Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
But, in this model before development is started, a system test plan is created. The test plan
focuses on meeting the functionality specified in the requirements gathering.

The high-level design (HLD) phase focuses on system architecture and design. It provides
overview of solution, platform, system, product and service/process. An integration test plan
is created in this phase as well in order to test the pieces of the software systems ability to
work together.

The low-level design(LLD) phase is where the actual software components are designed. It
defines the actual logic for each and every component of the system. Class diagram with all
the methods and relation between classes comes under LLD. Component tests are created in
this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete,
the path of execution continues up the right side of the V where the test plans developed
earlier are now put to use.

Coding: This is at the bottom of the V-Shape model. Module design is converted into code
by developers..

15.Explain the classifications of white box testing?


.
Static testing:
Required only source code of the product to test not the binaries or executable.
Static testing can be done by humans or with help of specialized tools.
The code works according to the functional requirement.
The code has been written in accordance with the design developed earlier in the project
lifecycle.
The code handles errors properly.

Methods of static testing


1) Desk checking of code:
Method to verify the portion of the code for correction.
Desk checking that most programmers do before compiling and executing the code.
Whenever the errors are found the author applies the corrections for errors on the spot.
This method of catching and correcting errors is characterized by:
1. No structure method or formalism to ensure completeness.
2. No maintaining of log or checklist.
Some of the disadvantages of this method of testing are as follows
a. A developer is not the best person to detect problems in his/her own code. He\she may be
tunnel visioned have blind spots to certain types of problems.
b. This method is essentially person-dependent and informal and thus may not work
consistently across all developers.
2) Code walkthrough:
This method and formal inspection are grouped-oriented methods.
Walkthroughs are less formal than inspection.
The line drawn in formalism between walkthroughs and inspections is very thin and varies from
organization to organization.
In walkthrough, a set of people look at the program code and resolve the questions for the author, the
author explains the logic of the code and answers the questions.

3) Code inspection:
Code inspection also called Fagan inspection is a method,normally with a high degree of formalism.
To detect all faults, violations, and other side effects.
This method increases the number of defects detected by:
e. Demanding through preparation before and inspections/review;
f. Enlisting multiple diverse views;
g. Assigning specific roles to the multiple participants.
h. Going sequentially through the code in structured manner.

Structural Testing Techniques:


Statement Coverage - This technique is aimed at exercising all programming statements with
minimal tests.

Branch Coverage - This technique is running a series of tests to ensure that all branches are
tested at least once.

Path Coverage - This technique corresponds to testing all possible paths which means that
each statement and branch are covered.

16.Explain Top down, bottom up and bi-directional integration and system integration?
Top-down integration testing is an integration testing technique used in order to simulate the
behaviour of the lower-level modules that are not yet integrated. Stubs are the modules that
act as temporary replacement for a called module and give the same output as that of the
actual product.

The replacement for the 'called' modules is known as 'Stubs' and is also used when the
software needs to interact with an external system.

Bottom-up testing is a specific type of integration testing that tests the lowest components of
a code base first. More generally, it refers to a middle phase in software testing that involves
taking integrated code units and testing them together, before testing an entire system or code
base.
IT professionals refer to design assemblies, or groups of code modules that are evaluated for
overall functioning, in integrated testing environments.

17.What is system testing? Why is syatem testing done?


Why system testing is important:

a) In Software Development Life Cycle the System Testing is perform as the first level of
testing where the System is tested as a whole.

b) In this step of testing check if system meets functional requirement or not.

c) System Testing enables you to test, validate and verify both the Application Architecture
and Business requirements.

d) The application/System is tested in an environment that particularly resembles the


effective production environment where the application/software will be lastly deployed.

Generally, a separate and dedicated team is responsible for system testing. And, System
Testing is performed on staging server which is similar to production server. So this means
you are testing software application as good as production environment.

18.Explain Guidelines on section of integration method?


integration testing: Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems. See also component integration
testing, system integration testing.
component integration testing: Testing performed to expose defects in the interfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and packages; testing
interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

19.Explain Integration testing as phase of testing?

Integration Testing is a level of software testing where individual units are combined and
tested as a group.

integration testing image

The purpose of this level of testing is to expose faults in the interaction between integrated
units. Test drivers and test stubs are used to assist in Integration Testing.
integration testing: Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems. See also component integration
testing, system integration testing.
component integration testing: Testing performed to expose defects in the interfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and packages; testing
interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

20.Explain Coverage of activities by scenarios testing


Requirements, Structure and Architecture are three software abstractions which are used to
develop and build the software. These can be described as the size of the software. With
these we can determine the completeness criteria with an ease. These are measure of
software testing.

We will understand each of these now:

1) Requirements Coverage:

=> Has the software been tested against all requirements for the normal range of use?

=> Has the software been tested against all requirements for abnormal or unexpected usage?

=>Techniques of requirement coverage:

Normal Range Coverage of Software Requirements


Normal Range Coverage of Software Design
Robustness Coverage of Software Requirements
Robustness Coverage of Software Design
2) Structural Coverage:

=>Has each element of the software been exercised during testing?

=>Techniques of structural coverage: Test Coverage is a structural coverage testing


approach. These techniques come under test coverage.

Code Statements
Decisions
Conditions and Decisions
3) Architectural Coverage:
=>Have the actual control and data links been utilised during testing?

=>Techniques of Architectural coverage:

Data Paths
Control Links
21.Explain all the challenges in white box testing
1. Human tendency of a developer being unable to find the defects in his or her
code = since white box testing involves programmers who write the code, it is
quite possible that they may not be most effective in detecting defects in their own
work product

Fully tested code may not correspond to realistic scenarios = this mean that even after
extensive testing, some of the common user scenarios may get left out and defects may creep
in

22.Compare various software development life cycle models


The Life cycle model describes how the phases combine together to form a complete
project or a life cycle. Such a model is characterized by the following attributes.
The activities performed. In any given software project, apart from the most
common activities or phases- requirement gathering, design, development,
testing, and maintenance- there could be other activities as well. Some of these
activities could be technical activities (for ex: porting) and some could be non-
technical activities (for ex: hiring).
The deliverables from each activity.Each activity produces a set of
deliverables, which are the end products of the activity.
Methods of validation of the deliverables. The output produced by a given
activity present the goal to be satisfied by that activity. Hence it is necessary to
have proper validation criteria for each output.
The sequence of activities. The different activities work together in unison in a
certain sequence of steps to achieve overall project goals.

You might also like