2017 in Review: Public Speaking, Amazing Testing Community & Self-Growth

“And, when you want something, all the universe conspires in helping you to achieve it.” –  Paulo Coelho, The Alchemist

This quote sums up 2017 for me pretty well: with hard work, determination and motivation some of my dreams materialized and I met amazing people who were willing to help me reach my dreams as well. I will slice up this blog post to milestone-like sections. 

From unaccepted speaker to accepted-to-every-one-I-applied-to

I kicked off 2017 reflecting on how I failed getting accepted to speak at conferences. I had a few useful lessons after my first abstract got rejected 5 times, and, I felt like I learned them – I had a bubbling new idea of what I should talk about. Something that I actually know best – my own story.

Don’t try to reinvent the topic and present something far away from your work – best stories are your own and there is a lot for people to learn from them

So, I created a new abstract called “Testing Big Data to Predict Your Perfect Fit”. I was surprised that sometimes it takes just a question to get some support from the experts: there were so many people who proof-read the abstract and were open to give feedback (Speak Easy, for example, introduced me to the wonderful Nancy Kelln). Once the abstract was ready, I submitted to 3 conferences.

I got invited to speak at all of them: Testing Cup 2017 in Gdansk, Poland, Quest for Quality 2017 in Dublin, Ireland and EuroSTAR 2017 in Copenhagen, Denmark! The last one being the biggest European testing conference with around 4-5 speaking tracks at the same time.

Before the very first talk I was so nervous that I couldn’t even sleep the night before. Technically I had some difficulties, but once it was over – the feeling was wonderful! I received great feedback, it was so rewarding to have audience members come to you and tell you that you inspired them or just to talk to you about work problems they have. I felt like I broke the ice and that was absolutely right!

Once you start stepping outside your comfort zone and deliver your first international talk at a conference – it gets better and you feel more comfortable

Quest for Quality’s experience I loved the most (thoughts on why it was the conference of the year for me). Theme spoke to me, talks were very interesting and the fellow speakers and audience in general were lovely people. I really wanted to deliver the best I could and it worked – the audience and my talk definitely clicked. I was voted the best talk of Quest For Quality 2017 with a rating of 4.61/5!

EuroSTAR was a great learning opportunity as it was a very big conference and I could meet a lot of people, but I did not feel the same click as at Q4Q conference. I met wonderful people there, heard good stories, but it wasn’t as cozy as smaller conferences.

In general, I loved public speaking – it was a great challenge. It taught me more about myself and enabled me to meet like-minded people. I am definitely thinking of some talks for 2018 now as well.

Give it a go at public speaking – it will help you grow

Meeting the old & new heroes

Participating in multiple conferences, meetups and online communities I got to meet so many amazing people. That is the best thing that happened to me this year.

Get to know the testing community – be it at conference, meetup or just online gathering. There are so many inspiring people with whom you can bond almost instantly

Imagine that you get to meet Michael Bolton who has been your inspiration since you started your testing career, you exchange stories and he looks at you and says “Impressive, you are going to be big”. It leaves you speechless. And there are so many known faces in conferences – having a chance to meet them in real life is unbelievable. Most of those people are so helpful and friendly that it will give you a kick of extra motivation to reach your dreams.

What surprised me more than known heroes were people of whom I hadn’t heard before. There are so many inspiring, wonderful professionals who add up to the experience of conferences or communities.

Looking at photo archives, I see this heart-warming picture from Quest For Quality conference. With 4 out of 6 people around me here I kept in touch and plan to continue doing so – if you ever meet any of these beautiful humans, tell them a warm hi – they are awesome!

20171003_204208-001

Also, online testing community has been such a great discovery – a lot of great people in testing are open, friendly and willing to share experiences!

Thank you to every single person I got to meet in 2017 – I am very grateful for every encounter!

Shift from Omega tester towards QA role at my work

For more than 2 years, I was a lone tester or as James Bach calls them Omega Tester. I worked a lot spreading testing awareness in general, not only building automation checks from scratch or getting to participate in groomings/plannings and collaborating a lot with other departments.

This year has been pretty generous to me as I got a new team member! So, now, I am shifting more to the QA role in a sense that I can actually ASSESS quality more – I use New Relic to monitor and spot quality issues we may be having. This ability has given me a lot of knowledge about the product, in-depth understanding of the internals and even got me invited to priority meetings with CEO, account manager and the head of engineering. I am becoming more of a quality professional (which I do love a lot) even if I still do a bunch of testing as well, but my new colleague now helps me out with most of the tasks and we can distribute accordingly. I think it was one of the main lessons in my career:

