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. 

 

 

 

Advertisements

Why phrase “pass the QA” makes me cringe

Today I heard someone say “pass the QA” and in this post I will share why I believe that we should cross out this phrase from all dictionaries where it is included because it is just wrong use of definitions.

Let’s break this phrase into two parts: QA and pass.

What is QA?
I am talking here in a sense of quality assurance. Okay, that sounds clear, however, what is quality assurance?

A lot of people mix up QA and testing on a daily basis. There have been various discussions about it and I mostly lean towards the point of Michael Bolton in his post Testers: Get Out of the Quality Assurance Business. It was an eye opener blog post for me: my first job as a tester even had it in the title “Software Quality Assurance Analyst”. Later on, I turned into QA Engineer. However, I am a tester.

Michael Bolton in that blog post gives so many valid points, it’s like a gold mine. It is one of my favorite ever posts about testing. It basically stresses that as a tester you cannot really assure quality. You just inspect it and help to improve it. You test.

QA is not a person or the department of certain type of professionals. It is a task of everyone in the company to work towards assuring quality. Tester may play a huge part in it, but the actual “action” assurers of quality usually are programmers because they actually are making changes to the quality level. And, let’s not forget the main part:

Assuring quality is an ongoing task/goal of the company.

What does it mean to pass?

In testing passing the test means that the test has passed based on its acceptance criteria.

Test may be built from multiple specific test cases or lead by charters. However, the defined acceptance criteria should be clear.

Passing of tests could be related to the common question in testing: how much is it enough to test? Sometimes the answer is not that obvious. There may be various scenarios, explorations to be made and a common standard should be discussed with product management team on what are the requirements and if edge cases should be addressed for the initial release/iteration.

Why don’t I like the phrase “pass the QA”?

After explaining both parts of this phrase, I can say that for me saying “pass the quality assurance” makes almost no sense.

Quality assuring is an ongoing task, so it is never going to end. You cannot pass the quality assurance as it is, but you can pass the test.

I do understand the intent of this phrase and why it was used: it was meant to say that testing will be completed with no show-stopper issues and will pass the acceptance criteria.

Let’s not underestimate the power of wording. Saying “pass the QA” can definitely be misleading. However, sad news are that this term is quite popular to describe the teams of testers. In this case, let’s spread the awareness of the differences between QA and testing – we all are doing QA in the company, but only testers do testing as their full time job (programmers do a fair deal of testing as well, but it is not their main responsibility usually).

 

 

 

Testing challenge was amazing! – Day 31 of 30 Days of Testing

When I decided to join 30 Days of Testing challenge, I did not have much expectations. Now, after a month of sticking to it honestly and sincerely every single day, I can admit that I have learned a lot and met some wonderful people on the way!

Here is the list of all challenges with links to the posts I wrote about them:

  1. BUY ONE TESTING RELATED BOOK AND READ IT BY DAY 30:
    Bought and read “Explore It!” by Elisabeth Hendrickson
  2. TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK:
    What I’m doing at work
  3. LISTEN TO A TESTING PODCAST:
    Testcast Podcast “Testing is Dead”
  4. SHARE A TESTING BLOG POST WITH A NON-TESTER:

  5. READ AND COMMENT ON ONE BLOG POST:

  6. PERFORM A CRAZY TEST:

  7. FIND AN ACCESSIBILITY BUG:

  8. DOWNLOAD A MOBILE APP, FIND 5 BUGS AND SEND THE FEEDBACK TO THE CREATOR:

  9. CREATE A MINDMAP:

  10. FIND AN EVENT TO ATTEND (ONLINE OR FACE TO FACE):

  11. TAKE A PICTURE OF YOUR TEAM:

  12. DOODLE A PROBLEM:

  13. FIND A USER EXPERIENCE PROBLEM:

  14. STEP OUTSIDE OF YOUR COMFORT ZONE:

  15. FIND A PROBLEM WITH AN E-COMMERCE WEBSITE:

  16. GO TO A NON-TESTING EVENT:

  17. FIND AND SHARE A QUOTE THAT INSPIRES YOU:

  18. FIND A BROKEN LINK. AND REPORT IT:

  19. FIND AND USE A NEW TOOL:

  20. FIND A GOOD PLACE TO PERFORM SOME SECURITY TESTS:

  21. PAIR TEST WITH SOMEONE:

  22. SHARE YOUR FAVOURITE TESTING TOOL:

  23. HELP SOMEONE TEST BETTER:

  24. CONNECT WITH A TESTER WHO YOU HAVEN’T PREVIOUSLY CONNECTED WITH:

  25. CONTRIBUTE TO A TESTING DISCUSSION:

  26. INVITE A NON-TESTER TO A TEST EVENT:

  27. SAY SOMETHING NICE ABOUT THE THING YOU JUST TESTED:

  28. SUMMARISE AN ISSUE IN 140 CHARACTERS OR LESS:

  29. FIND AN OUT BY ONE ERROR:
    Off-by-one error hunt

  30. GIVE SOMEONE POSITIVE FEEDBACK:
    Give someone positive feedback

     

     

