Happy testing? How maintain happiness in very hard times!

A good tester needs to be in a good mood to do a good job. I found out the hard way and I have to say that it is not easy to be happy when the hard times come.

The hard times:

In 2004 I created the company Testabil. This was my personal bet and I have always given all I have for the company. I was (and still am) happily married and have 6 daughters and the company was my only son.

Year after year the company was growing until at the end of 2010 beginning 2011 things started to turn. In one year I went from being the nice and popular boss to the worst and most despised boss.

I did not see that come as I was way to attached to my company (my son) and did not want to move out when it was needed to take a step back. I found out the hard way that trying to keep people happy is not always the best thing to do.

I tried to start in a testing job but I could not do a good job. I was too concerned, too stressed, too unhappy to be a good Test Manager/Lead and Tester. How can you plan and execute tests and find bugs if you are not in peace.

The change:

So there I found myself with no job (I resigned),  no money, no company, debts and people that turned their back on me. I was at a stage I only saw the black clouds be more and more dens and no sun close to shine a light. How could I be a good tester or sell a test service in that personal state?

I have looked down from my balcony various times but my family kept me from doing something stupid.

Finally I found my reply in prayer to Jesus Christ. I already was a believer, but I was not really dedicated. When I started praying I quickly got confirmation in the following Bible text:  Throw all your anxiety onto him, because he cares about you. (1 Peter 5:7).

Little by little I was able to do that and in return I received peace, patience,  good sleep, and happiness.

The future:

Thanks to God and my wife, dauthers and my parents (big thanks!),  I could start fresh and become a even better Test Professional I already was. You know why?  Because I found happiness and to be a good tester you need to be HAPPY!

Don´t I have hard times now? Yes, maybe even harder then before, but now I am able to put things in perpective.

My recommendation for you?

Well I found my way of releasing stress and finding peace and happiness to be a good tester. You have to find yours by yourself. If you need help, just write me..

It´s the end of the Test Manager and you know it…

It seems the Test Manager is a species in extinction. In the nineties and first decade of the new millennium a IT project without a Test Manager was not a project.
But things have changed in the past years. The fast upcoming of Agile as IT development strategy has made the classical Test Manager obsolete. The role does not exist anymore.

Does this mean that the Test Manager skill set is also obsolete?
I think that a good Test Manager should be a very good tester. Someone that has reported bugs from day one and still does. When is the last time you identified a bug? If you can´t remember you have a problem.
Maybe a lot of Test Managers have been really disguised project managers being “promoted” to Test manager.

Apart from that a Test manager should be a perfect facilitator and organizer as he has always been in the middle of projects, knows the technology and also the business needs.
I would therefor say a Test Manager should do very well as Scrum master.

My recommendation to the Test Managers is: Use your experience, sharpen your technical skills and get your hands into the testing.

It is not the end, it is just the beginning!

Planned Obsolescence Testing, do we really need to test??

Just some time ago I recovered my old super Nintendo. I connected it to the television, blew some air in the game and inserted the game in the slide. My kids and I started playing directly!
Still working and the games are still fun to play!
Imagine an old Ipad in 10 years? The thing probably won´t even start!

This is planned obsolescence.
Maybe the Nintendo example is not the best example as the games became obsolete. Although most of the games played at the moment on mobiles and (i)pads are still the same as then.

But I want to talk here about software testing and planned obsolescence. A lot of applications we test now are for temporary use. When you are testing they are already planning an improved version or an application that can replace the one you are testing.
As testers we have to make sure we know what the objective of the application is. What is the planned obsolescence time? Based upon that information we can create our testing strategy.

F.e. a new Ipad application is there to last maybe 3-6 months before the new version should make its way.

The application must run well, give the end user what they want. Running the basic functionality the user must be happy and want more. They probably except bugs in corner cases. Thanks to the bugs the user will even be encouraged to look out for the new version.
Our testing strategy must in this case be focused on testing the basic functionality and the performance of this functionality. It should work good, but not too good.
Remember how Google Chrome started, a simple browser but with a nice new functionality not yet available in the other browsers. The first version was full of errors, but the “customers” accepted this as they were focused on the new functionality not on the errors.
Is this planned Obsolescence? I believe so. They could spend more time making a better, more durable version but planned to make it obsolete in little time.
We as testers have to try to get into the minds of the decision makers. What is the planned obsolescence of the software products we have to test?
Some questions come up:
• Do we need to spend time and money on test automation on products with a planned obsolescence date?
• How far should exploratory testing go?
• Can quality standards and certifications like CMMi and ISO be used in the line of planned Obsolescence?
• What is the planned obsolescence date for Testers?

Outsourcing to Latin America the solution for Testing in Spain?

Something strange is happening in Spain. Everyone has probably seen the news and knows about the more then 5 million people without a job!!

But for Testing something else is happening? In 2011 more and more companies in Spain have requested Testing resources. Although a big percentage still is related to international companies also Spanish companies are requesting more and more Testers.

What are companies looking for:

Most companies are looking for “functional” testers with experience in a Test management tool (Quality Center/Testlink etc) and some automation skills with for example Selenium or Quick Test Pro.

The problem is that there are not so many people that have more then 2 years of experience and look for a job. Most of the resources with Testing skills are already employed. In the past year this situation has resulted in Job hopping, Salary increases and talent hunting. As the companies are in a urgent need they are willing to offer better salaries, although the rates that companies pay to consultancies have not really increased.

