It’s wonderful to work in a great team – Day 4 of 30 Days of Testing

buggylina1 Comment

SHARE A TESTING BLOG POST WITH A NON-TESTER

Yesterday night, soon approaching midnight, I have noticed that one of my rarely online friends (database developer) got online and thought of using a chance to share an article with him. I was searching quickly to find an article which would be understandable from many professionals’ perspectives, so my article choice was rather a ‘controversial’ topic in a way: more detailed (could say that it was a second part of a previous version) article by Anne-Marie Charrett called “Nuance on leaving testing to the experts“.

After sharing this article with my friend, I have realized that being a developer he’s not particularly a non-tester. So, I decided to ask someone at work what they think of it as well (because database developer went to sleep that night promising to read it in the morning and who knows when he comes back online again with his comments). At work I have found a perfect candidate rather easily – a wonderful outspoken UX designer sitting right in front of me.

The article I shared was rather a more detailed version of “Leave the testing to the experts!” article which caused quite a few comments and Maaret Pyhäjärvi’s response “Work on culture: being told and offering views”.

My colleague not only read the article I sent, but as well the original article and Maaret’s comments. He said that he understands both Anne-Marie and Maaret: “The final decision should be the expert’s, but collaborating with people is a good thing. Sometimes the best ideas come from non-experts. And if you work with competent developers, you can basically be sure that the product they hand over to you for testing should have very minimal number of bugs, so it’s like a trust thing.”

When I asked him  of his opinion on who is responsible for a bug going out to production, he told me that both programmer and tester should be.

This made me quite happy to be working with colleagues who have rather similar attitude to mine. I see Anne-Marie’s point as well and definitely agree with Maaret, for me summary of this would be that: telling what to do may be poison in a team, but offering what to do can help you improve.

I am pretty lucky with my team and company. There was never a saying ‘you must’, my work always involves my own decisions and confirmation. Eventually, it’s me who is testing, so the ways how to do it should work for me to begin with. I definitely soak in all the information I get at work as tips for my testing to be improved. So, in other words:

Please, offer me how to do my work (or rather improve it), all advice is welcome – in the end we are a team even if testing area is my main job

Experience of sharing an article with a non-tester colleague was great: especially to realize that they understand you and your job quite well. Knowledge share is great and we should all do that – because it’s not like in this comic (don’t do that), we all know something that others don’t.

dt000613

TestCast podcast “Testing is Dead”: Day 3 of 30 Days of Testing

buggylina1 Comment

LISTEN TO A TESTING PODCAST

I have never listened to a testing podcast before, so this was my first one ever -testing challenge is already yielding results in teaching me new things.

Not knowing where to start, I created a Google search with “testing podcasts”. One of the first results was a list of Software Testing Podcasts made by Ministry of Testing. I do trust this resource, so without further hesitation, I gave a go to #1 on the list – TestCast. The only problem with the list is that it’s pretty old – dating back to 2011.

I was looking for an interesting title for the first time podcaster and chose Testing is Dead. It is around 30 minutes discussion made by Bruce McLeod and Trish Khoo.

In the very start, they talk about some big names in the industry which claim that testing is dead. For example, Google or Facebook often would give examples in industry where testers are not present and developers do their own testing. Trish and Bruce gave some valid points that giant companies like that can give distorted view to other companies and it should be rather presented as their own way of looking at things and it does not mean that no testers approach would work for each company.

The way Google or Facebook can “reassure” their quality is users. They can be their first testers. If Google search does not work – a user may rather blame her own connection than the service itself. Nevertheless, Google can release their produt to one demographic only (let’s say a few thousands of users) and monitor the change. This approach may not work in other companies where pre-testing and quality is very important.

Later Trish and Bruce moved towards the fact that in many companies people don’t understand what testers are supposed to do. If management just wants a “safe net” because they feel that testing should be a part of the better quality, but they don’t really know what testing is, it may lead to test script writing, amount of work done estimated by checkmarks and actually, not testing, but checking.

To sum up my first podcast experience: it was a bit strange just to listen without seeing the presenters, it could have benefits of doing other task, but I am pretty bad at multitasking. Talking about the content, even if it’s back from 2011, but definitely we have same problems in 2016. Awareness of testing and what testers are supposed to do is a big problem and the approach to work with or without testers is just a choice. So far, testing is not dead and does not seem to be dying.

What I’m doing at work: Day 2 of 30 Days of Testing

buggylina1 Comment

TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK

I had to cheat a bit on this one: it’s Saturday today, so I am not at work. I had to take a picture yesterday, however, I’ll share it now.

13570268_10209801873230058_84405356_o

