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

 

 

 

Advertisements

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!

 

“I have a Craft in me” or Craft Conference 2017 impressions

Second year in a row I got a chance to attend Craft Conference in Budapest. After last year’s event I was very looking forward to this conference – mainly because it is our company’s tradition to give a chance to all the dev team members to attend the event. And, having in mind how wonderfully amazing my colleagues are – Craft is a great conference where we not only learned a lot, but also had our own team building time.

This leads me to community zones. At TED(x) conferences community zones are always very important – they say that anyone can watch the talks online, but people really want to attend the event for meeting new people and for the cool activities to do during the breaks. Well, I must say that Craft’s community zones were definitely moving towards that direction!

The conference had a huge amount of participants (around 2000!), but there were plenty of activities around having in mind that the venue was the Hungarian Railway Museum!

I love this venue choice – last year it was in the same venue (the pic above was taken last year – but I promise, it looked the same) and I was looking forward to try the activities I haven’t tried before. For example, we could take a ride on the little train:

Or my another favorite was small Bosch cycling cars – the only type I can drive properly. I saw this video on Twitter from the afterparty on the first event’s day and it is just hilarious:

The talks ranged quite a lot: from soft skills topics to very technical ones. There were several tracks as well – everyone could choose the talk they are interested in. I think this year I had more topics that interested me as a tester than last year, but there were different opinions as well – it all is a matter of taste in the end.

During the 2 day conference, I heard a lot of great ideas, but here I decided to list 3 my personal favorite talks from Craft 2017 that I highly recommend you to watch (ordered chronologically):

  1. Maaret Pyhäjärvi – Learning in Layers: A Demo of Exploratory Testing. As a tester, I just had to go to this talk! I think it gave a really nice overall image on how exploratory testing can lead you to different areas in a product – it all depends on your start choices. And, oh boy, how much you can find. At my work, I am a note taker, but in this presentation Maaret with the help of a volunteer did a strong style pairing and created a mind map. I loved this idea and can’t wait to actually use it in the new feature’s exploratory testing.

2. Melissa Perri – The Build Trap. As a tester, I often get to be the middleman between product and dev teams. I usually work pretty close with programmers, so sometimes I struggle to understand the importance of reliable usability testing for example. However, this talk shed a new light on the topic and I feel like I learned a lot from product management’s perspective on how actually the real user’s opinions matter – your colleagues are not the usual users.

3. Richard Kasperowski – Building Great Teams: Culture and Core Protocols. A very interesting talk which made me take notes. One of the key ideas that really hit me was that if a person is telling you how they feel – you never should tell them what to do. The fact that they share how they feel (even if sometimes it is a bad feedback in a way) should be accepted, not attacked (with forced suggestions that they should do this or that). Usually as humans we try to “give advice” (as we see it), but that is not what is needed at that point. Also, the talk had on the spot exercises. I went to this talk with one of my colleagues. When we walked out, we both agreed that we feel a little bit changed inside. After doing the exercises together – we learned more about each other and most importantly – ourselves.

And lastly, I must mention that with Craft conference having wonderful speakers in town, there are many Craft Edition meetups in the city happening! This year palinQA Budapest testers meetup that I’m a part of organizing had two consecutive days of meetups with three Craft speakers: Dan North and Emanuil Slavov on 26th of April and Maaret Pyhäjärvi on 27th of April.

Audience really enjoyed both meetups, I heard that for some people the first meetup was the absolute favorite of all meetups we have organized.

While the second day’s meetup had Maaret presenting ‘5 Controversial Ideas to Improve your Impact as a Tester’ and it was indeed pretty controversial. This made the audience extremely active and they asked a lot of questions. It was a wonderful evening.

Overall, I am very happy to have participated in Craft 2017! I met awesome people, had a blast and learned a lot.

Impressions of “How to Break Web Software” by Mike Andrews and James A. Whittaker

Everyday testing for me involves Web Software, to be precise, I mainly test a Web Service. At work we have a company book shelf and there were no surprises to encounter  “How to Break Web Software: Functional and Security Testing of Web Applications and Web Services” by Mike Andrews and James A. Whittaker. As it was the only testing related book in the shelf at that point – I decided to read it.

