How Does the Product Make You Feel: Usability, Testing & Airports

Recently I have been thinking about the future of testing. More and more I think that the future of a tester’s profession won’t be about the technology choices or even automation, but rather adding a human quality to the products. We will be the ones to stay alert on ethical sides of products, question design, development and usability (ease of use of a product or service).

As a quite experienced question asker, I get to wear multiple hats and collaborate with various departments during the product development. From my experience, I would say as a QA, you get to work with (not limited to only these people of course):

  • R&D questioning algorithms and their output
  • UX designers questioning design choices and trying to wear user’s shoes
  • Business and product teams questioning requirements and acceptance
  • Development teams questioning implementation
  • Management questioning priorities
  • Sales teams questioning domain

All this questioning for me means representing the user. Making sure the quality of the product is satisfactory and user feels good using it. Usability when it comes to feelings is one of the top qualities.

I am not sure if it’s because of my recent thoughts on people vs. products, but I became very sharp on observing the world and, oh boy, how much it hurts when our lives are affected by poor usability and bad design.

Usability and Bad Design Adventures

I was flying into Munich airport recently and remembered one of the most interesting talks I’ve heard on EuroSTAR 2017 “The Sky Is The Limit! – Or How To Test A New Airport Terminal”. In this talk, Christian Brødsjø shared the experiences of testing Oslo Airport. And, of course, it involved people – they had to see the readiness of the airport, the ease to use and the operational abilities. Airport testing is not an easy task, it requires a lot of time and simulation of the actual airport activities in order to see what feedback people are giving and how it would actually work. Nobody wants to repeat the story of the disastrous opening day for Heathrow’s Terminal 5.

When I was searching for more information on the airports, I found many articles on failed airports and even airport representatives admitting that their airports are a mess. This makes me think that I am not alone having bad feelings about airports. Sometimes I need a reminder that bad user experience is something that we should talk about.

In the past month, I had a pleasure of getting to work in the same team with a very caring UX designer Shawn Lukas. We discussed many times how important it is to care about the actual users. A lot of times we don’t even know people for whom we are creating the product – we have to make sure to get to know them instead of guessing or assuming how they are as we are creating something for them. In addition, as users very often we tend to blame ourselves for the product issues. A lot of times we take products the way they are and deal with their imperfections: it may hurt to use them, we may get annoyed, but we stay silent and just try to find workarounds. It should not be this way, the way we feel about products matters and we should speak up.

So, coming back to the Munich airport… It is one of the busiest airports in the world and I am sure that a lot of people worked on making it a good experience and did as much as they could. However, I travel a lot and usually don’t expect much from airports, but certain design decisions left me a little bit annoyed, frustrated and even angry at some points. I am sure that my mum would get lost in that airport – that is not a good sign, because everyone should be able to use the airport. Especially that traveling already is a pretty stressful thing in itself.

How Munich airport managed to trigger my feelings?

Sunday. After waiting at the airport and traveling, I just wanted to get some rest and get out of the destination airport. After landing, I went to go get my luggage. It is a big airport, so gets rather tricky with turns and quite a bit of walking – that’s alright. However, the way to the exit had these things bothering me:

  • Confusing direction arrow signs. Unfortunately I did not take a photo, but imagine this – there is a space with many escalators, some going up (on the left), some down (straight). There is a sign that baggage claim is ⬆. Does it mean you should go to the left and up or straight down? Apparently you should go straight down even if arrow shows up – learnt it the hard way by first trying to get up.
  • No indications to explain certain experiences. Finally I get to the little room where I see no more baggage claim signs, but what I see is the train. Train going to other terminals, I assume. I hesitate, look around for more signs or where is the baggage claim as I just want my bag, not to fly somewhere else (even if I wish I could at that point) and an angry airport worker tells me to get on the train. And I tell “I need to get to the baggage claim” and he shows me the train and says angrily “This is the baggage claim”. I am already a bit frustrated by this – how could I know to take the train? So, I murmur back while getting on “No, this is the train”. A little bit of human understanding would be nice in this service: add a note that you need to take the train to get there rather than show the train and tell it’s baggage claim. It’s not. It’s the ridiculous train.
  • Green signs for forbidden exit. I reached the baggage claim. Got my bag and looked around – it was a big room with windows and doors and could see people walking outside in the parking lot. Would not expect to get out this easily usually – we always have to pass passages and official arrivals are in the airport, however, this time I decide to check if it’s some kind of shortcut because the doors have green signs on them. Only getting closer I see that actually if I opened this, I’d trigger an alarm and it’s just an emergency exit:
    32405524_10216146622644828_8922115278297366528_n.jpg
    Usually forbidden alarm controlled doors or emergency only exits are with red, so why is it green? I walked back from the door and managed to eventually leave the airport in a different way.

