I go to a test Meetup every few months. Usually we start by talking about hard testing topics. Either someone in the group has an actual testing problem and wants to hear other people’s opinions on how they would approach it, or we talk about skill development. Toward the end of the evening, energy dips a little, and inevitably we start talking about the different tools we use in day-to-day work.
Software developers absolutely love talking about tools. I work from home as a test specialist in a team that does near-constant pairing. The tools I use daily are a combination of things that help drive code design and refactoring, collaboration tools, and tools to help create new environments as quickly as possible. Here are five tools I use daily to help me perform better testing.
Get TestRail FREE for 30 days!
Cucumber
Cucumber is one of the many behavior-driven development (BDD) tools available. These tools work by creating several layers of abstraction between the test idea and the test code.
At the top is Gherkin, which describes a test idea in a very simple given, when, then format. “Given” describes the current state of your software, “when” describes the action you want to perform, and “then” describes your assertions. Our Gherkin are plain text using the given, when, then keywords. Below that is a step file that uses a combination of ChromeDriver code and page object calls, and then under that is the page object.
For each code change, we make an assessment of what our test coverage looks like below the UI. This is made up of different types of spec tests; some test small parts of the API, some test the view using Jasmine, and some are more closely related to unit tests. We do this review to reduce the chances we build tests that perform identical experiments.
If we need a new Cucumber test (often called a Cuke), we build it early on in the process. A passing Cuke tells us we might be close to delivering, as well as letting us know when something bad has happened during a refactor. Our Cucumber suite regularly alerts us to things that broke during the development process.
A word of caution about Cukes: These can either be a powerful way to drive development or a beautiful illusion. BDD tests are necessarily shallow. They follow a simple format and perform tests in a linear way that doesn’t at all represent how your users will use your software. Be intentional in how you use BDD, and layer it among other more exploratory approaches.
IRB
IRB is the interactive Ruby terminal you get once you install Ruby. To run it, you type “irb” in a shell, and to exit, you simply type “exit”. Anything you can do in the Ruby programming language can be done through IRB. For example:
Justins-MacBook-Pro:~ justinrohrman$ irb
irb(main):001:0> cool_tools = %w(cucumber irb tmate discord containers)
=> "cucumber", "irb", "tmate", "discord", "containers"
irb(main):002:0> cool_tools.last
=> "containers"
We use IRB most often for debugging code and creating data. When something isn’t working in our product, my pair and I can jump into an IRB session, build the application state we want to work with, and then check the value of a variable, see what methods are available to use on an object, or see if an object we are expecting to be available even exists yet. Alternately, if I need data in the product and don’t have equipment I need locally to create it, and the method I use to get the data doesn’t matter, I can use the application stack through IRB to create that.
Much of this depends on having a decent understanding of your product code, which can be a lot to ask of most testers. I am able to do it because of the learning opportunities provided through pairing with developers.
tmate
For any code change,my team has at least two developers working on the code together at the same time. This might be a staff developer and a test specialist, two developers, or two developers and a test specialist. But everyone works remotely, which necessitates a different way of collaborating. People working in different locations need a tool to facilitate viewing and editing code.
We mostly use a tool called tmate for this. I can create a new session and pass a terminal command that anyone on the same network or VPN can use to see and edit the same code. In the context of a pairing session, anyone can ask for permission from the other person to start typing.
We also use the Mac screenshare function to see someone working in a browser. Screenshare has both control and view functions, so I can watch someone explore and ask questions, or I can ask to take control and work in their browser from my computer.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Discord
Working with a team that is entirely remote has been fairly easy, in my experience. Everyone on the team understands what it means to be available to your coworkers and how to let them know they they are stepping away from their keyboard to have lunch or go to the gym. Things are more complicated at companies that are mostly based in an office and have a handful of people who work remotely.
Discord is a tool that was popularized among gamers. I like it because I can jump in and out of conversations with people nearly instantly and seamlessly. There are no channels to join, no numbers to dial—I just select the room I want and am instantly thrown into a voice channel. I spend untold hours in Discord talking with my dev pair for the day, working through development and testing problems.
Containers
Historically, provisioning new test environments has been painful at worst and tedious at best. Containerization using Docker and some magic in our CI system created by a skilled DevOps team has made environment deployment simple.
Each change we work on is done in a feature branch. We build tests, build production code and then commit many times each day. Running spec tests and Cukes can be done against a local version of the product, but I prefer to explore and do more rigorous testing in a containerized environment. To do this, I go in our CI system and build a new container with the latest of our code branch using a set of menu options (not Docker commands). Once the container is built, I deploy that to an environment, again using menu selections.
In about 10 minutes I have a brand-new test environment ready to use. I might do this once a day or 10 times a day. Being able to build new environments as quickly as possible is crucial to the feedback loop. Slow builds often mean developers will be tempted to write larger batches of code before pushing to a build, to “make it worth their time.” More code means more risk—and less opportunity to discover that risk. Containers are another part of our testing strategy that allow us to offer feedback at a point in the development process when it is still relevant to the code that is being written.
Testing tools don’t make me a good tester, but they do make me a better tester. These tools help amplify things I need to do repeatedly or give me access to the product I wouldn’t have otherwise. They also shape the way I think about testing problems, for better and worse.
What tools do you use every day, and how do they improve your work?
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime
