1. Building QA Dashboard Based on a Real Project by Petro Porchuk 2010

3. BAD Communication

4. BAD Tasks Distribution

5. BAD Control

6. Too Much Time WASTE for Reporting

7. People Motivation

8. Continuous Customer Confidence Prompt

9. BAD Project Risks Visibility

10. Underestimation ? Copyright 2010 Petro Porchuk, Lohika

12. Resource

15. Tables

16. CheckLists

18. The JIRA Portlet Macro allows you to display a JIRA dashboard portlet on a Confluence page. JIRA is the issue tracking and project management system supplied by Atlassian. http://confluence.atlassian.com/display/JIRA/Customising+the+Dashboard http://confluence.atlassian.com/display/DOC/JIRA+Portlet+Macro Copyright 2010 Petro Porchuk, Lohika

20. The QAD update should be automated AMAP.

21. You don't work for statistics – statistics works for you !

22. QAD should be available for every team player.

23. Everyone should be keeping the QAD sources up-to-date and accurate in scope of his/her responsibilities.

24. QAD is a tool , use it! Copyright 2010 Petro Porchuk, Lohika

26. QA Resource Map Copyright 2010 Petro Porchuk, Lohika

28. (“Big Picture”)

29. Tasks Dependencies

30. Assignment per Person

31. Timings

33. Paint / Paint.net

34. Wiki / Confluence Copyright 2010 Petro Porchuk, Lohika

36. Tasks Distribution

37. Great Visibility

38. Links Container

39. Capacity Reflection

40. Tasks Overlay Visibility

42. Wiki / Confluence Copyright 2010 Petro Porchuk, Lohika

43. Tom DeMarco on Measurement „ You can not control what you can not measure. Measurement is the prerequisite to management control. “ from Tom DeMarco American Consultant, 1982 Copyright 2010 Petro Porchuk, Lohika

44. Feel Clean and Fresh When? Copyright 2010 Petro Porchuk, Lohika

45. Why do People change Job? Copyright 2010 Petro Porchuk, Lohika

47. TC by Priority

48. TC Monthly Grouth Copyright 2010 Petro Porchuk, Lohika

50. Priorities Look & Feel

51. Coverage for Equal Complexity Items

52. Determination of Weak Components

53. Test Effort Estimation is Easier to Do

55. Paint / Paint.net

56. Wiki / Confluence Copyright 2010 Petro Porchuk, Lohika

59. Paint / Paint.net

60. Wiki / Confluence Copyright 2010 Petro Porchuk, Lohika

62. Paint / Paint.net

64. Regression Testing Effort Evaluation

65. Work Progress Retrospective

66. Consider Automation QA Needs

67. Consider Team Capacity

68. Consider Estimates Timing Copyright 2010 Petro Porchuk, Lohika

70. Unresolved Production Bugs

72. Production VS Found by QA Bugs

73. Unresolved Bugs per OFI

74. Unresolved Bugs per Component

75. Unresolved Bugs by Priority

76. All the Bugs by Status Copyright 2010 Petro Porchuk, Lohika

79. Level of Coverage by Regression Tests

80. Level of Goodness of Feature Tests

81. Level of Customer Confidence

82. Level of ROI for QA Team

83. Level of Risks Mitigation Copyright 2010 Petro Porchuk, Lohika

84. BDP Analysis Copyright 2010 Petro Porchuk, Lohika BDP < 85 %

85. Different Charts from one Source Copyright 2010 Petro Porchuk, Lohika

88. Helps to set Priorities for the Team

89. Helps to find out which Test Level needs to be improved Copyright 2010 Petro Porchuk, Lohika

92. Helps to Set Priorities for PD, QA Teams

93. Helps to Plan and Estimate Feature Testing Copyright 2010 Petro Porchuk, Lohika

96. Shows Project's Reliability Copyright 2010 Petro Porchuk, Lohika

99. Helps to Evaluate Work Scope for either QA or PD team Copyright 2010 Petro Porchuk, Lohika

101. Average Time in Status

102. Time to First Response

103. Resolution Time

104. Average Age

105. Created vs Resolved Issues Copyright 2010 Petro Porchuk, Lohika

108. Resolved Issues

109. Created vs Resolved Issues

110. Level of Code Quality Copyright 2010 Petro Porchuk, Lohika

113. PD Team Handles Issues In Time

114. PD Lead Reacts Quickly Assigning

115. QA Drops are not a Bottle Neck of the Process Copyright 2010 Petro Porchuk, Lohika

117. PD Team is not skilled well

118. Not Enough PD Capacity

119. PD Team does not Monitor BTS Copyright 2010 Petro Porchuk, Lohika Issues are staying in Open / In Progress status too long... PD Team is having problems

121. Configuration Management should be Improved

122. PD doesn't Process Issues Flow Well Copyright 2010 Petro Porchuk, Lohika Issues are staying in Pending Build status too long... Configuration Management or Build Planning is Weak

124. QA Team is not skilled well

125. Not Enough QA Capacity

126. QA Team does not Monitor BTS Copyright 2010 Petro Porchuk, Lohika Issues are staying in Resolved status too long... QA Team is having problems

129. PD Team Handles Issues In Time

130. PD Lead Reacts Quickly Assigning

131. QA Drops are not a Bottle Neck of the Process Copyright 2010 Petro Porchuk, Lohika

138. Consider, whether old Issues are getting Fixed or are put On Hold.

139. Should get lower or stay Constant Copyright 2010 Petro Porchuk, Lohika

142. Resolved Issues

143. Created vs Resolved Issues

144. Level of Code Quality

145. The Two Lines should Cross Copyright 2010 Petro Porchuk, Lohika

148. Show Other Stuff Copyright 2010 Petro Porchuk, Lohika

151. Shows Statuses per Component

152. History Storage Copyright 2010 Petro Porchuk, Lohika

154. Metrics for Evaluating TC (complexity, etc)

155. Metrics for Calculating Test Costs

156. Metrics for Measuring Test Coverage

157. Metrics for Assessing Test Effectiveness Copyright 2010 Petro Porchuk, Lohika

159. ( Solves a Lot ) BAD Communication

160. ( Solves ) BAD Tasks Distribution

161. ( Solves a Lot ) BAD Control

162. ( Solves ) Too Much Time WASTE for Reporting

163. ( Solves Partially ) People Motivation

164. ( Solves ) Continuous Customer Confidence Prompt

165. ( Solves a Lot ) BAD Project Risks Visibility

166. ( Solves Partially ) Underestimation V Copyright 2010 Petro Porchuk, Lohika

167. Thank you! ? [email_address] Copyright 2010 Petro Porchuk, Lohika