Having been in the software testing industry for about 10 years now, I have had the good opportunity to witness first-hand the movement of the industry in this relatively short time span. When I started out, software testing was just beginning to make its importance known and have just recently upgraded from a ‘should do’ to a ‘must do’, regardless of what the software development lifecycle said.
Software testing, in the past, never had a big follower-ship due to the cost incurred. In order to perform testing activities – people had to be hired and trained, schedules had to be extended to include testing time, machines and software had to be purchased and maintained – and maybe, after incurring all this cost, just maybe the software will work better and the customers will be happy. Just how much does a firm need to spend to maintain the ‘cost of quality’, and at what point does this cost break even and we start seeing the benefits?
And all this stigma surrounding the notion of ‘settling’ for a software testing position rather than aiming for it simply because ‘you’re testing the software because you can’t write code’. I have to admit, this may be true in many cases. Software engineers who graduate with first class degrees come into the working environment with very little to no programming skills, and choose the software testing line. These testers then go on to become comfortable in their space, and do not thrive to learn and improve. They believe what they know and have done until now is enough. They get by. They become complacent.
While the testers were not looking, the consumer marketplace kept evolving – people’s attention span became shorter, the need for faster deployments became greater, the rapid change in technology became tough to keep tabs on. The industry demanded more be done with less. The concepts of agile testing became a buzz. I admit that I wanted to jump on the agile bandwagon too. When I was hired to start up a test department as I progressed along in my career, I had great ideas of implementing agile test methodologies, lean processes and rapid test turnarounds with the lowest possible post release defect percentage. I was determined to keep the team size small, because we were going to automate everything, and we were going to test products in production environments!
As we got into the groove of things, we also got into the boring and deadly rut of manual testing. Getting into such a situation is easy, because it requires no effort and no brainpower. But realizing it, and wanting to get out of it is not at all easy. The trick is to not get into such a rut in the first place.
What You Will Learn:
The list below is the top five things a tester must have to excel:
#1. Continuous improvement
Software testers must be constantly learning. The world of technology is not stagnant. It changes at the blink of an eye. Today, we’re talking about transporting people from Britain to Australia in less than three hours via jet planes that fly in space!
I am not saying that everyone should go out now and start learning aviation science. What I’m saying is that testers should not sit in their comfort zones and defend their lack of capabilities by providing the world famous defence motion of ‘I am only testing this’. Among many, one of the most important things a tester should learn is the constant growth of the product domain. A common misconception testers have is that product knowledge equals domain knowledge. This is completely wrong. Knowing the product is of course very important, but having the domain knowledge is vital. Not knowing the domain in which the system under test comes from is not only irresponsible but also dangerous.
#2. Programming skills
Software testers should know the programming basics. A tester who can’t program, at least basic programs, can’t be as effective a software tester. I remember in the company I first worked at, there was a rule to the effect of – to be able to become a tester, one must complete a development rotation first. What this achieved was that testers could relate and imagine the code structure when testing, thus providing great value to the developers and system engineers during the testing phase. This is when a test team truly provides value added services to the product they are testing.
#3. Mind of innovation
Testers must constantly think how they can do two things, and do them well:
a) vary the testing scenarios and
b) improve their testing methods.
Armed with these two skills, varying the testing scenario now just becomes a matter of strategizing. Implementing it is not a problem anymore. This frees the tester to concentrate on test strategies, rather than the details of testing. They stop ‘sweating the small stuff’, for the lack of better words. Many software testing tools and programs are results of such forward thinking.
In my experience, testers often feel that they are the “back office” people, therefore do not need to speak as much as the front office people. This may be true in some circumstances, but does not in any way mean that a tester needs to communicate less. Talking and communicating are two very different things, in almost any context.
A tester must be able to communicate clearly, accurately and demonstrate a high capacity of comprehension. Communication skill here includes activities such as reading and understanding specifications, translating those into structured test cases, reporting bugs and writing clear and concise reports to management. It does not stop there. When in meetings, the tester must be able to rationalize the discussion and convey their findings in a logical and unambiguous method. In short, a software tester must have exceptional spoken and written skills in order to excel in the industry.
This is a word that a lot of the software testers I have worked with in the past may not be very comfortable with. I interpret this term in two different ways:
a) Accountability to the product you are testing – Many testers come into the office in the morning, work on their tasks and then leave the office in the evenings. As long as their tasks for the day are done, they pack up and leave. Sounds reasonable? It does, and I have read about and seen so many people actually thrive to achieve that sort of routine in the workplace. However, this is not the point I want to make (another post for another day, perhaps).
My point is, often enough testers do not see where their product fits in the big picture. How does it affect the economy and market, businesses and business movement, consumers and end users, etc? If only testers can study this and realize the contributions they are making, the work that they do will mean so much more and they will work so much better due to the sense of ownership they have cultivated.
b) Accountability to the errors or mistakes that you have made – People commonly often think of testers as the people who catch other people’s mistakes. And testers love to believe this as well. However, testers (like the rest of the human population) also make mistakes. Owning up to those mistakes make honest testers.
I often say that the testers who admit to their mistake and do not provide an unnecessary explanation that wastes other people’s time and effort, are dependable testers. We then can move away from blame to focus on the solution. Finger-pointing or shifting the blame is dangerous too. I have experienced this with testers who just find someone else to blame for their mistake and this costs a lot of unwanted circumstances and bad feelings. Just own up and move on.
The world is moving forward, the industry is moving forward, and testers must move forward too and not be left behind. “Learn, improve, innovate”.
About the Author: Ratha Jegatheson is a Quality Assurance Manager with Actix Malaysia (an Amdocs acquired company). She has been in the software industry for 14 years and in the software testing industry for 10 of those years. She now leads a test department involved in testing, deployment, support and maintenance of enterprise network management products in the telecommunications industry. She also provides her project and product management expertise for the projects she is involved in. She aspires to tackle product teams in the near future and diversify to other key business areas in her domain.
These are just my observations and opinions. Feel free to share your thoughts in comments below.