Testing Zombie – Are you becoming one?

Slowly and steadily, with reasons or without, deliberately or out of innocence, many of us are becoming the Zombies of the testing world. Some people become part of this immediately after college when they start the job and some become as they grow up the ladder and start losing interest as they lose the aim and motivation.

Who is a Testing Zombie?
A Testing Zombie is a person that has been turned into a creature capable of testing without any rational thoughts.

How to find a Testing Zombie?
It is easy! To find a zombie around you, just look for the following symptoms/ characteristics

  • Is (s)he just coming to work as (s)he has to and does not take any ownership of actual testing?
  • Is (s)he hiding behind processes instead of testing?
  • Is (s)he pointing fingers on others instead of owning the failures?
  • Is (s)he does not understand the product functionality under test?
  • Is (s)he does not understand the technology behind the product under test?
  • Instead of owning the release and working in collaboration with product stakeholders, does (s)he wants to block the release to avoid future failures or blames?

Though, the above is not the only comprehensive symptoms list that can help you identify a Zombie in testing, you can add more negative behaviors to this list. But, if the answer to any of the above is “Yes”, you have potentially found one around you.

Types of Testing Zombies
These zombies can be found at any level in hierarchy. I have defined only the 2 broad categories below and will leave rest of them onto you to define.

  • Zombie Tester: These are the people who, land a job in testing just because they did not get anything else to work upon. There is no inbuilt motivation in them to work as a tester. They start working on the project as they are assigned one, execute the test cases that are written by others, word by word, point to the test case author for any missing step and reasons why they missed anything during testing and try to look good as a tester. They only have one mastery and that is to how to blame others for their misses.
  • Zombie Test Manager: These people, though have grown up the ladder in the organisation based on the years of experience, but do not understand the basics of the need of testing. Test Strategy and Test Plan for them means to fill up the information in  the templates. They are highly diplomatic and use their team(s) to run the show till the things mess up. They do not understand the complexities involved in the product, both at technical or non-technical front. They have the mastery to hide behind processes and create a hidden trap which is hard to break. These are mainly “Yes Boss” kind of people and do things mainly to please their bosses.

These kind of people are increasing in numbers at an epidemic rate in the corporate world and the time is not far when we all might be surrounded by them and it might lead to the end of the world for “Testing”! With time, we might also be bitten by one such Zombie and  will be pushed to become part of them.

It is a high time and imperative for each one of us to do some retrospection and see if we want to correct our paths so as to save ourselves in becoming a ZOMBIE!

What a Leader can learn from the current Kapil Sharma Show Saga

One of the most popular comedy shows of all times “The Kapil Sharma Show” is under huge controversy today. As the name suggests, it is named after it’s host and program lead actor and comedian “Kapil Sharma”. Personally, I was too tied up with this show and never missed a single episode since the days it was called “Comedy Nights with Kapil”. The popularity of this show can be understood from the fact that Sony TV coughed up 110 Crore INR for 1 year contract to Kapil Sharma for 2017.

There are multiple discussions happening everywhere, from social media to Bollywood gossip channels, about the failure of the show post the differences emerged publicaly among the costars on the show, but this whole episode has taught some very important lessons to follow for the leaders in the corporate world

  1. Never bring team fights in Public: There is no relationship in the world that can be termed as perfect, including teams. We have conflicts and fights, but it is better to keep them under the cover or else it can spoil the party.
  2. Never build too much dependency on a single team member: Though, this is easier said than done, but too many dependencies on a single team member should be minimized or one should not try to mess with the team.
  3. Leader Attitude counts more than Aptitude: Kapil is a great artist and comedian. As a leader of the team if he had restrained himself from making public accusations and later making fun of it in his own show, things might have been different.
  4. A-Team members needs to be handled delicately: The team was no wonder the A-Team of the comedy world in India, but the leader has the responsibility to handle the A players with humility. Any chance given for intrusion will be welcomed by all.

With all these learnings, I wish the team to get back together for another inning of a great comedy show for Indian viewers.

Overcoming the top challenges faced by Product/Test Owners during Product Testing

In one of my blog post, I detailed out the challenges that are often faced by the product/test owners during software product testing. In this one I will be talking about some methods or activities that can help in overcoming those challenges. I will leave it open for you to map the answers one on one to the challenges that I detailed out there.

Testing team is often involved very late in the PDLC. The product management team also collates frequently changing customer requirements and market expectations of a product, while also contributing to the product roadmap. As a result, the scope of the product changes constantly and testing becomes complicated with daily builds involved.

