when relevant content is
added and updated.
Hello to everyone who reads “Uncharted Waters”. I am excited to be one of the writers to contribute to this space, and looking forward to collaborating with Matt and Justin on future posts. For those who do not know me, I’ve been a software tester for twenty years (a lot more about that below) and I have had a wide and varied career, touching many different industries and disciplines. Through them all, the primary theme has been to test software and devices, and to encourage other testers to learn more, do more and dare more. It’s my hope that I can continue that tradition here and in future posts.
I officially became a “software tester” in 1994, when I was working with Cisco Systems. Actually, the title I was given was “Development Test Engineer”. I’ve had a variety of job titles since then, such as Application Engineer, QA Engineer, QA Tester, Lead QA Engineer, and other variations that HR departments deemed necessary. I was given the choice of choosing my own title (within reason, of course) when I went to Sidereel. I asked them “Can my title be “Software Tester?” After a quizzical look, they said “Sure, if that’s what you want.” Only once in my career have I had my actual work discipline in my official title. By any other name, do we not still test software the same?
The past twenty years have taught me that experiences with testing are all unique. I have worked for seven different companies. Each has had its own take on what testing is and what made testing “good”.
At Cisco, planning your work and working your plan was a huge part of the job. In the 90s, ISO 9000 was all the rage. I would create test plans, trying to think of every possible area, only to have it turned back with “sorry, we need more detail”. I learned the art of “turning the requirements sideways”. Every listed requirement was reworded into a test case. Did it help me test better? It made for a massive checklist, but I’m not sure it did much to improve the quality of the code.
Testing Virtualization Software
Wow, what a blessing. The systems were streamlined. It didn’t matter what the real machine hardware was, the virtual machine abstracted away everything. One machine to be used everywhere. We did not have voluminous test plans. Instead, we did lots and lots of bug reporting, followed by numerous bug fixes and retesting. Each setup and teardown was clean and seamless, but we worked with a lot of images for all the possible software combinations.
Synaptics was all about touch. Everything had some aspect of how the body carried electricity. Additionally, I learned a lot about environments, including extreme heat, extreme cold, extreme wet and dry, extreme turbulence and various other conditions, not to mention getting pretty handy with an ESD gun. It was heady and scientific. I often struggled to understand what I was doing. When I did understand it, though, what a ride!
Time For Video Games
“Testing games; that has to be the most fun job ever!” Truth is, do not mistake playing games with testing games. For example, take a movable character and rub it over every surface to see if you fall through any cracks. Repeat for every scene. It’s not fun, though that was just one aspect of testing games. The most memorable experience was the language barrier. Every test plan, bug report and test report had to be reviewed for consistent language use. A QA Liaison would take all of our test artifacts and translate them into Japanese. The next day, we’d receive replies from Japan (translated back into English) that we’d review in our daily meetings. I learned a lot about the precision of words. It takes discipline to write unambiguously (or as close to that as possible).
Immigration Law Case Management
Case management for foreign nationals requires strong analytical skills and attention to detail. My testing had to pass legal audits with the tiniest details intact. My best testing tool was an abundant use of personas, making up entire families and back stories, to see if I could follow them all the way through the necessary workflows. It required learning many corner cases and scenarios, but it proved worth it in the long run.
Testing a Video Content Site
The world of television required a total rethinking of who my customers were at any given time. The end users, the studios that generate content, aggregation services that gather links, the advertisers, etc. are all different customers, each with a different expectation. The ability to focus and defocus rapidly proved extremely valuable.
Today, I work for a company that creates collaboration tools. Our system focuses on one piece flow. There are no bugs while a story is in process. We talk about issues, rework, missed test cases and under-scoped features. We deal with bugs when they hit our staging server (which is our production environment). Testers get involved early in the game. To minimize rework and story churn, we aim to be at every story design and kickoff so we can articulate issues with requirements or implementation ideas.
Is There a Right Way to Test?
Anyone looking to say “there is a right way to test” will feel silly if they trace my path. There are many right ways to test. They are as unique as each organization. I am certain of one thing. Each company helped build skills that informed every job that followed. I’ll learn a lot more in the next twenty years, though I can’t say how many companies or ways of testing that will include.