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.

 

 

 

 

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.

 

 

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.