Takeaways from Rob Lambert’s “How To Thrive As A Web Tester”

Rob Lambert released a new book on testing early this year, with title “How To Thrive as a Web Tester“. Like “Remaining Relevant and Employable in a Changing World” and “The Problems with Software Testing“, the new book only takes a few hours to read through and is focused, this time offering ideas which challenges testers to think more about how they perform their day-to-day work and their skill set. Rob wants us to flourish as testers, and the book provides us with tidbits of actionable items.

Here are a few gems from the book:

  • Understand who your customer is.
  • Your job is to keep up to date with what’s happening, ask how it might affect your job or how you approach testing. Your job is to get involved with new ideas, movements and embrace the technology that floats your boat.
  • Pick something and learn it. It will likely be out-of-date soon, or surpassed by something else. Don’t let that stop you though – just pick something and learn it. What never goes out-of-date is a Tester’s ability to find problems, ask tough questions and work well with others. Focus on developing those skills and you’ll make a great Tester whatever the tech stack you’re working on.
  • The tech moves on, the way we deliver it has moved on, the pace of delivery may change but the same problems exist; how to get people to work well together, how to understand customer’s needs, how to scale, how to make profit, how to dominate a market, how to learn, how to build an effective and efficient businesses, how to stop bugs affecting customers. Same problems, different tech.
  • Your job is to ship software. Sure, if there are problems that will affect the customer or company, you’ll stop the release, but you’ll also work tirelessly to see how you can improve to allow safer releases, better monitoring, better rollbacks, better roll forwards and a more seamless release mechanism.
  • You need to remain relevant, employable and effective to a wider business community. You cannot rely on your employers for your career development and security – that is your own responsibility.
  • Let go of your job role, or what your job description says, and take ownership of the actual work and any problems that surround it. Take on problems others aren’t owning. Or offer to help those struggling with fixing tricky problems at work. There are always problems, and most problems exist between job roles.
  • Testing is the art of asking questions and seeking answers. Never stop asking questions. Study how to ask good questions. Study how to listen for answers. They can come from anywhere, at any time. Good Testers know when to ask questions. They build the muscle memory needed to match patterns, to know when and where to ask, to know what to ask, to know who to ask, and to follow instincts.
  • Good Testers solve problems. Even problems that are outside of the responsibility of Testers.
  • If you aren’t as good as you can be, it’s because you haven’t yet decided to be the best version of yourself yet. It’s as simple as that.
  • We are all, thankfully, different. There is no single model we should all fit. The world would be a pretty dull place if that were the case.

Tracking Numbers

What’s the use of tracking data (total number of story points per sprint, lates, number of added or returned tickets, number of bug reports per month, how many hours it takes automated tests to finish testing a particular app) if we don’t scrutinize them?

And what’s the use of a data scrutiny if it doesn’t have any bearing on what we do, on things where we want to get better at?

Number crunching and analysis only helps if the data we are tracking and the reasons why we are doing it in the first place are aligned.

We Find Ways

Banco De Oro’s slogan came to mind yesterday when a programmer friend and I were discussing how to fix a certain software feature which was becoming increasingly difficult to deal with. My programmer friend preferred not to work on the feature because he says that processing power in report generation will definitely increase several times because of it. The product owners, however, want that feature and would not budge after we told them about our opinion. In the end, we just decided to find a way to make it work.

And that’s what programmers and software testers do in tandem, really. Together, we find ways to make a new feature work as they should. We find ways to ship working software to our clients. We find ways to solve customer concerns as soon as they are found. We find ways to bring life to conceptualized software ideas. We find ways to show magic, creating interesting things out of people’s desires.

About Software Applications And Their Required Regression Testing Time After Each Update

About two years ago, when I was a new software tester in my current company, I started estimating the time I need in performing regression testing on each of the organization’s major products. I wanted to know how much time was enough in order for me to do my tests properly, without rushing and without dilly-dallying, because it helps me prioritize and pace tasks. If asked if I can deliver results after a specified period, I would be able to answer yes or no immediately. If I say I can’t deliver on the initial negotiated time, I would be able to tell my superiors how much more I require to be able to provide the information they want.

For one application, I found out that I have to commit a day, provided that tests are focused, not rushed, without much distraction from everyone else. I got my estimation where I then based all my decisions and made guided expectations. For that product, one day provided enough testing time such that every further project release for that software often went well. There were no troubles in the required testing time. I had no worries in pacing myself well.

That is, until recently. There was a scheduled major release and I told my boss I can finish testing before the deadline but I wasn’t able to, even after giving overtime work. Imagine my surprise: that day, the estimated testing time that I was so sure of looked like it wasn’t enough.

Several days later, I realized two obvious things that I never thought could lead to a disaster in decision-making:

  1. software applications grow in complexity as they continue to be updated, and, because of that,
  2. the regression testing time required for growing applications also needs to increase by a properly factored amount.