Non-reproducible bugs – What does that mean?

From Testing team standpoint: We found this Bug once while testing the software. Now we are not able to reproduce it.

From Development team standpoint: Please reproduce it else we will mark this bug as invalid.

These are the two aspects against a bug which the tester’s find only once while testing the software but not able to reproduce it. In my opinion, non-reproducible bugs should be renamed as "hard-to-reproduce" bugs. This term will justify some existence of these kinds of Bugs.

All the Bug Tracking Tools have some options to handle these kinds of issues but normally I have seen a same way to tackle these kinds of bugs by the development team. “Please reproduce it. Then we will consider this as a Bug and work on it”.

In one of my previous organization, I found a bug which I was able to reproduce it my setup but the developer was not able to reproduce it in his setup. I also tried my best to recreate the scenario in the development’s setup but all efforts failed. At that time, one of my development manager surprisingly said that the Test team should not file this bug because the development team is not able to reproduce this bug in their setup. It was the statement that truly captured his attitude towards Testing. But I still logged that Bug and it has been marked as “rejected” by the development team. After two months, same problem has reported by the customer and then you can imagine whatever happened after that was not good for that development manager. Every muscle in his neck and face was tensed when he was questioned by the management.

In my first organization where I worked and progressed as a Test team member, I fired 75% of the total bugs logged in the Bug Tracking System against specific software that I tested. Some of those issues are non-reproducible but 65% of those bugs have resolved by the development team. Fortunately, the development team understood the term in a better way.

I have seen in my carrier that a non-reproducible bug remains as it is in the Bug Tracking System as decorative as Chinese lamps. And after some time, that bug has been rejected by the management without even asking from the Test team.

There should be some rule (or process) according to the organization perspective as to how to handle the “Non-reproducible” (or better say “Hard-to-Reproduce”) bugs. Good people do not need rules to tell them to act responsibly, while bad people will find a way around the rules. If we ignore these bugs, we have to pay off. Ignorance can lead to unawareness that the light you see the end of the tunnel is actually an oncoming train.

-- Sanat Sharma (सनत शर्मा)
Quality and Testing Expert

Project Plan – Initiating, Planning, Execution, Control, Procedures and Deadlines.

A Project Plan (PP) should contain the track of all these activities mentioned above. Few days back, I was reading a book about Project Management and Planning. There was a statement which says “Every professionally managed, successful project is driven by a project plan and every un-successful project is driven by the project itself”.

Initially, I was a little bit confused for this statement. But after giving a second thought on it, I found it very realistic and relevant statement for Project Management (PM).

All the action items covered in the PP can be tracked in a better way if they have defined in a proper way. In one of my previous company where I worked in my earlier carrier phase, my manager always used to ask the question” What are you doing today?” Once I said to him that since there is no PP defined for this project, so better not to fire this question to me on daily basis. I asked him to first make a PP and define the tasks and action items against me, so that I can tell you in a better way. But I believe he was not convinced with my answer as most of the managers are not convinced with their subordinate’s answers. After two three days, he again came to and an interesting conversation between us went like this:

Manager: What are you doing today?

Myself: I am going to listen songs today.

Manager: What?

Myself: Yes, I will listen songs today. In fact I have done this exercise yesterday also.

Manager: This is not expected from a resource like you. You are one of the most critical resources in my testing team.

Myself: So what sir. I have no tasks assigned in Project Plan. In fact there is no Project Plan as such for me. So I can do anything what I want.

Manager: If there is no Project Plan, that doesn’t mean you will do whatever you want.

Myself: Agree. But in that case, you should assign me some other work related to project and then better come to me asking for what I am going to do today.

Manager: Ok.

And then he left my place. After one week, he again came to me with a Project Plan and also some additional activities for which he allocated me as a primary resource. I was pleased to see that change. This time, I have to answer his question “What are you doing today?”

This incident gave me a lesson that if your team is not performing, the managers are responsible primarily for this state.

The whole event comes to a conclusion that making a PP can definitely track the team activities in a better way and at any time of the project, it can be measured that how much percentage of work has been done against the project.

I have seen in some companies that managers are not interested in updating the PP on regular basis. They are only interested in making it once and forget to update. They should understand this fact that updating the PP is their primary task. If they are not doing this activity on regular basis, better not to say them managers. They are only a front desk employee of the company with a Manager’s salary.

Last month, I was discussing some quality processes for an accurate PP with one of my friend who is a Project Manager in a reputed MNC. He said that PP is one of the most important tasks that a Project Manager should perform. He also added that this is also one of the most cumbersome tasks in Project Management. According to his statement, he is going to leave the IT industry only because he has to update and maintain the PP. I tried my best to convince him that there are n numbers of ways to perform and execute this task in a better way. I personally share some of my views about the PP and Project Management with him. Somehow, he was convinced with me but not by the processes and techniques that his company is following with respect to the Project Plan and Project Management. We discussed about 4-5 hours for the same and then went off to our places. Last week, he called me saying that he has resigned from his current company and going to join a small IT company. He said that he will now check these management practices in a small company.

Anyways, small, mid and large companies don’t mean that there is a difference in the Project Planning and Management. The only difference is the attitude of the middle and higher management. The middle and the higher management should be responsible for anything that is going in a wrong direction in any project.

