Principles of Testing and ZAT Management

Although there are n principles of Testing but recently I have attended a testing training and got a list of principles which were not new for me. Those are the principles that are definitely a good collection. But after some time, when I was thinking about those principles, I tried to correlate them with the environment where your management is ZAT. Now what is ZAT Management?

ZAT management is Zero Aware Testing management. This is not a new kind of management type but can be found in any organization where testing is considered to be an overhead activity in the Software Development Life Cycle. Working with ZAT management is definitely near to impossible for some real and hardcore testing guys. To work with ZAT management, these guys have to compromise with their job, with their testing, with their ethics and rules. All the principles in this case remain in the team bucker as decorative as Chinese lamps.

But one should wait for the proper opportunity and power to show ZAT management that what is testing and what does it mean? One needs courage to do that. It takes courage to grow up and become who you really are. This is a challenging task and one should make a difference in how to view challenges.

Below I am summarizing the seven principles of testing with the possible view of ZAT management for the same.

Principle No. 1 – Exhaustive input testing is impossible.

View of a ZAT Management –

Testing team should perform the testing with all the inputs that is possible for a particular scenario irrespective of the time lines provided by them. If any issue comes from the customer side, the only culprit for that is the testing team. ZAT management wants exhaustive testing but they don’t want to fund it and they don’t know how to do it.

Principle No. 2 – Testing is creative and difficult.

View of a ZAT Management –

What the hell this principle is? Anybody can do testing at any time at any situation. After all testing team task is to identify problems in the development’s work.

Principle No. 3 – Testing is prevention of defects.

View of a ZAT Management –

Definitely, testing is not the prevention of defects. Testing should be hiding of bugs and believe in the excuses given by development about the bugs.

Principle No. 4 – Testing is Risk based.

View of a ZAT Management –

Definitely testing is risk based. And the responsible for all the risk is testing team only. For all the credits for a software success, development is responsible and for all the negatives in software, testing team is responsible.

Principle No. 5 – Testing must be planned.

View of a ZAT Management –

There is no planning required for testing. Since anybody can perform testing, this is one of the most unplanned activities in the Software development Life Cycle. You are wasting your time if you are planning for the testing and processes.

Principle No. 6 – Testing requires independence.

View of a ZAT Management –

It requires but from the customer. All the interactions should be done between the development and the customer and the testing team should watch them as a independent team. In other words, testing requires independence but from the management side and in other terms.

Principle No. 7 – Testing provides expected results.

View of a ZAT Management –

Testing should provide results but those should be development aligned results. If the expected is something different from what the development wants, change the expected results and align your results (that was expected) with the development mindset.

Finally, I would like to say that if your management is really a ZAT, you should recognize the source of their irritation towards testing and change your own response. ZAT management will definitely try to put you on the spot but you should be specific about your desired outcome.

Management wants their testing cycle good, fast and cheap. But I will say – pick any two. ZAT management’s goal is to get the product out the door as soon as possible but if you want your testing to pass muster, you need to work at it.

-- Sanat Sharma (सनत शर्मा)

Xtreme Testing

Too little testing is an offense and too much testing is impossible.

Deciding till what extent the testing should be performed against a specific module/component/system is called Xtreme Testing. This decision could be based on time, resource and functionalities.

Within the testing industry, we are really struggling with how to know when to say when. This becomes more difficult when you have to analyze your testing scope that you are going to perform with the release. And on top of it, this becomes most difficult when you are working in a vagrant requirements situation.

I personally believe that testing never ends. It just gets transferred from you to your customer. Every time your customer uses the program, a test is being conducted. That is the reason due to which no product is bug free. If a testing manager says that the tested product by his team would be bug free, he must be not aware of the testing and its realities. Recently, I attended one presentation in a seminar titled “Zero Defect in Software”. The presenter tried his best to convince his audience that it is possible to have“Zero Defect” software. After seminar, I asked him personally whether he had delivered any software product having “Zero Defect”. He said “No”.

Recently in my career, I am watching the managers in panic into the trap of achieving delivery schedules by trimming tests. Some managers’ shortcut test work by skipping reviewing and unit testing in the middle of their project. Others pressure the testers to "test faster" at the end. And, most frequently, they just drop planned tests altogether, hoping they "get lucky." This is the scenario when one should think about “Xtreme Testing”.

