SE-200

Software Engineering
Dr. Qurat-ul-Ain
Recap
Meet customer’s
How will it do? changing need

Design & Validation Evolution

Specification
Implementation

What will system Does it do what

do? customers want?

2
Last Week!
❖ Development Testing
○ Unit Testing
○ Component Testing
○ System Testing
❖ User Testing
○ Alpha Testing
○ Beta Testing
○ Acceptance Testing

3
This Week
❖ Release Testing
○ Requirement-based Testing
○ Scenario Testing
○ Performance Testing
■ Load Testing
■ Stress Testing

❖ Test-driven Development
○ Regression Testing

4
Release Testing

5
Release testing
❖ testing a particular release of a system that is intended for
use outside of the development environment
❖ to convince the supplier of the system that it is good enough
for use
○ system delivers its specified functionality, performance
and dependability, and that it does not fail during
normal use
❖ Usually a black-box testing process (i.e. functional)
where tests are only derived from the system
specification
6
 Database, automation tester
Manual tester, network protocol
Operating system

Test data generator

Valid test data, invalid test data
No data, boundary data

https://www.lambdatest.com/learning-hub/release-testing
Release testing VS System testing
❖ Release testing is a form of system testing
❖ Important differences:
○ 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)

○ A separate team that has not been involved in the

system development, should be responsible for release
testing
8
Requirements based testing

❖ Requirements-based testing involves examining each

requirement and developing a test or tests for it
○ Requirements should be testable.
○ Set of test cases can be defined for each requirement.
○ This is validation testing.

9
Requirements based testing

❖ MentCare system requirements:

○ 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

10
Associated requirement tests (1/2)

❖ 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.

11
Associated requirement tests (2/2)

❖ 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. 12
Scenario Testing

❖A form of release testing whereby typical scenarios of use

are used to develop test cases for the system
○ Set of test cases defined for each user story.
○ Testing sequence of requirements.
○ User story should be credible and fairly complex.
○ Evaluations of user story should be simple.
○ It should be validation testing.

13
Scenario Testing : Reading

14
Scenario Testing : Example

15
Features tested by scenario

16
Performance testing

❖ Part of release testing may involve testing the emergent

properties of a system, such as performance and
reliability.
❖ Performance tests usually involve planning a series of
tests where the load is steadily increased until the system
performance becomes unacceptable.
❖ Combination of validation and defect testing.

17
Performance testing
❖ Tests should reflect the usage (“operational”) profile
of the system.

❖ Example: If 90% of the transactions in a system are of

type A, 5% of type B, and the remainder of types C, D,
and E, then you have to design the operational profile so
that the vast majority of tests are of type A.

❖ Theseoperational profiles are then testing with

incremental load strategy.
18
Performance testing
❖ Stress
testing is a form of performance testing where the
system is deliberately overloaded to test its failure
behavior.

19
Test-driven
Development
20
Test-driven Development (TDD)
❖ TDD was introduced in support of agile methods such
as XP. However, it can also be used in plan-driven
development process.

❖ Code is developed 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

21
Components of XP
User Stories

Planning Design

Software
Increment
Testing Coding

Acceptance Testing - Refactoring

- Pair Programming
-Testing 22
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.

23
TDD process activities

❖ Writea test for this functionality and implement this as an

automated test.

24
TDD process activities
❖ 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.
(Reinforces “test-first” mentality)

25
TDD process activities
❖ Implement the functionality and re-run the test(s)…
❖ Once all tests run successfully, you move on to implementing
the next increment of functionality.

26
TDD process activities
❖ This step involve refactoring existing code to improve it
and add new code to what’s already there.

27
Benefits of TDD

❖ better problem understanding

❖ Ifyou don’t know enough to

write the tests, you won’t
develop the required code

❖ Example: Division of two

integers

28
29
Benefits of TDD
❖ 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.
30
Benefits of TDD

31
 Test-first Development - Limitations

❖ Programmers prefer programming to testing and

sometimes they take short cuts when writing tests

❖ tests can be very difficult to write incrementally.

❖ difficult to judge the completeness of a set of tests.

32
Regression Testing

❖ Re-running of one or more test cases, after some program

change, that ran without revealing faults prior to the change
❖ It is used to determine if the changes have not ‘broken’
previously working code
❖ This can be expensive in a manual testing environment, but
automated testing, it may be possible to run all previous
(together with new) tests with each increment
❖ Tests must run ‘successfully’ before the change is committed

33
Applications of TDD

❖ Software with new codes

❖ Functions from standard libraries

❖ Reuse of legacy system

❖ Multi threaded system

34
Thanks!
Any comment/questions?

35