My First Testing Experience – Part 1

I thought it would be fun to relive the event that really pushed me into testing. The first 5 years of my career were spent doing business analysis and development work. Apart from unit testing my own code, I had no testing experience or expertise. I was an average mid-level developer doing his thing when out of nowhere, I fell into the world of testing. This is Part 1 of that story.

My company was in the process of upgrading/migrating their web platform to SharePoint 2007. The project was broken into two teams; the platform team, and the migration team. The platform team was tasked with re-writing the entire platform (internet, intranet, and extranet sites) while the migration team was responsible for writing throwaway programs that would transform and move the company’s data from the old systems to the new one. I was a developer on the migration team.

The platform team had a typical setup. There were stakeholders, a product owner, a BA, requirements, developers, and several testers. The migration team however, was simply a handful of developers. Our job was to make sure the data was taken from the old system, transformed, and then migrated to the new system.

Since the old system wasn’t documented very well and the new system was still being developed we had little information to guide us. We had to dig into the old system’s data then talk to the developers to see what their new code expected then go write a tool to do the work. As the platform matured and changed, our migration tools had to evolve to accommodate those changes.

Many months went by and the platform and migration tools started to take shape. Every component on the platform had a specific tool, or part of a tool, that would handle its migration. Not surprisingly, the migration project grew very fast to the point where, in terms of lines of code, it was actually larger than the platform.

At this point there was a test manager and 5 testers working on the platform but no one was testing the migration tools. One day the project manager came to me and said:

“We are almost ready to start migrating data, but we need to make sure the migration tools work correctly. I’m gonna need you to go ahead and test them OK?”

Yeah, that was me (except I’m not a baby and my head isn’t shaped like a football).

“Let me get this straight, you want me, someone with no testing training or experience, to test an incredibly large and complex set of tools, without any documented requirements, by myself, all while the platform project, which is similar in size and complexity has had 5 people testing it for the past 6 months?”

“Yup”

“Wow…. Well, OK”

In part 2 panic sets in.

Strategies for a Testing Career – Part 1

I am reading through a book of articles titled “On Strategy”. It is published by the Harvard Business Review and the context deals with business strategy. What I have found is that even though the intended audience is business managers, the lessons can easily be applied to individual testers. As I read and study each article, I will write a post summarizing the content of the article and how testers can apply the lessons to develop their own strategy.

What is Strategy?

by Michael E. Porter

Operational Effectiveness Is Not Strategy

Operational Effectiveness (OE) means performing activities better, faster and with fewer inputs and defects then your rivals. The quest for productivity, quality, and speed has spawned a remarkable number of management tools and techniques. Enormous advantages can be gained from OE, but from a competitive standpoint, the problem with OE is that the best practices that drive it are easily emulated. When competitors both strive to achieve the best possible OE, the competition between them produces absolute improvement in OE (everyone is more effective), but relative improvement for no one and the more indistinguishable the competitors become. The pursuit of OE is not a bad thing, in fact it is a necessary part of strategy, but OE itself is not a strategy

As testers, we too pursue common tools, techniques, and procedures to do our job more effectively. Quality Center, Test Manager, test plans, test cases, bug tracking, and defect metric are just a few examples of the many ways the testing industry has enable testers to chase OE. As all testers attempt to become that sought-after tester they too fall into the trap of trying to become that one ideal tester. We all are want to become QC experts, and automation specialists, but as we all pursue that goal, we all become more and more similar which is contrary to our goal of standing out from the crowd.

So what is strategy? How do I as a tester establish my strategic position?

Strategy Rests on Unique Activities

Strategy is all about being different from your competition. Our competition as testers would be anyone who has the same goal as we do. For example all other testers that are applying for that job we want or the opinionated blogger who has the ear of the testing community that we envy.

Strategic positioning means performing different activities from rivals, or performing similar activities in different ways.

A perfect example of doing different activities is Jame Bach. Almost everything he does and teaches is exactly the opposite of what most “factory” testers do. While your average tester is pursuing certifications and following test cases, James supports open learning and exploratory testing. As a result, he is one of the most well know testers in the world. No doubt he is an amazing tester, but the reason he stands out is because he is so different from everyone else. He’s loud, sarcastic, opinionated (none of this is meant as a slight by the way) and people listen.

Almost every tester out there is experienced in Quality Center. Knowing how to write test cases or track bugs is expected and it doesn’t set you apart, but there are ways to do those similar activities in different ways. Consider learning about lesser know bug tracking software such as Kiln, or possibly create something totally new yourself. Try to find a new way to perform exploratory testing within an Agile testing environment.

A Sustainable Strategic Position Requires Trade-offs

A strategic position is not sustainable unless there are trade-offs. Trade-offs occur when activities are incompatible. For example, if my strategy is to be a white-box manual tester, then I should ignore learning about Selenium automation and focus on manual testing and coding skills. Pursuing both would split my available time and effort effectively making me a lesser white-box tester. Trade-offs mean more of one thing necessitates less of another.

Sustainable means that over time, your strategic position will erode if you try to do everything. You may be able to get by in the short term, but as you spend more and more time on non-strategic activities, your core skills will suffer and it will become apparent as others (who made the trade-offs) surpass you.

Fit Drives Both Competitive Advantage and Sustainability

Strategy is all about combining activities to give you that unique strategic position. Fit describes how those activities tie into each other. One activity’s cost can be lowered by the way other activities are performed. Similarly, an activity’s value to your strategy can be increases by effectively “fitting” it with other activities.

I want to become known as an expert tester. My strategy to accomplish that, in part, includes becoming knowledgeable in my field and sharing that knowledge with others. Learning and blogging “fit” because they both contribute directly to my goal, and each complements and improves the other. Learning give me something to blog about, and blogging helps me to better remember and reflect upon what I’ve learned.

Conversely, we need to be aware activities that don’t “fit” our strategy. If I decide that I want to be a context-based exploratory tester, will getting a certification from ISTQB contribute to that goal? does it “fit” with the other activities of my strategy?

Rediscovering Strategy

There are two distinct views on strategy. One is the idea of competing head-to-head with your rivals on the same things, the other is establishing a unique strategic position that provides a competitive advantage. Here are some characteristics of both views.

Head-to-Head

  • One ideal competitive position in the industry
  • Benchmarking activities to achieve best practices
  • Outsourcing and partnering to improve efficiencies
  • Focus on a few success factors, critical resources, and core competencies
  • Flexibility and rapid responses to competitive and market changes

Unique Strategic Position

  • Activities tailored to the strategy
  • Trade-offs focus activities
  • Fit across activities
  • Focus on the entire system, not individual parts
  • Operational effectiveness is a given

There are two points I took away from this article that I think are extremely valuable. First, we as testers need a strategy. Strategy isn’t something that should be left to managers of  big companies, it can and should be applied to individuals. And second, imitating what others are doing is not a strategy, it’s an anti-strategy. The only way to give ourselves an advantage over our competition is to have a unique strategic position based on trade-offs and carefully aligned activities.