Ch8b_Testing.pdf - software testing course

Chapter 8 – Software Testing contd.
Chapter 8 Software Testing 1
3/13/2024
Note: These are a slightly modified version of Chapter 8 slides available from the author’s site

Stages of testing
Typically, a commercial software system has to go through
three stages of testing:
 Development testing, where the system is tested during
development to discover bugs and defects.
 Release testing, where a separate testing team test a
complete version of the system before it is released to
users.
 User testing, where users or potential users of a system
test the system in their own environment.
3/13/2024

Testing Stage 1: Development testing
 Development testing includes all testing activities that
are carried out by the team developing the system.
 There are three stages of development testing
▪ DTSA Unit testing, where individual program units or object
classes are tested. Unit testing should focus on testing the
functionality of objects or methods.
▪ DTSB Component testing, where several individual units are
integrated to create composite components. Component testing
should focus on testing component interfaces.
▪ DTSC System testing, where some or all of the components in a
system are integrated and the system is tested as a whole.
System testing should focus on testing component interactions.
3/13/2024

DTSC System testing or Integration testing or
Interaction testing
 System testing during development involves integrating
components to create a version of the system and then
testing the integrated system.
 The focus in system testing is testing the interactions
between components.
 System testing checks that components are compatible,
interact correctly and transfer the right data at the right
time across their interfaces.
 System testing tests the emergent behavior of a system.
▪ Some system functionality and characteristics only become
obvious when you put the components together.
3/13/2024

System and component testing
System testing obviously overlaps with component testing, but
there are two important differences:
 During system testing, reusable components that have
been separately developed and off-the-shelf systems
may be integrated with newly developed components.
The complete system is then tested.
 Components developed by different team members or
sub-teams may be integrated at this stage. System
testing is a collective rather than an individual process.
▪ In some companies, system testing may involve a separate
testing team with no involvement from designers and
programmers.
3/13/2024

Use-case testing
 The use-cases developed to identify system interactions
can be used as a basis for system testing.
 Each use case usually involves several system
components so testing the use case forces these
interactions to occur.
 The sequence diagrams associated with the use case
documents the components and interactions that are
being tested.
3/13/2024

Collect weather data sequence chart
3/13/2024

Test cases derived from sequence diagram
 An input of a request for a report should have an
associated acknowledgement. A report should ultimately
be returned from the request.
▪ You should create summarized data that can be used to check
that the report is correctly organized.
 An input request for a report to WeatherStation results in
a summarized report being generated.
▪ Can be tested by creating raw data corresponding to the
summary that you have prepared for the test of SatComms and
checking that the WeatherStation object correctly produces this
summary. This raw data is also used to test the WeatherData
object.
3/13/2024

Testing policies
 Exhaustive system testing is impossible so testing
policies which define the required system test coverage
may be developed.
 Examples of testing policies:
▪ All system functions that are accessed through menus should be
tested.
▪ Combinations of functions (e.g. text formatting) that are
accessed through the same menu must be tested.
▪ Where user input is provided, all functions must be tested with
both correct and incorrect input.
3/13/2024

Test-driven development
3/13/2024

 Test-driven development (TDD) is an approach to
program development in which you inter-leave testing
and code development.
 Tests are written before code and ‘passing’ the tests is
the critical driver of development.
 You develop code incrementally, along with a test for that
increment. You don’t move on to the next increment until
the code that you have developed passes its test.
 TDD was introduced as part of agile methods such as
Extreme Programming (XP). However, it can also be
used in plan-driven development processes.
3/13/2024

3/13/2024
The fundamental TDD process is shown in Figure below. The steps in the process are as follows:

TDD process activities
 Start by identifying the increment of functionality that is
required. This should normally be small and implementable in
a few lines of code.
 Write a test for this functionality and implement this as an
automated test.
 Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
 Implement the functionality and re-run the test.
 Once all tests run successfully, you move on to implementing
the next chunk of functionality.
3/13/2024

Benefits of test-driven development
 Code coverage
▪ Every code segment that you write has at least one associated
test so all code written has at least one test.
 Regression testing
▪ A regression test suite is developed incrementally as a program
is developed.
 Simplified debugging
