Day 1: (11.7.2011)

Introduction, Outlook, Basics of Software-Testing – up to Quality vs. Testing

Day 2: (12.7.2011)

Basics of Software-Testing – up to Fundamental Testprocess

Exercise: Checklist-Funktion (big Aha)

Day 3:(13.7.2011)

Fundamental Testprocess – Planning

Exercise: Getting all items together what has been considered when making a plan, prioritizing (2 teams)

Software Development Process

Day 4:(14.7.2011)

Agile Development, Comparison to Testing

Exercise: planning a time attendance application (3 teams: business domain, developers, testers)

Discussion about results, correction of misconceptions (concerning Scrum)

Day 5: 15.7.2011)

Conclusion of Planning, Start of  Testcase design by starting with usecases

Exercise: Meeting Culture ( one team, 2 times, different moderator)

Day 6:18.7.2011

Testcase design, Equivalence Classes, Boundary Values, IEEE-829

Start with use cases

Day 7:19.7.2011

Exercise: test case review (Why a given testcase is not a testcase)

Use cases

Exercise: write a test case (first try)


Use case writing (from lecture 11),

Exercise Brainstorming actors and goals, writing a primary use case list for project AS

Exercise: write a test case (second try)

Day 8:20.7.2011

Exercise: criticism (one talks, one criticizes, the rest of the group reviews interaction)

Exercise: write a test case (third try)

writing a use case for AS

Day 9:21.7.2011

Exercize Usecase

Testcases: Coverage

Founding of a test center


Day 10 to 15 : 22.7.2011 – 29.7.2011

Work exercises:

investigation and presentation about FIT

investigation and presentation about FITNESSE

investigation and presentation about SELENIUM HQ

primary JAVA (for the non-programmer)

Python-starter (use case editor)

Day 16: 1.8.2011

Presentations FIT, FITNESSE, Python-Experience

Report on JAVA progress

General presentation review

About usecases and classes

Day 17: 2.8.2011

Presentation SELENIUM

3 Phase Modell

Group 1: Exercise Presentation

Group 2: Python booster

Day 18: 3.8.2011

Exercise Presentation


Error reporting, Analysis

Day 19: 4.8.2011

Business applications – Insurance – functional tests

Business environments – how to behave

as a tester

as a consultant

as a colleague

presentation of exercise

Day 20 – 25 9: 5.8.2011 – 12.8.2011

to be defined

Day 26 – 30: 15. 8.2011 – 19.8.2011

actual testing in practice

planning, testcase creation, execution, reporting, analysing, repeating the cycle

role playing: developer, testmanager, testers, test automation



































































































I am currently putting my books in a catalog. From time to time I will extract lists ordered by themes.

Current bibliography is found here.

When I looked up Testing in Kruchten’s An Introduction to the Rational Unified Process, lately, I found a remarkable statement. A tester – out of all other persons concerned with the software development life cycle – possesses a distinguishable property. She is and has to be negatively biased. She is not striving for success but for destruction. At her best she will fail in crashing the program under test.
This behaviour appears to emulate people who tend to overly critisize. The are generally not well beloved.
In certain cultural environments that type of behaviour is also called “teacherlike”, which does not always denote a high respect for the person.
How should a tester then find pride in her work? The excuse that she helps to increase quality and/or decrease risk of failure – a very noble goal, indeed – will not carry sufficiently. Most people judge upon their first impression. That first impression is of someone who is a destroyer. Deductive reasoning will not change the primary emotional response.
Reading Kruchten I was remembered of a very important book. One of the most famous pieces of the German literature is Faust by Johann Wolfgang von Goethe. Here, the devil fights for the soul of the curious, but somehow ignorant scientist Faust who is in search for the universal answers.
Wenn Faust first meets Mephistopheles (a very refined projection of the devil) the dialog contains the following rhymes:


Who then art thou?
Part of that power which still
Produceth good, whilst ever scheming ill.

What hidden mystery in this riddle lies?
The spirit I, which evermore denies!
And justly; for whate’er to light is brought
Deserves again to be reduced to naught;
Then better ’twere that naught should be.
Thus all the elements which ye
Destruction, Sin, or briefly, Evil, name,
As my peculiar element I claim.

Originally in German:


Nun gut, wer bist du denn?

Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.
Was ist mit diesem Rätselwort gemeint?
Ich bin der Geist, der stets verneint!
Und das mit Recht; denn alles, was entsteht,
Ist wert, daß es zugrunde geht;
Drum besser wär’s, daß nichts entstünde.
So ist denn alles, was ihr Sünde,
Zerstörung, kurz, das Böse nennt,
Mein eigentliches Element.

I remember my reaction to Faust when I first read it. Faust seems a little bit naive in spite of all his doctorates. Mephisto (as he is called with his short name) seems to have an answer for every questions and certainly knows the human race and its weaknesses.

More can be learned by Mephisto than by Faust, especially when an avid reader also digests Faust 2, where some very interesting items about today’s economy can already be found. (Money waiting for the emperor in the mountains)

It is a complete different story why software programs must contain so many errors. Fortunately, we nowadays realize, that we can not trace errors entirely to sloppiness on behalf of the developers or the analysts.
Granted however, that we are likely to encounter a certain count of severe errors in a program I would rather ask Mephisto than Faust for help.

Spiritually speaking, there are good sides and bad sides within us. There is no better justification for genuine mischieviousness than becoming a very good tester. In that respect, the tester can be very proud of herself. She can live out her bad thoughts in contributing for a positive outcome.
She may produce good, while scheming ill.

Isn’t that a concludent reasoning in order to be proud to be a tester.

My enthusiasm about computers stems from reading science fiction literature when I was young. Isaac Asimov greatly influenced my opinitions. I took it for granted that the computer should serve men. And women. And I still believe in its virtue as a special kind of machine.

Maybe, this approach seems to be naive. Very often I had to question it. The persevering question still has no answer. Why can’t the computer solve our problems? Why do we complain that our requirements are not met?

If somethings reacts unexpectedly – in software – we consider it to be an error. Errors are a sort of currency when we deal with software testing.

Software testing is more than just “trying out whether it works”. What software testing is all about you will find in this blog. No not all about. I should not plagiate my teachers, my mentors. Much has been said already that I could only repeat.

You will rather find my personal flavour of software testing.

[about the author]

Sometimes I write in German, sometimes I write in English.

I will not translate everything that I have written in German to English. Some texts might appear only in the English section.

In the software business you are well advised, if you use English as lingua franca. Sometimes, however, you have to observe local peculiarities. Special ways to understand. Sometimes English words are used in the German language. However, they are used for different meanings. Those words are called “false friends”.

Very many problems in the software business stem from semantic misunderstanding. Problems might result in errors. And errors are the currency of software testing. Information about this you may expect on these pages. And maybe even some leftovers from software architecture.