This experience I may not have noticed before, I may have taken it for granted or as is, but the more I work in tech, the more I realise that all we do and create is for people. It is not okay to make your users confused with bad design & usability. 

Why should we care about usability?

As QAs very often we get to see the whole image of the product/service. This adds a lot of responsibility to aim to feel the same way about the product as our users. The challenge here is that being involved in the actual development we know why certain design/tech choices were done in a certain way, and, this may add a familiarity bias and make us take things the way they are. However, we have to remember that products are developed for certain users and this means that their quality very often will be evaluated by feelings. As the saying goes:

People very often don’t remember what you did, but they remember how you made them feel. 

So, make sure to question usability and design. Catch any kind of feelings you may have about the experience and voice them. And, for the best result – get to know the actual users in order to understand their feelings.

P. S. Ironically, in order to write this post I had to login to my wordpress account and I was annoyed a bit again about user experience:

Screen Shot 2018-05-13 at 11.59.35Why would the field say “Email Address or Username” when only username is allowed? I used the correct e-mail and managed then to send a link to the very same e-mail and login via click there (as I could not guess the username field). This just sums up on how you should always think twice about the design: how users will interact with your product and feel afterwards. 

Advertisements

3 Tips for Thriving as a Tester: Impressions from “How to thrive as a Web Tester” by Rob Lambert

There is this one ultimate type of people that I adore the most in my life: smart, but humble. This does not sound like anything rare, right? Yet it is. In tech world there may be tension, competition, even stress-caused forgetting that others are humans, too.

I always get my inspiration from people who want to lift others up rather than bring themselves up. An example here is people who honestly care how you’re doing and actually provide feedback on how you could improve. These people share ideas and their keys to success to anyone who is willing to learn. In my testing career, I was amazed to meet so many professionals wanting to help you improve: be it a colleague programmer willing to share their ideas on how you could create a better automation checks framework, respected experts in the field supporting you on Twitter or sharing their books for free. 

This is how I came across How to thrive as a Web Tester by Rob Lambert: I really like Rob’s ideas on testing, especially on the social aspect of it, and a few weeks back I saw his tweet that you could download the book for free that day. I could not miss a chance: downloaded it immediately and actually read it in a few days.

“How to thrive as a Web Tester” is a collection of great tips and lessons learned by Rob Lambert who has been working in testing for more than 20 years. The book has two parts: social aspects of thriving as a tester and techniques on testing websites.

I found both parts great, but the first part was especially speaking to me. Rob shares a lot of realizations about work as a tester which are sometimes related to psychology and communication. Second part related to web testing had many practical tips which are especially useful for someone new in web testing. I really enjoyed reading the book and here is the summary of top 3 ideas I liked.

Top 3 my favorite lessons from “How to thrive as a Web Tester” by Rob Lambert

Be the best tester YOU can be

This point particularly spoke to me. We tend to compare ourselves to others constantly. Then sometimes we get unmotivated that we don’t know as much about something as person X does. Or we are not as smart as them or not as quick or not as good of a public speaker and this goes on… It is time to embrace ourselves for who we are. In the book Rob reminds us to confront our own beliefs on what a good tester is to us, not others. Where should we improve? How can we become the best version of OURSELVES? A brave advice that Rob is giving in the book is to avoid mediocrity in your workplace. In order to become the best version of yourself you must have an environment which allows you to experiment, fail, learn, succeed and grow. This means that you have to choose a healthy workplace which supports your growth.

Ask good questions

High quality questions generally lead to high quality answers. High quality questions are the hallmark of good testers.

I wrote down at least 5 quotes from “How to thrive as a Web Tester” which were related to questions. It really was something I aim to have at my work: ask more and by doing so, be more productive. Sometimes a question on implementation can open a lot of “we haven’t thought of that” and it saves a lot of time for you as a tester, too, because it all leads to conversation instead of many bug reports. In the end, we all are working for the same purpose – to build a high quality product.

