My journey as a Test Engineer

I am a Test Engineer at Google. I focus on Engineering Productivity, making the development and release process faster, better, and more reliable.

How did I get here?

I studied University of Waterloo, and completed my bachelors and masters in Statistics. I enjoyed the CS courses a lot and got some programming work experience through the co-op program. My later work experiences included statistical quality control and design of experiments, but I knew I wanted to work in software.

I got hired at a software company after my masters, Cognos, now IBM Cognos, to do quality assurance, which was policies and procedures for code reviews, code inspections, and releases, which was similar to work experience I had in a factory doing policies and procedures around control charts and quality assurance. After that quality assurance group got disbanded during a layoff, I started doing software testing, learning mostly from the book Testing Computer Software, by Cem Kaner et al.

I’ve bounced back and forth as a software developer/manager during my career. I joined Microsoft in 2005 as an SDET in the Office security test team. Prior to that, I had been the security assurance manager at Entrust, now Entrust Datacard. I moved from Canada on a TN visa, which required me to be an individual contributor, not a manager. It was exciting to do both penetration testing, security test tools, and test security features for Microsoft Office.

I am still an individual contributor at Google, even though the immigration reason is gone. I write code and design systems to make engineers at Google more productive, specifically on Cloud Dataflow, Apache Beam, and internal pipeline products at Google. Large scale data processing is exciting, especially being able to harness lots of resources for efficient parallel data transformations.

Although I enjoy my work at Goog,e, I no longer like the title “Test Engineer”. Over the years the word “Test” in a job title has become progressively less desirable. “Test Engineer” is associated with repetitive manual testing,  and not software design, development, and coding. Even the exploratory testing, boundary values, or strategies for system testing have become less exciting over the years. Microsoft merged most of the SDET (Software Development Engineer in Test) to SDE (Software Development Engineer), blurring the distinction and helping remove the lack of respect in the SDET role. Google moved the SET (Software Engineer in Test) role to SETI (Software Engineer in Tools and Infrastructure).

Hoping the TE’s at Google can craft a better title that reflects their role and impact.

 

Cheezburgers and testing advice

I started to make a list of 10 tips I’d give to junior software testers.  But then I saw a talk by Ben Huh, of lolcats/icanhascheezburger fame.  Ben made the point that, with the internet, content is free, but the organization, editing, and presentation all require skill.

Inspired by Ben and the cheezburger franchise,  I asked 60 successful testers to each provide 3 tips they’d give to a junior tester.   I received tips back from more than 40 of the testers, and ended up with a list of more than 100 tips.

To respect their privacy, I won’t provide the verbatim tips here, but I did find it interesting that there was a lot of commonality and the tips were collectively much better than what I came up with.

I grouped the collected testing tips into these 19 themes.

1. Focus on the customer  Keep the customer in mind when testing.  Develop empathy for their needs.  Talk to customers and observe them using your software.

2. Read bugs  If you work with a group of testers, read all the bugs they log each day, especially any logged in the area you’re testing.  You can learn a lot from how other testers approach bug finding.

3. Read code  Find the code that implements your feature.  Even if writing code isn’t your thing, reading code critically helps find potential boundaries and flaws.

4. Take pride in your bugs  Bug advocacy starts with a well written bug title and description. I re-read the bugs that I log to assess whether they are fair and properly detailed.  For important bugs, if they aren’t getting fixed, be the driver to make sure the right decisions and tradeoffs are being made.

5. Get involved in your feature’s design Before code is written, find out about the planning and get involved while big changes are still possible.  This also helps to understand the tradeoffs and compromises that are being considered.

6. Design your tests Whether it is finding boundary values, applying combinatorial techniques, drawing pictures, or creating models, it helps to put thought into your test design.  During exploratory testing, consciously alternate your test planning and product learning.

7. Know your feature  Whatever features you’re testing, you should know the design, limitations, bugs logged by others, code churn, and interactions with other features.

8. Work with others to test your feature  Work with testers with different expertise to test your feature.  Brainstorm test ideas and ask for their feedback.

9. Learn your product  Even if you’re only responsible for a small feature area, becoming an expert on your product and the other new features can help you be a better tester.

10. Foster good relationships with your developers  Testing can be adversarial, and it is easy to flip the “bozo” bit on some of the people you work with.  To find out the latest and get your bugs fixed, it helps to develop strong relationships with the developers that fix your bugs.

11. Expand your scope and network  Successful people have strong networks they can rely on for expertise and advice.  Work both within your company and externally to meet new people and develop professional connections.

12. Find mentors/role models I’ve worked with some amazing testers, and learned a lot from them.  To improve your skills, look for mentors to meet with, or role models to emulate.

13. Be self-critical  Testers are great at finding flaws in software.  It can help to turn some of that attention inward, and identify what you need to improve.

14. Manage your time It is easy to get focused on big tasks or distracted by meetings, and not make time for learning, bug hunting, or a healthy life.  To avoid burnout, learn how to manage your time.

15. Automate wisely Automated tests may lack the same “peripheral vision” as a skilled tester.   When done wrong, automation can lead to spectacularly unmaintainable code that doesn’t provide value in assessing product quality.  But careful automation can provide value in noticing defects faster.

16. Improve your coding skills  I’ve met some talented testers who’d rather not write code.  Arguably, just as movie critics become jaded and don’t appreciate the move-going public, when I put on my coding hat I think differently from customers.  But coding is a valued skill, and it can help you become better at reading code and understanding the internals of your product, as well as become better at small tools to make mundane tasks easier.

17. Attend triage  In the final days before shipping, triage teams review bugs to decide what to fix and what to postpone.  If you don’t normally get invited, ask to attend.  It is fascinating to see the roles of tester reputation, customer impact, and perceived risk balanced to make decisions.

18. Keep learning  Whether it be a soft skill,  like public speaking, programming language, or new test technique, successful testers take time from their busy days to keep learning.

19. Enjoy what you do, and do it well  If you can’t afford to leave your job, you need to learn how to love it.  Testers can get cynical, especially during challenging release cycles.  Testers who enjoy their work, and exceed expectations will do well.

Special thanks to all those who provided tips.  For privacy, I’m not listing the names here, but I’ve emailed you all to thank you.  I learned a lot from all of you.