It is your attitude not the aptitude that decides your altitude.

-- Sanat Sharma

Buffer Time in Project Management

3 years back, when I was not a part of project management, I was not aware of the term "Buffer Time" or BT. or fairly I can say I was not aware of the actual meaning of "BT". When I primarily started my carrier in Project Management, I came to know the actual and meaningful meaning of this term. I was fortunate to start my role in project management in a very small company but a value centric company with a genuine and great management team. At that time, I was under the impression that BT means time that is being kept by the management to protect the project from the impact. I believe that is somehow the appropriate definition of BT. At that time, I tried my best to keep BT on the basis of other factors so that it can be evaluated in a proper way.

As far as factors affecting the BT is concern, two factors “Risks” and “Dependencies” plays an important role to evaluate this. There are some common rules based on these two factors that calculate the BT for any project. Whenever I asked to provide the effort estimation for any Testing cycle, I always try my best to calculate the effort estimation including BT on the basis on these two factors – Risks and Dependencies.

But now days, BT is becoming a part of effort estimation in projects. Let me clear it in a mathematical way.

Effort Estimation = Time to develop (or Test) + Buffer Time

What I have seen recently is that Buffer Time is being used by the teams (either development or Test) as a part of performing their activities. In that case, if anything goes wrong i.e. any of the risk or dependency happen, the project delays. Ideally, the BT should not be used in the primary activities. The managers should not disclose the BT to the front desk employees. If the BT is being shared with the team members, everyone is assuming this time as a regular project activity time. These practices definitely delay the project deadlines.

But before calculating the BT, the managers should be aware of the risks and dependencies. Not to disclose this but I have seen some managers in my carrier who are not aware of these terms and managing the project. What a joke.

I have seen on the road traffic signals a great example of crushing the BT. The vehicle owners always look on the other side traffic signal so that they can act according to its movement. If there is a green signal and the traffic goes on, the other side vehicle owners will not see their respective traffic lights. They will see the other side traffic lights and immediately when the green turns to orange, they start running irrespective of the fact that they still have red light to stop.

Now this orange light is the BT. But who cares. People start their vehicles running on orange light itself. Most of the accidents I have seen in the traffic signals in due to this BT crushing.

So a million dollar tip for the managers is that they be aware of the risks and dependencies of the projects and should try their best to evaluate the BT. If possible, do not disclose the BT in front of your team and if you have to do that, in any case, keep another BT for the completion of the project still on the planned dates.

-- Sanat Sharma

(Quality Assurance and Testing Expert)

System Requirements Document (SysRD) versus Software Requirements Specifications (SRS)



Questions 1. Who is responsible for creating SysRD?
Questions 2. Who is responsible for creating SRS?
Questions 3. Who will approve the SysRD?
Questions 4. Who will approve the SRS?
Questions 5. In which phase of product life cycle, the SysRD should be finalized and approved?
Questions 6. In which phase of product life cycle, the SRS should be finalized and approved?
Questions 7. Which document should be considered by the Test team to test the software? SysRD or SRS?


And the ideal answers are

Answer 1. System Engineers after having discussions from the marketing teams.
Answer 2. Development Team taking inputs from the Testing team.
Answer 3. System Engineer
Answer 4. System Engineer
Answer 5. Phase - 2 i.e Requirement Analysis phase
Answer 6. Phase - 3 i.e System Design
Answer 7. Both

But what is happening in the Software industry now a day. See the factual answers

Answer 1. System Engineers but not having a clear picture from the marketing teams.
Answer 2. Development Team only. Few inputs or rather no inputs from the Test team.
Answer 3. System Engineer
Answer 4. System Engineer and Testing team
Answer 5. Phase – 4 i.e. Coding
Answer 6. Phase – 4 and 5 i.e Coding and Testing
Answer 7. Mostly SysRD.

-- Sanat Sharma

Testing Effort Estimation
--------------------------

This is one of the most crucial issues that the Testing team is facing now days in Software Industry. Your manager will simply ask for the effort estimation that is required to Test the software. He is definitely not aware of the fact that the Test team has no requirement documents. Or if he is aware by any chance, he will not consider this fact.

Recently, I have seen that one of the development lead was asking for the Test cases from the Test team without providing them the requirement documents. That was really a great fun. I don't know from where these guys are getting their engineering degrees.

Well, the problem is not with the estimation but with the clarity. If you are not aware of what you have to estimate, how you can estimate the exact deadlines. We should understand this fact that why these are called the Estimations not the Predictions. We should know the difference between the Estimations and Predictions.

Recently, I have seen an example where Test team has given an effort estimation which could not be met due to some miscommunications between the development and the Test team. But finally, all blame goes to the Test team saying that your estimation was wrong. That was one of the most horrible experience I have ever suffered.

I have seen some managers who are not aware of the difference between the Risks and the Dependencies. And officially, those guys are responsible for effort estimations in development cycle. Amazing.....

I think one of the major factors for providing the effort estimation for Testing is definitely the requirement documents. But one more important criteria that should be considered before, is the previous experience. Make a thumb rule that I will estimate twice the number of days that is actually required to test the system. If you don't do so, the blame will come to you only.

-- Sanat Sharma