This book was written in 2006 so you can imagine that a lot has changed since! Web Software is bigger than ever. Even a regular website may use multiple web services. I did smirk a lot on some of the terms like Web Bugs (I never heard this term before: it would always be called a tracker or a tracking pixel in my environment). Also, to be honest, some of the tools or examples including IE6 made me cringe a little bit and felt a bit outdated, but…

“How to Break Web Software” gives very good foundation for Security Testing Web Software. I haven’t had much experience with Security Testing except for  one of the days in the 30 Days of Testing where I got to play around with Gruyere.

SQL injection, cross-site scripting, session hijacking and cookie poisoning (web cookies not the ones you brought to work to your colleagues as advised in “Explore It”) are just a few attacks which are in this book. Attacks have very clear structure: when to apply it, how to conduct it and how to protect from it.

Not only that the book describes attacks clearly, but it explains the way Web Software works and introduces its terms and technologies. I realized that the last chapter called Web Services would have been like a gold mine for me from the first day when I started working here. It describes technologies I have to work with daily.

“How to Break Web Software” gave me a better understanding of Web Software and even how to be safer in the Web applying some tips mentioned in the book. The attack descriptions were a great way to learn about the testing techniques heard about before, but the best way to learn them better is to apply them practically.

 

 

Fail Better in 2017: Story of Unaccepted Conference Speaker

It’s that time of the year again: Christmas, relatives, and, a great opportunity to reflect on the past year. I have decided to write about one of the important lessons I had a chance to experience: failing to succeed as a conference speaker.

It is not as drastic as it sounds like – I never actually tried it before, so I just did not get accepted. However, I somehow thought that it will be easier, but everything takes time. After attending several conferences, I thought I have something to share that is really important and should be heard about: I wrote my first abstract and started applying to the testing conferences. You can as well find some tips on how I started this journey in my previous post:  Where to start if you want to be a speaker.

I failed to get accepted to around 5 conferences.

When I got the first reject, I tried to rationalize it: its lineup actually ended up having the majority of men with more than 20 years of experience. Not that I have anything against experienced professionals who tend to be men, but I felt that maybe organizers were not ready to believe that there are more good female speakers even if they don’t have many years of experience. This calmed me down a bit and I started thinking that maybe this is just a matter of external conditions and coincidences.

After a few more rejects, I realized something: there are many reasons why you may not be accepted and don’t let it bring you down. Keep trying.

Sometimes reasons may be actually your topic: maybe conference is interested in a different kind of talk, other times it could be that there are just more stronger and better candidates than you.

A great thing to do is to actually ask why your talk did not get accepted. I did ask for it in all my rejects, but to be honest, I received the letter back only in one of the cases, however, I really appreciated it. The feedback letter explained situation and gave me some information that I couldn’t see: there were more than a 100 candidates and even if my topic was nice, but this year there were some other topics that got prioritized.

So, I started thinking, that if my topic gets overbeated by some stronger topics, maybe I should start thinking of a stronger topic, too. Something that would not get rejected easily.

All the “No” answers actually motivated me to work harder and try again maybe in a different way. So, the advice for this year (my favorite quote ever and in general the motto of my life which I use way too often) is:

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

Happy 2017! Don’t be afraid to fail – it will make you better.

 

 

 

How “Clean Code” by Robert C. Martin helped me to get my automation tests going

Even if I am a pretty decent bookworm, it took me months to finish “Clean Code”! It definitely was not an easy evening read for me (even though I do know some people who read it overnight) and it was the very first book I have read on programming.

In the first years of my testing career my tasks were limited to setting up my own testing environment and manual testing (very often with manual test scripts). No wonder it started making me feel like a monkey and bored to death!

When I changed my job to being the lone tester in a startup, my time resources became very limited. Manual routine tasks started to hurt a lot, so automated UI tests became a long term plan. Luckily I have wonderful colleagues who gave me a lot of needed support to get going.

In the very start as a very beginner programmer (never done it before except in university basic classes) and a practical person, I just created some automated tests based on examples I found. My main purpose there was to make it work. If it works – then I move on to the next thing I want to automate, google, find a solution, modify and move on.

Then, the fun began. We did want my automated tests to be actually used and scheduled. For this purpose GitHub was chosen to store it and for that I had to start creating pull-requests and get them reviewed by a senior Java developer. It was definitely terrifying. First pull request I made got 30 comments in one review session.

