Quest for Quality Strikes Again: The Impressive 2018 Edition

Last year’s Quest for Quality conference had a huge impact on me: it was the best conference of 2017 I’ve attended, I spoke there and I was humbled to have my talk evaluated the highest by the audience, I made wonderful connections with which I’m still in touch up to this day, and being there even initiated my move to another country for a new career challenge!

This year, I had the honour to be a part of the programme committee and help choose the talks. What a hard candy that was! Conference’s theme Reinventing QA for the New IT Era was refreshing, yet challenging: there were so many great talks, but looking back at the theme, I could not see some of them being heard at Q4Q. Knowing well myself how much work and effort goes into each tiny abstract, with a heavy heart I rated the talks as objectively as I could with the information I had. The total of a diverse programme committee’s votings was considered, and, I must say, the speaker lineup was pretty impressing: there were quite a few new voices sharing the stage with the experts, and there were even speakers who normally do not speak at testing conferences.

After being in the programme committee, I also got to enjoy the conference as an attendee. I did not think that 2017 year’s experience I had at Q4Q could be challenged, but I believe it was. Both years Q4Q was in Dublin, and I just fell in love with the atmosphere there, what to even say about the inspiring thoughts I heard at the conference, and wonderful people I met again. After the conference, I was just smiling from ear to ear with the new ideas buzzing in my head.

To give you a glimpse of what kind of an experience Quest for Quality conference is, I’ll touch on the 3 key areas where Q4Q2018 excelled: organisation, content & people.

Organisation

Proud to #gather the #world in #Ireland: Austria, Belgium, Bosnia and Herzegovina, Bulgaria, Brazil, Croatia, Estonia, Finland, Germany, Hungary, India, Israel, Latvia, Lithuania, Norway, Portugal, Russian Federation, Slovenia, Spain, Sweden, Switzerland, UK, USA 👉 at #Q4Q2018 pic.twitter.com/UqbcZwhTgO

— Quest4Quality (@Quest_4_Quality) October 2, 2018

Quest for Quality wins hearts with a welcoming atmosphere: many nationalities attending, speaking, and even organising this event. This diversity definitely speaks up to many and makes people feel included. While Dublin is an absolute gem of a city in itself, the beautiful Marker’s hotel as a venue was a lovely addition.

The organisers are very kind and helpful people as well: always there for you, looking for feedback – I still smile remembering one of the main organisers Nikola turning to me to see what I thought of the talks or the event in general. It is important to be with an open heart and willingness to improve.

With all this, even the usually scary filming crew was not that scary at all. The friendly Andjelina was taking interviews and really making sure everyone feels comfortable. She was so kind that even not knowing me much after hearing that I’m coming to Belgrade – she invited me to meet up for a coffee. It still is rather weird for me to see myself in a video testimonial on the conference, but I am sure that it helped a lot to have such good support.

Content

After attending many testing conferences, content for me became one of the very top priorities. Presentation skills matter, of course, but if there is no useful content – what is there from that! I am happy that Quest for Quality met my expectations and differently than some other conferences I attended, it included some topics which were not just testing related – that helped us learn something new, broaden our minds, and just get inspired.

Here are some of the talks that really left an impression on me.

Anna Royzman from Global Quality Leadership Institute delivered a keynote “Test Leadership of the Future: New Challenges, Big Opportunities“. She spoke of challenges we are facing right now, how important it is to be a quality leader, and how our role may actually change. I really enjoyed this talk – I ended up writing down 2 pages of notes. One of the key takeaways I took was how being yourself is powerful: you can help others learn, so you have to embrace that. Also, her 8 principles of modern quality leader are just something that speaks very much to me. It’s important to share knowledge and speak up in order to inspire and coach others.

How do we prepare for the future in tech? We have to become quality leaders. @QA_nna @Quest_4_Quality #Q4Q2018 pic.twitter.com/PCDYXQFcnk

— Lina Zubyte (@buggylina) October 3, 2018