▪ When a test fails, it should be obvious where the problem lies.
The newly written code needs to be checked and modified.
 System documentation
▪ The tests themselves are a form of documentation that describe
what the code should be doing.
3/13/2024

Regression testing
 Regression testing is testing the system to check that
changes have not ‘broken’ previously working code.
 In a manual testing process, regression testing is
expensive but, with automated testing, it is simple and
straightforward. All tests are re-run every time a change
is made to the program.
 Tests must run ‘successfully’ before the change is
committed.
3/13/2024

Release testing
3/13/2024
Testing Stage 2:

Release testing
 Release testing is the process of testing a particular release
of a system that is intended for use outside of the
development team.
 The primary goal of the release testing process is to
convince the supplier of the system that it is good enough
for use.
▪ Release testing, therefore, has to show that the system delivers its
specified functionality (functional testing), performance and
dependability, and that it does not fail during normal use.
 Release testing is usually a black-box testing process
where tests are only derived from the system specification.
3/13/2024

Release testing and system testing
 Release testing is a form of system testing.
 Important differences:
▪ A separate team that has not been involved in the system
development, should be responsible for release testing.
▪ System testing by the development team should focus on
discovering bugs in the system (defect testing). The objective of
release testing is to check that the system meets its
requirements and is good enough for external use (validation
testing).
3/13/2024

Approaches to Release testing
 Requirements-based testing
 Scenario testing
 Performance testing
3/13/2024

Requirements based testing
 Requirements-based testing involves examining each
requirement and developing a test or tests for it.
 Mentcare system requirements that are concerned with
checking for drug allergies:
▪ If a patient is known to be allergic to any particular medication,
then prescription of that medication shall result in a warning
message being issued to the system user.
▪ If a prescriber chooses to ignore an allergy warning, they shall
provide a reason why this has been ignored.
3/13/2024

Requirements tests for Mentcare system
 Set up a patient record with no known allergies. Prescribe medication for
allergies that are known to exist. Check that a warning message is not
issued by the system.
 Set up a patient record with a known allergy. Prescribe the medication to
that the patient is allergic to, and check that the warning is issued by the
system.
 Set up a patient record in which allergies to two or more drugs are recorded.
Prescribe both of these drugs separately and check that the correct warning
for each drug is issued.
 Prescribe two drugs that the patient is allergic to. Check that two warnings
are correctly issued.
 Prescribe a drug that issues a warning and overrule that warning. Check
that the system requires the user to provide information explaining why the
warning was overruled.
3/13/2024

A usage scenario for the Mentcare system
3/13/2024 Chapter 8 Software Testing 22

Features tested by scenario
 Authentication by logging on to the system.
 Downloading and uploading of specified patient records
to a laptop.
 Home visit scheduling.
 Encryption and decryption of patient records on a mobile
device.
 Record retrieval and modification.
 Links with the drugs database that maintains side-effect
information.
 The system for call prompting.
3/13/2024

Performance testing
 Part of release testing may involve testing the emergent
properties of a system, such as performance and reliability.
 Tests should reflect the profile of use of the system.
 Performance tests usually involve planning a series of
tests where the load is steadily increased until the system
performance becomes unacceptable.
 Stress testing is a form of performance testing where the
system is deliberately overloaded to test its failure
behavior.
3/13/2024

User testing
3/13/2024
Testing Stage 3:

User testing
 User or customer testing is a stage in the testing process
in which users or customers provide input and advice on
system testing.
 User testing is essential, even when comprehensive
system and release testing have been carried out.
▪ The reason for this is that influences from the user’s working
environment have a major effect on the reliability, performance,
usability and robustness of a system. These cannot be replicated in
a testing environment (Why ?).
3/13/2024

Types of user testing
 Alpha testing
▪ Users of the software work with the development team to test the
software at the developer’s site.
 Beta testing
▪ A release of the software is made available to users to allow
them to experiment and to raise problems that they discover with
the system developers.
 Acceptance testing
▪ Customers test a system to decide whether or not it is ready to
be accepted from the system developers and deployed in the
customer environment. Primarily for custom systems.
3/13/2024

Agile methods and acceptance testing
 In agile methods, the user/customer is part of the