The comments were super useful, but it made me realize so well that to make it work is not enough – we need to make it maintainable, readable not only to me, but others, and scalable for the future. There were so many things I did not know about programming. And there came an advice from the developer for me to read “Clean Code” by Robert C. Martin.

I did read it and I realized how important it is to actually write clean code. It definitely should be a long term goal of everyone.

Some very important points mentioned in the book which I loved:

  • Meaningful names: Code has to be readable and understandable to others as well, so use intention-revealing names without disinformation.
  • The single responsibility principle (SRP): there should be only one reason (responsibility) for class or module to change.
  • Tests should be clean: readable! One assert per time if possible and single concept per test.

“Clean Code” is full of useful advice on how to make your code cleaner. It includes some easy tips like the ones I listed above, but it also goes in depth and looks into code examples and tries to make the code cleaner hands-on.

Getting software to work and making software clean are two very different activities.

I think the quote above sums up the main idea of the book. Very often whoever is doing programming forget this very important aspect: clean code can make your life way easier in the long run and even help you to avoid making mistakes (or bugs!).

Months later, I finally finished this book (reading bit by bit) and my automated tests are now scheduled for nightly runs. I am far from being a great programmer, but, due to a lot of useful code reviews and information obtained from “Clean Code”, I have improved my code quality a lot and can make changes way easier than before.

Even if you are a not a full time programmer, but have to do some programming, do not underestimate the power of clean code. It is not only about making it work, it’s about making it work in the long run, too. It will scale, get used and be easy to maintain if you work on writing cleaner code. 

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).

 

 

 

Learnings from “Explore It!” by Elisabeth Hendrickson

Exploratory testing is mentioned quite often in the testing world and I believe that the best book to start learning about it is Explore It! Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson.

This book is pretty short (186 pages), written in a wonderfully smooth and easy to read style, and, it is full of practical tips and tricks for testers. I felt that a lot of things I’ve read in the book I always wanted to express myself, but never found the right words.

Elisabeth starts with foundations about exploring and why it is important. What I liked a lot in the first part of the book was the definition of testing which allowed me to finally know how to clearly answer what’s the difference between testing and checking:

Testing = Checking + Exploring

You’re not done testing until you’ve checked that the software meets expextations and you’ve explored whether there are additional risks.

Very often some colleagues may not understand that testing is more than checking the requirements – there are many silent risks which may cause problems and to find them we need to explore. I also loved Elisabeth’s example of a net: you can imagine software covered in a net and the better coverage there is of the checks, the finer the weave is. However, checks may not cover some spots, so we must explore to find areas where we should improve the net weave.

After some foundations, this book provides many practical tips on how to explore. It teaches you how not to get overwhelmed with the areas to explore, how to create charters and lists many helpful methods for exploration. They are explained in a clear manner and their summary is added in an Appendix 2 of the book. You may have heard of same author’s Test Heuristics Cheat Sheet which is pretty similar to the one in the book.

One more thing that I found especially useful and right on point was the last part of the book called “Putting It in Context”. Not only does it have a lot of useful information on testing itself, but also Elisabeth includes several valuable tips on the communication part of the tester’s job (and.. I love this topic!).

What struck me the most was that very often testers end up “creating” new requirements which may cause some tension in a team. This is very common in a life of a tester as the more you use the product – the more areas you uncover and some of them may not have their requirements specified. In this situation, programmers may get a bit hurt that the tester is coming up with never mentioned scenarios. Here Elisabeth gives a great tip for testers: try to get into requirements meetings. Testers must be present when the requirements are being created together with a programmer and a product manager. In this way, risks can be discussed and clarified together avoiding silent requirements popping up in the late stages of the product which may expand the scope. And, Elisabeth gives a brilliant tip on how to get into those meetings:

Bring cookies. The other people involved are less likely to kick you out of the meeting if you come bearing chocolate.

In conclusion, “Explore It!” was a pleasure to read. It is a very helpful book on how to express yourself better and how to do that sometimes overwhelming job of a tester more systematically. I feel like I have gained confidence as a tester after reading this great book. Nevertheless, I recommended it to some of my non-tester colleagues as I am sure that it gives a good and easy to understand insight to testing.