It is not always around more testing

Sometimes there are tendencies to automate as much as we can, but this is not always necessary – automate where it makes sense. Also, your work can be more productive and faster if as mentioned above you ask questions and also if you use tools to test quicker.

What I liked a lot in the second part of the book was the suggestion to use various tools to ease testing. Rob has a support page for the book with all kinds of resources accessible to everyone and using tools is possibly a tip I would give to my younger self, too. A lot of times I have filled in text fields manually or done other test data preparation routine tasks which took a lot of time and were pretty error-prone. A way to a more productive testing can be as simple as having an extension on your browser which helps you fill in text input fields. One of my favorites is Bug Magnet Chrome extension by Gojko Adzic.

 

 

 

 

Testing to Make Product Better vs. Perfect

Reading Seth Godin’s post Perfect vs. important I realized that his idea is very relevant to testers. To rephrase, the main thought of his post is:

Spend more time on making something better (more useful) than polishing it to perfection

When it comes to testing, frequently testers jump into a habit of reporting every minor issue found which leads to quantity vs quality sometimes. Have you ever reported an ugly progress indicator or not the prettiest alignment of UI elements? I have. And I even fought for these to be fixed.

Obviously, UI is important. Distortion bug on IE9 can make you lose customers who use IE9, for example. Ugly UI is not inviting to be used. However, let’s stop for a minute – what is the actual importance of these issues for your product? Are they more important than a security bug where user can access different user’s account by changing their user id in the URL?

Sometimes we are wasting our energy, effort and even nerves with bugs which are for “polishing to perfection” rather than making the product better.

Think for a moment: what is the main purpose of the product?

The art of being a good tester is the ability to ask good questions, so let’s ask ourselves some questions when we test:

  • Does the product work as expected?
  • Are there any areas which may cause trouble and were not thoroughly tested?
  • Does my testing concentrate on making product better or perfect?
  • Do we (testing + other departments) have time to polish the product to perfection? (If yes – yay, there is time to fix minor issues as well!, if no – then concentrate on the important functionalities)

Sometimes you have to let go of the minor bugs – there are more important features to test/improve. Be smart with your priorities: work on making the product better, not perfect.

5 Tips for Humans in Tech from “The Confidence Code”

During EuroSTAR 2017 conference, there were a couple of discussions about Women in Testing (if here you thought “what about men?” I can redirect you to a good article on whatabouting). Being a woman in tech myself, talking about issues like feeling shy, an impostor and uncomfortable in a sometimes man-dominated tech world has helped me greatly to improve myself and even the way I work. However, I truly think that these discussions can be useful to men, too – maybe not as commonly, but every single human can have issues with confidence. At my company instead of using “guys” we adapted a beautiful “humans” instead and in this post I would like to talk to you all, dear humans.

At one of the gatherings during the conference, there was a recommendation of Katty Kay’s and Claire Shipman’s “The Confidence Code: The Science and Art of Self-Assurance—What Women Should Know”. I immediately knew I had to read that book. What I didn’t know was that the realizations I would get as a result of reading this book would affect me, my attitude and even the way I do my work.

“The Confidence Code” combines a lot of research on the confidence of women and proves that even if there are some biological differences in the brain of men and women, or there are genes responsible for confidence, but every single person can work on feeling more confident – brain plasticity is a real thing, so we can change at any age.

