Monday, 13 January 2014

RBT - A better option for regression testing?

RBT - A better option for regression testing?

Is the effectiveness of your regression testing experiencing the “law of diminishing returns”? Is the business value of your testing being questioned? These are most likely to occur over a period of time, as the regression test case effectiveness will decrease over time and this would result in regression defect leakages. It is here where Risk based testing gains its importance. Risk based testing is basically a test on projects based on risks or is in other words it is a  type of software testing that prioritizes the tests of features and functions based on the risk of their failure.

Why RBT?
To analyze this we first need to understand what the drawbacks of traditional regression testing are. The most common drawback seen is that the regression test suite is built by accumulating test cases from several releases. And the execution of this test suite depends on factors like time, test environment and test data. The result being that the test cases are not prioritized based on business criticality and that the requirements are not updated after every release. Also, it is common that the impact of release specific changes are not assessed and also that there are no regression specific test environment and test data strategies. Risk based testing helps address some of these issues like, prioritization of test cases, impact assessment, eliminating non-productive test cases etc.

How to adopt RBT?
Most of us would be, knowingly or unknowingly, using risk based testing during our test phases, but without proper risk assessment. This can happen mainly because of the lack of business domain knowledge or the increasing size/complexity of the application under test.
The first step we need to take is to identify what is critical. Next you have to calculate the risk factor. Then categorize and prioritize based on the risk factor. Some of the things to be kept in mind while calculating the risk factor are complex areas, changed areas, Areas with many defects before, History of prior use etc.
One basic formula for calculating the risk is:                                                                                                                
Risk = (probability of failure) * (Cost of failure)
And based on this calculated risk, prioritize your test cases so that you execute only the most relevant ones.

Conclusion
Day by day, the complexity of application is increasing, thereby demanding a better regression testing strategy. Risk Based testing is definitely one of the best strategies that testers can look into here. This definitely saves your time and reveals the most ‘risky bugs’!!!

Thursday, 2 January 2014

An exploration into Exploratory Testing

An exploration into Exploratory Testing


To explain something that everybody knows is one of the hardest things to do. Same is the case with exploratory testing. Exploratory testing is nothing but testing the software without any formal plans or schedules. And hence this is most useful when we have very short time to test the application.

Exploratory testing is just like a tourist exploring any place. And you would agree to me in that all the tourists (business tourist, medical tourist, cultural tourist) will explore their places of interest in different manners. Same is the case with exploratory testing. The exploration you do depends on the type of application you test. Some of the tours in exploratory testing are so simple that you would have been doing it all these while. Tours are nothing but patterns or strategies that you follow during your test. Each tester would have a technique to find out which the most important tests are and all skilled testers would know, which are the ways to test, so that most number of hidden bugs can be uncovered. If analyzed carefully these would follow some pattern. These patterns are nothing but tours.

These tours have been studies carefully by experts and have been classified and documented.
Some tours in exploratory testing:

  •   Antisocial tours – Doing things that should not be done
  •   Supermodel tour –Is the application under test fit to be a “super” model ?
  •  Intellectual tour –ask hard questions 


There are many more tours that can aid you in exploratory testing apart from the ones listed above.

So depending of the application under test and the type of testing that you are doing, you can decide or choose on the tours that you would like to follow. For e.g. you are performing a usability test of a web application, then one of the best tour you could use is the supermodel tour.


So the whole idea of practicing exploratory testing is that, you explore you application in a structured way (rather that ad-hoc) and uncover the most important bugs.

Friday, 27 December 2013

Passion for Testing

Passion for Testing


Regardless of what some may think, software testers need strong analytical and problem solving skills. But what is most essential for a great tester is the passion for testing. It is well quoted “if you do not like testing your product, most likely your customer won’t like testing it either”. Passion for testing is nothing but the passion for breaking things. Doesn’t that sound good enough to make testing fun and challenging?

 Along with passion there are some little things that makes one an excellent tester. Your desire and ability to learn matters- be a continuous learner. Your ability to contribute in the project and excel in your work depends on keeping up with the ever increasing knowledge base and ever expanding skill set. And always be prepared and confident to apply your knowledge and skill in your work whenever the situation demands.

Developing a critical mindset is also important for a good tester. Never ever assume things, but always question. Check everything and expect the unexpected- it never hurts to be a little pessimistic! Always think of “what-if” scenarios. Be a perfectionist and demand for better product. A common statement always said to a tester is “test from the customer point of view”. But I would suggest a tester to consider himself as the customer who paid for the product. You will definitely end up finding more bugs!

No doubt, the aim of testing is to find defects. But the way you report the bug is also important. A bug report should be an accurate, concise, thoroughly-edited, well-conceived, high quality technical document. Also, master the skill of writing a diplomatic bug report. You need to be politely blunt- tell people what you think – tactfully. And most importantly never be hesitant to admit your mistakes.
A tester is the first person who should realize the importance of testing and create this awareness among others. 

You should understand that testing is the first step towards quality. High quality products are recognized and appreciated everywhere. It is always obvious that quality and productivity go hand in hand. Higher quality leads to higher productivity. So dear testers, you are the one who can make the difference.


So next time, the moment you get an application to test, start your treasure hunt. The treasure of bugs is always hidden and will appear at places where you do not see them easily. Make bug hunting a fun.  I recently got a chance to read an incident narrated by a passionate tester who broke an ATM machine when he went to withdraw money. Out of his curiosity he inserted his expired card into the machine and the machine hanged- forever. Though the fellow users were frustrated and disgusted, the tester in him was delighted because he was successful in breaking the machine! Testing was no longer his career, but has become his habit. Once you cultivate this habit in you, you become an excellent tester no matter who says what.