Let me start with: I know i am preaching to the choir here. But it is a simple, in my opinion, undiluted and often disputed fact which make great testers great: a different view of the world and how it works. The ability to execute a test plan can be completed by anyone even a machine (eg. Automation scripts).The key is the engineering, thought process, vision, value, experience, mindset, point of view and problem solving which Testers are renowned and hired to fulfill.
Hence why people are beginning to shout in the streets: "testing is dead - long live testing". Why should i, a hypothetical-CIO, pay for and invest into a testing team? The script can be written and executed by anyone - I will just employ a number of software engineers of test to manage these scripts as well as forward program a number of new solutions. They read, write and execute code better than testers (in a general case) as well as being able t fulfill other roles within the business.
From a future testing perspective; I would view the testing teams as guardians - to assist in rooting out the evil amongst the code (melodramatic I know). The purpose for hiring them is to alleviate risk through the quality of the software solution; by means of verification, validation and hostile testing.
So it's the value behind the point of view: let's take me for an example (i know - a dangerous idea).
Area: turtle (random)
My thoughts and approach:
- Turtle and the hare (arguably a tortoise): story about being the fastest isn't always right. Let's take a methodical approach to testing; is the hard and fast deadline that immovable. Have we allocated ample time to best mitigate the risk of the new system?
- Roman military maneuvers: (fun fact: named a 'Testudo') form in a group with shields raised to reduce casualty from ranged fire, chariot/mounted soldiers and close combat. So let's see - working with the Business Analysts and developers: let's talk through what we are building. View the 'big picture'. Have we covered security and availability concerns? What about building this all into the test strategy?
- Pull your head in: often there is a lot of shouting and opinions on a project. Focus on the quality - by all means DON'T let your relationships decline but make sure you are focused and not distracted by the politics. Make sure when you pop your head out - you provide value and CLEAR communication to the stakeholders to make the right decision when it is needed.
- Know what makes you sweat (ie. your weaknesses): to make a turtle come out of its shell - light a fire under its belly. To get your team fired up; find out their needs, fears, concerns and desires - push them out of their shells. Team development is difficult and a long term strategy - you need to prepare and push forward with each member and their own development plan.
- Swinging above your weight: last year on YouTube, a turtle caught and ate a pigeon (see here). I assumed up to then they only ate lettuce and bread. Don't limit yourself or your team. Don't say "its not my problem(I know I am often Guilty of this)", get out there and do something new. Especially pigeon. :)
- Defensive programming: work with the devs and provide input into how you will test the application. Make sure that shell around your product is robust and ready to defend against any attack. It's only when you work together do you achieve great things.
- Shell scripting: (corny i know) have the means to speed up regression or even forward testing via scripts. Many a time - expert testers are hampered by menial and repetitive tasks: remove this through the use of scripts to alleviate time invested in the tasks.
- Source controls: SvN - is it appropriate? Which branch are you testing on? Have you checked the code is ready to be tested? Is the environment set up and functioning?
- Age: turtles have fantastic lifespans (for their size); make sure your career and interest spans this time and even more. Take advantage of that experience and skill - improve your skills constantly and you will be the unstoppable force - meeting no immovable object.
But my point is: how do you see the world sit together? It does not merely just exist - it is what we make of it, how we embrace it, how we learn from it, how we improve it. Don't think of software in narrow minded views - map your thoughts out - communicate them and make sure to get someone to review and give you feedback.
What do you guys think?
