A Simple Solution of A Common Problem

Problem:

A new aspiring tester in the team was given the test cases and asked him to execute the test cases. This new aspiring tester was just completed his degree in computer engineering. He was one of the brilliant students in his batch. Everybody including the management of the company was expecting him to do well in his job. So this new tester started executing the test cases for the first time and then for the next time and so on. All test cases were passed and no bug was logged.  

After a month the tester was terminated from the project.  As per management the new aspiring tester couldn't become a tester because he didn't have the flame that a tester must have. The Tester was expelled from the team. Now he was sitting on the bench and thinking what went wrong.

How many of you have seen this problem? Actually I have seen a few and I had been also thinking what went wrong in this case.

Understanding the Problem:

Recently I was reading a clinical tale by Oliver Sacks. The tale was about a patient who was congenitally blind with cerebral palsy. The conditions are more pathetic than we can think of – she was suffering of spasticity and athetosis, i.e., involuntary movements of both hands, which was added due to failure of the eyes.

After initial tests and checkup it was found that there was no sensory ‘deficit’. Her hands would seem to have the potential of being perfectly good hands—and yet they were not. They were functionless—’useless’—because she had never used them. Had being protected and looked after since birth prevented her from the normal exploratory use of the hands which all infants learn in the first months of life.

Can you correlate the problem with the case mentioned above?

The real problem is that new aspiring tester was being pampered by the management itself. Instead of really doing the testing he was asked to follow the test cases which are most probably written by someone else. Initially, following the test cases made his task easy. He used to execute the test cases and finishes the task early. He couldn’t learn how to test from this exercise and we all know the result. The tester was put on bench (Literally killed the aspiring tester)

Solution:

A new aspiring tester in the team was given the application and asked him to test it for all the functional and usability issues. This new aspiring tester was just completed his degree in computer engineering. He was one of the brilliant students in his batch. Everybody including the management of the company was expecting he would do great in his profession. So this new tester who was hesitant initially started with exploring the application. Think about the infant who reaches for the breast when feeling hungry. Similarly the new aspiring tester took some time but he did some testing and logged few good issues.

Benefits from this Solution:

• Confident and satisfied tester
• Better Testing
• More No. of bugs
• A lively job
• Better Self Education
• Happy Management

What do you think? Does it seem a right solution to you?

Reference: "The Man Who Mistook His Wife For A Hat" by Oliver Sacks

The Test Cases

It is a hot debate topic among testing professionals “Exploratory Testing Vs Scripted Testing”. Open any discussion forum and you will find one or more such discussions. In these discussions, majority of the test professionals support Exploratory Testing and a very few test professionals are there in favour of Scripted Testing. This displays that the exploratory testing is in trend.

I also think that Exploratory Testing is better approach than Scripted Testing but still we can't ignore the importance of Scripted Testing. Although majority of testers support Exploratory Testing Techniques but still the mostly organizations follow the Scripted Testing process.

In Scripted Testing, tests are predefined in form of Test Cases.

What are Test Cases? - In simple words, a test case is a step or sequence of steps to test the correct behavior of a functionality/feature of an application.

More organized definition of Test Case could be:

A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not.

It doesn't mean that a single test case is sufficient to determine the correct functionality of an application. It may take many test cases to determine that a software system or application is functioning correctly. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.

Now the question is why we write test cases? - The reason behind writing test cases is to ensure the testing coverage of an application. Another reason is to test the application quickly. The idea is to write test cases based on design while code is incomplete, so that we could test the application quickly once the code is ready.

The test cases can be divided into two categories:

Formal Test Cases : Formal test cases are designed to fully test all the requirements of an application. There must be at least two test cases for each requirement: one positive test and one negative test.

Informal Test Cases : For application without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In few organiztions, test cases are not written at all but the activities and results are reported after the testing is completed.

Test Case Format: A typical Test Case may include

• Test Case No.

• Testing Component

• Description of Test

• Input Data (If any)

• Expected Result

• Actual result

• Test Date

• Status – Pass/Fail

• Remarks

A sample Test Case is attached here.