Nitesh Parashar - Software-Testing-Report
Nitesh Parashar - Software-Testing-Report
Nitesh Parashar - Software-Testing-Report
1. Introduction
In a software development project, errors can be creeping at any stage during the
development. For each phase we have discussed different techniques for detecting and
eliminating errors that originates in that phase.
During testing, the program to be tested is executed with a set of test cases, and the
output of the program for the test case is evaluated to determine if the program is
performing as it is expected to. Due to its approach, dynamic testing can only as certain
the presence of error in the program; the exact nature of the error is not usually decided
by testing. Testing forms the first step in determining the errors in a program. Clearly
the success of testing revealing errors in programs depends critically on the test cases.
Page | 1
Page | 2
Assuming the best, previously unknown problems may present themselves during
development and testing. This can lead to problems maintaining the schedule. Failing to
adjust the feature set or schedule when problems are discovered can lead to rushed work
and flawed systems.
Page | 3
3. Heuristics of Software
Testing
Software testability is how easily, completely and conveniently a computer program
canbe tested.Software engineers design a computer product, system or program keeping
in mind theproduct testability. Good programmers are willing to do things that will help
the testingprocess and a checklist of possible design points, features and so on can be
useful in negotiating with them.
3.1 Visibility
Visibility is our ability to observe the states and outputs of the software under test.
Page | 6
3.2 Control
Page | 7
• Test Interfaces: Interfaces may be provided specifically for testing e.g. Excel
and Xconq etc. Existing interfaces may be able to support significant testing e.g.
Install Shield, AutoCAD, Tivoli, etc.
3.3.1 Observability
What we see is what we test.
Distinct output should be generated for each input
Current and past system states and variables should be visibleduring testing
All factors affecting the output should be visible.
Incorrect output should be easily identified.
Page | 8
3.3.2 Controllability
The better we control the software, the more the testing process can be automated and
optimized.
Check that
All outputs can be generated and code can be executed throughsome combination of
input.
Software and hardware states can be controlled directly by thetest engineer.
Inputs and output formats are consistent and structured.
Test can be conveniently, specified, automated and reproduced.
3.3.3 Decomposability
By controlling the scope of testing, we can quickly isolate problems and perform
effective and efficient testing. The software system should be built fromindependent
modules which can betested independently.
3.3.4 Simplicity
The less there is to test, the more quickly we can test it.The points to consider in this
regard are functional (e.g. minimum set of features), structural (e.g. architecture is
modularized) and code (e.g. a codingstandard is adopted) simplicity.
3.3.5 Stability
The fewer the changes, the fewer are the disruptions to testing.The changes to software
should be infrequent, controlled and not invalidating existing tests. The software should
be able to recover well from failures.
3.3.6 Understandability
The more information we will have, the smarter we will test.The testers should be able
to understand the design, changes to the design and the dependencies between internal,
external and shared components.Technical documentation should be instantly
accessible, accurate, well organized, specific and detailed.
3.3.7 Suitability
Page | 9
4. Types of Testing
Testing is usually applied to different types of targets in different stages of the
software’s delivery cycle. The stages progress from testing small components (unit
testing) to testing completed system (system testing).
Unit test, implemented early in the iteration, focuses on verifying the smallest testable
elements of the software. Unit testing is typically applied to components in the
implementation model to verify that control flow and data flow are covered and
function as expected. These expectations are based on how the components participate
in executing a use case. The implementers perform unit test as the unit is developed.
The detail of unit test is described in the implementation work flow.
Page | 10
Acceptance testing is the final test action prior to deploying the software. The goal of
Acceptance testing is to verify that the software is ready and can be used by the end-
users to perform those functions and tasks the software was built to do.
In the introduction to Test, it was stated that there is much more to testing software than
testing only the functions, interface and response time characteristics of a target-of-test.
Additional test must focus on characteristics/ attributes such as the target-as-test:
• Integrity (resistance to failure)
• Ability to be installed/executed on different platforms
• Ability to handle many requests simultaneously
In order to achieve this, many different tests are implemented and executed each with a
specific test objective. Face focused on testing only one characteristics or attribute of
the large-of-test.
Often individual tests are categorized, implemented and executed in groups, most
commonly arranged by similarities in their test objectives or the quality dimension they
address, such as:
Page | 12
Page | 13
5. Test cases
A Test case a set of test inputs execution conditions and expected results developed for
a particular objective such as to exercise a particular program path or to verify
compliance with a specific requirement.
Unit testing is implemented against the smallest testable element(units) of the software
and involves testing the internal structure such logic and data flow and the unit function
and observable behaviors. Designing and implementing tests focused on a unit internal
structure relies upon the knowledge of the unit’s implementation (white- box approach).
The design and implementation of test s to verify the unit’s observable behaviors and
functions does not rely upon knowledge of the implementation and therefore is known
as black-box approach.
Page | 15
Page | 16
6. Finding Faults
It is commonly believed that the earlier a defect is found the cheaper it is to fix it. For
example, if a problem in the requirements is found only post-release, then it would cost
10–100 times more to fix than if it had already been found by the requirements review.
6.1 Testing Tools
Program testing and fault detection can be aided significantly by testing tools and
debuggers. Testing/debug tools include features such as:
• Program monitors, permitting full or partial monitoring of program code
including:
○ Instruction Set Simulator, permitting complete instruction level monitoring
and trace facilities
○ Program animation, permitting step-by-step execution and conditional
breakpoint at source level or in machine code
○ Code coverage reports
• Formatted dump or Symbolic debugging, tools allowing inspection of program
variables on error or at chosen points.
• Automated functional GUI testing tools are used to repeat system-level tests
through the GUI.
• Benchmarks, allowing run-time performance comparisons to be made.
• Performance analysis (or profiling tools) that can help to highlight hot spots and
resource usage.
A test specification is called a test plan. The developers are well aware what test plans
will be executed and this information is made available to management and the
developers. The idea is to make them more cautious when developing their code or
making additional changes. Some companies have a higher-level document called a test
strategy.
A traceability matrix is a table that correlates requirements or design documents to test documents. It
is used to change tests when the source documents are changed, or to verify that the test results are
correct.
The test script is the combination of a test case, test procedure, and test data. Initially
the term was derived from the product of work created by automated regression test
tools. Today, test scripts can be manual, automated, or a combination of both.
The most common term for a collection of test cases is a test suite. The test suite often
also contains more detailed instructions or goals for each collection of test cases. It
definitely contains a section where the tester identifies the system configuration used
during testing. A group of test cases may also contain prerequisite states or steps, and
descriptions of the following tests.
In most cases, multiple sets of values or data are used to test the same functionality of a
particular feature. All the test values and changeable environmental components are
collected in separate files and stored as test data. It is also useful to provide this data to
the client and with the product or a project.
6.3.6Test harness
Page | 18
Page | 19
Employee id - 202981
Nitesh Parashar
Software Testing 2023
7. Conclusion
Software testing is an art. Most of the testing methods and practices are not very
different from 20 years ago. Good testing also requires a tester's creativity, experience
and intuition, together with proper techniques.
Testing is more than just debugging. Testing is not only used to locate defects and
correct them. It is also used in validation, verification process, and reliability
measurement.
Testing is expensive. Automation is a good way to cut down cost and time. Testing
efficiency and effectiveness is the criteria for coverage-based testing techniques.
Complete testing is infeasible. Complexity is the root of the problem. At some point,
software testing has to be stopped and product has to be shipped. The stopping time can
be decided by the trade-off of time and budget. Or if the reliability estimate of the
software product meets requirement.
Page | 20
8. Bibliography
Books
✔ An Integrated Approach to Software Engineering by Pankaj Jalote
Websites
✔ www.4shared.com
✔ www.google.com
✔ www.scribd.com
✔ www.wikipedia.org
Page | 21