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)
Testscenarios
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
Speak-exercises
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
Refactoring
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:
FAUST
…
Who then art thou?
MEPHISTOPHELES
Part of that power which still
Produceth good, whilst ever scheming ill.
FAUST
What hidden mystery in this riddle lies?
MEPHISTOPHELES
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:
FAUST:
…
Nun gut, wer bist du denn?
MEPHISTOPHELES:
Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.
FAUST:
Was ist mit diesem Rätselwort gemeint?
MEPHISTOPHELES:
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.
software testing and all the rest of 42 