Author Archive

This is my backlog:

This is my “Done Bowl” (just emptied):

Sometimes if feels quite unstructured with all these sticky notes but there are some really great benefits

1. It’s easy to sort them into different groups and priority.

2. The really really urgent tasks I can put on my screen so I won’t miss it.

3. I don’t need my computer to write new tasks.

4. When I leave them on my desk I really do leave them so they won’t stress me.

5. They are really visual and the amount of tasks is really obvious as well.

6. Thanks to the “Done bowl” even the tasks that are done are really visible so they make me feel good and happy.

7. They make my life more colorful.

 

Don’t underestimate the power of sticky notes!

 

 

Software testing is not only about verifying functions. A system is so much more than functions, if it’s suppose to be useful anyway. The system has to live in a context and in a world with many different users with many different needs and behaviors.

 

There are many stakeholders, not only the end users. All these stakeholders have different requirements and wishes for what the system should handle or support. It can be deliverables or qualities that must be in the system to make it possible for these people to do their job. For example, if an operating technician should be able to maintain a good level of security there must be routines and support for back up. Taking new back up and restoring an old back up just have to work. These things are crucial for an operating technician while the market department hasn’t dedicated this even the slightest thought. The market department on the other hand, might be anxious about the coolness of what is delivered in the next version, so they can beat the market by surprise in their next press release. Yes, there are many different stakeholders and many different wishes.

Example of stakeholders and their requirements/wishes

 

How do we do to cover more than just functions?

 

First of all I think we have to look beyond requirements specifications, meet all the different stakeholders and discuss what’s important for them. There is a lot of support in lists of test types like performance test, load test, usability test, installation test etc. Collect a list of your own, with suitable test types and go through them for every project to determine which applies for the test object. My list, of absolutely necessary test types that should be included in almost every project, is:

 

–          Functional test

–          Usability test

–          Platform test

–          Security test

–          Access level testing

–          Performance test

–          Stress test

–          Stability test

–          Installation test

–          Recovery test

–          Storage test

–          Volume test

 

There might be other types of test that can be applicable depending on the project and system under test. There might also be the opposite, several of the test types mentioned above might not be applicable or require very little effort. Often this is related to time and money but also what is valuable to test. But, just by discussing an area you have lifted up the different qualities and then the project can make a decision whether the area should be tested or not.

 

When you come to the point where you have identified all stakeholders and their requirements and whishes, you probably have an enormous amount of work before you. To cover all is impossible and most likely not meaningful. Therefore, your next task, possibly even more difficult, is to prioritize. Whose requirements are the most important? We can look deeply into this but the thing I think is the most significant is to make sure you communicate a lot with all stakeholders.

 

Someone whose list is very long and full of details is Rikard Edgren. The last time I listened to him his list was 77 test ideas long. See http://thetesteye.com.

 

What does your list look like?

What smart test types do you have in mind and which to you think is absolutely necessary for most systems/projects?

 

 

Once upon a time there was this company who struggled with a poorly built system. Every day the users got more and more annoyed on the bad interface. One day enough was enough and the kind boss asked a prominent consultant to build them a new system. The developer consultant arrived with his shiny laptop and started working. It was not long before the consultant started to struggle. The environment and business logic turned out to be a lot more complex than he predicted and none from the company side could give him any straight answers on how things should work. After many weeks of swift coding the system was ready for the users to test. And once again the consultant was faced with the users’ unavailability.

It was time to call in a tester. The humble tester arrives and is quickly introduced to the system and the users. Only two weeks left until deployment and no tests run, the tester decided to use the users as testers. One by one the users were booked for an hour each. The tester arrives to the meeting with a few bullets that needs to be tested and tell the users to use real data when testing. The users slowly start to familiarize themselves with the system and a lot of feedback is recorded by the tester.

The developer is happy to finally receive feedback.

The kind boss is happy the quality will be improved.

The users are happy that their opinions are raised.

The tester is happy that the system has been tested, the users introduced to the system through coaching and that everyone now seems comforted that this new system will save their day.

I doubt 200 test cases could have done a better job in this case.

 

 

Do you need something fun for your test conference or need to cheer up your test team?

 

We are looking for new oppertunities to perform the “The Supertester – A Slightly True Story”.

 

The Supertester – A slightly true story” is a theater performance where we try to mix serious test issues and common prejudices with laughs. We will take the roles and personalities of project managers, testers and super heroes to a new level. We will use prejudice and radical opinions in our effort to entertain and inspire.

You will meet the project manager who blame the test department for everything that goes wrong. The project manager loves all the new and cool development methods. He is not making it easy for the poor shy little company tester who lost the last shred of self confidence the first day at work. Can she be saved by the magnificent Supertester and once again be restored to a strong tester who stand up for her profession? Will the powers of the Supertester be enough to save the organisation?

 

Join us in a twisted but still slightly true world of testing.

 

You can read more about the show under The Show.

If you are interested don’t hesitate to contact us at linda.hoff (at) gmail.com or anna.o.hoff (at) gmail.com

 

 

Enjoy!

http://www.eurostarconferences.com/content/supertesters.aspx

Is agile better than waterfall? Or is waterfall better than agile?

Well, it depends!

It depends on your organisation, your staff, your product, your previous methods and processes. If you are happy with your waterfall projects today, why change? If you already are efficient and have high quality, why change? Don’t try to squeeze Scrum into your organization just because you think it is cool and the only way of having fun at the same time as you are really efficient.

And before you dismiss Scrum and Agile be sure you really tried the true Scrum/agile. The Supertester has heard people say things like “We have adopted Scrum to our organisation by taking parts of Scrum. But Scrum is really frustrating and it doesn’t work for us testers.” How can this person know that Scrum doesn’t work when he/she haven’t tried Scrum the way it should be?!

There are pros and cons with both agile and waterfall. Please be open minded and try to see the whole picture!

The supertester couldn’t agree more:

Lisa Crispin on YouTube, Agile vs Waterfall

We all seen this picture:

… and we all know this is the truth and cruel reality. Or is it?

I’ve heard about companies that are concentrating on fixing bugs really fast when they are discovered by the end user, instead of trying to find them before production. How on earth could that save time and money?

Perhaps there are some products/system that are really easy to release. Then it might be possible. But what about the customer satisfaction? If I was the user and I found a lot of really serious bugs in my product I would be really angry, even if I got a fix just a couple of days later.

The company is relying on the end users to report the bugs and updating to a new version.

But are there any other better to test a product/system than the end users!?! They know what is really important and what is not. But still… how do you manage to keep the end users happy? I can only think of one situation where end users do the job and are still happy, and that is the game industry where there often are a lot of end users doing test on beta versions.

Is this a new trend? Will all testers be out of work? No, I don’t think so. There are a couple of products that this never will work on. For example, pacemaker. You can’t rely on the end user to report any bugs. They’ll never get the chance!

It is official, the supertesters love the EuroSTAR audience. For the second year in row we are treated with standing ovations. What can top that?

The Supertester is currently at EuroStar 2010 in Copenhagen.

The quote of today:

“Testig is lika a buffet, if you get the chance you will try all”
– Ruud Teunissen

Though, not too good for the figure! 😉
More posts from EuroStar will come. Stay tuned!