Clear communication, collaboration between teams and being open to everyone has helped me grow and learn a lot about the product

When it comes to testing, I also got to finally play around more with APIs this year and learn more about back-end. That was so fascinating that I would love to learn more about it in 2018.

2017 in Numbers

My personal numbers:

  • Speaker at 3 international conferences
  • Multiple amazing professionals in testing met at conferences/communities
  • QA & Testing department doubled (from 1 person to 2!)

My blog’s numbers:

  • 7 post published
  • 1404 unique visitors – record number since the start of my blogging
  • 2033 views – second in place after 2016 when I did 30 Days of Testing challenge
  • 338 people read the most popular post: Dear tester! Others care about quality, too.

Resolutions in 2018?

After 2017’s challenges with public speaking, I definitely want to speak again at a conference (or a few). I am researching biases right now. I want to do a talk related to our own and other people’s biases. Especially working as testers we get to deal with that a lot! A practical talk of stories and tips (if you have some stories to share on what you faced related to systematic errors and/or dealt with it –  I’d love to hear them!) .

Apart from that, I am aiming to continue occasional blogging and also learn more about APIs!

Advertisements

Dear tester! Others care about quality, too.

Dear tester,

I know that sometimes it feels like people you work with just want to mark the cards in JIRA as Done without proper testing. Sometimes they tell others “…once it passes the QA” or create tasks for you subjected “QA X” like it is being done just because “they have to”. The feeling of annoyance caused by urgency to complete the task immediately without reporting any bugs is inevitable because of the way they tell just to “pass the QA”. I did write of that before on why “pass the QA” makes me cringe, so I can feel your pain really well. Especially, that even after me trying to explain QA vs Testing vs Checking many times in my company and clarifying, the very same wording is still being used. I would like to share with you a story that happened to me which made me think that sometimes we exaggerate a little bit assuming that others do not care of quality as much as we do.

Today one of developers in my company came back with initial implementation and results to “QA”. The task was fairly simple – there is a lot of data generated by an algorithm and we should check it (I’m using here check consciously as it’s not really testing at this point): does it make sense, what patterns of fault we notice, does algo actually work? All of this should evaluate the quality of results produced by this new algorithm.

The wording of this task’s formulation and documentation with the data had QA mentioned around 5 times in various forms and I’m sure you are familiar with most of them: “data to be QAed”, “for the QAing” or my least favorite “pass the QA”. These terms do not feel too good as they are not correctly used and it may feel slightly insulting sometimes that your colleagues may not bother to even understand what you’re doing. However, you cannot teach all people to use the terms and it’s important to let it go sometimes. Remind yourself that we all have biases (and I do have a story on Managing your biases which made me slow down a little bit before judging). I decided not to exaggerate and think from that developer’s point of view: we both know what he wants as a result – the quality should be evaluated even if he is using the wrong terms.

Some colleagues may use the wrong terms and confuse testing/checking/QA, but don’t go and nit-pick on that. Words matter, but not everyone cares either how to name the rose: all you can do as an empathic quality specialist is to show people that you are open to explain to them, but only if they want to. 

This is not why I’m writing to you, though – this colleague of mine may have used the wrong wording, but letting go of that wasn’t the main takeaway I got.

When the colleague created the task description, it lacked one thing: any description of implementation details of algorithm. No documentation was yet created, no code mentioned, only thing provided was the generated data and vague explanation what should be done (compare columns and say if it’s okay or not using some human sense and research on each of options).

I really wanted to see implementation details: how else can I assess actual risks? Maybe there are areas and patterns that are design flaws and can be seen before even looking at the data generated. This developer tends to work alone as well, so there isn’t much of code review going on.

When I asked if there is any documentation on this algorithm, this was the response I got from the developer:
“Not yet, this is not ready for production yet. When it passes QA there will be a documentation page with all the changes that have come out of the QA process.”

This wasn’t something that I expected to be honest – I replied that to do the QA process we need to know the implementation details and this shouldn’t be made visible only when the algo goes to production. We shouldn’t check in the dark.

My reply has made this developer write to me personally and the words that were used by them again were a little bit rough I could say. The arguments on why the documentation wasn’t created were that “it is too big overhead” and then eventually “it seems that we disagree on the QA process here: for this task, there is no need for implementation details”. How would you react to this, my dear tester? Developer is claiming that as someone who is hired to test and give quality evaluations you shouldn’t look at implementation details at all.

