A real world example of converting from an MRD to a PRD. This is the process of translating from a market-requirements view of the product to a product-requirements view of the product.
Lists / Software development / Software requirements specification / Test Automation / Testing
Posted on:
Software Testing Series: Organizing a Test Suite with Tags Part Two
This is the second in a three-part post about using tags as a means to organize an automated test suite.
Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.
Communication / Software development
Posted on:
Outside reading: Enterprise versus consumer software
Cote’ recently posted a good comparison of the features of Enterprise Software versus Consumer Software. Although we may not agree with all the items in his lists (consumer software can have a login, and very often does have upgrade paths), we do appreciate the general classification. And we really like his insight:
Process Improvement / Slightly off-topic
Posted on:
Outside reading: correlation and causality
A while ago, we asked you to send us links to good blogs. Jeff Kinsey sent us a link to his blog, Ski’s throughput on command. We found this post on logical thinking processes which is good. Thanks Ski for sending us the link!
Their post discusses the differences between causality and correlation of events.
Process Improvement / Software development / Software requirements specification / Test Automation / Testing
Posted on:
Software Testing Series: Organizing a Test Suite with Tags Part One
This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions – including a form of tagging.
Administrivia
Posted on:
New theme for Tyner Blain!
We’ve upgraded our theme! The new look should provide much better support for users with larger monitors, while still supporting folks reading at 800×600 resolution. We’ve added a calendar widget to make it easy to find the posts for a given date. We have easier navigation from page to page, […]
Prioritization / Project Management / Requirements / ROI / Software requirements specification
Posted on:
Using ROI For Requirements Is A Risky Business
We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.
If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.
The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.
Definitions / ROI
Posted on:
Definition of Expected Value
Understanding the expected value of a possible future event allows us to make mathematically sound decisions. We can decide if we want to make an investment. We can assign a reasonable price for our services. We can prioritize requirements. Expected value is a calculation that should be used when calculating ROI.
Marketing / Testing
Posted on:
Software Testing Series: Top Three Measurements of Quality
The three most important things to understand about the quality of your software are the three things most relevant to your business and your stakeholders (and arguably, your boss).
Top three measurements of software quality
1. How do people perceive our quality?
2. How big of a problem is our quality?
3. How bad is our software, really?