I have worked with lots of wonderful people and some of the most touching confidence stories I have heard were by men, too. For example, I have this colleague who on the surface looks like a strong confident male and yet once after quite some time working together he opened up that he feels like an impostor. I was shocked – I did not see it coming at all. So, even if a lot of issues described in “The Confidence Code” are more common for women, I would like to share 5 tips that I (re)discovered from this book which are applicable to everyone despite their gender.

  1. Don’t let the stereotypes dictate your life: give things a try

    In one of the studies mentioned in the book,  Zachary Estes, who is a research psychologist with special interest in confidence disparity between men and women, made over 500 students solve spatial puzzles. He made this experiment not only to prove that women have lower confidence sometimes, but also to show that confidence can be manipulated. The results of this experiment were that the women performed way worse than men, but what Estes noticed was that in general women didn’t even try to solve most of the problems. Then, he decided to repeat the experiment with a saying that participants should at least try and… the results were around even. Women performed as good as men when they actually tried to do the tasks without giving up.

    A lot of women assume they are not good at spatial puzzles or… tech. There may be some stereotypes in the air and sadly, but a lot of women themselves get trapped in it. My real life example is programming – a lot of times I would think I can’t do something just because I can’t do it immediately and I am not perfect at it. Last week I got a task to improve my automated checks and I got a little bit scared – I haven’t touched the code for a while. However, once I sat down, I decided to give it a try like I learned in the book. In the end, code review was very kind and I just needed to add an extra validation – the code I created was better than I thought.

  2. Intention is not enough: what matters is action even if it is not perfect

    I see it all around me – wonderful women fretting that something won’t be perfect and sometimes freezing over doing because it won’t be perfect. I had the very same with the code I mentioned above – I even had thoughts that maybe I should sit down with a back-end developer before even committing. However, what is important here is to fail fast – okay, I may commit something utterly wrong, but that is a chance to learn. Not holding back anything and being ready for feedback – I learn and actually get things done. It is not enough to dream to be the best programmer on earth – you have to fail and learn from your mistakes.

  3. Start small and you will overcome your fears

    Inaction very often comes from low confidence. Often we avoid things that we are not good at – we should try to break that and do more of it in contrast.

    In “The Confidence Code” there was a good example of school in the USA versus the schools in Japan. One American journalist was sitting in a geometry class for kids in Japan. One of the kids couldn’t draw a figure right. To his surprise, the teacher pointed out that child and made them come to the whiteboard and draw in front of the class while being given feedback after each time. The journalist was feeling very anxious – in the USA if someone can’t do something calling them out would be rather insulting and embarrassing. And, well, after first try the teacher asked the class if the drawing was good enough and they said no, so the kid had to try again and again… until they got it right. When the shape was good enough – all the class applauded and the child was smiling from ear to ear. 

    This reminds me of an interview with singer Pink who was asked how she got into air gymnastics that she does so well in her performances. And then Pink answers that she was afraid of height and she did not want to be afraid of it. That was the reason why she went straight to air gymnastics – to beat her fear. So, don’t run away from the things you are not good at – overcome them by facing it.

  4. Stay authentic – everyone’s confidence is unique

    One of my friends says that there are two types of confidence: fake and real. The fake one is loud and looks glamorous, but it’s not the one you should seek. It is okay if you are not loud, you can be silent and confident. This I have learned especially working as a tester – I listen a lot, but I still stand my ground and if needed I will express my concerns and risks. It is important to find your own balance of what confidence is for you.

    Being authentic and daring the difference are the best signs of confidence as well: a lot of women seek to be liked by everyone. This is rather impossible – you have to be yourself, it is impossible that everyone would like you, but it is possible to earn respect from your colleagues for the fact that you are being yourself.

  5. Be a role model

    A lot of times we say that the main problem for women not joining tech is the lack of role models. Have you ever thought that some people may see YOU as a role model? We all are different and I can assure you that even if people don’t tell you directly, but some consider you a role model. So, be responsible for your actions, make your decisions clearly because there are people who look up to you. Set the standard. Sometimes people may know less than you and are waiting for you to speak up. From my experience – often people close to you believe in you more than you believe in yourself.

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!

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. 

 

 

 

Quest for Quality 2017: Best conference experience of the year

Early this year, I stumbled upon Quest for Quality conference’s website. I was browsing conferences about testing trying to find a place where I could apply to speak at with my newly written abstract. As very often it goes with first impressions, I liked the design of their website and the general impression this conference had: dev-ops and testing are such a great match which I appreciate a lot in my daily work. To fast-forward a little bit: I was invited to be a speaker at Q4Q2017 in Dublin, Ireland and can honestly say it has been one of the best conference experiences I have ever had. 

At this conference, I was both an attendee and a speaker. First of all, I believe one of the greatest benefits of being a speaker at conferences in general is a chance to meet fellow speakers as well as amazing attendees who are interested in your story. It definitely is an ice-breaker for introvert speakers. In Q4Q2017 there was plenty of that thanks to the great organizers who helped speakers to get to know each other in a really cozy and sincere speakers/sponsors dinner before the actual conference. We bonded instantly and it gave a certain confidence boost to know fellow speakers, support them and get their support as well. During the conference, we got to talk to each other more and I believe that we got some great long-lasting connections.

