April 11, 2017
April 9, 2017
Leave a Comment
The Software Process and Measurement Cast 437 features a discussion of our recent re-read of The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) with Steven Adams. Steve has participated on nearly all of the re-reads, providing his unique wisdom. It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development. Steve also has some advice on how to get the most out of the re-read feature.
Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development. Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems. Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson. Steve enjoys listening to technical podcasts, and SPaMCAST was one of the first and is a favorite! Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.
Re-Read Saturday News
This week we begin our read of Holacracy with a few logistics and a review of the introduction. We have a short entry this week that will give you time to buy a copy today and read along! If you have not listened to my interview with Jeff Dalton on Software Process and Measurement Cast 433, I would suggest a quick listen. Jeff has practical experience with using the concepts of holacracy in his company and as a tool in his consultancy.
Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson was published by Henry Holt and Company in 2015. The book is comprised of a forward, 10 chapters in three parts, notes, acknowledgments, and an index. My plan is to read and review one chapter per week. We will move on to a new book in approximately 12 weeks.
April 8, 2017
This week we begin our read of Holacracy with a few logistics and a review of the introduction. We have a short entry this week that will give you time to buy a copy today and read along! If you have not listened to my interview with Jeff Dalton on Software Process and Measurement Cast 433, I would suggest a quick listen. Jeff has practical experience with using the concepts of holacracy in his company and as a tool in his consultancy. (more…)
April 6, 2017
Leave a Comment
Jeremy Berriault provided an example from this presentation at QAI Quest 2017 for us to count test case points. Jeremy, QA Corner, indicated baseline data was required to effectively run the three test cases in his example
The logon, transaction
, reports and expected output blocks represent verification points. The arrows from one test case to another represent interfaces and steps are. . .steps. The results of the count is as follows:
|Test Case||Number of
test case 1
|test case 2||
|test case 3||3||2||3||required||
Deriving the complexity leverages the following chart: (more…)
April 4, 2017
Independent testing groups are often asked how long and how much effort is required to test a piece of work. Several size estimation techniques are actively in use in many organizations. Each of these techniques begins by deriving size either based on a set of rules or through relative sizing. Size, once derived, is used to estimate effort. Effort is then used to generate cost, staffing and duration estimates. The first sizing technique is“Test Case Points”
Test Case Points are a unit of measurement generated from the the testable requirements based on a set of rules. The process is straightforward:
- Identify the testable requirements in a piece of work. Use Cases or technical requirements documents are used for identifying testable requirements.
- Identify the complexity of each testable requirement. Test case points evaluate four factors to determine complexity:
- The number of test steps. The number of execution steps needed to arrive at an expected (or unexpected) outcome after all preconditions have been satisfied.
- The number of interfaces to the other requirements. A simple count of the number of interfaces in the test case.
- The number of verification points. A simple count of the points in the test case that the results are evaluated for correctness.
- Need for baseline test data. An evaluation of whether data needs to be created to execute the test case.
Once all of the simple, medium and complex test cases are identified, they are summed by category.
- Weight each category.
- Sum the weighted categories together to yield the total test case points
The goal of test case points is to use size to generate an estimate. Every version of test case points I have worked with uses a set of factors to adjust the size as part of the sizing process.
- Develop an estimation adjustment weighting based on a set of factors (for those familiar with IFPUG Function Points this adjustment is a similar process to the one for determining the value adjustment factor). The factors are:
- Count or Single Factor Adjustment Factors
Factor 14 – Operating System Combinations (simple count)
Factor 15 – Browser Combinations (simple count)
Factor 16 – Productivity Improvement from Second Iteration Onwards (percentage)
- Factors that leverage a combination of fixed factor and complexity weighting
Factor 1 – Domain Knowledge & Complexity
Factor 2 – Technical Know How
Factor 3 – Integration with other Hardware Devices such as Handheld Devices, Scanners, Printers
Factor 4 – Multi-lingual Support
Factor 5 – Software/Hardware Setup
Factor 6 – Environment Setup
Factor 7 – Build Management
Factor 8 – Configuration Management
Factor 9 – Preparation of Test Bed
Factor 10 – Stable Requirements
Factor 11 – Offshore/Onsite Coordination
Factor 12 – Test Data Preparation
Factor 13 – Network Latency
- Generate an estimate using the following formula
Weighted Test Case Points X Adjustment Factor X Historical Productivity Rate
In many cases, organizations generate estimates for types of work separately using the adjustment factors that that would affect the type of work. An example of a type of work is test case generation. Factor 5, software/hardware setup, would not be predictive of the effort for setting up test cases.
The process for deriving test case points is fairly straightforward (steps 1 – 4). The process of turning the test case points into an estimate is more complicated. Next, we will develop a short example and examine the strengths and weaknesses of the process – some which are very apparent and other are not.
April 2, 2017
Leave a Comment
The Software Process and Measurement Cast 436 features our essay titled, Change Fatigue, Tunnel Vision, and Watts Humphrey, in which we answer the question of whether the state and culture of the organization or team, can have a large impact on whether a Big Bang approach or an incremental approach makes sense to change.
Our second column is from Jeremy Berriault. Jeremy discusses user acceptance testing and Agile. There are lots of different ways to accomplish user acceptance testing in an Agile environment. The only wrong way is not to do UAT in Agile. Jeremy blogs at https://jberria.wordpress.com/
Jon M Quigley brings his column, The Alpha and Omega of Product Development, to the Cast. This week Jon puts all the pieces together and discusses systems thinking. One of the places you can find Jon is at Value Transformation LLC.
Re-Read Saturday News
This week we wrap-up our re-read of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In the wrap-up, we discuss overall impressions of the book and suggest a set of exercises to reinforce your growth mindset.
The next book in the series will be Holacracy (Buy a copy today) by Brian J. Robertson. After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy, therefore we will read the whole book together. (more…)
April 1, 2017
Next week we will begin our read of Holacracy. Buy a copy today and read along! In preparation I suggest listening to the interview with Jeff Dalton on Software Process and Measurement Cast 433, Jeff has practical experience with using the concepts of holacracy in his company and as a tool in his consultancy. Today we wrap up our re-read of Mindsets. If you have not read the book or have not read each of our installments please use the links at the bottom of this entry and enjoy. (more…)