This looks like a wonderful job for a woman – doesn’t it? All day looking at clothing. My boss sometimes remarks “You’re again shopping!”.

I am testing fit solutions and visual similarity algorithm. It is a pretty exciting task to do with many layers and challenges. This picture just reflects a common screen view you can see on my computer when you pass by.

30 Days of Testing challenge: Day 1

buggylina1 Comment

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

Ministry of Testing has announced 30 Days of Testing challenge for the month of July. I decided to join in as it’s a great opportunity to possibly learn something new about testing and, most importantly, it’s very fun to do it together with other fellow testers in the world and get to know them. Testers, let’s unite! Here is the proposed challenge:

30-Day-Challenge-1-page-001
Day 1: Buy one testing related book and read it by Day 30

I never owned any testing related books (woops!) so I took this as a great chance to buy some paperback books (I’m old-school like that). I went to book depository and actually ordered two books on testing which I have always wanted to read:
1) Lessons Learned in Software Testing: A Context-Driven Approach by Cem Kaner, James Bach, Bret Pettichord
2) Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson

It will take time for my books to arrive, so even if I won’t finish them this month – I will the next one. I have heard many great feedback comments about these two books and thanks to Ministry of Testing for motivating me to finally get them.

Rebirth as an Omega Tester

buggylinaLeave a comment

Last time I wrote an entry in this blog was 2 years ago. Definitely, a lot has changed and it’s time for a rebirth.

Reasons why I got silent were simple: I got tired at my work, it became monotonous and lacking of challenges (later reasons became simpler: I forgot about the blog, it was not a habit anymore and I was pretty busy).

More than a year ago, I decided to look for a new job. With a bit of luck and accidents, I stumbled upon an ad for a first full-time software tester in a startup. As I have met all of the requirements and job sounded challenging enough, I just had to apply even if it was based in other country (where I have never been before).

Response was quick and inspiring: I got homework (I always think it’s a great sign of a company – you can prove yourself with actual task). After that, I had multiple Skype interviews and… quit my job (which is definitely a tough thing to do when it’s your first job), packed my bags and moved to a new land of opportunities.

I must tell you that this change was the happiest change in my life. Now it’s more than a year that I work as an only full-time tester in a promising and exciting startup! I have many stories to share, so, it’s about time to make a rebirth.

Changing from manual tester executing test scripts in a big international company to being a sole tester in a (sometimes chaotic) startup is a huge difference, but, oh boy, how worth it is! Advice for you:

If you ever wake up at least a couple of days in a week thinking “I don’t like my work and don’t want to go there” – it’s about time to change your work. New opportunities are around the corner waiting for you.

And, if you find yourself wondering, why did I call myself an Omega tester, there is a great article by James Bach: Omega Tester: Testing with a Team One. Definitely worth reading it!

Fail is for the Winners Part Two: Accidents

buggylinaLeave a comment

Best advice for a software tester: make mistakes.

When it comes to black box testing (testing software from user’s perspective), let all your imperfections loose! You don’t need to be a professional user all the time, you can be a clumsy user misclicking something. This kind-of-out-of-the-box-testing-strategy hits security parts. And, trust me, those are the most interesting bugs which can even break the system.

Most of the best bugs I found were found by accident. I did something that I was not intended to do, and, bang – beautiful bug appears. Of course, usually bugs like that are really difficult to reproduce because being such a free spirit and doing something unplanned, you cannot remember exactly what you did.

Trying to reproduce that bug is a long journey sometimes. However, it is wonderful. Your adrenaline is rushing to catch the leg of that bug again. You are a little bit bitter that you slipped it and cannot remember how to reproduce it. And, you just cannot give up because you had it in your hands, and, it’s one of the best bugs you found. The ‘destination’ of finally finding that accidental bug is more than words can describe. It fills you up with harmony and self pride.

Accidental bugs are the best in my opinion. They are the ones that define the purpose of manual testing:

Humans do mistakes and that’s why automated testing will never substitute manual testing done by imperfect humans.

Set yourself free! Get crazy with your software. Misclick, choose another option, experiment, and… break it.

Fail is for the Winners Part One: Neglected Bugs

buggylina1 Comment

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better” – Samuel Beckett

Sometimes software testing is like a roller-coaster ride: fails (bugs) make you happy, but at the same time sad, and… to make matters worse: sometimes you may fail by reporting something that is not actually a bug.

At the very start of my work, I was scared to file a bug in order to avoid a… failure. How would I feel like if it actually figures out to be not a bug, but a feature? Maybe I’m just not aware of how the software must work.

Later on, I got braver and braver…

I have filed more than 100 bugs in past 3 months. In this new project we just started, I’m the tester who has filed the biggest amount of bugs. Does it make me the best tester? No.