As an attendee, I was impressed that Quest for Quality had such amazing speakers and I loved the selection of topics. All the topics were linked to the challenges of Quality Asssurance and digital transformation in this fast-paced IT world. I will mention a few of the talks and key learnings from them.

The conference was opened with an introduction from Nikola Šopar who is the Director of QA Services, Comtrade Digital Services – the company which has organized the event. I could relate to his talk a lot and I think it laid a great start for all of the speakers. Nikola talked about the change we are facing: the pace is really fast in platform economy and with that the concept of quality is changing, too. In the upcoming two days – that was actually the main theme for the conference: change and adapting to it.

Andreas Grabner from Dynatrace delivered a keynote “How DevOps is done by Top Performers” which I found extremely interesting. The current motto unfortunately is “deliver crap faster” and this should change. Andreas told a lot of interesting stories about how dev-ops and quality interact and the continuous user feedback driven innovation including Facebook, Etsy, Dynatrace, Verizon and SOFICO. I loved to learn how companies made delivery not only faster, but better quality, too. Monitoring can help a lot in those cases to avoid false positives and get extra information from automated checks. Also, what I loved in this talk was this:

Maik Nogens with “How the XING Team Created a Successful Content Platform from Scratch” had a lot of great concepts to share that everyone should be familiar with in testing. Maik’s story was full of great lessons, so I’m just going include a couple of photos from it:

Talking about wonderful new friends – I got a chance to meet Maja Schreiner who is going to be my roommate during EuroSTAR 2017 conference! After talking for a while it turned out we are both going there and would be willing to split the costs. Funny coincidence and I’m so grateful for that! By the way, Maja wrote a really great blog post about this year’s Quest for Quality in her blog so check it out! Maja delivered a talk “Continuous Delivery Using Crowdsourced Testing” about how her company involved crowdsourced testing into their workflow. I think crowdsourced testing is a really hot topic nowadays and it was great to get some myths about it busted.

On the second day, a great start of the conference was the keynote by Finn Lorbeer from ThoughtWorks called “Building a High Quality Product”. It was my favorite talk because I could relate so much to it. Finn gave great examples and a lot of food (or to be more precise – muffins) for thought.

Another great talk was by Amela Teftedarija and Darko Nikolić who presented “Think Globally, Act Locally – Build Stronger Distributed Agile Teams”. Most of us have experience working in distributed teams and there definitely are some challenges with that. Amela and Darko gave a lot of great tips to build amazing distributed teams and be more considerate towards yours team members.

Lastly, on the second day I also got to present my talk “Testing Big Data to Predict Your Perfect Fit” and it was a blast! I was fighting with a little cold, but having mini jars of honey in the conference venue and helpful staff was definitely a big advantage! Audience was great – I got a lot of interesting questions after the talk and I felt so honored and happy to be a part of this conference.

In conclusion, I highly recommend Quest for Quality conference – you will come back changed and what is most important – the people there are simply magical! Big thanks to name just a few: the best organizers team with Evelina & Nikola in front, wonderful attendees and the best fellow speakers Maja, Maik, Finn, Neven and Amela! Good luck to all of you and see you next time.

With closing smiles and great memories: me & Amela after the wonderful Quest for Quality 2017 experience:
DSC_0041

 

 

 

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.

 

London Tester Gathering Workshops 2017 Impressions

When Ministry of Testing announced a competition to win tickets to London Tester Gathering Workshops, I submitted my entry and didn’t think I’d actually win it. However, social media is the thing nowadays and I must say enormous thanks to 10 testers who entered competition via my lucky URL and made the chances of me winning higher! I cannot express enough on how grateful I am for getting this ticket – workshops for me are the most valuable method of learning. LTGW2017 was a blast!

London Tester Gathering Workshops lasted two days and each of the days had half-day workshop sessions which were fueled with interactive participation. Also, there were 2 workshops happening at once so you always could find a good alternative. Variety of topics didn’t make the choice easy, though! I wish I could have attended them all!

