Archive for the ‘Interview Stuff’ Category

Error, defect, and failure

In I have a question, Interview Stuff, Software Testing, Testing Jobs on April 10, 2011 at 6:53 am

Many a time,  I come across this question from people who are experienced in testing.  The difference between error, defect and failure is distinct, as they happen in different stages of a software development life cycle.

An error is introduced by the developer during the coding phase of the Software Development Life Cycle (SDLC)

This error if undetected, creeps into the testing phase and is referred to as a defect/bug

Finally when this defect/bug creeps into the Production phase or live phase – it is a failure.

The production phase is the phase where the end user or the user for whom the software was intended to, starts to use the product. Ex: If you bought a new software (available in a CD format) you install it on your machine, and start using it;  You find that, after a while, the software crashes or some functionality of the software does not work – this is a failure.  Had this issue been caught by the tester it would be a defect/bug.

Had this issue been caught at the development phase it would have been an error.

An analogy in failure can be shown in  the automobile industry, when a customer was driving a Tata Nano, and it caught fire in the middle of the road.

What is a Test Deliverable?

In Interview Stuff, Software Testing, Testing Jobs on April 10, 2011 at 4:43 am

This simple question, as I have found out, doesn’t seem to ring a bell with some associates.  Let me take this opportunity to clear the air.

A test deliverable is basically a work product that is promised to be given to the customer.  It is  an out come of a certain amount of effort undertaken by testers including test lead, manager etc.  Examples of a test deliverable are: test cases, test execution reports, defect reports, test plan, test strategy document etc.

Where are the offer letters?

In Interview Stuff, Software Testing, Testing Jobs on April 10, 2011 at 4:35 am

In a recent walk in interview, I came across an old friend of mine who was looking for a change. After exchanging a few pleasantries and catching up, I asked him whether he had applied in other places also. He frowned and said ” Yes”. He also said that many companies these days are simply calling candidates for interviews, and giving a verbal “Yes” to their appointment, but when it came to providing the offer letters, they say ” We will get back to you in a few days, please leave a copy of your academic records, payslips etc.”.
I sometimes wonder, why would such a thing happen. One reason could be that some companies are following the policy of some old economy companies, which used to show off that they are in business and doing well. These companies used to simply announce a massive hiring drive and select very few people or sometimes none at all. This gave an impression to many people that this company is the company to join. It was assumed that the competitors of such companies would get the jitters. The side effect would be a domino effect of other companies resorting to “pseudo hiring”, thereby giving a self boost to their own morale. But the job seeker in either case was the main loser.

A brief Introduction to Boundary Value Analysis

In Testing Methodologies on January 3, 2011 at 12:40 pm

Jack and Tom were next door neighbours.  Theirr home were seperated bya  compound wall which was not thick enough for a person to walk  comfortably.  People would fall if they were not careful enough. Jack and tom were discussed  a bet.  The bet was to walk on the compound wall seperating their two homes, without falling down.  Whoever achieved this would win the bet. 

       Boundary value analysis is probably one of the most elementary of test methods.  It is like walking on the compound wall mentioned above. The belief is that, if a person can walk on that compound wall, it can be safely said that he will be able to walk on the ground easily.

       When you have lots of input data, you could partition the input domain and select values that lie on the boundaries of this partition.  If the application does not throw any error, it can be assumed that the application would work fine for data values from inside the input domain.

A brief introduction to Equivalence Classes

In Testing Methodologies on December 30, 2010 at 1:16 pm

1000 Apples 900 Oranges 1400 Guavas have arrived ina truck.

You have only a few minutes to examine them. What would be the

best way to do this?
One way to do this would be to pick one or two fruits

from each category (Apples, Oranges, Guavas) and see if they

are good.

This is an analogy for equivalence classes. Each class is a

class of fruit. The fruits domain has three types of fruits

Apples, Oranges and Guavas. Hence 3 equivalence classes.

Lets look at another example:
We have an input domain allowed between 1 to 100 (intergers

only, no decimals or fractions allowed), to be fed to our

application under test – what could be the valid equivalence

Ans: The range of 1 to 100 comprises of 3 equivalence classes, namely: single digit (0-9), double digit (10-99), triple digit (100). If the user wants to test the application he just needs to select just one input from each of the three ranges. This avoids the tester from testing the application using each of the numbers from 1 to 100. The testing can be completed by just using 3 values!.

The above examples clearly show that testers in their daily lives have to deal with vast amounts of data. They can definitely divide the input data into valid and invalid (more on this later) equivalence classes, and select just one or two samples from each of the domain to safely say that there has been a good coverage in terms of input.

Divide and Rule rules!!!

%d bloggers like this: