Few people have a more diverse QA/testing background than that of Jane Fraser, our latest Testing the Limits guest. Jane is currently the Test Director for start-up called Anki. Prior to, she managed test teams for the likes of Electronic Arts, Vodafone and several other companies. You can read more about her extensive background on LinkedIn.

In this interview, we ask her thoughts about becoming an influential tester; tips for test managers; essential skills to acquire and much more. Enjoy!

********

uTest: This Spring at STPcon, you’ll be presenting on the topic of becoming an influential tester, in which you focus on developing several non-technical skills. What are some of those non-technical skills that a tester needs to become the “go to” tester in their organization? 

JF: Three things in particular:

1. Communication Skills: You need to be able to converse with others, and be understood. You need to be clear. “Doesn’t work” isn’t clear.  “When you press A, B is suppose to happen, but C actually happens” is clear.

2. Ability to understand their audience & customer: We need to listen and learn what is important. To a VP of Finance trying to convince him that we need to change a color a product because customers won’t like it, generally doesn’t get you any where. But phrase it in terms of sales, and that green will sell better than blue because of “some reason”, you have a better chance. Take time to understand their motivation.

One of my early lessons was at Corel, 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. I tried sending it back, again saying it was “too slow”. Back it came again.

A day or so later, our VP was giving us 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 stop watch  and 6 different graphics in different formats. I created a table with the 3 programs and the results. One example Competitors: 2sec, .5 secs.  Ours: 19sec.  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).

3. Ability to tell a story: Sometimes saying this happens when I do this, isn’t enough. But to tell a story about how it affects the customer. When a customer tries to do A, 50% of the time they won’t be able to.

uTest: Of course, testers can become more influential on an individual basis, but what are some the things preventing the department from becoming more influential within a business? 
JF: When the department becomes a team, and puts the product ahead of themselves. When your aim is to help others, great things happen. View your developers and producers as customers. We are there to help them achieve the common goal. Building relationships with them. When people understand that you care about what they are doing (creating a software product) they are more likely to listen.

uTest: Surely you have some awful horror stories from when testers (and test teams) were not taken seriously. Care to share any specific ones? If not, 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 story telling 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 testing something that would never be used.

uTest: You were with EA from 2004-2012 and worked with several different teams during your tenure. That was 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 books.  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 shear number of combinations of devices & OS’s has created new ways of testing. Between using pairwise and other tools to reduce the number of repeat test cases, and risk based testing to handle the sheer number of combinations.

uTest: You have testing experience that covers desktop software, web and mobile. How did you transition from one to the others? What types of new skills did you need to learn as you went? 
JF: The biggest issue was letting myself start over. New means you need to start learning again. I also found honesty was the best policy, tell people when you don’t understand, nodding or hiding misunderstandings hurts everyone.

Taking good notes (or whatever it is that helps you remember) – if you have to ask more than twice it looks bad.

Clarify and confirm what you are learning, one to make sure you really did get it, and when you turn it into your own words it easier to remember.

uTest: You have experience redesigning and reengineering testing processes? Why is this practice important? 
JF: I really believe if your not trying to improve your processes you be left behind. I’m always looking for new ways to do things, listening to the experiences of others, building a network of peers so I have people to ask advice.  As products and technology change testing must change.

uTest: You’ve held several Test Director positions. What advice would you give a Test Director struggling to make his/her department understood and appreciated within the company? 
JF: Learn to empower your team, be the enabler not the dictator. Protect your team. Whenever someone made an error, missed a bad bug, it was me apologizing to the higher ups, and never throwing someone under the truck.  When you make a mistake, first figure out how to fix it, then how to reduce the risk of it occurring again, then move on. Grant it, if someone makes the same mistake over and over again, its not acceptable. And reprimand in private, congratulate in public. But if we are not making mistakes we aren’t pushing the envelope, we not trying hard enough.

Make sure to hire people that complement you, not mirror you. Learn to expand your world view. When you start as a tester, your head down with your test area. As you grow, your world has to grow. Looking to help out with others around you, looking at connections with other parts of the software, looking farther ahead.

uTest: Any suggestions on how to keep projects on time and budget? 
JF: Ask questions and use your history. Many times I’ll comment that a similar project we had this happen, and we could only fix x number of bugs per day, which is more than the days left. In current project we aren’t fixing any faster.  What can we do to minimize the risk of slipping.

Always thinking risk and reward, will the code change be worth the risk of what could break. History shows pretty much for every two bugs fixed, you get another one.

uTest: What are the top three things you look for when you’re hiring a new tester? 
JF: Curiosity.  Testers always need to act as detectives. Asking Why? Always looking to learn. Lifetime learners make the best testers. Always trying to find new ways to create a great product.

uTest: You’re with Anki now, a company that is still fairly young and small. What’s the best thing about switching from a large company like EA to a startup like Anki? 
JF: I’ve moved from management focus to hands on focus. I am the test team, which is a big difference.

As to moving to a smaller company, you have the ability to gain a lot more interaction and the capability to have huge impact on the product.

uTest: You’re pretty active on the software testing scene, which peer-to-peer groups do you find most helpful and engaging? 
JF: I follow a lot of groups on Linkedin. I probably don’t participate as much as I should, hopefully over time that will change.  I like to try and watch a webinar at least once a month, to learn something new. Some are good, some are too much advertising, those I usually turn off.

And reading lots of articles and books. Lately I’ve been immersed in robotics and artificial intelligence.

uTest: You’ve experienced some pretty big tech shifts during your 18+ years in testing. In your opinion, what’s the next big thing? What emerging trends/tech are you most excited about? 
JF: Not that its really new, but ability to prototype new products so quickly has made innovation and iteration so much faster.

As I’m working in hardware and software now, the 3D printers have made prototyping and finalizing a design so much quicker. Not having to wait weeks for a new version, these 3D printers can help you create many more designs in much shorter time.  Iterating very quickly can really help get you to a better product.

Think of how this might have changed the Palm Pilot. As Hawkins said he carried a block of wood, the size of the potential Pilot, in his pocket for a week, how that might have changed with the 3D printer.

Editor’s Note: Thanks for reading another installment of our Testing the Limits interview. Have a suggestion for a future guest? Drop us a line.