TEST IT LIKE YOU OWN IT

Chevrolet has been advertising the “Beat” with a new caption these days: "TEST IT LIKE YOU OWN IT” Today I had a chance to see one such car with that caption printed on its outer surface.

Took a snapshot of that car and went to my team who were as usual busy in their testing activities. Once they are done with their work I called two of my testers and then showed this picture to them and asked a question to them and that question is “What do you think about this caption- test it like you own it”? and told them that assume you are going to test drive this car.

Here are those answers give by those two different testers:

Tester 1: since this is a demo car just for test drive purposes, the person taking a test drive should be cautious that he/she would not make any damages/accidents while doing the test drive.

Tester 2: This is a demo car for test drive and the person trying test drive can enjoy the freedom of driving this car as per his wish. It may be something like he/she can try driving the car with highest speed, high speed and sudden breaking, zigzag turning etc.

On analyzing those two different answers it looks like tester 1 is constructive and tester 2 is destructive.

The same caption is being understood/taken in a different way by different people but it is not sure what Chevrolet’s real intention of using this caption. They want the test drivers to be constructive or to be destructive?

Do you blindly use this controversial caption “TEST IT LIKE YOU OWN IT” for your testing projects? Your views and comments are welcome.

Driver -A Tester?

I , playing the role of Test lead was speaking about testing progress rate and defect details to my testers group and they were giving me the details and as a result of this discussion it is found that defects count already crossed the earlier predicted threshold limit and still software testers are coming out with lot of defects .On further detailed discussion with my team I had concluded myself that if this trend continues then it’s very tough to complete the testing activity on time since the release date being just two days away from today.

5.00 pm at office

With all the necessary details and the data went to the development team lead and started explaining the current bad quality of the product and listened to him. He replied me like there is no need to worry about this current trend on the testing status and defects count and he said like we will release the product on the planned release date with whatever bugs could be fixed and verified since for him the release date is important and I got shocked on hearing this. For the testing group quality is the important aspect and at the same time it is a reality that release date is also an equal aspect to be considered as quality.

The discussion went for a long time …………..

Now the controversy between testing and development team is: which one is higher priority: Quality or milestone date (release date)?

5.30 pm at office

This is the daily office closing time and I got ready to pack up for the day and started catching the office bus which will be leaving the office premises by 5.40 pm and it will take almost an hour to reach my destination stop to reach my home. The bus as usual started leaving the office by 5.40 pm and I (sitting in one of the very front seats) am inside the moving bus with some other colleagues.

As usual there was considerable amount of traffic on the road and at some places little heavy traffic and I was realizing that the bus will not reach my bus stop by 6.40 pm.

6.30 pm inside bus

Suddenly a lady colleague (who used to get down at the bus stop where I will be getting down) inside the bus stood up from her seat and went towards the driver seat and started speaking with the driver and that discussion went as follows.

Lady: Hey Driver why you are so slow at your driving. Hurry up. Go-fast. I need to reach my home at least by7 pm today. Now itself its 6.40 pm. By this time we should have reached our bus stop.

Driver: Excuse me Madam I am driving as usual but today there is unexpected traffic here and there on the road.

Lady: No. you need to travel still faster so that I can reach my destination by 7 p.m.

Driver: Sorry Madam, There are chances that we may end up in accidents if we are too fast. It is my duty to safely land all the passengers including you on your destination stops and to me today even its ok to land you people at your destination stops with little delay.

At 7.00 pm

Bus reached our destination stop at 7.00 pm where I and that lady colleague safely stepped down from the bus and we started walking towards our home. The bus started moving away from our stop to drop other passengers at their destination stops


On my way of walking towards my home I started thinking about my bus driver and that lady colleague. The point came to my mind was though the bus was delayed by 20 minutes (reached the stop by 7.00 pm instead of 6.40 pm) we were very safely landed. As the driver told to the lady colleague we could have met with some accidents if the driver would have driving too fast.

To me it looks like bus driver is like a tester where the driver’s responsibility is to safely land the people at the destination bus stops on or before the scheduled time and the tester’s responsibility is to deliver a quality product on or before the milestone date.

Though delayed by 20 minutes I and that lady colleague reached our destination safely. I need to wait for 2 more days to see how my product is going to get released…with better quality on time/with some delay? or with not so good quality but on time? Keeping my fingers crossed!

Suggestion to get suggestions to improve current software testing practices

Are you moved to a new testing team within the same organization or to a new organization recently?If yes then I am sure you may be starting exploring or learning the current team/organization’s testing process. And by this time you would have noticed the usage of various software testing related jargon/terms which may be different from your past team/organization.Slowly you would have started learning the new team/organization’s testing terms and processes.


As a test lead or test manager you will be in a position to find out various hidden and open problems related to software testing terms, processes and other stuffs. I was also in that same situation. As a new person there in the team it was too early to create the personal rapport with the members of the testing group.Slowly I had started interacting in person with the people and tried collecting their view points and inputs on the testing process they were following. But people were little reluctant in answering my queries (may be due to fear/hesitation with a new person in place?)


Nothing worked out for me but my main task at that moment was to find out the inconveniences being experienced in the testing processes followed by the testing group.When called for the meeting for an hour and asked about their openings people shared only about their career related issues and not the real improvements needed with the current software testing process.


Then I decided to change my strategy to get suggestions from people in a different way as follows: Circulated a email to the entire group stating like a suggestion box will be kept between so and so dates at a common place where the testing group members can post their suggestions in writing on a paper and we highlighted in bold letters that there is no need to mention their name or employee no or project name or domain name in that suggestion paper.

As communicated the suggestion box was placed for a week and at the end of the week we have opened the suggestion box found that there were around 35 suggestion papers placed by the people.



The further course of actions we had done were self analysis of those suggestions; filtering out a few invalid ones; forwarding the valid ones to the QA group(Process group) for their analysis and to hear their decision to include those valid suggestions into day to day testing practice.


This way of getting suggestions by keeping suggestion box helped me a lot in my environment. This way may work out to you as well when you try but the results may not be guaranteed since it depends mostly on your people and environment.

Red-Green-Yellow –Status/Rating/Decision Indicators

We, software testers are the factual information providers to the decision makers.
Though the decision is going to be made by some other entity or department like project/product management group of your organization, we the testers have a very high responsibility there in helping them to arrive at a decision by providing our valuable inputs and feedback on the quality of the product.

Let us take a look at our day to day life on the road. To control the traffic flow we have traffic light signal system as follows.

Red-A signal to stop
Green -A signal to proceed
Yellow- A signal to proceed/stop with caution (get ready to start/stop)

The above RGY concept is being used in different organizations for different purposes and three such practices what we are following in the testing perspective are as follows.

Case 1: Status Indicator

Status---> testing progress status

Red- Progress is bad; high improvement is needed.
Green –Progress is good
Yellow- Progress is not good as well as not bad; Slight/little improvement needed

Case 2: Rating Indicator

Rating---> rating the inputs/deliverables delivered by the development team to testing team

Red- Things went bad.
Green –Things went good.
Yellow- Things went ok; not good as well as not bad.

Case 3: Decision Indicator

Decision---> may be product release decision or decision to move from an earlier phase to the next phase.

Red- No-Go
Green –Go
Yellow- Conditional Go

No-Go means not allowed proceeding, conditional go means fix some issues and then proceed with release.

If you have some other different purposes of using this RGY model/concept, Please share your thoughts and experiences.