Davar Ardalan from IVOW told us about “Storytelling in the Age of Robots and Artificial Intelligence”. IVOW is a storytelling agency that wants to create a deeply inclusive AI. Very often when talking about AI we forget the human aspect of that: what about the culture? Wouldn’t it be great to have an AI that can help us recognise cultural events and stories? Or an AI telling us stories about our ancestors? I loved the idea that we have to work on making AI be inclusive and have the context of culture. Also, Davar’s storytelling skills are just wonderful – she has worked at NPR, so hearing her speak alone is quite an experience, what to even mention about such a content.

Inclusion matters more than anything. Such a great, touching talk about deeply inclusive AI that has to include culture by @idavar at @Quest_4_Quality. We need to talk about this more! #Q4Q2018 pic.twitter.com/qbESr6uEE9

— Lina Zubyte (@buggylina) October 4, 2018

The closing keynote by Fabian Dittrich from Helpando “Agile living and the future of work: What I learned as the CEO of a nomadic company” was very refreshing and inspiring. Fabian quit his job and decided to work while traveling the world. He shared all the adventures he had and what it taught him. From productivity tools to the fact that it matters more than anything to live a life that you love.

What a story! @TheGoBetween ran a startup while driving through deserts in South America and is inspiring everyone to work more productively with help of these tools. Only at @Quest_4_Quality such keynotes happen! #Q4Q2018 pic.twitter.com/KfGUgt4vVU

— Lina Zubyte (@buggylina) October 4, 2018

People

One word: wow. Crazy, beautiful, smart, inspiring, charming people at Quest for Quality. Just to name a few extra things apart from constant networking at the conference: breathtaking discussions on security testing the night prior to the event with Milan and Amela, spontaneous pub crawl in Dublin after the networking event with the most fun people (Stuart – I absolutely adore him, highly recommend to follow him – great things will come out (and some already did like him being featured in The Guilty Tester podcast or his new TestingBants podcast); Lewis; Saga; Pieter; Jarl  – you are simply treasures), inclusion talks during breakfast with Niranjani and Gabrijela…

So many topics close to my heart were discussed: testing, culture, machine learning, communication, diversity & inclusion. In Quest for Quality networking goes so smoothly, maybe it’s because it’s such a family-like atmosphere. As for me people is the number one thing that inspires me – this conference was just breathtaking with amazing new friends I gained.

A blurry memory from the wonderful Long Hall during the pub crawl ❤

Networking on #Q4Q2018 in #Dublin pic.twitter.com/nZj26t2hzr

— Saga Davidsdottir (@SagaDavidsdott1) October 3, 2018

So, Quest for Quality did it again… With amazing organisation, people & content it yet again was one of the highlights of my year. People matter a lot to me and it is a conference which allows you to meet so many amazing people and learn a lot as well. What could be better! I left the building admiring the skies of Dublin and the neighbourhood with a huge smile on my face – thank you, Q4Q!

 

 

 

 

 

Non-tester, come to testing meetups! – Day 26 of 30 Days of Testing

INVITE A NON-TESTER TO A TEST EVENT

In one of previous challenges I created a post on how to find testing events. Today’s challenge is half done knowing which event you’d like to invite people to.

So, to any of non-testers reading this, I would like to kindly invite you to come to Budapest’s QA meetup’s palinQA events! Upcoming one will happen in September.

Great part about this meetup is that each time we have some non-testers joining us. A lot of topics are very interesting even if you’re not a tester. A great example of this is the latest meetup we had on Making a QA Career. Not only that the audience had testers who wanted to know more about job opportunities, but also people who are interested in the QA career, or, even non-testers (who possibly won’t change their career) come to listen to what qualities should testers have and how it feels to start a career as a tester.

Join a testing meetup and come to get to know the breed of testers: how they feel, what challenges they face and it will definitely give some insight to their work. The more insight there is – the better team we can create.

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

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

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. 

Psychology of a Software Tester: Expectations and Moral Lessons

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. 

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. 

Bugs come in through open Windows

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 raining bugs… Hallelujah?

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.