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

buggylinaLeave a comment

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: 
Image

Love Story between Software Testers and Developers

buggylinaLeave a comment

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).
Image
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

buggylinaLeave a comment

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. 

Bugs come in through open Windows

buggylinaLeave a comment

Today I’m in a deep sorrow. I lost those two my beloved weirdo bugs which have magical powers.

I think it’s time for me to tell you all their beauty and my silliness. I was testing integration with Microsoft Excel, and, our product has its own ribbon when add-in is installed. In that add-in there is special Insert Object button. That’s the place where bugs decided to live and prosper. After inserting an object which is also an Excel file a blank Excel document would open up, and, cause a lot of trouble: closing it you would close all the file and file’s window would become blank, closing that blank window would end up in Excel not responding. The beauty was that not with all files this would happen. It would just be sort of random!

The second bug was with another part of files who usually did not have the first bug effecting them. So, it seems that everything works great: object is inserted and no blank window appeared. Dream on. Dragging the object Excel’s blank window would open up and flash. Creepy, right?

As a noob software tester, I checked the previous release with Excel 2010, and, of course, there were no bugs like that. I got so happy  and filed them even if later on I was confused several times when bugs did not reproduce. 

Today software developer writes to me and breaks my heart (of course, he is young, smart, and, cute… what else guys like that can do than break hearts?). It figures out that non-integrated Excel cannot handle its own Excel files inserted as objects. So, at least one bug, is not our problem, but Excel’s. Another bug is sort of a “son” of the previous one. Our add-in even solves the problem somehow for some files. So, that blank page does not show up, but flashing appears. Our guess is that it’s just an effect of this “father” bug. 

Of course, I wouldn’t be me if I did not say to a developer that he made me sad, and, I feel like a mother who just figured out that her two kids are actually not hers.  Our scrum calls are more than formal, but today that developer could not hold himself and started laughing when telling about discussing the bugs with me. 

To sum up, the lesson I’ve learned today:
It’s not always your products fault, check the native application, because Bugs come in through open Windows, and, well, everything else that’s made by Microsoft. 

It’s a Bug’s World… and Artistic Discoveries

buggylinaLeave a comment

Bugs love playing silly hide and seek games, and, breaking the rules. However, for a software tester aka seeker, it may be quite tricky to find the bug when it has magical powers!

Magical bugs know the secret of becoming invisible at the right place and time. Seeker comes nearby and bug simply disappears. Magic happens! At least their magic has its limits and cannot keep up with seeker’s patience and persistence. After a while it gets caught, and, then again, when seeker tries to write down an instruction for his best friend collecting bugs – a developer, then the bug again tries to hide. This may be tricky, but those bugs are most valuable.

Today two witty bugs fooled me! They were written down by me, but testing a new build – I did not find them and thought that maybe they got fixed with other bugs, so I talked to manager and dev leader about it. They agreed that it’s madly strange and those bugs are very witty, but we can mark them as No action… However, the real story was that those bugs just used their magic in the new build and hid under their invisibility coats. So, I even started to doubt their existence. However, I got really ashamed of myself and, tried to prove, that they actually exist… And it worked out. Though description is pretty awful: the bug may appear and may not appear – depends on his mood. Please be patient trying to meet with him. And, I’m so ashamed that I doubted bugs and changed their statuses 3 times today… But now they are caught and ready for the fix once again!

Also, bugs are preparing for winter. It’s madly cold outside, so, some of them were given gifts – pretty clothes by our team. Why so? Because we love taking care of our little bugs. Some of them are now fancy and will never be fixed, we have pet them… and they became… features! (Some people believe that the reason is not that we love bugs, but… that developers are lazy to fix them.).

bug-feature