The best tester is the one who gets the most bugs fixed.

Of course, filing a lot of important bugs gives you a bigger chance of actually getting a lot fixed, but… another side of this is that there will be a lot of Closed bugs which will be neglected and it makes you feel a little bit stupid for filing them after developer’s responses like “it works as designed”, or, “cannot reproduce”.

It takes time and practice to learn how to deal with them, but…

Don’t get down because your bugs were neglected. If there is a chance – file it as a task or enhancement. Even if bugs sometimes get closed for various reasons, it is always very useful to put attention on them. What you are doing is great and maybe first 2 times that bug will roughly be marked as Works as Designed, but in future releases someone will take it as an amazing suggestion to improve the software.

And, remember, don’t let failures bring you down. Don’t be scared of being laughed at. It would be way worse not to do anything and sit silent.

There is only one way to become a professional at what you do: Fail.
Fail a lot and never stop moving forward. Only leaving your comfort zone, you will reach some of the most amazing things in the world…

How to Attract Interesting Bugs: Use your Talents and Be a Software Terrorist

buggylinaLeave a comment

The release was supposed to be tomorrow, and, today I found a really interesting bug. I think it is the bug that I’m the most proud of so far… or at least today. (:

I will tell what that bug was like in this post, but before that I must say how my colleagues reacted after getting an e-mail with developer’s commit and bug’s description: “What? Why did you do that? How did you manage to find that bug?”. And the answer is pretty simple: I try to make my testing nice and not monotonous…

Collect the best pictures: art, photography, travel, whatever you like and use it when you need to test something with Insert Picture, or, with image files in general. 

This seems so unimportant, right? Who cares what kind of picture you insert while testing. But, hey! You get tired of those default Windows pictures with tulips or penguins. And, let me tell you a secret – a picture which you like looking at can do wonders. Your imagination strikes with all this creativity/nice view in the image file. You suddenly feel happier and testing is more fun. To make it even more interesting, you could save quite many images you love with random names, so each time inserting an image you wouldn’t know what you are inserting exactly and get a bit surprised.

Practice your foreign language while testing. 

Modifying a file (usually it’s a text modification) may seem such a boring task – just type in ‘Aaaaa’ or any other ‘asafsfjdsf’. So dull, repetitive and what a mess it creates when you try to save a lot of files with random file names like that and you are never sure whether this random name is unique. Then again you need to change it, oh, boy, so annoying.
One way could be to think of interesting words, people to name your files, but…
Why not to practice your foreign language skills? Try to use testing as a chance to repeat newly learned words and just have fun while doing so. 🙂 It will definitely be more fun to write a funny word in a language you are studying instead of ‘Aaaa’. 🙂

Take inspiration from music.

If you lack of words in a foreign language, why not to listen to a radio of that language you are learning while testing? Then when cannot think of any word – just write down the one you hear in the song. In general, music can help to create a good vibe and mood for testing. However, this is not for everyone (for example, I cannot listen to it all the time, I need to get silence, but sometimes it really helps to refresh my mind).

Be a Software Terrorist. 

A what? It’s time to tell about my lovely bug which made our release shift even more and a developer send me a message saying “You’re a terrorist” (I am not a terrorist, just a software terrorist…). 🙂
Try things out, have fun and you will find bugs like these…

***

I turned on the software, inserted a lovely travel photo as a background picture, and, thought of a song I just heard on a Swedish radio (I am just a beginner, and, they say it’s really good to hear the language constantly, so I try to listen even if I understand only a few words). It had lyrics like: “wherever i turn in the world i’m standing here with empty hands”, so, I thought that this time my modification will be “empty hands”, but in Swedish. I wrote: “tomma hander” (without Swedish characters). Then I wanted to check some shortcuts and pressed Ctrl and got surprised. We test integration of products like that with a file system product of ours. And, there showed up the login to our file system. This is weird, I thought. Ctrl itself should not make any dialogs open. After log in there came integrated Open dialog… So, basically, it meant that if a user wants to save the new document with “tomma hander” and presses Ctrl+S he won’t be suggested to Save the file, but Open it from that file system product. This may be very annoying for a user working with large files and using shortcuts.
I would have never found it if I typed in ‘asdajdaskdj’… The bug itself was as follows:
every time typing the letter o in the document (either it alone, or, in the text) and then pressing Ctrl key would work as Ctrl+O and give log in to our software and integrated Open dialog. 

A secret of a happy and productive tester: be not only passionate about testing, but fuel it with other passions you have in life. 

 

Software Release: False Alarms, Stress before the Deadline, and, Prospering Bugs

buggylina2 Comments

I did my first false alarm! 

We are working on this integration project for way longer than we thought to work. Bugs kept appearing, or, coming back to life. Finally, on our _4th_ final testing cycle (all cycles before failed), we got a build with a good feeling that it may be the release candidate build. Maybe it was the historical day with test plans actually passing! 

After a delayed release all the team is tired: developers lose hope to fix bugs and leave them for further releases, testers want to start testing something new as it gets a bit repetitious, and, everyone in general feels a bit low. Every new bug is way more painful if the deadline for release is coming up. Here comes the psychological crisis: developers feel like their coding is still not working after all this time and are a bit bitter on that, while testers…. Testers don’t get any support for finding bugs at this stage, a new bug is like a curse that nobody wants to have (even if it is silently valued: having in mind that the issue won’t be there after the release after the fix). But as I talked in previous post – being a software tester can give you a lot of psychology lessons, too! 

Also, when release is nearby every bug matters. If there comes a serious bug to be fixed in this release – you must react as soon as possible, let all the development and test team know about it. 

So, I did. I was testing a so called 0 bugs build today, and, well… one bug which had to be fixed in this build seemed to reproduce. It was weird that one case of it was fixed and another wasn’t, but I was trying to be very quick and inform the team about recurring issue. I sent an e-mail saying ‘BAD NEWS. This bug reproduces. I’m sorry!’. 

After I sent it and I reopened a bug (which was very painful as it was our release candidate and it was not anymore a real release candidate), I got concerned. How come it was fixed for one case, but not for the other… I ended up re-checking, re-installing everything and making my machine as fresh as possible. For my biggest horror: it actually was fixed, and, before my machine was not clean enough (had some left influence from previous builds). I wanted to bury my head into the ground: I just wrote a response to that e-mail I sent ‘Nevermind, False Alarm, I’m so sorry’. Dev lead replied that ‘It feels that release is coming… ‘. 

However, I actually found a real issue later on. This time I first checked a few times before filing it. And, well, it’s horrible, but, I destroyed the dream that this build was a release candidate. But it’s my job and it’s better to find it now than after the release. 

So, some bugs must be fixed, but… there are loads of bugs that are ‘pushed’ to the further releases as at the stage before the release date it’s too risky to fix them: may ruin something else and cause harm. That’s how we get those bugs that are always there, everyone is aware of them, and… they keep getting pushed for the further releases. 

Image

Psychology of a Software Tester: Expectations and Moral Lessons

buggylina1 Comment

Even if at the very start my colleagues laughed at me when I felt bad that our software is ‘buggy’ telling me that ‘it’s our job, silly, be glad’, but… I still have that good versus bad fight inside of me. It is good that I find something bad which means I work pretty well, however, I work for a company, for that specific project, for the specific software. Is it bad if the software that I work on (our product) is bad? 

I am not the only one with questions like that. Understanding how common this ‘crisis’ is between testers, Cem Kaner, Jack Falk, Hung Q. Nguyen in their book ‘Testing Computer Software’ gave a lovely introduction which even had a few psychology notes there. I am going to share some of my findings. 

You get what you expect. 

Imagine that you’re a scientist and you just discovered a new wonderful theory. You have a lot of methods which you could apply to prove that it’s correct. However, take a minute, think about it… Would you choose methods which could make your theory fail? 
There actually has been a research about how intelligent experimenters unconsciously avoid test experiments which show that their ideas are wrong (Rosenthal, 1966). 
Similar example showing how expectations rule our mind is proof reading. We expect words to be written with no typos and we manage to raed wdors the way we expect them to be.
Exactly the same thing happens with a software tester…. If you have an attitude that your software is good – you won’t find any bugs, you will miss the ones that actually are there and take them as details or accidents.

You have to want software to fail. 

This sounds rough. I know. It is your software, you work on its quality and you want it to be bug-free. But your attitude must be very strict and judging – in order to make your software really good, you must put high standards on it.
It just reminded of a quote which I liked way before I was a software tester (maybe it’s a sign!) by Baltasar Gracian: 

Attempt easy tasks as if they were difficult, and difficult as if they were easy; in the one case that confidence may not fall asleep, in the other that it may not be dismayed.

You can do your job well (even if it will never be perfect). 

There are always bugs left. This is a one more ‘sore’ point for testers. You will never catch them all. Therefore, you will never be a perfect software tester. You will never do your job completely, but… you can do it really well. 

Sometimes it’s hard, but hey… Being a software tester is way more than catching bugs, it teaches you… life. It may be difficult at times, but noticing problematic areas in software is actually a path to a better software, and, even if testing does not win you any popularity contests, but secretly, everyone is grateful that you point out the defects which could have caused a lot of trouble.