Fee or Free

Why is it that, with so many free tools out there to do the jobs that we do everyday, that we still feel the need to fork out money, on tools that cost alot of cash?

For example: where I work for me to do my job according to the coorporate policy, my collegues and I need to be able to use the following tools

Web King
Mercury Quality Center
WinRunner

Not to mention all the programming tools and standard Microsoft functionality.

Do we really need all of these tools? The simple answer is NO.

Large organisations go with the well known pay for tools and this is why:

1. They have a reputation for quality so little work is required to confirm it will work.
2. Training can be easily obtained.
3. Support is readily available.
4. A tool is likely to continue to be provided and not be dropped.

For a small flexible organisation on a lower budget however the free tools are ideal and all it will take is a little research.

Priorities really?

Well, I know how to use priorities and assign them in my testing. It allows me to be able to structure the coverage that i will give based on the time and resources that are available.

It has struck me looking around that their seems to be alot of people that dont do this either because they dont know or dont see the reasons for doing this. So although I am definatly not the expert on this I thought I would list a few reasons why I think that prioritising is important.

1. Test scenarios with priority can be placed before stakeholders to decide exactly what needs to be covered and what can be left out. This can be done before any real outlay is made.
2. When testing gets crunched as it always does.. rather than struggling to cover everything in to little time, you can say "we will only be able to cover priority 1 and 2 tests in the time available as per the time scales we have already provided".
3. Tests with high priority can be executed where possible first to maximise effectiveness.
4. In large groups it can be made clear to everyone what order script production and test execution needs to be performed.

This is just to name a few things I have thought of off hand ... on a saturday night with a beer in one hand and fork of chicken fried rice in the other.

Testing is easy

Would like to think that this is true.. but it just isnt as you are reading this you will know how much hard work it can be to do testing. We dont just get a new product, mess about with it then say "yea go for it, looks good to me".

Based on requirements we plan all of our testing to be the most effective in the time that is available. We know what to expect and what is acceptable often before we have even seen the system and in a very short space of time provide a method to assess the quality of the system.

I do find that many of the people that I have touched in my job come to understand how much is involved and soon change their minds. So just why do people assume that testing is easy.

Consultants in testing

I like consultant testing staff but a few things that I have found that can be issues are:

1. Make sure that the experience matches what has been stated in CVs.
2. Consultants should be managed closely to ensure they are conforming with any corporate practices.
3. Often people within a company will assume specific business knowledge not possessed by an external consultant. Assistance should be provided to fill in this knowledge gap.
4. Consultants cost more than internal staff so should be sought with a specific purpose in mind.

New Issues of Testing Experience Magazine

Here is a great free magazine.. no I aint getting any cash for saying this it really is a good source of free information. You can subscribe or view the magazine online below

http://www.testingexperience.com/

I get the printed version myself cause i like to read it while travelling.

SIGIST Conference

For those that dont know SIGIST = Special Interest Group In Software Testing.

Just thought I would say that there is a conference for this coming up in london on the 18th September. If you look closely you might even notice me there.

if you want some more info on this
http://www.bcs.org/server.php?show=nav.9264

Unit Testing

Last week I was working on a project where the unit testing had been done by the developers. Trust me that is rare not only had they done this fairly completely in a tracable manner but they had records of it all. Suffice to say that I was very impressed.

Time being short we gave our testing estimates and it clearly wouldnt meet the deployment dates so we brazenly said for this to be tested it will need to be delayed... did they delay it ... no they took the risk to put the software in anyway. Further they also declaired that user acceptance testing was not required.

I being a pain took it upon myself to smoke test it. Within the first 30 minutes of trying to run the software it was clear it wouldnt even run in the environment. Funny thing is when it finally was working we found a unit test defect.

Guess my point with this is back to basics really.. a developer shouldnt test there own software and independant testers will uncover far more defects with a system as they are looking for problems not just checking it works.

Evidence Evidence Evidence

When you are testing a system of any kind something that you must maintain for everything is evidence. This is like the holy grail of testing.

For planning you need a record of:

• What you are testing?
• What steps you are running?
• Why you are testing?
• What order they should be run in?
• What inputs and outputs are expected?
• Who is testing what?
• How many resources?
• When to start testing?
• When to stop testing?

and many more things..

for execution you need a record of:

• Has entry criteria been met?
• What succeeded and failed?
• What tests were run?
• What defects were raised?
• How long it took?
• Current progress
• Has exit criteria been met?

We need this to be able to:

• Provide informed opinions on the quality of a peice of software.
• To display value for money of the testing process (it pains me that we would ever need to prove this... but keeps me on my toes.)
• To feed back traceable defects for correction by the rest of the development team.
• To be able to prioritise and organise a workable solution within time and budget.

etc..

but what really gets me going is that all this is required by testing.. so why is it that requirements gathering and the system development itself is allowed to relatively escape producing the same kind of documentation and accountability is always placed firmly at the testers door.

Weekends

Isnt it funny how I have been working all week planning, designing and executing tests and all that I can think of is more about work. No I dont mean to say that i am not having great fun playing with my daughter and living life up. I however have work floating in the back of my mind all the time.

It seems that when I was a developer I was forced to leave alot of my work in the work place. For testing it seems I find myself challenging everything. Even when I browse the web I find myself looking for the mistakes others have made and looking for better ways to do the smallest of things.