I have now spent a good 9 years as a test engineer (the titles have been different, the fundamental job profile the same). Specifically I have since my grad school days made my bones (and income) from testing complex wireless systems from LMDS (www.lmds.vt.edu) to HSPA modems (www.interdigital.com) to the E-RAN (www.spidercloud.com). Along the way, I have picked up habits - good and bad; lessons- lasting and ephemeral; and mentors- wonderful and giving. I thought of compiling some of those good lessons to benefit a fellow novice tester who comes along and to also remind me of my roots, when I deviate from them. I am nobody without these lessons of engineering, testing and being a team player that I learned from mentors, and colleagues every one of whom I consider a friend today. Lesson 1: Embrace the Paradigm In many an instance, a test engineer will be called in to test something a little too late or a little too quickly. This is the business of testing. Development steals critical test time and the QA guy is given too much to test in too little time. But instead of blaming the system, learn to embrace it. The time spent idling around for development to finish up is much better spent in building a tool infrastructure to support the barrage of issues when they happen - and believe me they will. Automation is a buzz word that will pop up a lot of times in this essay and rightfully so. And it starts here, when you are waiting for code complete. Lesson 2: The more you share, the more you learn Being raised in the ultra-competitive Indian education system, the habit of having aces up my sleeve and not in my desk was drilled into me. I carried it forward into the early stages of my career where I had my stash of scripts and test tools that I used to improve my own work and not that of the team. But as I started seeing how much my colleagues shared in terms of task enabler tools, I realized the futility in being so selfish of my own stuff. Once I started sharing, the feeling was liberating. I felt as if I had a bigger part in the overall success and also a significant leap in my own attitude towards work in general. Sharing is incredibly liberating and it builds not just the technical cache of the team but does wonders to team dynamics. Lesson 3: Learn to Script Coming from a non-CS background and without any formal programming or scripting training, I had a tough time initially with this one. I could'nt really write scripts to simplify some routine tasks. Thanks to some Perl proselytizing by a colleague at work, I embraced the world of Perl and havent regretted that since. From Perl I moved onto learning ruby and am learning python now. Each one of these scripting tools have their pros and cons and one doesnt have to know them all. But knowing atleast one of them is worth its weight in gold. Lesson 4: Automation is Awesome One of the more important lessons I have learned in my career (the hard way) is the value in automation. This is probably the most important tools for a test engineer. If a tester cant automate, he/she is wasting their precious time and also taking a hit on the value of the bugs discovered the non-automated way. Automation can be as simple as a few scripts to start and tear down a test suite and as complicated as building a framework to manage the test, logging and post processing of the test run. Everything has some value and goes towards solidifying the test engineer's case. Lesson 5: Developers are your friends, their code not so much Before someone reads too much into the title, let me clarify. There is a very interesting dynamic between the developer and the tester. The former loves his work and thinks its perfect. The latter's job is to disprove the trust of the former. What gets lost in the mix is that it is not about the developer or the tester but the nature of the job they are trying to do. One is building his castle, the other trying to find out the tunnels, backdoors, and holes in the wall. Both of them are trying to build a solid, robust and wonderful castle- just in their own ways. To understand the mindset of the developer is a key responsibility for the tester. Without that, the test process will be bloody. Lesson 6: You job does not always get the credit it deserves When a successful product ships, the product managers, architects and developers are praised to the roof. When a product has critical issues in the field, the tester is blamed for having done a poor job. No one wants to talk about the delays in development that compromised the scope of testing. After all, what is to be tested when it is not fully implemented. This can be a difficult experience especially at the start of one's test career. You seem to only take the brickbats and never the bouquets. But never lose heart. Good project managers and leaders understand the true value of testing and thus you. They realize that a well tested but poorly designed product is just as meaningless as a well developed but untested product. They may not acknowledge your true value to the big world but they know and show their appreciation in every which way they can. You will be valued- just not as obviously as you may want to be. A good product is a team effort and a good team has a mix of everyone - managers, developers, testers, and what not. Lesson 7: Patience and persistence Patience and persistence play a huge role in the tester's job process. A patient tester is the one with the most complex bugs and thus the most value. A persistent tester is the one who will not stop until his vision of product perfection is attained. There will be compromises along the way that are not of the tester's choosing. But with real patience and persistence, the best of products can be shipped to the marketplace. Lesson 8: Testing as Exciting. Be in it to stay Every interview I have been to and the many other phone screens I had, the constant question that comes up is if I have aspirations to move into development. The answer is No. If an engineer is looking to use testing as a stepping stone to development, it compromises his honesty in the testing process. Testing is not for everyone. So is development. If you think you want to be a test engineer, believe in it to stay for the long haul. It is a lot of fun. Resources: Here is a list of good test resources. THIS PAGE IS ALWAYS UNDER CONSTRUCTION - ONE NEVER STOPS LEARNING! |