My Software Testing Learn-Line
I rather joined Zycus as a QA quite accidentally. I started interview rounds for a role of Developer, but was later conveyed about Testing Opportunity. So I joined on terms of being given Development opportunity in case Testing doesn’t interest me(which I never had to even think about later). Needless to say, I knew nothing much about Testing before starting the interview rounds and very less by the time I got selected.
So why am I writing this piece? Well, I am doing so to share very critical aspects of being a Software Tester which I learnt during my journey. I cracked my interviews, joined one of the biggest and most ambitious product of Zycus, logged near 3000 defects in initial 2–2.5 years only, spanning across categories like Functional, Performance, Security, Usability, Multilingual, Multi-tenancy and many more . What I want to highlight is- My journey till this point(~2/2.5 years) of time was successful without any direct and great knowledge of Software Testing principles, Test matrices, Testing theories, etc.
I don’t mean to say this is all what it takes to be a Successful Tester. Of course, my test planning, people management and leadership skills came to my rescue after the initial hard-core tester phase. I had to learn more about different types of testing, how to do execute those and ways to explain it to people in my team at right stage. I had to evaluate new ideas, tools and implement those. Learning new concepts, methodologies becomes equally important as you move up the ladder, but my understanding says, it can’t teach you real testing. I strongly feel- Experience is the best teacher.
My explanation from my experience:
- I was up(solo) against a team of 15–20 experienced Developers ranging across Junior, mid-senior and senior level working for new, complex and very ambitious product(product huge enough to make team of 30 engineers work tirelessly for 3+ years to get it to a sell-able level). We were relentlessly adding core features, which all required nearly equal and parallel attention from testing side. No book, no course, no methodology gave me any practical knowledge about how to face this problem then. And even now, I’m not sure if I’ve come across any such thing which gives you ready solutions to problems like these. What I was rather doing is, aggressive and rapid rounds of exploratory testing(I wasn’t aware of the name by then) on each feature one-by-one and then repeat. This solution works purely on how fast you can move your thoughts and frame situations/actions.
What I mean by aggressive round is, you target one element of form/one thing at a time and test it independently and in association with other linked elements.
e.g.: Text-box. What you can test here is- 1. Whether it accepts and stores data as is | 2. Data type validation | 3. Max length validation | 4. Special character’s handling | 5. XSS handling | 6. Multilingual data handling | 7. Handling of empty spaces/no data | 8. Behavior of tab and enter keys | 9. Error handling(cross-browser) | 10. UI alignment(cross-browser) | 11. Copy paste data/dragging links data to text-box | 12. Most important-behavior of this field w.r.t. other linked elements(any business expectation linked to this field like populating something in some other field based on this data)
Does thinking about above testing give you confidence that nothing much can go wrong with this field? Well, targeting one thing at a time always worked for me and I used to get some work completion too.
– I remember the day, when in the absence of our Product lead I along with few other Junior and mid-senior members was supposed to deploy our application on Demo(was prod to us then) instance for the first time. We did it, but with Trial-and-Error. Reason being, none of us had expertise on Linux and shell scripting. I remember, there were concerns raised by our IT department(all in good faith) to my then Manager about me running wrong commands on Production servers. May be I took it personally, may be it was my natural interest, but in short while after that I ended up taking responsibility of maintaining and upgrading five to six environments simultaneously. Shell and Linux caught my interest so well, that soon I was the one who started conducting internal training sessions on it to new batches of Testers and Developers.
– I was suppose to understand complex procurement business scenarios and not only work out my cases but also contribute in the Requirement and Design phases of each Iteration. Even here no ready reference came to my rescue apart from my thinking and reasoning ability.
For Business cases, nothing works like pen and paper. I used to write down the scenarios I want to try or build test cases upon, even drawing your scenarios works like a charm many times. When you write/draw, it goes in your head with better clarity and then starts working of your mind which processes information and produces more like it. This goes on till you get that feeling of DONE!!!
– In a year after my joining only I was getting compared to very evolved and experienced testers and those who have gone through such phase will understand what those extra+ expectations does to you. I had to find out a way out myself here too-Remedy was to Push & Evolve. Not think about how less experienced I’m, not limiting myself by World’s standards of measuring how slow/fast I should grow/learn. Not limiting myself to World’s criteria of how soon one should start Leading and the title one needs before doing it.
For this particular point, irrespective of which field you belong to, I recommend reading Robin Sharma’s The Leader Who Had No Title. It will help you unleash what lies within you. It will tell you no one except yourself can hold you back.
I understood that
“Your curiosity, attention to details, discipline, logical thinking , passion for work and ability to dissect things is all what matters to be a Destructive Tester. It worked for me and I strongly believe it will work for You, if you have these qualities it got to work for you.”
I dived deep into testing theories first time when I decided to appear for ISTQB and believe me there were lots of concepts which I came across for the first time. These were something I had never used before like some unnecessarily categorized types of testing , Seven principles, Types of reviews, test plan templates, etc. and many(if not all) of which I haven’t used till now also.
Present days, I’m working as a Sr. QA Manager at Zycus, looking after some 5–6 products and components and leading a team of 30+ fantastic testers.
My Learning Timeline so far:
- Testing is very tough to define. Someone can do a superb testing and might not be able to define it in words. It is as you see it.
- Everyone can have their own definition of testing. Mine was simple- “You are given a thing — Find faults and make it better.”
You don’t necessarily need a course, big theories, complex matrices or ISTQB to be a destructive tester. You got to be curious, focused, passionate, think logically and have dissect-ability. However, knowing extra doesn’t harm but not at the cost of loosing crux.
- As a tester, it becomes equally important to learn new tools, techniques and methodologies as you move ahead. Test planning, better approaches to perform different types of testing, Situational testing are few to name.
- The traditional approaches/concepts too have their own importance and I have equal respect towards them considering the fact there is good part of world where those are just necessity. Testing alone can’t evolve, the surrounding also has to evolve for that.
- As testing is fluid, definition of being a right fit also differs vastly, organisation to organisation. Being a destructive or excellent tester might just be good enough to get a pay cheque if you are lucky or it might demand extra. Both are right at their own place. e.g. I hire people according to my definition of testing(which varies a bit as per candidate experience though).
- As there is style of coding, driving, cooking; there is also a style of testing. You might not enjoy it unless you’re doing it your way. What I mean is Testing can have guidelines but it shouldn’t be hard bound by the micro-processes.
- Testing world has to evolve, considerable part of World is moving to more practical approaches like Exploratory Testing, Context-driven testing(which many people do without knowing it is it), DevOps which even others should try and add more like those.
- More Testing communities should be formed and like-minded people should get together on larger scale and more often. There is so much to share, learn, adapt and innovate.
“Thanks for reading. Do leave a comment if you have any feedback/suggestion.”
It would be only fair to thanks James Bach for his priceless teaching which helped me become something better in Testing and at writing about Testing.
My Call to Future Testers and Answer to ‘Why Testing?’- Read it here.
Originally published at www.maheshchikane.com on April 19, 2016.