Testing knowledge base

I like Agile methodolody and everytime I try to adapt some practices from this methodolody to testing.

On that time, it's Planning Poker technique.

Benefits of this technique: 
1. Estimation are wighted up
2. Everyone understand and know what timeline they will have
3. Common responsibility of made decision.

How to play:
Make group of estimators and a Moderator.

1. Each estimator gets a deck of cards
2. The moderator reads the description of task
3. Task are discussed by team. Open points to be clarified.
   
4. Estimators should select an estimate card and and place it face down on the table
5. After all estimates are in, the cards are flipped over
6. In the event that the estimates differ, the high and low estimation are discussed.
7. Group briefly debates any arguments. Then estimation session repeats until decision is done.
   
8. The moderator notes down the final estimate and the group continues with next task.

What are necessary things before meeting:

1. Work Breakdown Structure should be done.
2. Task should have as much information as possible.
   

The objective of defects by how found is to show how the defects were discovered, for example, by external customers, manual testing, and the like. If a very low percentage of defects was discovered through inspections, walkthroughs, or JADs, this indicates that there may be too much emphasis on testing and too little on the review process. The percentage differences between manual and automated testing also illustrate the contribution of automated testing to the process.

The objective of root cause analysis is to show the source of the defects, for example, architectural, functional, usability, and so on. If the majority of the defects are architectural, this will pervade the whole system and require a great deal of redesign and rework. High percentage categories should be examined for maintainability after it is released for production.

Today, I would like to think about test management activities that always should be in mind of test manager. So the list is following:

1. Lateral Thinking in Developing Test Cases
2. Convey Issues as They Arise
3. Improve Communication
4. Always Keep Updating Your Business Knowledge
5. Learn the New Testing Technologies and Tools
6. Improve the Process
7. Common Knowledge Base

The objective of test burnout tracking is to indicate the rate of uncovering defects for the entire project and is a valuable test completion indicator. The cumulative (e.g., running total) number of defects and defects by time period help predict when fewer and fewer defects are being discovered. This is indicated when the cumulative curve “bends” and the defects by time period approach zero.

The objective of defect severity status is to show the distribution of the three severity categories for the entire project, for example, critical, major, and minor. A large percentage of defects in the critical category indicate that there existed a problem with the design or architecture of the application, which should be examined for maintainability after it is released for production.

The objective of defect gap analysis is to show the gap between the number of defects that has been uncovered and the number that has been corrected during the entire project. At project completion these curves should coincide, indicating that the majority of the defects uncovered have been corrected and the system is ready for production.