development team (as an alpha tester) and is responsible
for making decisions on the acceptability of the system.
 Tests are defined by the user/customer and are integrated
with other tests in that they are run automatically when
changes are made.
 There is no separate acceptance testing process.
 Main problem here is whether or not the embedded user is
‘typical’ and can represent the interests of all system
stakeholders.
3/13/2024

Key points
 Testing can only show the presence of errors in a
program. It cannot demonstrate that there are no
remaining faults.
 Development testing is the responsibility of the software
development team. A separate team should be
responsible for testing a system before it is released to
customers.
 Development testing includes unit testing, in which you
test individual objects and methods; component testing
in which you test related groups of objects; and system
testing, in which you test partial or complete systems.
3/13/2024

Key points
 When testing software, you should try to ‘break’ the software by
using experience and guidelines to choose types of test case that
have been effective in discovering defects in other systems.
 Wherever possible, you should write automated tests. The tests are
embedded in a program that can be run every time a change is
made to a system.
 Test-first development is an approach to development where tests
are written before the code to be tested.
 Scenario testing involves inventing a typical usage scenario and
using this to derive test cases.
 Acceptance testing is a user testing process where the aim is to
decide if the software is good enough to be deployed and used in its
operational environment.
3/13/2024

➢ As I have done in the previous chapters covered in this
textbook, provide me with a graphical summary of the
Software testing chapter.
3/13/2024 Chapter 8 Software Testing 31
Critical Reading Exercise

Other Business
➢ AWS Jam – East Preliminary Competition
➢ Participation is limited to the first 100
registrants, so don’t wait to register!
➢ Date: Wednesday, March 19th
➢ Time: 10:00am – 2:00pm (ET)
➢ Register Here
➢ https://cvent.me/xANqBr

Other Business
➢ Industry Tech Talk 2 (Coming Soon !!!)
➢ Tuesday, 4/1/2025
➢ Topic: Software Engineering and Life at IBM
➢ Speaker: Prince Njoku, Software Engineer at
IBM
➢ Student Logistics Lead: Grace & Sienna
➢ Possible light Refreshments

Other Business
➢ AWS STJ Developer Challenge
➢ Powered by CodeSignal
➢ Date: April 17th 2025
➢ Time: 2:00pm – 4:30pm (ET)
➢ Platform: Webex
➢ Format: 2.5-hour event including a 70-
minute coding assessment
➢ Register by April 15th
➢ Register Here!

Other Business
➢ LeetCode Study Sessions
➢ Meeting Time: 2:00pm – 3:00pm (Friday’s)
➢ Meeting Room: SCI Rm 236
➢ Prior Experience in Coding is not required
➢ Sign Up Here
➢ Benefits:
➢ Practice common algorithm and data structure questions.
➢ Improve your problem-solving abilities.
➢ Learn different approaches to tackling coding challenges.
➢ Collaborate and learn from your peers
➢ Safe space for ALL students
➢ Informal: For the student, by a student
➢ Organizer: Onyedikachi Kanu
➢ Previous Intern at Amazon Web Service (AWS) (2023, 2024)
➢ Incoming Intern at Netflix, Summer 2025
➢ Faculty Coordinator: Dr. Tawose

Important Dates
➢ Course Evaluations
➢ Open period: March 31st, 2025 – April 21st, 2025
➢ Group SE project presentation / demonstration and
source code submission
➢ Date: April 15th, 2025 (Tuesday)
➢ Time: During normal class time (No extensions)
➢ Final Exam (covers all) – Don’t plan travel on exam day
➢ Date: April 24th, 2025 (Thursday)
➢ Time: 3:30pm – 5:30pm
➢ Group SE project final report submission
➢ Date: April 25th, 2025 (Friday)
➢ Due Time: 8:00pm (No extensions)
Advice:
Start Reading for Exams Now !!!
Avoid Paralysis by Analysis

Avoid This
:
Paralysis by
Analysis
Remember the tips for achieving an ‘A’ grade from slide
of our first class
Start reading early for clear understanding and to avoid
seeing the material to include overwhelming contents

Ch8b_Testing.pdf - software testing course

More Related Content

Similar to Ch8b_Testing.pdf - software testing course (20)

Recently uploaded (20)

Ch8b_Testing.pdf - software testing course