programmer

How to predict the number of bugs in the next code of a programmer

You have a programmer who is writing codes for years that comes to you for testing. The programmer might be coding for a number of projects simultaneously or sequentially. Similar would be the case with you. You would be testing a number of projects simultaneously or one after the other. By now your subconscious mind knows the pattern of bug writing while coding by each of the programmer. But since these patterns are not recorded or analyzed you can not predict the probable number of bugs in the next set of a code from a programmer.

You can do that with the help of your bug reports so far you have submitted back to the programmer or development team. Just pull out your last ten bugs reports produced from the code written by the same programmer. Check for a specific number of lines of code how many bugs were found. Based on this one report’s bugs were from how many lines of code. Do the same exercise for all other reports. Take an average for all ten reports.

Based on the number of lines of code, this way you can easily predict the number of bugs that will be there in the fresh set of code submitted by the programmer for testing.

20 gems for project managers

1. A project manager is always right
2. Quality is seriously maintained by developers while developing software
3. A separate set of people (quality control or testers) is not required to take care of the software produced or developed
4. Testers don’t do any substantial value addition in product development
5. Testers lack business knowledge
6. Testers lack technical knowledge
7. Testers lack essential skills to test software
8. Testers don’t understand product requirements well
9. All developments and implementations are prone to extensions because of change in customer requirements or other customer constraints
10. All delays in development and implementation are due to customer
11. Testers have a very little role to play in product development
12. Testers need less than 1% of project time for testing and reporting bugs
13. Testers should be able to test the product well even if substantial knowledge related to product has not been shared with them
14. Testers are the biggest misleading agents
15. Developers and programmers are not testers and thus are not supposed to test what they develop
16. Testers are de-motivators to programmers and developers
17. Testers are project delayers
18. Customers blame development and implementation teams just to hide their own shortcomings
19. Customers don’t know to explain their processes and business rules well
20. Customers are always interested in delaying the project

Quality of documents says it all about the health of the project

A software project has to undergo various stages before reaching the final stage of customer sign off. At each stage of the project there are certain set of documents that are maintained by the project team for internal or external purposes.

These documents are prepared by various team members – by business analysts, by coders, by project manager, by testers and by other managers.

The Quality and maturity of documents straightaway tell about the health of the project, the team, the management, the product and the progress. It tells clearly about the intentions behind the documentation – that if it is merely a formality or it is really meant for helping the project progress.

And it is not difficult to ascertain the intentions after going through the documents maintained or being maintained during the project.

Why is Change opposed?

A coder or programmer when told that he is not writing his code, by way of presenting him with a list of bugs, he is being told to CHANGE.

A tester when is told by his superior that he lacks business depth for testing the product, he is being told to CHANGE.

A project manger when told that he has to improve his way of managing a project, he is being told that the current methodology does not suffice the purpose. It requires a CHANGE.

A management when consistently fails to deliver its commitments to its employees and customers, means it needs to introspect and CHANGE.

When a person, department, team or country stops delivering, or starts giving indications of failure in one aspect of other, it asks for CHANGE.

Change is powerful.
Change is inevitable.
Change does not challenge your knowledge.
Change does not indicate that you are incapable. Rather when one is being told to change, someone has confidence in his capability to CHANGE and PERFORM better.
Change does not mean that you are wrong, it means that there is a scope of improvement.

But

Change is often opposed as a natural tendency because it is taken as an indication that you are not performing well and what you are doing is not doing well.

The 80/20 rule in Software Testing

Pareto Principle or Pareto Rule is quite fascinating in managing personal and professional life, time management, task management, self motivation etc. Crux is if you focus few vital issues in life you manage major part of your life better. The same applies in profession, organization, department function, and activity too. Only thing is it is to be applied objectively, and smartly.

Let us see how it can work in terms of software testing and quality control:
80% of software quality is maintained by 20% of programmers
80% of bugs in an application are written by 20% of developers
80% of bugs are fixed in 20% of time
20% of a business application accounts for 80% of bugs

A wonderful powerhouse gifted to a project manager – his Team

All project managers depend on their teams working on the project and in turn the persons who form the team. Teams could comprise of project leader, module leaders, functional consultants, technical consultants, database architecture, system designers, developers, programmers, testers etc. To keep working towards excellence a project manager has to focus continuously on people management, grooming of teams and team members.

If project manager’s has this as one of the top priority in his list then his performance, the results related to his project, and his team’s momentum are always improving. The top management and the project manager have to clearly understand that what it makes to run a company and project successfully is not anything else but the people constituting various teams.

Project Management – Tasks vs. Milestones

A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.

Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.

Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.

So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.

Milestones have more visibility as compared to tasks.

Mr. PM, what metrics you use for measuring “Task Completion”

It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.

Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.

Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.

Transparency about the project progress is as important as the authenticity to both – the management and the customer.

Integrity of task completed is another measure that you have to take into account for your project completion.