Monday, August 24, 2009

A Thought - Why do Companies follow Conventional Testing Methodology

Since last few years, I have been working as a Test Engineer, testing applications of varying nature specifically in Finance domain. Moreover, my approach had been just like what I am told to do. For example; Write Test Cases (using some Test Management Tool), execute the written scripts and report bugs. At the end of day, send the Testing Status Report to stakeholders. Over the time I realized, “This way is not going to help me in longer run.” I had to do something to keep on learning and reporting some show stopper real bugs with an intention to make application better (less risky if not risk free) for the end users. So I started exploring things apart from my application like finding new ways to reduce cycle time (by means of Automation), report High Severity bugs etc and start questioning anything within my limits.

I asked that why we need to write Test Cases, when I know that this is not going to help. I knew that test cases are not covering all the functionalities because application is not a Web Based one; I am doing data validation and certainly cannot come up with generic test cases. I said Instead of wasting time on preparing Test Cases when I can put it in testing my application effectively.
Similarly, I asked questions on filling different kind of Test Metrics (DAR, CAR etc) which certainly do not convey any real usage. Someone replied that we use this data to benchmark ourselves with the best in the Industry and it helps us winning clients.
It still did not satisfy me completely because I knew that data is not always 100% correct. There is always some gut feeling involved. There is always some overlapping happening when we talk about SDLC or STLC. Everything is driven by money. In real life situation, money is allotted to project first and then the estimation is done whereas it should be other way round.
So, Why do companies follow conventional (Script based and so many processes) approach. This thinking lead to some questions-
Note: When I said Conventional, I meant following a plan in terms of writing test cases and doing script based testing all the time without getting much value, filling metrics etc.
Supporter of conventional methodology said;
1) How will you ensure that testing is complete if you don’t write test cases and mark their execution status by some means?
2) If after testing, a defect is found in Production (/Live) environment how would you say, “whether the underlying functionality was to be tested or there was some change in requirement which went untested?”
3) How would you measure Test Effectiveness in case you follow Exploratory Testing?
4) How would you measure and compare the performance of two testers as at the end of year, only one can be promoted or can get a better hike?
5) When one tester leaves an organization or project s/he working on, “How will you pass the knowledge if you don’t have things written? This is a risk area which has to take care of from company’s perspective.”

I could not find the answer to above-mentioned questions. I started reading some Slides made available by Cem Kaner (it was suggested by Pradeep from http://testertested.blogspot.com/ ) on Exploratory Testing. At one place, Cem mentioned "How to assess individual tester performance" under "Areas of Ongoing Concern”. This point acted as a trigger. I know Exploratory Testing is the way to go but still few questions remains.
I request readers of this post to please respond with your thoughts on the above listed points and help me learning.

Tuesday, August 4, 2009

Testing - A Career by Chance

I have been thinking to start my blog on Software Testing for quite sometime now. So here I am... I joined an IT company as a fresher close to 3 and 1/2 years back and since then I've been testing applications of different nature. I was a tyro in software field...had no knowledge of different terminologies and had zero exposure to different testing tools.
In an span of first 2 months, I recived rigorous training on all these thing and this training was then followed by testing a product (a dummy project). We as a team of 5 associates identified 27 issues (bugs/defects) with different severities. But one thing went completely unnoticed that we didn't have any reuirement document. Before we actually started testing the assigned product, one senior person came in and explained the functionality, work flow and basic objective of the product under test. That all discussion was never documented.
We divided the whole product in different modules and distributed the work among ourselves and started playing with the application (remember we didn't have any requirement doc, no test cases etc.)
All we knew was "This application would enable its end users to order something online." When we were playing with that application, one of us left his machine idle and when he went back to his terminal he found an interesting thing "Your Session Timed Out. Please Login Again."
WOW!!!! We thought that functional expert guy never told us about any such feature this application is supporting. We went back to that guy, asked him about this behavior, he replied "If you leave your machine unused for 15 minutes, application will automatically log you off". We thought of testing this and in each attempt we found "inconsistent" timings and this was the first bug we reported.
Then our mentor said, "you all guys are taking so much time to test this application, remember we have just 3 working days to complete testing". We asked him, "Is there a shortcut or a faster way to do this". He replied, "Do one thing, compell your application to do something that it is not supposed to." Bingo!!!!
Later I learnt the approach we followed was actually exploratory testing where we never followed any test cases or written scripts and it was effective as we could find almost all of the HIGH Severity defects.
In these two months, I explored an unknown territory i.e. Testing. People in my friend circle said, why did you opt to be a tester. I said, "I didn't choose testing, it has choosen me...probably I was destined to be a tester." I am happy that I was right. Moreover, it is difficult to produce the correct things but so far its not been that difficult to prove that the product is full of bugs.
In last three and half years, I cleared a good number of certifications on tools, testing and business (I am in Financial Services Industry). I consider myself as a learner in Software Testing field. I spend my free time reading things, exploring new technologies and always try to find a way to do things in a better manner. I am not sure how many people (from testing field) would ever read my post or would care to put a comment but one thing is for sure that I won't stop writing or reading things.
At last, thanks to two people. Parthiban Murugesan (http://testingattitude.blogspot.com/) and Pradeep Soundararajan (http://testertested.blogspot.com/) for encouraging me to start writing.
I am here to learn and share my experiences so far and will contribute to testing field in whatever way I can. Thanks!!