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

Docker: A Dockerfile to Fix the “Call to undefined function pg_connect()” Error when Using PHP with Postgres

When integrating a PHP application connecting to a PostgreSQL database, both services running as Docker containers using the official PHP and Postgre images, you might encounter (as I have) an error that looks something like this:

    Uncaught Error: Call to undefined function pg_connect() in ...

It’s actually a simple error, which means that there’s something wrong with the connection between the app and the PostgreSQL database, but when I first stumbled on it I had a hard time finding out what I needed to do to fix it. There was definitely something missing from the Docker setup, but I did not know what it was until I sought help from a teammate.

Apparently the official PHP docker image does not contain the PDO and PGSQL drivers necessary for the successful connection. Silly me for assuming it does.

The fix is simple. We have to create a Dockerfile that updates our PHP image with the required drivers, which contains the following code:

FROM php:7.1-fpm

RUN apt-get update

# Install PDO and PGSQL Drivers
RUN apt-get install -y libpq-dev \
  && docker-php-ext-configure pgsql -with-pgsql=/usr/local/pgsql \
  && docker-php-ext-install pdo pdo_pgsql pgsql

Easy peasy. And to run this Dockerfile from a docker-compose.yml file, we’ll need the build, context, and dockerfile commands, replacing the single image command that does not use a Dockerfile:

version: '3'
services:
  php:
    build:
      context: ./directory/of/Dockerfile
      dockerfile: ./Dockerfile
    # All your other settings follow ...

And that should be all that you need to do! 🙂

Notes from David Bryant Copeland’s “Build Awesome Command-Line Applications in Ruby 2”

The experience of writing and running automated checks, as well as building some personal apps that run on the terminal, in recent years, has given me a keen sense of appreciation on how effective command-line applications can be as tools. I’ve grown fond of quick programming experiments (scraping data, playing with Excel files, among others), which are relatively easy to write, powerful, dependable, and maintainable. Tons of libraries online help interface well with the myriad of programs in our desktop or out in the web.

Choosing to read “Build Awesome Command-Line Applications in Ruby 2” is choosing to go on an adventure about writing better CLI apps, finding out how options are designed and built, understanding how they are configured and distributed, and learning how to actually test them.

Some notes from the book:

  • Graphical user interfaces (GUIs) are great for a lot of things; they are typically much kinder to newcomers than the stark glow of a cold, blinking cursor. This comes at a price: you can get only so proficient at a GUI before you have to learn its esoteric keyboard shortcuts. Even then, you will hit the limits of productivity and efficiency. GUIs are notoriously hard to script and automate, and when you can, your script tends not to be very portable.
  • An awesome command-line app has the following characteristics:
    • Easy to use. The command-line can be an unforgiving place to be, so the easier an app is to use, the better.
    • Helpful. Being easy to use isn’t enough; the user will need clear direction on how to use an app and how to fix things they might’ve done wrong.
    • Plays well with others. The more an app can interoperate with other apps and systems, the more useful it will be, and the fewer special customizations that will be needed.
    • Has sensible defaults but is configurable. Users appreciate apps that have a clear goal and opinion on how to do something. Apps that try to be all things to all people are confusing and difficult to master. Awesome apps, however, allow advanced users to tinker under the hood and use the app in ways not imagined by the author. Striking this balance is important.
    • Installs painlessly. Apps that can be installed with one command, on any environment, are more likely to be used.
    • Fails gracefully. Users will misuse apps, trying to make them do things they weren’t designed to do, in environments where they were never designed to run. Awesome apps take this in stride and give useful error messages without being destructive. This is because they’re developed with a comprehensive test suite.
    • Gets new features and bug fixes easily. Awesome command-line apps aren’t awesome just to use; they are awesome to hack on. An awesome app’s internal structure is geared around quickly fixing bugs and easily adding new features.
    • Delights users. Not all command-line apps have to output monochrome text. Color, formatting, and interactive input all have their place and can greatly contribute to the user experience of an awesome command-line app.
  • Three guiding principles for designing command-line applications:
    • Make common tasks easy to accomplish
    • Make uncommon tasks possible (but not easy)
    • Make default behavior nondestructive
  • Options come in two-forms: short and long. Short-form options allow frequent users who use the app on the command line to quickly specify things without a lot of typing. Long-form options allow maintainers of systems that use our app to easily understand what the options do without having to go to the documentation. The existence of a short-form option signals to the user that that option is common and encouraged. The absence of a short-form option signals the opposite— that using it is unusual and possibly dangerous. You might think that unusual or dangerous options should simply be omitted, but we want our application to be as flexible as is reasonable. We want to guide our users to do things safely and correctly, but we also want to respect that they know what they’re doing if they want to do something unusual or dangerous.
  • Thinking about which behavior of an app is destructive is a great way to differentiate the common things from the uncommon things and thus drive some of your design decisions. Any feature that does something destructive shouldn’t be a feature we make easy to use, but we should make it possible.
  • The future of development won’t just be manipulating buttons and toolbars and dragging and dropping icons to create code; the efficiency and productivity inherent to a command-line interface will always have a place in a good developer’s tool chest.