How I helped the account manager to test better – Day 23 of 30 Days of Testing

HELP SOMEONE TEST BETTER

Quality of a product is a very important topic to anyone in the company, so ability to quickly check real-time status of major product’s KPIs is a great skill to have.

In my company, very often some of the checks are done by our account manager. Imagine a situation where a partner writes in with a problem with web-service which your company is delivering. Account manager is usually the first person to read this, check the problem and reply to the partner. In other scenarios, account manager may just need a quick check of certain partner service quality before making any kind of communication step with them. Have in mind that sometimes other colleagues are not able to help immediately, so account manager would clearly benefit from knowing how to execute some checks independently.

Our account manager is a great learner and has been very open to get to know more about the product, so we arranged a meeting to talk about my beloved monitoring tool – New Relic.

I have explained to him some basics of New Relic: where to find dashboards, how to see queries behind each dashboard, how to make your own queries. We created some queries together to check a few important questions and modified existing ones to get the grasp of how to build queries if you don’t know where to start.

Of course it will take some time for the account manager to get used to this new tool, but I’m sure that he got a good background now and will be able to check out some of important questions real-time.

It was very fun for me to share knowledge and we even found out together that one of device types for our web-service in the last 2 weeks was a car, specifying which car it was we learned a fun fact – our web service was used by Tesla car owners.

 

Where to start if you want to be a speaker? – Day 14 of 30 Days of Testing

STEP OUTSIDE OF YOUR COMFORT ZONE

After attending a few conferences, I realized that a lot of us may feel Impostor syndrome when it comes to professional knowledge. Its definition in Wikipedia states:

Impostor syndrome is a term referring to high-achieving individuals marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

This should not happen, because we all have unique stories and career advice to share. So, why not to step outside of the comfort zone and become a speaker?

In one of the conferences I attended the after-party and a couple of speakers shared their road to becoming a speaker. What inspired me the most was that they stressed that you already have a “No” by default, so why not to try applying to the conference and suggesting your topic until you get a “Yes”? It cannot get worse because you already have a “No”. This is how many speakers actually became speakers – by trying to use each chance they have and not giving up.

Working on becoming a speaker has been recent stepping outside of the comfort zone for me. I still need to work very hard and actually achieve my goal, but I have collected a few valuable tips which can help you to get started as well.

  1. Think of your knowledge and passions to decide what topics you could talk about.
    As a professional you definitely have tools or methodologies you use. These could be easily transformed into a useful presentation for others. Especially, if they are made of advice and tips on how others could improve their work. Some examples that I have noticed often are “Responsive Design” or “How to improve your Selenium tests”. These topics are specific enough and a lot of people may be interested in hearing more about it. Also, you could think of something which is not that common but you are passionate about. It can be your own success story, or, area that interests you. For example, maybe you’re passionate about Internet of Things and could share what you’ve learned about its testing so far?
  2. Read and watch online resources
    Don’t be afraid to search for information online on how to become a speaker. Recently I found a great blog post on how to write an appealing abstract for the conference, and, noticed a soon approaching webinar on Conference Speaking 101 by Lee Copeland. These resources are free, but definitely very valuable.
  3. Find a mentor
    There are many speakers who are willing to help you to become a speaker. One of the great ways to find them is to apply for Speak Easy programme which is free. There you get an experienced mentor who helps you to build your talk and gives you a lot of useful advice. I have joined it and my mentor has been giving great thought-provoking feedback (some of it inspired this blog post). Also, recently Maaret Pyhäjärvi  volunteered to help mentor new speakers and organize Signature Webinar Series with Ministry of Testing.
  4. Practise speaking in your company and local events
    The best way to get experience in public speaking is to start little by little and grow your audience. In my company every two weeks we organize a Secret Gathering where anyone from company can share their discoveries or work details if they want. This helps both to understand the team better and also practise your own presentation skills. When you are better in presenting in smaller groups, why not to give a go giving a speech in a local meetup? If you’re in Budapest and would like to talk about something QA related – feel free to contact me and join Budapest’s QA meetup as a speaker.
  5. Don’t give up
    Becoming a speaker definitely requires a lot of patience and hard work. I am sure that I will first get multiple rejections before getting an invitation to actually speak. However, only trying we can actually achieve our dreams.

