Sponsors

Engineering logo

Bosch logo

Intland logo

RCP logo

BMW logo

Sigsdatacom logo

BSI logo

Microsoft logo

CAS logo

Andrena logo

bsi logo

OSBF logo

Open Source logo

Bredex logo

sopera logo

Microdoc logo

O'Reilly logo

Soyatec logo

compeople logo

itemis logo

dpunkt logo

Sontatype logo

Eclipsesource logo

sap logo

Xored logo

Oracle logo

Vogel logo

Actuate logo

"User" is not a four-letter word (sponsored by Bredex)

Hans-J. Brede (BREDEX GmbH )

Other / New & Noteworthy · Sponsored
Wednesday, 10:30, 25 minutes | Seminarräume 5

7
·
8
·
9
·
10
·
11
·
12
·
13
·
14
·
15
·
16
·
17
·
18

These days it seems all too easy to forget who we write software for. Amidst implementation details, architectural decisions and design concepts, the user who will eventually sit in front of the software tends to be ignored. Yet it is the user (or the customer) who makes the final decision about whether the software is acceptable; not only in terms of low amounts of errors, but also as a whole – does it do the job it was supposed to?

Given this fact, it is a shame that acceptance tests are often pushed further and further backwards in the release planning and are finally rushed through right at the end. This has two large disadvantages. First of all, the actual workflows the user stated in the requirements that he/she will perform daily aren’t tested until it is too late to change them anyway. Secondly, leaving acceptance tests until so late means that there is no chance for the user to easily change or adapt the requirements during the course of the project.

It would be much more beneficial to consider the software from the point of view of the user earlier on in the process and use this perspective as a yardstick for quality and development decisions. This generally requires changes to the development process as well as considerations of how to perform acceptance testing (manually or automatically).

This talk looks at what changes are needed (or useful) to make the user perspective the centre of the development process. We discuss how acceptance testing can be performed reliably, on time and with minimal wasted effort. The points of the talk are highlighted using examples from RCP applications where timely acceptance testing saved the team from errors, bad design decisions and customer confusion or rejection.

Introducing better acceptance testing into the team and process doesn’t have to be done in large jumps. Many of the suggestions made in this talk can be tried out individually to start to move processes to a more user-centric approach.