First day of conference (June 29th) I kicked off my day going to Security in the Cloud workshop facilitated by Abby Bangser & James Green. Nowadays a lot of companies are moving their infrastructure to the cloud (my company is not an exception) Amazon Web Services (AWS) are bigger than ever and security is one of the key elements that need to be taken care of.

Abby and James gave a great introduction to Amazon AWS and even helped us to understand Software/Platform/Infrastructure concepts better. Here is one of my favorite slides:
Screen Shot 2017-07-11 at 6.05.08 PM.png

After a small theory part, we actually did hands-on exercises trying to utilize Amazon AWS website, finding security issues in the cloud and discussed on how to avoid these.

3 key take-aways I got from Security in the Cloud:

  1. Cloud services are flexible and make you feel that a lot of infrastructure related tasks are not your problem anymore, but come with some risks and this means that for testers AWS can be just another domain for testing
  2. Make sure that only the wanted files are available to the public (or certain group of people) and nothing else (for example, the whole bucket may be available)
  3. Even logging of processes can unravel restricted information to someone who doesn’t have authorization and they could misuse their rights

Second part of the day I spent in the workshop An Introduction to Complexity and Cynefin for Software Testers with Martin Hynie & Ben Kelly.

I have heard about Cynefin (/ˈkʌnᵻvɪn/ kun-EV-in) before just as a buzzword. I did not know what it exactly is and how it is used, so I decided to finally learn by attending this workshop. And, well… I ended up taking more pages of notes for this workshop than any other.

With a few group exercises Martin and Ben were challenging our known decision & sense making patterns and made us realize that we naturally lean towards putting everything in boxes, but it is more important to get more information, stay open and actually reconsider categorizations we made. A lot of information that we got can be used not only in our careers, but even in personal life. Cynefin is not really a decision-making framework, but sense making.

3 key take-aways from An Introduction to Complexity and Cynefin for Software Testers:

  1. We tend to make premature decisions based on our known approaches and Cynefin could help to make us think about the actual problems, ask questions and challenge our believes by rethinking, breaking issues into parts rather than categorizing
  2. The better you become at something – the more you tend to think that it is obvious. This has no second guessing and may lead to disaster
  3. Questions are indicators: there may be a need to expand discussions. Concerns are very important

Another LTGW day had 2 more workshops and I started my day with Telling the Testing Story – Storytelling for Testers facilitated by Huib Schoots.

In this workshop, we learned way more about storytelling and its importance in every single area of life. Storytelling is rather a tribal thing and we tend to lean towards the people who tell good stories.

Also, we got some hands-on practise in presenting our group flipchart creations and I really felt like the team I was in was sort of a dream team – we didn’t know each other at all before the event and at Huib’s workshop we were made to collaborate, it worked out so well and we loved working with each other. Greetings to the wonderful Malonie, Galina & Andrew! And here is one of our group work creations:

3 key take-aways from Telling the Testing Story – Storytelling for Testers:

  1. Storytelling is a very useful skill to have especially as a tester: it is important to communicate well and manage to convince people
  2. Even your job interviews can go way smoother if you prepare stories on what the company wants and how you have done that
  3. Culture at companies is a collections of stories told

For the grand finale workshop, I went to Traffic, Verbs, Testing, and T-Shirts with Sharath Byregowda & Tony Bruce.

We learned more about REST APIs and how to test them. The very fun part was actually playing a game with t-shirts and forming 3 groups (clients, verbs and servers) in order to understand how the requests work on HTTP: clients would provide stickies with URL to the verbs who then ran to the servers to get the response.

I got to be a POST request and carried back all kinds of API codes returned in various situations.

IMG_1676

Later on we got to play around with a certain website and use curl to do some API testing.

3 key take-aways from Traffic, Verbs, Testing, and T-Shirts:

  1. Sometimes even if the returned code is 200, but body still may be wrong
  2. http://www.any-api.com has many API documentations
  3. Curl can be used for API checks and it is actually very interesting to play around with it in order to test REST APIs!

In conclusion, each workshop was full of content worth sharing and was very useful. I heard a lot of interesting information that I can apply at my work, met amazing fellow testers and gained so much of motivation to read about many concepts I haven’t thought of before.

 

 

 

Breaking the ice in Testing Cup 2017

The adrenaline was rushing to my heart so heavily that I couldn’t sleep the whole night. I kept falling into drowsy mind flow, muscles relaxed, but heart just could not calm down. At around 4 AM birds started chirping outside, I still felt the heat wave, took a cold shower and kept trying to fall asleep. At 6 AM until 7 AM I managed to doze off a few 10 minute intervals and then it was time to get ready. The big day was here. June 9th, the conference day of Testing Cup 2017 where I was doing my first ever conference presentation. 

I was so honored and extremely excited to be invited to speak at Testing Cup 2017 in Gdansk, Poland. The greatest ever thing about Testing Cup is that testers can compete for it! How awesome is that? Teams/individuals participate in a testing competition and can prove themselves to be the best bug catchers! Such a great opportunity for testers in Poland! And take a look how the actual prizes look like:

I arrived on the afternoon of the 8th of June, so sadly, did not see the competition itself taking action, but could join the beach after-party which was an amazing experience! I took a train ride to Sopot (on the way I learned a good lesson about Polish trains – the ticket validation machines are on the train stops only, not on the trains themselves!) and after a walk on the beach I joined the Testing Cup participants & speakers in a bar on the beach. There were snacks, drinks, even a DJ and the fire show, and, of course, the most wonderful view with a special appearance of the rainbow:

DSC_0042-001

After the party, I went back to rest before the big day and here is where we get to the first paragraph of this post. Even if the night hadn’t been wonderful and I was worried, but one of the speakers told me when I asked if they are nervous “I was, for the first talk”, so I believe this is a natural feeling. The good part is that I didn’t feel sleepy at all and could listen actively because of the adrenaline rush.

I arrived to the venue to participate on the second day of the Testing Cup which was the conference day and I haven’t mentioned yet, but the whole competition was in a stadium! This was where we would relax during the breaks or just go to breathe some fresh air:

stadium

The fantastic part about the conference was that it had several tracks! One was purely in English, so I always had what to listen to. To name a few of many great presentations that day:

Andreas Faes talked about his experience of changing beliefs as a tester in his presentation “Losing my religion”. Andreas gave an overview of testing schools, told examples from his professional journey and shared great concepts about testing. I could relate to it so much!

Maria Kedemo delivered a great keynote on testability “Dimensions of Testability”. I cannot stress enough how I agree with the points she made because usually the most common obstacles we face as testers are testability issues.

Ben Simo (better known as “the bug magnet” or “a sort of skilled hacker”) gave a keynote called “An Incredible Mess”. It was one of the funniest talks I have ever seen. Ben shared his story about his experience with healthcare.gov website’s usage and the publicity that was caused by the bugs he reported to them.

And now… what the curious of you have been waiting for – how did my talk go?

I think in general the talk itself went fine, I delivered the content and didn’t feel nervous, but all my nerves went away partially because slides.com just went black once I started the presentation! Even if before we did a tech check (I wanted to make sure it works as I had an iframe which prevented me from using other presentation options then) – all worked well then. However, once I started we had to interrupt the presentation a couple of times and change the laptop (which was not ready for presentation and got some meeting pop-ups!) I think I faced one of the biggest technical problems speaker can get all together, so this just gave me the attitude that – the worst may have happened, so I should just continue and deliver the message the best I can! After the presentation, I really felt like the ice has been broken and the speaker’s words about the first presentation being the hardest were more than truth – it wasn’t as scary as I thought it would be!

In the end, even if I wasn’t too happy about technical issues and got my lessons learned (slides.com never again and always have back-ups!),  I really got inspired by the great feedback I got from the audience. This has shown me that it doesn’t matter even that my presentation had some glitches (of course would be better if it didn’t, but life happens!), people in the end came to hear the content! Nothing can be more rewarding to a speaker than to get a message like this:

And I must say, Testing Cup’s audience was so nice! People were smiling, patient and supportive. Once I went to deliver my talk and saw people’s supportive eyes shining with curiosity, I knew that I am in a safe place!

Huge thanks to the wonderful organizers of Testing Cup and the amazing participants. Also, thanks to my colleagues for sending encouraging messages and believing in me from the very start. Lastly, enormous thanks to such a magical community of testers in social media who are always there to support you and are so welcoming to new speakers!

The ice has been broken. I am ready to speak again!