Testing community is great and the more people we get involved in it – the better. Join me trying to step outside the comfort zone and bringing in some new voices to conferences.

 

Testing web accessibility – Day 7 of 30 Days of Testing

FIND AN ACCESSIBILITY BUG

Accessibility refers to the design of products, devices, services, or environments for people who experience disabilities. – definition from Wikipedia

There are various kinds of disabilities and points to test web accessibility in. I found a website with a variety of articles on web accessibility called WebAIM. Introduction to web accessibility listed 4 major categories of disability types (taken from WebAIM):

  • Visual (blindness, color-blindess, low vision)
  • Hearing (deafness, hard-of-hearing)
  • Motor (inability to use mouse, slow response time, limited fine motor control)
  • Cognitive (learning disabilities, distractibility, inability to remember or focus)

Keyboard accessibility can be considered as a low-hanging fruit because definitely not all websites are keyboard-friendly. Thus, it did not take me much time to check a few websites and learn that:

  1. My company’s product is not keyboard accessible (this turned out to be a never-defined requirement which may never become defined)
  2. Yahoo’s Home site does not create a hover effect when you tab on article’s Comments. It does tab nicely and gives impression of working on all other icons (like Love):
    Screen Shot 2016-07-07 at 4.46.11 PM

These issues are rather minor, but I would expect Yahoo (being such a giant website) to make Tab accessibility rather more user-friendly and create hover effects on all items.

On Twitter I noticed Visual accessibility‘s bugs. It intrigued me and I checked out Spectrum Chrome extension. This rather simple tool allows you to see instantly how people with different types of vision deficiency see the website.

I thought of games including many colors and checked Bricks Breaking. With normal vision it looks like this:
Screen Shot 2016-07-07 at 6.53.43 PM
A person with achromatopsia could hardly play this:
Screen Shot 2016-07-07 at 6.53.51 PM

For Hearing Disabilities screen reader tools can be used. One example could be NV Access free tool. I really wanted to try it out, but it supports only Windows OS.

Challenge like this raises accessibility awareness. It is very important to build your product smart and accessible to all kinds of people. Living with a disability already makes life more difficult, so let’s try to work on making the Web a friendly place to everyone.

Why you should improve your test automation code – Day 5 of 30 Days of Testing

READ AND COMMENT ON ONE BLOG POST

Did you know that it’s quite easy to find great testing blogs following just one blog? 5 Blogs is the one! Everyday there is a post with 5 best blog posts read. This blog has been a huge help for my 5th day’s challenge. I got a big list of great articles and chose Learn Development Practices To Improve Your Test Automation Code by Jeroen Mengerink.

This article pretty much expressed what I’ve learned myself. I started coding at my current job wanting to automate some Web UI tests with Selenium. In first month I was googling a lot, reading practical examples and playing around with code. My main focus was to make it work: if I want it to click on a button, it should do that.

I was glad to have something to show: I could run my code and a lot of operations I used to do manually would quickly be executed in the browser. However, even if my code worked, but it was not scalable at all.

After seeing my interest in coding, company’s developers decided to help me and move my project of automated tests forward. This is how my code started to be reviewed. I must admit that I was terrified. My first pull request got around 30 comments about structure, naming, all kinds of conventions. The main advice from the developer was to read “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

With time passing, I did read bits of the book and started noticing patterns of what mistakes I usually do and a lot of comments under my pull requests would be known conventions which were mentioned in the book. I improved my tests according to feedback I got and… it felt great. I really value all kinds of comments as usually they are helping me and my code to be better.

Thus, I definitely can say from my own experience, that if you want to do test automation, then you have to learn some software development practises as well. This is exactly what article I’ve mentioned in the start is saying: software development conventions are very beneficial to you. I cannot agree more.

Development practises ease your automation work: it is easier to add new tests, you don’t get lost in your own code (with time it’s going to expand), it is easier to refactor your code and change it when the need comes.

Code improvements even become like an addiction in the end – you want to refactor more and more to make your code cleaner and nicer to work with. Do not forget to invest some time to that because if you don’t – you will lose way more time trying to maintain messy code.

are-you-too-busy-to-improve2.png

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

SHARE A TESTING BLOG POST WITH A NON-TESTER

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

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

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

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

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

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

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

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

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

dt000613

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

LISTEN TO A TESTING PODCAST

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

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

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

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

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

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

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

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

TAKE A PHOTO OF SOMETHING YOU ARE DOING AT WORK

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

13570268_10209801873230058_84405356_o

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

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