The Harajuku Moment

On a chapter from Timothy Ferriss‘s book titled “The 4-Hour Body“, he talks about something significant called the Harajuku moment, described as:

.. an epiphany that turns a nice-to-have into a must-have.

The expression actually came from a realization Chad Fowler (programmer, writer, co-organizer of RubyConf and RailsConf) had in Harajuku with friends some time in the past, while window shopping and lamenting how unfashionable he was. He noticed the tone of helplessness in his own words as he talked about his obesity, and felt angry at himself for being an idiot who went with the flow, making excuses, for many years.

After that defining moment, he turned things around and lost nearly a 100 pounds.

Two years in a row of annual physical exams (2015-2016), I was told that I have hypertension. The previous years I also felt that I tire quickly, becoming more so as the days went by. I’m just over 30, skinny, and believed that I should still be in my prime but was not. I wondered why things turned out the way they did, and eventually recognized that existing habits did not help me become the healthy person I thought I was.

I’m now performing weight-lifts and body-weight exercises 4 times a week, and is in my best shape in the past 10 years or so. What’s interesting is that making the change was actually fun and somewhat easy, very unlike the grueling and exasperating experience I initially thought it would be. I plan to keep things up, gaining as much strength as I can and keeping body fat percentage minimal.

What the Harajuku moment tells us is that, often, on most days, we have insufficient reason to take action. We only have nice-to-haves. We tell ourselves it would be nice to get fit, go on a date with that someone we really like, have a well refactored code, travel internationally, or learn a new skill. But the nice-to-haves do not give us enough pain to move forward. That’s why we sometimes feel we’re stuck in a rut.

Our nice-to-haves must first turn to must-haves before we can take advice and act.

Running Application Audits with Lighthouse

It was only recently that I was made aware of Lighthouse, a relatively new tool for running notable audits for web apps. It’s an open-source tool from Google, and can be found inside Chrome’s DevTools under the Audits tab.

Here’s what it looked like when our team tried it on a recent project (click GIF for a full view on another tab):

Running Audits with Lighthouse

The results:

Accessibility, Best Practices, and SEO Audits

Apparently we did good on accessibility, SEO, and best practices. We don’t usually test for these things, but it’s nice to know that we do enough on them. The application running on localhost wasn’t configured to run on HTTPS yet so it’s about right that we failed that audit for best practice. It’s also true that our app was designed to have small font sizes.

Performance Audit

What’s interesting to see was the dreadfully poor app performance. Throttling our page on a mobile device with 3G connection, it took at least 20 seconds before anything appeared on the page. That’s not good.

And some culprits:

Performance Audit: Opportunities for Improvement

It seems we can do better with our images and style sheets. And it also looks like our JS takes too long to boot-up. We don’t exactly do high-detail performance testing at work so it is awesome to have such a quick audit report from within the browser that notify us about such issues early. At least we’ll know the areas where there’s room for improvement right away.

There’s no excuse to not testing performance (as well as SEO, accessibility, and best practices) on a web app anymore, as far as tools are concerned.

Five People and Their Thoughts (Part 6)

Some engaging articles I’d like to share today:

  • The Failures of ‘Intro to TDD’ (by Justin Searls, about classic test-driven development, code katas, what TDD’s primary benefit actually is, mocks, and discovery testing)
  • Branching is Easy. So? Git-flow Is Not Agile (by Camille Fournier, on Git, tooling, teams, developing software with agility, how easy it is to create feature branches with Git, and some reasons why you don’t need it)
  • What’s Wrong With Estimates? (by Yorgos Saslis, about estimates, why we are being asked to provide estimates, and the pitfalls of the ways we are using them)
  • A New Social Contract for Open Source (by Eran Hammer, on open-source, free code but paid time, sponsorship, making clear rules and specifying benefits, and sustainability)
  • Introducing Example Mapping (by Matt Wynne, about conversations to clarify and confirm acceptance criteria, feedback, colored index cards, and the benefits of writing examples when exploring a problem domain)

Exposing Local Apps Publicly with Ngrok

Here’s a screenshot of something we’ve currently been working on:

It’s not available publicly yet, because it’s still in the early stages of development. The app, hosted locally on http://aspen.reservations.com/#/stay-dates, will redirect to a 404 page unless you have the app installed in your machine. As a programmer, the changes I’m making on the app is only accessible on my local computer. Other programmers will only be able to view the changes I’ve made if I push said changes and they download those updates on their machines.

Similarly, I’ll be redirected to an error page if I view the said app on my phone:

What if a tester or a product owner requests an impromptu demo of the app? What if they want to test it as is? Early constructive feedback is always nice. We can set up the app on their machine, but what if they’re working remotely? I’m pretty sure it would be a pain for them to install the development environment on their own. And what if they want to test it on their mobile phone? Having the environment installed on their computer doesn’t mean they can test the app on an actual phone.

Apparently there’s Ngrok. It’s a quick solution to publicly sharing local apps over the internet.

Here’s a screenshot of me trying out the free version:

And now I can test the app on my phone!

No installations needed on the tester / product owner / client side, just a single bash command from the programmer instead. So cool!