It is important to design the test strategy early along with the product roadmap so that everyone knows what all will be needed to test and what all methodologies will be applied during the process. This will enable the test owner to define the right budget for the testing cycle and get the necessary approvals on time.

There is a wide range of testing methods and testing techniques currently in use that serve multiple purposes in different life cycle phases. Team should choose the testing programs best suited to their needs.

Additionally, team must also focus on the cost element when identifying and evaluating testing tools available in the market. By picking Open Source tools, organizations can cut capital expenditure. At the same time, automated testing tools can also allow companies to undertake cheaper regression testing. Automation is again a debatable approach, might be I will share more thoughts on this in my upcoming posts.

It is also important to prioritize the test areas based on business criticality and test coverage. A test metric driven report also helps in getting the visibility into the exact team/product status from time to time. This enables management to take a decision regarding the market release of the product.

When examining the outsourcing option, companies must explore and clearly differentiate on what part of testing can be done onsite and what to outsource, while optimally using the collaboration tools. If there are questions of who is doing what, setup a transparent system in order to track each remote team member of the test team.

Currently I am busy designing a test solution that will act as a SINGLE solution to overcome all the challenges in software product testing space. It might be too early to talk about it or maybe you will need to wait for few more days before I start detailing about it in my blog posts.

Be a tester first

I was talking to a group of individuals from testing community. They were boasting of the things that they do as part of their testing assignments. I am posting the conversation that I had with them.

Me: What do you do to test a system?

Group: Validate all the requirements that are provided in the form of specifications, UI mockup, rules etc and certify the product for quality.

(I was a bit overwhelmed, smiled and congratulated them on their achievement because as a tester they are doing so much and also certifying the product for quality.)

Group: Why are you congratulating us. This is part of our job that is given to us as a testing team.

Me: If you are doing so much, your client might be delighted about the quality of work that you are doing.

Group (a bit nervous): NO

Me: Why?

Group: Our client does not value us and often says that the testing team is not able to identify bugs that are being reported by the actual customers. We are testing and certifying whatever is provided to us as requirements, still the bugs come.

Me: So you are not doing ‘testing’

Group (confused): We are doing testing. We are verifying everything. We mostly achieve 100% requirement coverage in our testing.

Me: Wow. Then why are bugs coming in?

Group: Because the user can do anything. He sometimes go through the scenarios and does not know what are the right values to put in the fields. Hence it sometimes crashes the system.

Me: Didn’t you tried out those scenarios?

Group: We tried some of them, but on discussing with the development team we were told that these are invalid scenarios and the user will never use that.

Me: Wow. So the developer was creating it for some particular users and they already collaborated with them and told them not to run those scenarios on the system?

Group: No. The system was being developed for the users who will use it on internet. The developers never had idea about who the actual user would be.

Me: Then why didn’t you question that? Who are developers to decide that the user will not use the system in that form?

Group (Whispering): It is how it works.

Me: This is where the problem is. It is often seen that you, the testing team, is being driven by the development team. How can they know that user won’t be using the system in the form that they could not think about or are not able to fix? This is where you as a tester can add value to your clients. Before proudly certifying the product for quality, which is not your job anyhow (Read post), be a tester first!

You should never

  • Remove your thinking caps
  • Be driven by documented requirements
  • Be driven by developers
  • Stop testing once you execute the already created test cases. Read Michael Bolton’s Testing vs Checking series

Group: hmmm. But how should we convince the project manager on this. This might require extra time as well.

Me: Good point. It is not always easy to convince the stakeholders on time. There are two ways. Either you become rigid on implementing what I told above, which is definitely NOT the right approach or you can prove your point first. With proving I mean, show the benefits to the stakeholders that they can reap with the new approach. Showcase how the bugs are getting reduced post delivery. Practice the testing craft and keep on making the complete process more efficient with time. This will add value to what you do and will also be helpful in convincing others.

Group(thinking): Well we understand what you are saying but still not sure if the client will agree. We will try to practice what is suggested above.

Me: Thanks guys. This was a great transpection session that we had. At the end I will say

Think beyond boundaries. Take Control. Don’t allow anyone to define boundaries that you should confine yourself in while testing. – @VipsGupta

P.S. Thanks to Michael Bolton and James Bach whose transpection on twitter inspired me to write this down.

Darr ke aage jeet hai

A typical product testing scenario

The final round of testing was going on in full swing in a Product company and the team was under pressure to certify the product for release.

