You must UN-LEARN what you have LEARNED!
Dawn Haynes, Perftest
How far into the future can you see?
Are you even looking?
Are you wondering what’s coming next?
Or do you have your eyes so fixed on the current process, the traditional methods you were taught, the metrics you’re trying to make look good, the budget/time box/staff you’re trying to keep, the performance appraisal you’re trying to ace – that you’re not seeing the writing on the wall?
Here are some examples:
- Overnight, Salesforce.com announced they no longer employ software testers. Each person who held a related title or role was given “n” number of months to find another job in the company or was let go. The other jobs were “development” jobs the company considered to a contributing role, as evidenced by the requirement that everyone should know how to code and be able to contribute code during each sprint. During interviews, people were asked to code on the spot.
- Google doesn’t hire testers. I have often been told that if you want to join Google as an SDET (Software Development Engineer in Test), you must have tangible programming skills on your resume and be able to demonstrate them in an interview.
- Industry propaganda: Test is Dead – Alberto Savoia’s GTAC 2011 presentation (Google Tech Talk) that test is dead was damning to the hordes of testers in the industry doing the job every day. What was his REAL message? Were we listening? Do we understand enough to take notice and take action?
- Project habits: reduce or limit testing time to risky levels, testing work is often valued less than dev work, testers are often paid less than devs, test teams often get less budget for training, tools, and hardware than devs, testers often have to prove their value while devs contribution is often assumed and unchallenged, testers are often the scapegoat for poor releases instead of learning the real culprits which could include poor requirements, poor code quality, poor dev processes, weak bug triage, unrealistic project goals and/or time constraints.
If we want to survive into the future of software, we need to figure out how to contribute tangible value every day. If that means pairing with a developer on Day 1 of a sprint, so be it. If it means developing data sets for automated tests on Day 2, let’s do that. If it means automating tests, let’s learn how to do that. If we need to learn programming and scripting languages, automation tools, continuous integration frameworks, version control/Github, etc., LET’S DO IT!
Can we learn more about project management, corporate missions, and release goals? And if we did, how could we tune what we do and when we do it? Could we lead a risk management session at the stakeholder level? Could we contribute to backlog grooming and retrospective sessions with an eye toward quality AND delivery goals? Could we coach our teams to be quality minded and proactively test? Could we ask the questions that enable our teams to reach their goals with more grace and ease, instead of holding them back? I think in order to do that, we must let go of much we have learned about software testing and transform ourselves into a new role – Testing and Quality Coach.
- Testers test vs. Everyone tests
- Quality is QA’s job and responsibility vs. Quality is everyone’s responsibility
- Testing = Test Cases vs. Testing = Evaluation
- Test Plans are fixed and control things vs. Testing is an organic response to dev tasks
- Testers shouldn’t code vs. Testers should learn every valuable thing to enhance their contribution
- Testers make go/no go decisions vs. Project stakeholders own project decisions
Are you ready?
