Tips for Becoming an Influential and Efficient Tester
At STPcon, you’ll be presenting on becoming an influential tester , focusing on non-technical skills. What are some of those non-technical skills a tester needs?
JF: The ability to understand their audience and customer. One of my early lessons was at Corel where I found importing of graphics slow. And I logged a bug that importing was too slow. Needless to say it came back—will not fix.
A day or so later, our VP was giving a presentation on the product and where we were going. He compared us to our competition several times. So now I knew he cared how we stacked up to others. Back at my desk I fired up the competitors’ programs, pulled out a stopwatch and six different graphics in different formats. I created a table with the three programs and the results. One example: Competitors: 2 sec, .5 sec. Ours: 19 sec. The bug was addressed. I now tell this story quite a bit. Comparisons can be key—and knowing what is important to your audience (those making the decisions).
Surely you have some horror stories from when testers were not taken seriously. What are some of the big dangers in having a non-influential test team?
JF: The worst stories of testing are when teams are isolated from each other. The closer the test team can get to the start of a product, the better they can affect the quality of the product. Now this isn’t always easy and generally has to be done slowly. This is where storytelling can come in really handy.
I’m not a coder. I’ve taken classes and work to gain an understanding of the process but don’t do much after that. But I still attend code reviews. One of my first ones was a user’s transactions database. The engineer was discussing adding, editing, and deleting entries. From a different meeting I knew we were not allowed to delete a transaction. This saved the engineer quite a few weeks and saved me from testing something that would never be used.
You were with EA from 2004–2012, an extremely transformative time for tech. What were some of the major changes you saw?
JF: Waterfall to agile, or as I saw, waterfall to fragile. Many teams took agile to mean 'leave us alone, we don’t have to tell you what we are building or when it will be done.' Not agile in my book. Also, dropping any kind of documentation. Again, not agile.
The other large change was in mobile—from a device that barely made phone calls to the mini computers we carry around today. And the sheer number of combinations of devices and OSs has created new ways of testing.
To read the full Jane Fraser Q&A, visit the uTest Software Testing Blog.
