News | About | Projects | Contact
Browsing posts tagged with: Software Testing
last.fm and guerrilla testing
Informal testing sessions on the street, in cafe's (also called guerrilla testing, ghetto testing,...) are a great and inexpensive way to get valuable feedback from potential customers of your software. I wrote about the topic before here.

last.fm


One of my favourite websites last.fm is currently beta testing their next version and guess what they use guerilla testing to do so. Fortunately they also spread the word and write about it. So hop over to their blog and learn how they organize their testing sessions and how it works out for them.
QA = Quality Assistence
Cem Kaner on quality assurance:

"When I was hired at WordStar, back in 1983 (when WordStar was the top producer of word processing software in the world), the test group was called Quality Assurance. The company was attached to the label QA for testers, but as Testing Technology Team Leader, I was able to convince them to change the name, from Quality Assurance to Quality Assistance.

Quality Assistance--that's what testers do. We help. We investigate. We learn things. We report them clearly. We make sure that people understand what we have found and what its significance means. We provide the good data that is so important for understanding and improving the quality of the product. That's important, but it's not "quality assurance.""
from The Ongoing Revolution in Software Testing.

Look left


Kaner has a valid point with his argument. Somebody can only assure quality if this person has the necessary powers. However most tester will not be able to stop a release if the quality goal has not been met. Furthermore the word assistance lowers the tension between the developers and the QA group. Assisting somebody is about offering help and guidance which is completely different than what assurance stands for.
BOF on exploratory testing
I am happy to announce that I was accepted to do another BOF session after the one in Melbourne in June. This one has the title "Exploratory testing or ways to improve your manual testing skills..." and will be a part of the SDN Community Day in Munich on the 16th of October.

SAP TechEd '07: See you at Community Day!


Exploratory testing is an interesting topic. It is one of those activities which everybody is doing but nobody is aware of it and therefore it is hard to improve this skill. Usually I am more known for talking passionately about automated testing so it is nice to venture into different territory this time. So if you are interesting in learning something new about software testing attend my session. For all the people who cannot attend I will post all interesting resources here for review.
Testing on the toilet
Where is the best place to put information up for your fellow co-workers? The testing evangelists at Google discovered the toilet for promoting testing ideas. Check out Joe Walnes post here.


That's a pretty neat idea. The same guys also have a blog which covers a good range of testing topics. Have a look.
Thus spake the master...
My final thesis for my first University degree was about automated software testing and how it can be implemented at a company. While doing my literature review I stumbled across this beautiful Zen-like explanation why software will always contain bugs.

Thus spake the master: "Any program, no matter how small, contains bugs."

The novice did not believe the master's words. "What if the program were so small that it performed a single function?" he asked.

"Such a program would have no meaning," said the master, "but if such a one existed, the operating system would fail eventually, producing a bug."

But the novice was not satisfied. "What if the operating system did not fail?" he asked.

"There is no operating system that does not fail," said the master, "but if such a one existed, the hardware would fail eventually, producing a bug."

The novice was still not satisfied. "What if the hardware did not fail?" he asked.

The master gave a great sigh. "There is no hardware that does not fail," he said, "but if such a one existed, the user would want the program to do something different, and this too is a bug."

A program without bugs would be an absurdity, a nonesuch. If there were a program without any bugs then the world would cease to exist.

- Geoffrey James, The Zen of Programming