January 25, 2008 at 4:18 am
· Filed under Quality, Software Testing
One of the key items for a software tester is to know when software is defective. The best definition of a defect that I have been able to find comes from Software Testing (2nd Edition)
:
- The software doesn’t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn’t do.
- The software does something that the product specification doesn’t mention.
- The software doesn’t do something that the product specification doesn’t mention but should.
- The software is difficult to understand, hard to use, slow, or—in the software tester’s eyes—will be viewed by the end user as just plain not right.
Points 1 and 2 above are pretty clear cut. Basically, if the software acts differently than explicitly stated, it is a defect. Defects found of this type are relatively easy to report and usually are not contested by the developers or product manager.
Given that 4 of the 5 rules are related to the specification it shouldn’t surprise us that the specification is typically the number one cause of defects. Why? Because specifications are hard to write. It is difficult to capture the entire design of a feature or product without having concrete examples of what is possible. Customers’ needs can change from the time the spec is born and the time it is implemented.
If we are in a position that is more of a Quality Assurance type of role, then we should be concerned with the quality of the spec. We should take an active part in reviewing it. If we are in a position that is solely testing-based, then we must live with poor specs.
Read the rest of this entry »
Permalink
January 24, 2008 at 5:31 am
· Filed under The Business of Software
There has been a recent flurry of activity in the Mac community regarding the bundling of applications. MacHeist has just recently concluded its second bundling attempt in which they offered 14 products normally priced almost $500 for only $49. In addition to the bundle, 25% of their sales are being donated to charity. The first year the bundle was offered, they sold approximately 16,000 bundles in one week. This year they sold approximately 44,000 bundles over a two week period.
Most of the opposers to this particular bundle have focused their criticisms from the viewpoint of a developer who offers his application in the bundle. We hope to dispel such negativities in this article.
End-Users’ Perspective
From the end-users standpoint, this bundle was a no-brainer. If there was even one application in the bundle that you desired, this bundle was the way to go. Most of the applications offered are normally sold at or above the bundle price. There has been some criticism that some of the apps offered were “special” promo versions. These special versions are equivalent to the current shipping version but could potentially charge customers in the future for major upgrades. In my mind, this would not be a show-stopper for an end-user purchasing this software. I, as an end-user, get the current fully functioning version and, in the world I live in, I have already been conditioned to paying for upgrades. This did not even effect all of the applications in the bundle. From what I saw, only 3 of the applications had these special promo versions and nothing was explicitly mentioned that I’d have to pay for upgrades.
The bundle has also exposed end-users to apps that they might not have explored had they not been included. For example, I brought the bundle just because Pixelmator was included. When I bought the bundle, I downloaded add installed all of the apps. Once I started using some of the other apps, I became hooked. On paper, the app 1Password didn’t seem like something that I’d need. Now that I have used it, it is indispensable. I would have never known this without trying and I would have never tried it because it doesn’t sound that exciting.
The charity donation was also a nice touch. The bundle was set up such that the buyer could specify which charity out they would support. The amount of money raised was prominently displayed on the front and was updated in real-time. I enjoyed going back to the site just to see how much was raised.
Read the rest of this entry »
Permalink
January 23, 2008 at 4:47 am
· Filed under Book Reviews, Quality
I have recently finish reading the book Four Days with Dr. Deming: A Strategy for Modern Methods of Management (Engineering Process Improvement Series)
and I would like to share my thoughts on it.
This book is designed to replicate the feeling that a CEO would have had attending one of Dr. Deming’s four day seminars. The book is a relatively quick read and is presented to appeal to multiple learning styles.
Some of the items that strike me as most important in applying Dr Deming’s principles are:
A) Quality needs to be top down to be truly effective.
Bottom up is ineffective. Even if the bottom tier is doing it’s assigned duties in a high quality fashion, they may still not be doing the right thing. It is an employees job to make sure that he “cuts down trees” in as efficient manner as possible. It is a leader’s job to make sure that the employee is in the right “forest.” The employee does not have the visibility to know if he is in the correct forest. This is especially true in software development. The cost of finding a defect increases exponentially the further away from it’s point of origin. If quality is not made a priority for the whole team and is relegated to a Quality Assurance group, the system will not function optimally.
B) Variation always exists.
The identification of “special causes” and “common” causes are key. Special causes can be fixed by the people implementing the process via such things as training. Common causes need to be fixed by changing the process. Until Fred Brook’s Silver Bullet
is invented or found, there will always be defects in software from the common causes of variation. Therefore, we need to get individual developers trained to a stable state and then focus on improving the process of development.
C) Systems with only common cause variation are said to be stable.
Stable systems can only change if the process changes. Attempting to provide further training to individuals will be ineffective.
Read the rest of this entry »
Permalink