As someone who recently encountered several design flaws in built products which caused issues and could have been spotted years ago, I felt ridiculed. Of course testers or QA (whatever way people want to call these specialists) should see implementation details. Is this developer really thinking that their design and implementation is perfect that we should look just at the results produced?

Issues can be spotted when getting to know algorithms and implementation: you may spot a logical error which causes certain bugs before you even look at the data obtained from running the algorithm

I stood my ground then, though. I tried to explain that I would love to see the implementation because it will help me to do the “QA processes” faster, more efficient and may display me some of issues before I actually look at the data. I want to be familiar with what it is actually doing.

And, to my surprise, it worked. This very same developer who was fighting that QA does not need any details on implementation shared with me the code they wrote to produce the results. It turns out that they thought I needed detailed documentation, but even code was enough which could easily be provided.

In the end, I realized that I could have given up. I could have closed myself up and exaggerated thinking that it’s only me who cares about proper quality judgement and people just assign tasks blindly without even considering that there may be issues in their logic of implementation. I could have felt hurt by the words used and impressions I got from this person, but in the end, even if we spoke in different terms, we both aim to finalize quality assesment (not to pass the QA, just understand if this implementation is good enough). I stood up for myself trying just to do my job better and I got help even if it took an extra step.

So, dear tester, believe that your colleagues are there to help you – you all want your products to be successful and of great quality. It is not only you, just sometimes others don’t know what you exactly need to do your tasks – open yourself up and ask for it. Only by sharing your needs and communicating you can make others understand your tasks better. 

 

 

 

Managing your biases

Looking back to the very start of my career I see a rollercoaster ride of the confidence levels of my professional knowledge: first I didn’t know anything and felt like a student, then I felt like I know a lot about the product, then I doubted if I know anything when an issue hit the fan, after learning mistakes I again thought I have enough of knowledge… and, well, now it’s slightly different than “I don’t know anything”: I am proudly admitting that despite whatever knowledge I have about the product and testing,  I can be a fool and biased, and learning how to manage my biases has helped me to learn more and more every single day.

The more experience I get in testing, the more I realize that there is always a bit of information that I may not know and this can affect my judgement. And the person whose opinion on quality I may discard can be actually helping me to expand my view on quality.

We all have different background colleagues – I do, too. They may not have the knowledge that we have, but this shouldn’t block us to hearing them out and seeing that maybe this is pointing to something important.

Some time ago a colleague of mine who we can name Lambda would a little bit annoy me coming to me with issues which didn’t seem to be worth a lot of attention. Lambda would be deeply concerned, but a lot of times even if I did investigate the issues presented – I would still hold some inner blockages towards the issues reported because I felt like we have bigger fish to fry than investigate those problems.

Once Lambda again ran to me to talk about a certain issue. This time I was certain that this issue is important, but I felt like we cannot do much about it and we cannot tell why this issue is there. Lambda insisted that we should sit down together and investigate. I was hesitating because my inner biases were telling me “we cannot do much about it, Lambda is not a tester”, but still tried to help Lambda. After some time, Lambda got a genius idea on why the issue was happening. I was dumbfounded. I did not see this person as a viable information source, I felt like I may know better and yet.. I was utterly wrong.

This little story was just one of many – with time I am learning to listen more and more. Before when I would get e-mails about issues from various people – I would be rather skeptical. Now I am intrigued. I love investigations, I try not to block the issues that other people find important – it is a great room to grow myself as a tester.

There are so many points related to this topic: the way we test, the way we make conclusions, the way we listen. I have touched only the tip of the iceberg here, however, from my mere experience in testing, advice to my younger self:

Shut up and listen to others more, dig deep to the issues reported even if you want to quickly comment that “it works this way” – you may find something that you did not expect at all. There are dark areas in your product even if you could not notice them. Communicating to people you can learn many new things and information is key in testing. Your knowledge will expand constantly.

Issue investigations have been my favorite part about testing and I must say that improving listening skills and hearing out other people has helped me big time to be better at that. I cannot give a lousy answer to a person from a different background – I have to prepare a detailed answer which doesn’t leave question marks even if person is not too technical. And, sometimes, I definitely can be a fool with my ideas about how it’s working – others may be correct even if I don’t believe it because I feel like I know better.

Managing inner biases and all the blockages that we have is quite a challenge. However, looking back, I think all the mistakes I’ve encountered/done in testing have helped me to slow down and listen. Not only in professional life, but in personal, too – give people a chance, they may actually know better than you.

 

Fail is for the Winners Part Two: Accidents

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

“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…

The Perks of Being a Software Tester

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.