Currently there are still Testing requests but the market is somewhat stuck. All testers with some experience have a TestABil, Inqalabs, Sogeti, MTP past and have all a pretty well paid job. The rates and salaries cannot increase a lot so it is really hard to find  Testers.

In my opinion there are only 2 ways to come out of this situation:

1. Trainees/Juniors:

There are more then 5 million people without a job, a lot of them with academic titles. Consultancies and clients should agree on hiring trainees and give them good training and support. In my experience a well trained resource can after 2 weeks be operational as a funtional tester (manual) tester. This resource would need support and that is where the more experience testers come into the picture. After 6 months there will be a new generation of Testers and who knows some real talents will come out of that.

This although will mean an impact on the companies (people need time to get up to speed) and also the current (so popular) testers (the market will be less crazy and some new talents will come available).

2. Outsourcing to Latin America

The other option is outsourcing. There are still a lot of good testing resources available on the other side of the ocean and they are all willing to start. The benefits for the companies are clear (better rates, now worries about jobhopping, long term relation) but there are also counterparts (dependency, infrastructure, good support and communication needs).

In my experience it takes at least 2 to 4 weeks for an outsource tester to be up to speed. But they will bring already experience which a new tester will not bring.

Conclusion:

Although my preferred option would be 1 (Trainees)  I am afraid that spanish companies are not willing to invest (directly or indirectly) in training new Testers. The risk of training and coachin someone and loosing him without any recompensation are to high and the companies are not protected. In my experience, when we gave a ISTQB training to our people 50% got another job in less then 6 months (Who is paying the preparation cost).

Also the companies want results yesterday!

Also they are not willing to pay more and most of the Testers should be tired of jobhopping by now.

So on the short term the best solution would be outsourcing. This unfortunately will not help Spain unemployment…

 

Po Po Po Po POWER Testing

One our first employees is called Franklyn. He is from the Dominican Republic and started his testing carreer a bit more then 5 years ago with TestABil. Franklyn has been an boxer in his youth and also has a pretty good hit for baseball. He still is a baseball fanatic.

Over the years in various projects in TestABil he has created a very good sense for defects. He can smell them from a distance. Is he the most organised tester, no. Is he a automation crack, no. Franky is getting bored very quick if he has not shouted DEFECTAZO at least every 2 hours. He moves in his chair, clicks on back and forward buttons, refreshes the screen… he will get really nervous. He needs to put all his power on his test to push the bugs to light. In our Mantis defect metrics he is the absolute number one.

A short time ago we started a testing project for a new online database. In a few weeks time my team was very busy with writing and executing test cases. But… the number of defects was a bit low. The customer (at 800 km distance) was wondering why there were so few defects.

I explained that we were doing a full test and that we had a lot of test cases to do. But, as the customer wanted to know quickly if the provider had delivered a ´bug´ free product we had to do something. I proposed the customer that we could do a one day ´bug hunt´ without executing “formal”  testcases. They agreed as they quickly wanted to see some bugs.

I called in Franklyn for one day (he is in another project) to help.

The result:

• totally 78 bugs reported (70% severity major&crash), with step by step descriptions.
• We identified new possible test cases
• The team learned some test techniques in practice
• The customer happy because we could warn them on time.

The bug winner: Franklyn with 38 (among which 70% severity major & crash). So we heard more then 25 times “DEFECTAZO”  in one day!

The rest of the team was impressed and also learned some tricks from him.

They now call him the PO-PO-PO-PO POWER TESTER.

What kind of test is this: exploratory, well no, although we explored a lot we were to focussed on bugs, also it is done when you are already doing structured testing, we really could confirm that the reported bugs were bugs. Is it a bug hunt, well maybe, although I like the following term: POWER TESTING, a one day test execution using powerful test techniques to bring to light high severity bugs.

I believe this test is ideal for web sites that already are on the web. Or projects that have decreasing defect metrics. Just to see…what  you cannot see…

Power Testing

Organise your test – the bug tracker

The bug tracker is for me the most important tool in a Test Project.  When I start a new project the first thing I put in place is the bug/issued/defect tracker.  The issue tracker is the central place of a project. When you start to reviewing the project and you have doubts or issues. Raise a issue in the bug tracker. When you make the plan raise an issue.

In that way you easily log everything and reduce emails (you loose), numurous meetings without meeting minutes etc.

In my opinion the best tool is a web based tool that can be configured easily and is user friendly. I have used excel, Access, Traq, Jira, Bugzilla, Mantis and HQ Quality Center. But for me the number 1 is Mantis. It is so easy to use and to configure, has a nice user interface and has good reports. It is also a tool that can be implemented very easy.

I recommend to use as much as possible the standard configuration of the tool. It easy to add additional fields, but before doing that evaluate if those additional fields really add any value. Keep it simple.

When reporting try to make write clear summaries. Both for project related issues and for bugs/defects.

For example (bug summary): When logging in with an incorrect user name the error message is unclear.

Or for an (project) issue: The funtional documentation is not delivered on the agreed date.

It is important to set some clear rules, a defect/issue process, that need to be followed by the whole team. The main rule for me: Reporter of issues is responsible for closing the issue. When I say responsible it does not mean he has to close it him/herself, but at least be aware of who is closing the defect.

For more info on my favourite open-source defect tracker: http://www.mantisbt.org/