Lessons learned in Agile QA testing

Original post published here. More about Daneez Owais.

Quality Assurance is a fun job especially if you are an inquisitive person like me because when curiosity doesn’t actually kill the cat; it makes a better product. Quality Assurance allows you to learn & develop techniques for looking at a product in new ways. Each product requires a different approach to testing. As my previous manager used to say:

“How many ways can you sketch a picture of a cup? Each time you look at it, you will see a different side to it!”

My journey started roughly 10 years ago when I worked at a traditional software development company. I started with testing sales reports for the clients. Many hours and days were spent making sure that each report was just right. But, is a product ever going to be just right? No! that’s because a product evolves over the course of its development and it continues to evolve after the release when your users feel that they can get better results with some changes. Gone are the days when you create a product and present it to the clients on a platter stating, “This is all we can give you so learn to work with it”.

My journey then progressed to moving to an Agile development environment. Alice was truly lost in Wonderland! Fast paced, collaborative, and learning new concepts while always on the go. When in Agile your entire mindset needs to be flexible and ready to evolve. After all that IS the definition of “agility”. For me personally, I ended up wanting to log in to work all the time wondering what will happen now? Was some new bug found? I wanted to know and I wanted to reproduce it. (No don’t worry I did not log in all the time!).

So, in this journey of testing in Agile, here are the lessons learned:

1. Find bugs — A bug is a bug ONLY if it can be reproduced multiple times, not just by you, but also others in your team.

2. Be clear & concise — Be very clear and concise in writing the bug tickets! The developer who is reading the ticket was not sent the login credentials that you used, in a dream the previous night. Help the poor chap by putting that in the ticket along with every step you took to get to the problem.

3. Pick and choose your battles — Some product changes are mere enhancements so accept them as that. There may be other projects with greater priority so don’t bother the developers about your idea just yet, but always document it.

4. Stick to your guns — When you have chosen your battle and decided that it is worth standing up for, then chase the developers all the way into the kitchen while they make their coffee and try to hide from you. Prove your point with example scenarios of how you are visualizing the issue.

5. Meetings and meetings and then some more meetings — Daily standups (no, I was sitting in my chair because I worked remotely) and multiple ones! Oh boy you better have your status on what you have been doing every day ready for those scrum masters, product owners and then, your own manager. They mean business when they want to know where you are in your testing and what the delays are and no this is not the same as micromanaging. It is an awesome way to keep all the teams in the loop.

6. Story points? What story are points? Grooming meetings are where you look at the backlog together with the developers, and the scrum masters to decide priorities. Where the scrum master keeps asking “how many story points?” (and you secretly (and) quickly google what story points or what scrum poker is — oh wait it is just an estimation of how long it will take to test?)

7. Understand the issue or requirements even if means harassing people — In the traditional environment, it was very common to get a ticket or a print out of the screen shot of the issue with a written instruction “pls test” and not be able to understand it (because it was not clear and yes, a picture is worth a thousand words but NOT in this case). Then you walk up to the developer’s desk and demand an explanation of the problem that was fixed. Not in Agile, you will learn to document each question you have. Make sure it is written down on the ticket so people can see where there is a delay. Although I do miss watching the developer run out the door as I am walking towards his desk (here comes the witch either on the beam (google beam robot) or in person), or the developer (you know who you are) who snuck in from another door of the office to avoid crossing his managers office (who would suspect that he was walking to my desk because I had found a problem), to quietly ask me what I had found so he could fix it on the side without his manger knowing. Alas, the sad part was that it was part of my job to keep the managers in the loop.

8. Gotta love those DevOps guys — Can’t log into the QA environments at all? Where are those DevOps guys? Oh no, they are all on vacation this week. What did they do to the environments now? Uh-oh, it wasn’t them at all but the developer in charge of the environment making code changes and breaking the environment in the process. Be patient and wait for them to fix it. Make your request and then forever hold your peace.

9. Works in QA but not in stage? If it works in a QA environment, that doesn’t necessarily mean it will work in stage so check it again on stage! Remember drawing a cup and getting a different result each time? Just like proof reading a document, it never hurts to read it 50 times (I think I got tired of reading this one after the 20th time)

10. Browsers, browsers & more browsers — Make sure the website works in all the new browsers out there. Do not give the client a response like, “Sorry our site only works in Google Chrome so download it!” The user comes first. Your intention has to be to make it easy for them, not easy for you (success I only need to test it one browser and do the happy dance). Is it responsive? Hmm what is that? Does it work on all different screen sizes mobile and web? Mobile companies keep on releasing new bigger and smaller devices. The product should work in all otherwise you be in trouble.

11. Project overload or actually increase in knowledge base? Work in cross-functional teams on different projects. It helps to understand and know the product inside out.

12. Walk down the memory lane — Retrospective meetings — what went well in the sprint? l I think the QA team did great (I am part of that team so that is the first thing to point out!) What went wrong? Where do I start? The user story is supposed to be small and concise not a book about the requirements. Lessons learned? Keep user stories short and make sure the UI/UX design matches what you are stating in your ticket in words. Oh, and in future please don’t tell me at 3 pm that you want this to go out tomorrow at 9:00 AM.

13. Sharing IS caring — Don’t keep it all to yourself! Share knowledge even if it means sharing something someone might already know. Maybe they have a different perspective to the knowledge. Share knowledge about the product and its features or a new bug you discovered while doing ad-hoc testing. You never know maybe somebody else found the same issue and already added a ticket — this helps avoid duplication.

So all in all whether traditional or agile, be nice to your developers and product teams. They have feelings and ideas too. Don’t build your own 2.5 inch temple on the side and stand alone in it (as they say back home — curious where that is?). Creating a better product requires teamwork and a passion for the product. Quality Assurance is an important job from start to the end — know it and believe it. Don’t just follow a straight path, make left or right turns and sometimes U-turns too and you may just run into an undiscovered bug. Think outside the box and help others do it too.