The Project manager was a smart person who, to fulfill his interests, wanted testing team to certify the product with minimal testing as otherwise he would miss the deadline to launch the product. He was playing safe. On one hand he was progressing to deliver the product to the market, on the other hand he himself was not to loose anything. Later he could easily put the complete blame on testing team if anything crashes in production.

The test manager was reporting to the Project manager and so he had to follow the orders that he got.

Now as the testing was proceeding further and the critical areas were being tested, the team found a bug.. a critical regression issue that got introduced due to the fixes made for another bug. The team was in a dilemma, if they reported the issue, the Project manager will be literally killing them, but if they don’t report the issue, the customers will kill them. As they were struggling to get out of this situation, the test manager came in. Everyone asked him, what to do?

He was very clear in his thoughts and what was expected from the testing process. He said, we are into testing business and we are providing a service to the development team. In case we don’t report this bug, it will be that we will not be doing our duty. If we don’t report this bug, it is such critical in nature that the customer will report it and we will be in soup again. It is better to report something early than later.

He asked the team to report the issue in bug management system. The tester was very much afraid to do so, but had to follow the orders. The project manager came in and shouted at the tester as he was surely going to miss the deadlines. The project manager went to his room and talked to development team to review and fix the bug. The development team found the possible cause of error and fixed the same.

Now the testing team again tested the issue and the affected areas and found another critical defect, which went to development lab for fixes. The Project manager was getting red as each minute was passing. The testing team was not following the orders!

To safeguard his interests, he wrote an e-mail to all the stakeholders. As the testing team is keeping everyone busy and finding the bugs at the last stages of the release cycle, we need to postpone the release by a day.

The stakeholders called up a meeting and discussed the issues. On analysis, it was seen that the testing team had nothing to do with the stage at which the bug was getting caught. As the bugs were arising due to the fixes that the development team was making. So the testing team was no one to blame.

Can you predict what happened at the end?

Few days later, all the stakeholders praised Test Manager and testing team in front of the whole group and told that if they released the product with those defects, it might have pushed them into legal battles with their clients.

What is my intention of writing all this?

The testing team often faces pressures like the above one in any PDLC, yet they need to be persistent in following the mission that is defined for testing. There will be various people on the top who will sometimes try to build pressures on you, but remember the fact that though these will be decisive times for you, but never divert yourself from the mission that you are on. Believe me, doing this, you will not only get self satisfaction, but will also gain respect of others. It is rightly said “Darr ke aage jeet hai”

Why do people complain about Salary?

Nowadays as recession is becoming the thing of the past, often people come to me and tell me that their salaries should be increased; the company is paying salaries less than the market; or they don’t take care of the staff that has spent more years with them and take them for granted. I was a bit surprised on all these statements as I was not hearing them during recession and people were silent so as to keep their jobs safe. At that time no one came and said that company needs money at this time of crisis so we should do x or y thing to help it out. Why?

Well, I don’t want to get into that debate, but I just wanted to list down my three thoughts on the questions that are asked to me.

#1 No company can satisfy anyone in terms of salaries. I myself am not satisfied with my current take home and I know it very well that if I make a move to join another competitor who often calls me up, I will easily get atleast 50% or more hike. Whenever you switch jobs, most of the time you get better salary as compared to your current one. So that is not a good argument to get a raise. This is the fact.

#2 Look at the history of the company too. How did it behave during good times? Was everyone given a good raise when the time was ripe? If yes, just wait for the time to be ripe again. When the projects, revenue goes up, you will again be given good share from that.

#3 No company wants to loose its good employees. So if you have a misconception that as you are old so company has started taking you for granted, then you are totally WRONG. If they are not able to retain or increase the salaries, then there might be another thing going in the background that you or me might not be aware of. Apart from salaries, companies often needs to spend X amount of money for growth and sustenance. Spending cannot be more than the earnings. If it is, then they will not be able to sustain and everyone will be jobless. You are and will be always an important member of the organization irrespective of the fact that company is able to retain you or not.

Even if after this people don’t understand and don’t believe, I think it is better to let them go!

Hadoop India First User Group Meet at Impetus, Noida

I attended Hadoop India User Group meet today at Impetus, Noida. It was great to listen to speakers from Impetus, IBM and Yahoo. The event was attended by many enthusiastic engineers and they were leaving no chance to query the speakers and wanted to go into minute details of the topics that were being presented. I will like to congratulate my friend and coworker Sanjay Sharma for successfully organising this event.