To plan and perform Xtreme Testing, one should do their best to optimize testing by means of both tried and tested and innovative techniques. How much testing to perform is based on risk of failure? Prioritization of tests is an important task to perform.

I said before testing is a never ending process and that is why prioritization is required for best testing. It totally depends on your project of how you will perform the “Xtreme Testing” but this is a must do activity in the environment in which the software testing is moving at a rapid pace.

-- Sanat Sharma

Processes – Adorable, Achievable, Applicable

I will start this blog with an anecdote. Recently one of my friends working in a mid sized company came to me and discussed this scenario. He was testing something when his manager came to him and asked to update the Software Test Management Plan (STMP) as per the testing cycle that he had performed and still performing. My friend asked him not to follow this practice as this is not fair in terms of processes. All the STMP contents should be finalized and updated before the kit released to the testing team. After that each and every action item should be tracked and presented to the management in the Test Summary Report (TSR). In this way they can easily track the variances in the Software Test Cycle. I totally agree with my friend’s opinion. Not because of that he is my friend but because of whatever he said was right. But the interesting thing happened after this.

His manager was not happy with the facts that he told him. He simply said that this is the process and you should follow it. When my friend asked what do you mean by a Process? He got a very interesting answer. “Whatever I said is a process.”

I was totally shocked after hearing this statement from a manager about the process. This means that whatever your manager says is a process. Or in better words – managers are always process oriented because whatever they are saying is a process.

Now the question is “What do you mean by a Process?”

A Process is an agreement between two parties about how do the things will be done between them. If there are no agreements, there are no processes. And the worst part is if there are broken agreements, which mean you have broken processes.

There is always a negotiation between the processes and their implementation. Negotiation is processes of interaction among parties who have differing, conflicting, or competing goals but want to seek a solution agreeable to all. To constructively engage in negotiation, it is helpful to think of it as a collaborative process. The goal isn't "winning" but to find an agreeable solution that accommodates everyone’s needs.

I have seen in my carrier that sometimes processes (or edited processes) are often rejected because the management believes these improvements are nothing more than a self-serving attempt by someone to make a name for him. They don’t believe that the new processes and process improvements really are meant for the good of the project. What to do now? In my opinion, producing positive results will always be more beneficial than focusing on new processes or process improvements because it will eliminate the belief that you are offering a new process simply because you don’t understand the existing one.

Sometimes, I have seen that new processes are unfamiliar and perplexing. The longer the process, the longer before new team members understand how the various parts of the process fit with each other. You can speed this understanding by shrinking the time taken by the process. This is called the process miniature. Run the entire process in a very short time period (a few minutes to a few days).

To perfectly implement the processes, one should use statistical and quantitative analysis to understand and improve them. You goal should not be of making “Good Control Charts”. Understand that some of the process data you evaluate is based on product characteristics (defect density) that may have causes outside or unrelated to the process being analyzed. Look outside the process and product to the people executing the process for help. And the most important is that if your company is CMMI Level 4, 5 and it doesn’t help in your processes and their improvements, why they have gone for this Level and what are the company’s goal to achieve this level? Wrapping ourselves in the flags of ISO, CMM, or Six Sigma doesn't make our users feel any better. We have to implement the processes and measure the effects of them in the Software Life cycle.

Sometimes what I have seen that an organization may have a quality process in place, but when schedules get tight, schedules win, and the quality process goes out the window. In this scenario, our actions are driven by many motivators. These motivators shape our processes—those that we really follow. These motivators are more stable than processes, for they come from the deeply held values of the organization.

This is a true and valuable point that processes will always affect tasks. And also no one will follow the processes if he is not interested in following them. Also the processes will be followed by anyone if they are feasible in the real environment with the real people. Processes should be prepared and planned in such a way that they can be used by REAL people to achieve their REAL tasks in the REAL world.

Solo efforts are OK, but the process is much richer when other members of the project community are involved. Once the process is good, many errors and faults can be caught before the damage is done.

So the whole episode has turned up into an extract that your processes should be

• Adorable
• Achievable
• Applicable
  

Adorable means that processes should be lovable by those who will have to follow them.

Achievable means capable of existing or taking place or proving true; possible to do.

Applicable means capable of being applied; having relevance.

This is all about the 3A Processes.

-- Sanat Sharma