In the land of bugs or why you shouldn’t blame yourself for missing a bug

2 months that I’m a software tester. I have learned a lot, but there is a lot of other things to be learned. 

In the previous post I was talking about the relationship between developers and testers. Now, I think it’s time to talk about problems with other testers, and, inner hurricanes of emotions. 

You won’t catch all bugs. It may sound sad, it may break your perfectionist’s heart, and, on some level, you realize that you will never be perfect at your job… However, this is the beauty of being a tester – there is no comfort zone. The learning is constant and sometimes it does hurt. Sometimes you do shout on yourself and regret not checking something. 

There are pluses and minuses of working in a team of testers with testing cycles. I must admit that some testers make me bitter by skipping quite important bugs. They just seem to ‘float on the surface’ of the test plan and don’t put too much of attention in actually finding bugs. But… it’s good to work in a team and get the same thing tested by several people. This prevents possible major bugs of being unnoticed. 

It breaks my heart when the test plan I did before and all its bugs got fixed, fails for some other tester. I feel like I did not notice something, or, did not put too much of importance to something. However, there are a few main things to remember why you shouldn’t be angry on yourself for letting the bug pass unnoticed:

New builds may cause trouble.
You shouldn’t blame yourself for not finding something that was not even alive in a previous build. Things happen, and, sometimes, by trying to fix something – we ruin something else. 

Importance of the bug is subjective. 
Of course, you should write down everything. However, at times the bug seems so tiny, that you consider it as a feature. You simply take it that it works this way. For example, you may think that in that application hyperlink does not get created automatically. Then after a while someone else tests the same thing and files the bug about it. It gets fixed. The feeling is not too good as you were aware of it, but thought that it’s not important (as there was an obvious workaround and manual creation). 

In conclusion, bugs are everywhere. There are lots of bugs, but you must know which ones are the most important and must be fixed for this release. And, I found this lovely quote in a book called Testing Computer Software by Cem Kaner, Jack Falk,and, Hung Q. Nguyen: 

Love Story between Software Testers and Developers

I’ve moved to a new website, to find my new blog posts, please visit: https://qualitybits.tech 

It has been a pretty hectic period of time in my life: loads of bugs, and, experience. I’ve been thinking what I should write this post about as at the same time I have so little, but so much to tell that I don’t know where to start. After work, I decided that this day and my feelings about it would be best described in a post about a relationship… Between testers and developers…

The Love and Hate Relationship Between Testers and Developers

From my first day, developers for me were an object of investigation. I would try to get what kind of relationship I should expect us to have (sounds serious, doesn’t it?). I am a pretty funny and silly person at times and my contact with developers has been somehow… awkward. I would talk about my beloved bugs with lots of inner passion, love, and, laugh… I guess this may be called a bit unprofessional, but it’s me, and, I love my job with all its problems which I take as simple challenges, and, allow myself to joke around. However, this sometimes creates misunderstandings and developers are not used to see someone fight for their bug so much.

1. Developers may hate testers only in two cases: 
    a) bug was found
    b) bug was not found
To sum this up: no outcome is good enough. 

Of course, we are a team. We try to create bug-free software and seek for the best product possible.

However, in the case a) usual scenario is like this: a developer writes to the tester asking whether it really is our problem. Maybe we could blame something else? Maybe it was there before, not only in this release. Check this, and, that, and, this also more.
While dev leader also always asks us how many bugs we are going to find in the future, how many they should expect – my answer was very simple: as many as you have done in your code (he is always very confident, but that time he blushed and got silent).

In general, developers are lazy. They try to avoid work as much as possible. Sometimes testers have to explain 5 times and share screen to make them fix bugs. Also, it happens that they don’t bother to read notes, details, comments, on bugs we give them. Just reads the start and assumes. Afterwards, marks it as cannot reproduce without even trying. Or, another possibility is, that they blindly follow steps and don’t even waste time to try to get the same result in a different way which is quite obvious, but it’s not written down.
I must admit that in a case, I hate developers a little bit, too (I love them more, though!).

In the case b) as I mentioned before… Testers are going to be blamed for leftover bugs. Developers may just put all responsibility on our tiny shoulders by saying: your fault that you did not see that obvious bug and now users suffer, bad tester.