What is more, I must share you my artistic discoveries. Looking at biographies of bugs, I found this beautiful Excel file with pretty art in it. The tester who created that biography loved the bug so much that created brilliant environment for it to prosper. The artist’s name is Evgeniya Gapchinska. Lovely, playful and happy paintings. Check her out! While I found one with… a bug (how ironic). (:

Moi-bogatstva-25h30-orig

The Perks of Being a Software Tester

buggylinaLeave a comment

Today is exactly one month since I started my job. For this reason, I decided to give you a little treat and name all the best things you get with becoming a software tester. 

1. Software-awareness. 
Here I’m not just saying that you will learn more about the software you are testing. The more experience you have with software, the more comfortable you are to try out something new and make your life easier. Attitude on software just widens up making you try out features you never used before.

2. Ability to try out new software products.
Try out may be even a too humble expression as it is so much more than that. Being a software tester you participate in the process of creating a good software product. This makes you get to know the software really well. When it comes to testing integration, you get to try a lot of different products, for example, Autocad, Office, etc. All the newest products are there for you to try out. Of course, most of the job may be based on integration part, but you get to know the in-built flaws, and, new features, of the software. All of this allows you to learn more about what’s in the software market right now, try the product out legally, and, get to know what’s new in this new version of it.

3. Software testing is dynamic and full of constant learning.
There may be days that are bug-free, and, full of sadness by being repetitive, but, in general, being a software tester, allows you to test all kinds of different software. Usually, there are projects and they don’t last too long. For example, a new update for this product is coming to the market at a certain date, and, of course, the release build has to be bug-free. However, usually testing and fixing bugs for a new release may take only a month or two if it’s just an add-in. This means that you move on from one product to another, and, you learn new things constantly.

4. You are not scared of failing anymore.
First, I thought to name this “Being a software tester awakens your inner child”, but fail is the thing that inner child is not scared off. Children can be quite rude with their brutal honesty and bravery. They are not concerned what people think of them, they fall and get up, they are not afraid to try new things and are curious. Later on in life they get full of society’s norms and rules, and… become adults. Adults who are thinking of what others may think and are scared of trying new things in order not to fail. Being a Software tester breaks this attitude so much. We get happy when something fails. Software testers are not afraid to try something totally silly: what happens if I press on this big red button? (Adults would shout: Just don’t press the red button!). This changes the attitude on failing in life on the whole. It’s fine to fail, even the best products fail, so, let’s try and see what will happen. Let’s be playful.

5. Software testing improves your concentration and memory.
You will not do tasks mechanically, some bugs are really difficult to find, and, the road to their cave is not straight. Software tester must remember what kind of turns were done before in order to get there.
Once we got a really buggy build. To make matters worse, the product on which the integration was tested, changed. So, my developer came to me to see how the integration is working now. He did a lot of random things so quickly, I was trying to follow, but it was a challenge. Then after a while he modifies the Excel file, does some random commands in between, and, tries to exit the file. Instead of expected “Do you want to save?” message there comes nothing, and, that new file just turns off with all the modifications. The developer says “Oh, that’s no good. If I worked a few hours on that and it just turned off? All my work would go to waste.”. However, the developer did not remember himself what he did, and, the worst part was that me and my colleague could not sleep calmly after failing to reproduce that bug for 2 days. Today I caught it. Testing something else and playing around, I found THE BUG. I could not be happier. It was not easy to be very concentrated and try to make the same bug with as little steps as possible in order to find the real cause.
The main thing is that you cannot relax when searching for bugs: your memory has to store steps, and, you must be really concentrated in order not to miss the bug. No mechanical work is found here.

It’s raining bugs… Hallelujah?

buggylinaLeave a comment

After a long wait, my first bug was discovered. First bug filed. Though, this made me have mixed feelings.

Of course, I am very happy, indeed, to have found it. However, our new build is so buggy, that it even hurts a bit for me to file a new bug. What a pain it is for developers, and, I want our product to work perfectly. I shared those mixed happiness/sadness feelings with my fellow colleagues just to make them burst from laughter: “Oh, new software testers, they are so naive and still thinking about developers… Be happy that you found a bug. It’s your job. You do that, and, you’ll never be friends with developers.” 

After that first bug I found 4 more undiscovered ones… And, there is no light at the end of the tunnel yet! This build is very buggy and some bugs are parents to others… One tiny bug can go a long way!

I feel like today was my first real working day. I am tired, it was a busy day and lots of bugs are still waiting to be put in their tiny cages… I’ve learned a lot.

My last today’s bug was such a beautiful one! It was basically that all integrated dialogs, for example, open a file, had it… Imagine you press on open, a dialog appears asking you to select a file. There is a quick search field. You enter something, for example, ‘*.doc’ and by pressing run search, your documents with .doc should be nicely put in that window. I wrote it in, and, all the software got unresponsive. It just got all disabled. Even the red exit cross was unresponsive and disabled. What a wonderful bug! Made all the application somehow crash. Brilliant. I am truly proud that I found it. 

Housekeeping in testing

buggylinaLeave a comment

During my first job interview, I was overly-excited and happy. I wanted to become a software tester. I liked the tasks given, the questions asked. Then I decided that even if job market is not for me – I at least enjoy going to job interviews! I wish it was paid… 

One of the questions was about monotony at work. They asked me whether I think the job is going to be boring. Of course, I said no way and told them how cool it is to be a software tester! What kind of monotony are we talking about? It’s exciting, it’s out-of-the-box, it’s dynamic. My then-interviewer (now-boss) calmly replied that some days can actually be boring… Now I get it!

We finished our old-project and had to start another integration with different software. Excitingly, I prepared my fresh Windows 8 virtual machine… I turned on the software, and… integration is not there. Hmm, I try re-installing the build – same thing. Then, we figure out, that the build is not working. With no integration in software – we cannot do any integration testing… 

Now it has been 2 days with no build (writing this I feel as sad as if it was ‘2 days with no food…’). This means it’s a nightmare for software developers who are struggling to create a new one, and… It’s a nightmare for testers, too. We are working as secretaries now! Sooner or later this had to be done, but, at least it could have been between the breaks of testing. We do… housekeeping.

Housekeeping in testing basically means that we are updating old test plans according to the new release of the software (GUI changes). Also, most of the test plans are from 2006 and just shout for a make-over to our new test format. It’s a lot of copy-paste, formatting and document creating in Excel…. I dislike it sooo much, and, want to test things again!

Oh, God… Wait, no…. Oh, developers, please develop the new, working build…

Laziness of developers, tears on updates, and, fear of bugs

buggylinaLeave a comment

Feature tracking was quite an interesting test plan to do! We log in into integration server and see what kind of feature ID some of our actions get. For example, I have two verticals installed on my virtual machine: plain AutoCad and Autocad Civil 3D. Opening files in them gives me some kind of an ID in the license log list. Having in mind that we are testing integration with our product – the ID has to be different for integrated and non-integrated actions. 

The funny part about the test plan I did was that it was the best proof how lazy developers are. Two bugs in that test plan were not fixed at all because developers were waiting for approval of some kind of ‘higher’ people. So, they decided to re-schedule them to the next release. Of course, I did not get anything new – same bugs live and prosper when it comes to feature tracking. 

I thought that in the morning creating a new virtual machine with two verticals is going to be my longest wait for Windows updates, but… I was wrong. During our scrum meeting, I noticed that my computer is acting weird – the sound would disappear at times and a table with ‘your computer is causing sound problems’ made it clear that something’s bad. I am using this oldie computer with 4 GB RAM which is too little and made my surfaces load forever. Finally, the IT guy woke up and said that my computer is so old that they cannot add more RAMS, so they will just change all the computer. Well, it’s great, but I’ll need to set up all my work accounts and virtual machines once again (more updates!). So, now realizing that these are his last days of staying alive, the computer decided to install windows updates automatically causing everything to be so slow. I pressed shut down. 

It took 1,5 hours to install updates. 83 updates, then later on configuring when it’s restarted. I thought I will cry. It was not on my virtual machine – it was on my work computer. I could not do anything! What a waste of time, but, well, it so makes sense that even if we work 8 hours per day, only 6 are for testing. 2 left over hours are for irritating developers and setting up working environments… I both love and hate updates: it’s a must to have it to work properly, but takes ages… 

Our add-in’s release is going to happen next week if everything’s as it’s planned. Now we are into the final stage of testing. I took the first cursory test I looked at to test now. There was this one test case which was not executed with a comment that this feature was not in AutoCad versions before 2013. However, the tester who did the test before me was executing it with AutoCad 2013 and still left that case as not available. I decided to check it out cause the test plan itself does not have too many bugs and is pretty simple. And… Well, it’s a tricky test case. AutoCad itself does not have that feature implemented perfectly, but… It’s possible to do it. However, all the test case would fail because our integration is not working. 

This would make me happy if it was not the final stage of testing, because if now my bug will figure out to be a bug for this release – then, oh well, all the release will be postponed and a lot of test plans will need to be re-executed. And… developers will hate me, too. 

Image

Getting to know the limits of ‘outside the box’

buggylinaLeave a comment

I am working a bit too fast. Hopefully, I don’t miss anything out, though. I do test plans almost as quick as a ‘normal’ tester. On Friday, I was supposed to work on one test plan, but finished two and started a third one.

Third time did not lie and there were a lot of weird bugs written. Most of them were suggestions of previous testers and tiny tiny errors which would show up if you were very into details.

One of the test cases was about disable/enable the integration. There were two ways written to check: the button and the command line with a certain command. The test case passed. However, one of the comments reported a bug. A third way to disable the integration. I thought of it, too. Checked that bug out and it was correct. There was a tiny little bug living and prospering outside the test case. Outside the frames. However, it was marked green as fixed and written WAD. But it was not fixed!

Then, I got very confused. I tried to think whether it’s ‘fixed’ because the test case did not mention the third way… However, the confusing part is… isn’t our job to think outside the box? My colleague then explained that WAD means ‘Works As Designed’. It basically means, that there is a way to beat the system, but it’s supposed to be like that.

This is quite funny to realize that a profession which needs so much outside the box thinking, actually… may have limits. Some of the tricks may be a part of the software (that’s still a bit weird, isn’t it? but.. maybe the creators want to do a selection for new testers and will employ the ones who find that way out…). (:

Image