Author Archive

 

The list of things you can do to become successful can be long; learn about new techniques and processes, attend courses and conferences, read blogs, books and articles, collect ideas, create a network with successful people, observe successful people, set up visions and goals etc. I and many others are desperately trying to do all these things and everything at the same time. Except for work and career my life is also filled with a family, a pet, a home, friends and hobbies. I guess you already figured out where I’m heading. All things mentioned above are really great things to do if you want to become successful and you have to start doing them. There are hundreds of these lists so I don’t need to write yet another one. After doing all those things for a while it’s time to switch to another list and spend your time on other things. This is my list:

 

1. Stop learning new stuff.

There are always new techniques, tools, methods and processes to learn and you will never learn them in a true meaning if you don’t practice them. Pick one (1), that you think will suit you/your team/your system/your organization and try it out. If you notice that it doesn’t work for some reason, stop and switch to another. But make sure you understand and remember why it didn’t work. If it works, congratulation! You just became successful in using this new technique/tool/method/process.

 

2. Stop going to courses and conferences. Stop reading blogs, books and articles.

There are many courses and the supply of conferences are great and most of them are very inspiring and worthwhile. The amount of blogs, books and articles are enormous. You will definitely be inspired, get new ideas and learn new stuff. But this is a never ending story. You will never be able to read everything worth reading and won’t remember all your good ideas and how to do things best. As soon as you feel inspired and have an idea of something that you would like to do… stop reading/listening and carry out your idea. Let your inspiration lift you up and give you energy when it’s fresh (it will lose its strength after a while). You will never become successful by learning and reading about stuff, you will become successful by doing stuff.

 

3. Stop hanging around successful people and observe what they are doing.

Successful people can definitely help you become successful. They can give you ideas, new contacts and you can see with your own eyes what successful people do. But I’m sorry, that’s not enough. You have to do the same things as successful people do. Don’t just have successful people in your network, become a part of a network of successful people! Don’t just observe successful people, do what they are doing. Sometimes this can be big and difficult changes, everything from dressing a certain way to communicating with people (both oral and body language) in a different way. This is difficult and you need to practice a lot. So pick one (1) thing you want to change and practice that until its implemented forever. When you’re done with one thing you are one step closer to be a successful person!

 

4. Stop creating visions and goals.

When you have one vision and one goal, stop! It’s easy to want a lot of different things at the same time but if you go for everything it will become too big and when you’re finally done with the last one, the first one will be outdated. But what perhaps is even more important is to specify what tasks you have to do to get to the goal. But hang on… you’re not there yet. To be able to meet you goal and live up to your vision you have to perform all those tasks. Roll up your sleeves and just do it! If it feels like painstaking work, don’t look at all the tasks, just take the first one and make sure that one will happen. Slowly you will take one step at a time to your success, your goal and your vision!

 

 

We are living in a world of information overflow where a career is something both men and women should aim for. At the same time life quality and family is more important than ever. I can see people around me constantly failing and working insanely hard trying to know everything and do everything, ending up being tired and miserable people. In many cases I think it’s a really good thing to spend time on fewer things and do/perform more things. You will learn more and it will sure feel good to know and see all the things you’ve done (and not everything you haven’t done yet)-

Yep, I’m not talking about everyone else here… I’m talking about myself as well. I sure have some valuable lessons to learn from myself.

 

Good luck doing stuff!

 

 

It’s time to empty my “done bowl”, clean my desk and go home! The plan is to spend the next couple of months with a new and exciting mission… being a mother of two.

My “done bowl” is full of colourful notes and I know I’ve done a lot of things. It’s a pleasant sight and insight.

 

 

28 minutes in you can see Linda talk about test reports.
http://oredev.org/2012/sessions/testing-that-made-me-proud

 

 

 

I will do a short lighting talk at Öredev next week. I will talk about test reports that actually bring value.

http://oredev.org/2012/sessions/testing-that-made-me-proud

 

 

 

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.

 

Usually the screens on the train shows news and the weather. Today we got some strange news, 9 years old news!

 

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!