Sunday, November 29, 2009

My friend's Story - Who should do the Automation & When?


My friend recently changed his job. He is a Software Tester in Telecom domain with good knowledge of things (Domain & Technology) and more importantly he is willing to learn, for him learning has no limits. And this is precisely the reason why I thought about sharing his story with you, as it concerns us all.

As we all know that whenever one switches his/her company, s/he has to first adjust to new working environment, new colleagues, new processes etc. Same happened with my friend as well. My friend was given a project / application to work on. The project didn’t have this QA function earlier and there were no documents available for my friend either. So question was where to start?

Well, a meeting was called with all the Stake holders and it was decided that the new joiner should undergo some Knowledge Sharing (KT-Knowledge Transfer) sessions to get some more knowledge about the product he will be working on. KT completed just after a single one hour session and my friend was asked to start writing test cases. The irony was, the person who gave this KT to my friend was also a new joiner and was a developer. For most of the questions asked by my friend, he didn’t have any answer and what can be the better excuse than saying “I am also new like you.

Then somehow Test Case started coming in and there were hour of reviews by different stakeholders to get it correct. (Actually no one knew what is correct, as told by my friend.)Later my friend came to know that the test cases he prepared are to be used by some other team. That team will use these test cases for preparing Automated Scripts.

My friend wondered as he never did automation straightaway without executing at least one cycle manually just to make sure that application is stable enough to for automation. To worsen the matters, he had to conduct reverse KTs for that so called Automation Team to make them understand the functional flow of the Application Under Test.

My friend proactively offered a solution to his manager saying he can do a lot better job if given an opportunity to work on his own with a definite timeline. Manager partly agreed and party disagreed. Manager said, “You should focus on preparing test cases, leave automation to concerned team.” But at the same time, manager was also concerned with deliverables that were getting delayed because my friend (who was asked to just write test cases) was not just writing test cases, he was also executing, logging defects, attending calls, feeding automation team and exploring application under test all at the same time and these things remains unsaid but he has to do it.

This whole process required a lot of time and the result was neither test cases could be completed by my friend (who is still exploring the product to learn more about it) nor the automation team could completely prepare their scripts.
So, Who is responsible for all this delay? NO NO I should rather say What is responsible for this delay? My friend who was a Star Performer in his previous organization (because of his gifted skills in Testing and his hunger for knowledge) is a worried guy these days.

I could think of few reasons, I would request you to put few points from your experience as well.

1) Stakeholders should not have directly jumped onto automation to get more coverage; they should have first allowed my friend (a tester by destiny) to understand the application thoroughly.

2) If it was pre-planned that automation will be done by some other team, that team should also have participated in KT session. This would have reduced the Learning curve.

3) Taking parallel approach for automation and manual testing makes sense only when one knows what should be automated and what not that too when application is stable but not otherwise.

My take, stakeholders should think in long terms, consider the broader view. What do you think?
My friend is in need of your guidance, please share your thoughts.

Wednesday, October 7, 2009

Trading & Software Testing - Is there something common?

A true Story: Explained My Work i.e. Software Testing to my Father

When I started my career as a Software Test Engineer with a reputed company my father asked me what you do sitting all day looking at the computer screen. I said that I make sure that things (software) work the way it is expected to. And believe me it was difficult for me to explain my job because my father is businessman and IT is not something went down well with him earlier. Although he made a handsome profit after investing in some IT companies right in middle of Dot com crash...it did take some time before he en cash it.

Few years later, one morning I asked my father, “If you invest Rs. 500,000 in share market, in Share of one single company, do you see any risk (of making losses) there and if yes how do you minimize the losses?”
He promptly said, “I am not a fool to invest Rs 500,000 in a single company without considering Risks, the risk of losing hard earned money. Once I invest, it means that I have taken a Long position on some equity with a view that I will sell these shares after sometime when prices of this equity go up and thereby I’ll make profit. But as I cannot afford to lose all my money so what I do, I buy Put Option (buyer of Put Option gets a right to Sell underlying asset at pre-agreed terms and conditions to seller of the option.) to hedge my risk for a minimal premium (amount)”.

I said, “Papa now I’ll explain what I do. Software is developed with an intention to reduce manual intervention in things which we do in our day to day life and software does all this at a very fast speed. As a trader, earlier you were buying / selling shares by making a phone call to your agent and he used to do all the trading on your behalf, now sitting at home you can see price movement and buy/sell accordingly by using a Computer with Internet connection and having some Demat / trading account. Now if something goes wrong with your trading application (suppose it starts buying against your sell order) you might lose a lot of money.” He agreed to my delight as it made some sense to him.

Then I said, “As a software tester my job is to identify such problems which we call Defects and get it fixed by developers and again test before it is shipped to its users. A trader hedges the risk by Buying a Put option against the Long position s/he has taken on some equity. Though, not all traders do it and the reasons can be many. For example; Not a big amount of money is at risk and s/he is willing to take that risk of losing money ad don’t want to pay extra cost s/he will incur on buying a Put option for a premium. In market, if price of Share does not go down and market is offering more than what seller of Put Option is then trader will not sell his securities to that fellow and will let option seller keep his Premium (which s/he initially paid as an Option buyer) and sell the securities in the market for a higher profit.

Now implement this is Software industry. Company invests a good amount of money on developing the application and if they do not go for testing Risk of something going wrong increases so in order to hedge this risk the application owners ask for testing also.
By drawing this analogy I could successfully explain my work to my father and he agreed that I am doing something good.

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!!