2. Developers and testers actually silently love each other: for finding bugs, fixing them, and, making a good product together.

Today I got so amazed by our developers as they fixed so many new defects quickly. Of course, my happiness did not last too long as some of their fixes had to be rejected and did not work properly. However, I really feel that it’s magical that they manage to fix those bugs that we just write down. Some bugs are very tricky, and, developers get to know them, understand them, find their reasons, and, fix them. I feel happy when my bugs get attention, are taken seriously, and, are taken care of!

And, even if they will never admit that because of 1 a), but… I believe that they secretly love testers back. A little bit. For helping them improve and giving a lot of interesting riddles (aka bugs) to solve.

I am not sure whether any film company will buy a script for a movie about a relationship like that, but, I find it fascinating.

Responsibility in Software Testing

After people hear what I actually do, they somehow start thinking that maybe they should change their field and go into testing as it seems so easy:
Seriously, how come this job needs no pre-requirements, no degrees, anyone can do it, and, yet, it gets paid pretty well?

No. Not everyone can be a software tester. Not only you have to think constantly and be technology-friendly, but the main thing a tester has to deal with is… responsibility. 

I got this developer lunch buddy. We somehow synchronized our patterns and meet during the lunch break. Being all so curious, I asked him what he thinks of testers in general. Is it true that some developers look to testers from high above? Of course, he was not as emotional as a female and said that he does not feel any hard feelings on testers. However, to be honest, there are only a few good testers. Most of the testers just work… to work. Not to name the teams of countries (somehow he got bad experience with certain nationalities), but as he says “I don’t understand, how come for them everything passes, and, whatever I run – it does not work?”. 

If you want an easy life, you could just write pass on every single test case and act that everything works fine, or, as it worked in a previous release. Then you would just sit in the office, maybe playing solitaire or sitting on facebook, mark test plans as pass, and, live happily ever after. Not forever, though. Product gets released, users notice bugs, and… it comes back to you. 

Passing every test plan is somehow an extreme case. However, it can be also the case, that a tester bumps into just main and obvious bugs, or, sticks to the test plan if there is one. The scariest part is that:

Tester is responsible for a bug he did not notice. 

Even if a developer is the one who created the software, but… When it comes to testing and getting paid for that – everyone hopes for the best job possible. Then developers just take reported bugs one by one and fix them. Developers do not report new bugs as they trust testers. This means that all bugs that are left in the software first of all are because of lousy testers. 

When I started out, I would just blindly get stuck to the test plan. I was scared to play around. Last week, my manager wrote to me about a project I worked on my first week. It figures there was a test plan on 2014 version of software installed together with version of 2013. I did that smoke test and it passed, nothing new. And now support says that users say that integration for 2013 stops working when 2014 is installed! Manager is like “Did you check 2013? It was not written but I take it as kind of a common sense to do that.”. My answer was really simple “My common sense was non-existent at the very start. I did what was written, not something more.”. After a day he made me redo that test on 2013. It passed. It figures that I was lucky this time: users themselves did something wrong (later reported that it works again). I said to my manager that “oh well, magic happens”. And his reply was: “There is no magic in software.”.

After all this we come to a one more important thing. Managers just plan things, developers just fix things, and, well…

Testers need to have a big picture of the software and work for it to be bug-free themselves.

This means that a tester cannot just be stuck with a test plan. A tester needs to look around and think what he’s testing, what else could be somehow complicated. Even if test plans have a time limit, but… We work for a bug-free software and have to work hard to achieve it.  

One more thing is that only testers are like users pre-release. Usually, the bosses are so high above that they don’t even write requirements what they hope from the software. Developers don’t know themselves what bosses want. Manager just makes sure that we all are getting along. 

Testers have to decide how software is going to be. 

Of course, it comes with discussions with management and developers. However, we write bugs about changes that need to be made, we make suggestions, and, we get asked even by developers – how should it work. This is a difficult task at times as we would like just to work and not to think too much. However, creation of software is a long process. 

To sum everything up, there is no easy life in testing. If you want to be a good tester, sometimes you will spend hours trying to figure out something that may not be working. And, you cannot trust previous testers – maybe they are one of those always pass people who live comfortable lives.