The post http://www.developsense.com/blog/2010/11/context-free-questions-for-testing/ contains a list of very good questions related to any project, even for people who don’t use  any particular approach in testing.

I will try to go over some of the most relevant to me for now and comment/give answers on it.

Is it okay if I ask you questions?

It is an important part in the beginning of a project to know to whom you ask the questions. Its a moment also where someone can be reluctant in having the courage to ask it, but can have a greater impact later.

Who is my client?

This is again a critical one. I think you need to be able to separate and clarify who is the client. Is it your boss or someone upper?  Because you can have a bad lead than can block you to bring value to your real client and eventually you might pay for it.

What is my mission?

You need to find or define your mission. If you have experience is much more easier. But still the difficulty of a project might come from lack of information or other thing that you haven’t experienced so far. You might need also to ask a lot of question to define your mission.

Has anyone else tested this?

This is one of those questions that are necessary. But is also a question that will trigger the need of other questions since in a product is not easy to delimit a certain area, without having in mind interactions with other components.

What equipment and tools are available to help with my testing?

Special software needs more than a simple PC to test it. So the value of the testing done will depend a lot of the tools/equipment used.

All the questions in the list are great and most of them  are asked by testers subconsciously.  But for improvement we need to bring this to the surface.

In an application or a system there will always be boundaries.  For example a computer will not run for 1000 years continuously without any problem. When uploading a file there will be an accepted limit for its size. When sending a text message there will be a limit. Every functionality, size, property will have a limit created by an adjacent functionality, size or property. Adding a 10 TB attachment to an email is failing because of buffer limit used to read the data or because  account is limited and total size is less than the attachment etc.

So the limit will always exist for a certain size or type or value. The idea is to find the limit.

A lot of boundaries are not relevant or feasible to take in consideration or  try. For example heating a useful PC in an oven to check when it will stop working properly. But even in this case such information, without the hassle of course , would be useful.

In many situations is possible to check the relevant limits, either directly or by scripting. Some of them are already validated (you have to test that to make sure) like “The size of the image must be under 700 KB”. Finding the limit will not mean always finding a bug where the application crashes, but it will give you information about the system.

Having the limits of the system will help having a better map of the application in our mind.

Now going to a specific functionality and using boundary testing on it, its a science in itself. And a valuable test approach I think will need the exact context.

Connecting boundaries and negative scenarios (I call this way the scenarios where the application fails) can be done in 3 steps:

1. Make a list of the boundaries that can change the behavior of the application: username after a certain size, traffic too high, traffic too low (you need the context to make the list)
2. Go then through every item of the list and imagine a situation related to that limit where things can go wrong. Not to be pessimistic but to avoid bad things to happen before it gets to the client. For example application is storing some data. The negative scenario is that the disk will become full after a while.
3. The last step is a complex one where you are now able to connect more dots ( the real ones and also the imagined ones) and you can derive a lot of other scenarios. You can gather info on the application. Finding bugs and negative scenarios increase motivation and productivity because there is a purpose involved. As opposed to just navigating without direction in the application. The probability to find critical issues is also higher.

I participated in EWT 37.

EWT is the European chapter of the Weekend Testers. Its two hour testing sessions every weekend, setting new challenges each week to enable attendees to practice their skills in a safe and friendly environment, to try out new approaches, and most of all to have fun sharing knowledge and ideas with other participants. Find out more at http://weekendtesting.com or follow @europetesters on Twitter.

The applications most of the time are very simple, because the purpose is to check approaches, to explore, to determine patterns.

This time the application was http://uk.download.yahoo.com/ne/fu/dodge.html and made two very short videos on using it – once editing the JavaScript to cheat.

and the next one is showing record time, but after JavaScript tinkering:

1.Database gets full, which can cause bigger problems: application crash, data loss etc.

2.Hard disk is getting full and its not monitored for that.

3.Network disconnects combined with lack of resuming functionality: for example downloading a large application that takes time is interrupted.

4.Memory crash.

5.Power off – electricity down, hardware getting old, processor heating etc.

6.As a problem of long duration I am listing software getting old – because it can affect the business and a bug is something that reduces the value of the application.

7.Competition may appear that creates the need of better software and reduces the current one.

8.Software can become obsolete – there is no practical need for it anymore.

9.Software becomes incapable of satisfying the needs of  increasing number of users.

10.Lots of issues that couldn’t be predicted in design process.