TDT 4242

Tor Stålhane

Course contentsThe course consists of two parts:• Requirements – a description of what we

shall develop: 11 lectures• Tests – a description of how we will

check that we have developed what the customer required: 19 lectures

The curriculum consists of

• A set of slides

• Copies of journal articles

Course grade

The course grade will be decided based on

• One group exercise on writing requirements – 10%

• One group exercise on writing a test strategy for a set of requirements – 10%

• One group exercise on testing a software package – 30%

• Exam – 50%

Lecture plan – 1 Mondays 12:15 – 14:00 in R41

Thursdays 12:15 – 13:00 in R91• First lecture – Thursday, January 9, 2014.• Last lecture – Thursday, April 24, 2014.• Exercise 1 – week 4.• Exercise 2 – week 7.• Exercise 3 – weeks 11 and 12. There will be no lectures during the exercise

periods.

Lecture plan – 2Week Course content

2

-

What you will learnPresentation of lecture plan and exercisesGoal oriented requirements specification Quality issues in requirements

3

Requirements elicitation with boilerplates (templates)On requirement – testability and traceability – 1

On requirement – testability and traceability – 2Intro. to exercise 1

4 Exercise 1 – Write a requirements specification

5Testing vs. inspection – strong and weak sides

Testing and cost / benefit analysis

6

Testing strategies – a general introduction

Black box vs. White box

Grey box testingIntroduction to exercise 2

7 Exercise 2 – Write a testing strategy for the requirements specification from exercise 1

8How to prioritize requirementsRequirements handling in COTS, Outsourcing, sub-contracting etc.Requirements in embedded and information systems

9Aspects, cross-cutting concerns and non-functional requirements Testing COTS, Outsourcing, sub-contracting etc.Presentation of the FITNESS tool

10

Domain testingCoverage measures Use of test coverage measures for code and requirementsIntroduction to exercise 3

11 Exercise 312 Exercise 3

13Requirements through user stories and scenariosHow to write good user stories and scenarios

14Advanced use casesTest driven development – TDD 1

15Regression testing Non-functional requirements – safety, user friendliness etc. Testing non-functional requirements

PlagiarismPlagiarism • means that you publish other people's work as your

own. • is regarded as cheating and is strictly forbidden.• results in you failing your exercise and that you may

be expelled from the university for a longer or shorter period.

It is not allowed to either copy from books, articles, nor to use the “cut and paste” method with electronic resources (e-books, electronic articles, the Internet, etc) without writing where you found the information, that is - referring to the source.

Deadline for exercisesAll exercises will have a deadline for delivery.

This deadline may only be exceeded after agreement with the

• course responsible – lecturer • teaching assistant

If no such agreement exists, we will deduct 5 points on the grade for any obligatory exercise for each week it is delayed.

Main theme

The main message of this course is that requirements and tests are two sides of the same coin.

• Requirements without tests will be ignored.

• Tests without requirements are meaningless.

The need for traceability

It must be possible to trace– From test to requirement. Why do we need

this test?– From requirement to test.

• Where is this requirement tested?• Staus: How many of the tests for this requirement

has been executed successfully?