Archive for the ‘Test general’ Category

 

I often hear that testers are a whining type of people. One of my Swedish testing colleagues, Jörgen Damberg, wrote an article with the title “The whiners who became a profession” (http://www.idg.se/2.1085/1.426822/gnallspikarna-blev-ett-yrke). And I often feel like I’m whining. For a long time I saw this as something good. I chose to see it as we found things, issues, to lift up. I chose to see it like we were never afraid to speak our mind. All this is something good.

During my years in the testing business I met some not so good testers. And to be honest, they can whine in ways that are not positive in any way. One can whine and one can whine. There is a huge difference.

Let me explain what kind of whining I’m thinking about. I’m not saying this is a complete list. This is the list of things I have faced from time to times.

Whining with no progress

Something is not working or it might be someone else’s outdated test case or a test environment or your computer or instructions or the sink in the bathroom or anything. You are whining about it, loudly, to everyone except the one that can help you with the problem. Your whining will do NO good. Your problem will not be solved, you and your surrounding will only be more miserable, since your whining is contagious.

 

To get some progress, one has to whine to the person who can solve your problem/issue. If that person doesn’t do anything about your problem you have to remind her/him. You have to continue whining, otherwise there will be no progress. You have to run that outdated test case, you have to use that test environment, you have to use your computer, you need to follow those instructions, you have to wash your hands after doing your needs in the bathroom. You are suffering from the problem/issue so you have to make sure it’s solved but it might not be you who can fix it.

Whining with no alternative solution

You are working with something you don’t like. You don’t think it brings value. You feel like you are wasting your time and the company is focusing on useless stuff. Your manager or test leader tells you to do ridiculous stuff that you don’t understand. The amount of administration and documentation is huge and no one ever reads it. This is probably something we all experienced and that’s fine. What’s not fine is when your manager asks why you think it’s unnecessary and what your suggestion is and you have no answer. You just shrug and ramble something about it just feels unnecessary and boring. This whining doesn’t take you or your company forward. It doesn’t add any value but it will probably make your manager and test leader ask about your opinion more seldom. They will probably stop listen to your whining and it will definitely make your surrounding more miserable.

 

If you are not satisfied with something, make sure you understand why and think about a solution that could make things better. If you really do this well, I see two possible outcomes; You will understand that this way of doing things might not be that bad and perhaps it already is the best solution. Or you will have a really happy manager and/or test leader that got some really good suggestions of how to improve things. Managers and test leads are often thinking a lot about these things. To have team members that are thinking in the same direction and bring constructive improvements suggestions, that’s a dream team. Okay, there might be a couple of lousy managers and test leaders that are not susceptive to these kinds of suggestions and discussions, but then you can start whining about that (to the person who can solve that issue).

Whining with no proof

There is this bug, it’s very basic and it should work. You are really tired of this bug and it’s kind of serious. You are writing a bug report with a lot of whining. You think the developers made a lousy job introducing that bug and it should be found in unit test. Since it’s so basic you are not adding too much information in the bug report. Some vague steps how to reproduce, no logs, no screen shots. The developer who receives the bug report is not able to reproduce the bug and gets angry about your whiny tone the bug report and lack of information, so she/he tries to close it. The bug might be shuffled back and forth without a constructive communication. It turns out that you’ve been running the test in a production environment and the developer run the same test in her/his local development environment and the bug only appeared in a production environment. This whining doesn’t help anyone. You will probably get a tense relationship with developers since they feel unjustly attacked. No one wants your bug reports and no one wants to communicate with you.

 

If you want to whine, make sure you have reasons to whine and show them to the person you are whining to. If you just attached a video in your bug report showing the bug, the developer would probably be sure the bug existed. Then the question would be what the difference is between your ways of testing and not whether the bug really exists or not. This is a much more constructive discussion. If your whining is about testing tasks that takes long time to perform in relation to the value it brings, why not measure exactly how long time it takes. Present that to your manager/test leader and add information about what you could have done during that time that would have given you much more value. It’s all about proofs. And to be a really good tester you have to prove in what scenarios a bug exists and not. This ability to prove things is useful in a lot of situations.

 

 

But, now I will contradict myself and this blog post. There are times when I think it’s ok to whine in all the ways I just described. The testing profession is sometimes hard. We are seeing a lot of stuff that doesn’t work, test environments are often not easy to handle, our deadlines are often tight, and we are often pushed by quality gates, developers, project managers and other stakeholders in different directions. Sometimes we are just full of feelings like frustration, annoyance and we might be angry. Then, it might be ok to just let things out… to just blow off some steam… whining about everything and everyone, preferably to a close colleague or the closest test team. You probably don’t mean even half of what you are whining about and you don’t want to take any action on any of the issues and you don’t think it’s important enough for anyone else to take action either. This is totally fine, as long as everyone in your surrounding understands that this is your “whining session without substance”. It will take a couple of minutes, it will stay between you and the other participants and it won’t happen every day. Everyone will nod in recognition; say a couple of encouraging words and you will start feeling much better and relieved.

 

So, there is a difference between whining and whining. If you want to whine, do it in a professional way!

 

 

I tried a couple of ways of doing “testing days” or really focused testing sessions. The common denominator might be that testing should be done really focused under a short time period. Administration and planning are done to a minimum and bug reports is often enough as documentation once the testing is done. The expectations are usually that a lot of issues will be found that the usual, often requirement focused testing with few testing opportunities, won’t find. Let’s leave this for now… what I want to write about is that I’m starting to find a way of doing this that I really like.

In my example I will tell you how I and one other person (a project leader) did one of these testing sessions. We tested an application, available for both Android and Iphone, which I knew almost nothing about. Let’s call the application “AppX”. What I will show you below is what we did but I changed it a bit to anonymise the application.

 

We spent 2 hours like this:

• 15 min test planning
• 1h 25 min testing
• 20 min test reporting

 

The goal was to test as much as possible and to find as many critical bugs as possible. All testing should be visualized as much as possible, in test logs, notes, pictures etc.

The result was 15 new bugs and this is what it looked like:

 

What we did?

 

The notation I used:

 

I really like this way of working. Why don’t you try it!?!

 

 

“Technical tester”, “Automation Expert” and “Test Engineer” are sought after skills. Everyone wants them, everyone needs them. We go from heavy manual tests in waterfall projects to Agile development with rapid and automated testing. In the agile world the test cycles becomes more frequent and the regression tests really heavy since they need to be run more often. This requires a lot of manual testers or automation. The automation itself makes the tests become more technical. The number of testing tools is increasing, but they also increase in complexity. We can record all types of protocol language, we can, with a little fix in the script code, manipulate our test case to be something completely different. We have well thought structures for automatic verification where modules are reused. We feed the test tool with generic test data, etc.. This requires an entirely different kind of knowledge and experience than the tester who grew up with manual click-step-by-step tests.
The knowledge about testing is more spread and people understand that it is important and want to go for it. This is of course great and after striving for this for years, it feels good when things are finally happening. But “people” are often managers, project management, or similar, that primarily have been, and are, focused on development. This makes it easily to focus on building something smart, efficient and ­– that’s right, automated. But there are very few good testers to come by.
Having a tester’s way of thinking AND technical skills AND be able to automate … well, then the question might be if we are looking for developers more than testers. If you are lucky and find a developer who also has experience in testing, it is quite likely that you have found a developer who does not want to test but who was forced to the job. The same goes for the opposite. There are a lot of manual/non-technical testers who have been forced to work with more technical tests, because that was what the team had to do. The tester is not interested and feels uncomfortable when he or she lacks experience and knowledge. Where can I find the modern tester who can hold both types of knowledge and engagement? I know some but they are few!

 

It’s not just about fully automated tests. I have had the privilege to work in teams who had a type of test-developer. That person made a lot of scripting, generating test data, developing small tools to support testing or test case management and scripts to semi-automate testing.
Is it courses and training that is missing? Is it still the test profession’s reputation as a low status job, which prevents developers from wanting to be a tester? Is it our old-fashioned way of thinking of how the test should be conducted, that makes it difficult to venture into the future on a broad front? Or is it that technical testing and automation is the wrong way to go?

I don’t know … I just know that it’s very hard to get really skilled testers who also possesses deep technical knowledge and experience in test automation.

 

A while ago I saw a video with Jan Jaap Cannegieter where he said something like “it doesn’t have to be a Tester, it could be a developer with passion for test”. After that I started to think about what is the different? When do you become a developer with passion for test instead of a tester and vice versa.

• Is it depending on your title and tasks at work?

• Is it about your ability/knowledge about programming?

• If you are a really good programmer but also a really good tester. What are you then?

• Is it only about where your heart lies?

• If you are a developer that works a lot with testing, perhaps often more than developing, are you then still called a developer? or are you then a tester, whether you want to or not?

 

One thing I know is that I am a tester and not a developer, maybe a tester with a passion for development!