October 2005 |
||
 |
 |
|
The Seapine View |
This month's Seapine View includes more information about the TestTrack Pro 7.5 release, along with an informative article about identifying the competencies needed to build a successful team. Blogger Michael Russell also returns with a look at using milestone acceptance criteria during software testing.
Enjoy the View.
Rick Riccetti
President
Seapine Software, Inc.
rick@seapine.com
Adaptive Path, LLC
Every Web team has its own take on dividing up roles and responsibilities and implementing processes for design and development. Formal titles, job descriptions, and reporting structures can vary widely. But the best teams I've encountered have one important thing in common: their team structure and processes cover a full range of distinct competencies necessary for success.
I've come to think of these competencies as the Nine Pillars. In a successful team, we can quickly and clearly identify which team members have which of these nine competencies, and where these competencies come into play in the design and development processes. When the system seems to be breaking down, it's often because one of the pillars is missing, either from the team structure or from the process.
 |
Read the full Adaptive Path essay. Jesse James Garrett is the Director of User Experience Strategy and a founder of Adaptive Path. He is author of the widely-referenced book The Elements of User Experience. To learn more collaborative development best practices, read the Seapine white paper Breaking Through the Barriers to Collaborative Software Development. |
TestTrack Pro 7.5 is now available. This release includes full Unicode support, a new cross-platform client, added custom field options, expanded workflow functionality, and many other features and enhancements.
Not a current TestTrack Pro customer? Try it free for 30 days - it's easy to install and includes free technical support. Download now.
Thank you to everyone who stopped by our booth at SD Best Practices 2005 in Boston last month. It was great meeting so many of you in person!
Ritual Entertainment
After my smoke tests, I usually include common criteria that will be appended to each milestone acceptance test. Since these usually include overarching goals, it's best to make sure that they're established and signed off on up front.
In addition, "Acceptance Criteria" may be a bit of a misnomer. You specifically want to list anything that will cause you to fail a milestone, because that's what the team will care about most.
For example, this is a section from my "Milestone Acceptance" section on [deleted]:
A milestone shall be considered to have failed if any of the following are true:
- A reproducible crash is found during the first sixty (60) minutes of testing the milestone.
- Three (3) reproducible crashes are found during the first eight (8) hours of testing the milestone.
- One (1) major milestone deliverable is found to be not implemented or non-functional during the testing of the milestone.
- Three (3) minor milestone deliverables are found to be not implemented or non-functional during the testing of the milestone.
- At least one (1) level transition does not work.
- At least one (1) level cannot be completed without using the ÒnoclipÓ cheat.
- At least one (1) level does not load.
- At least one (1) weapon does not work.
- At least one (1) multiplayer mode does not work.
- A multiplayer game cannot be hosted or joined.
- If there are more than ten (10) active severity 1 bugs in the [deleted] bug database.
The above may seem very harsh, but it's also very common in video gaming...especially from a publisher standpoint. More and more, publishers are including stability bars in their milestone acceptance criteria. So let's walk through the list really quickly.
Numbers 1 and 2 are there simply to act as a deterrent against submitting unstable builds. If a build can't last an hour without crashing, why am I looking at it as a progress milestone? The three-crash bar acts as an additional stabilizer.
Numbers 3 and 4 are pretty basic as well. Milestones are supposed to have a certain set of deliverables. Those deliverables may be shuffled between milestones, but what is delivered in a milestone is expected to 1)be there; and 2)work. While there may occasionally be dickering regarding what is a major or minor feature, that's a small price to pay for making sure that each milestone has what it says it will have.
Numbers 5 through 10 are very specific to the title. In [deleted], the goal is to have the entire game capable of being played through very early, so as part of my acceptance test, I'd go through and play the entire game from beginning to end.
Finally, we have number 11. This one is the one that people usually get the most grief over. Every project has a bug database. It may be just E-mail going back and forth, it may be an Excel spreadsheet, it may be a modified version of IssueTracker, it may be a full-featured bug client like Seapine TestTrack Pro, but you always track your bugs. The goal of this is to make sure that major bugs don't carry over from milestone to milestone.
Bugs are always rated by the test team on their severity. Severity levels are fairly well defined, and severity 1 is the worst. For a bug to be severity 1, it must be either a crash bug, cause data loss, cause the title to fail certification on a console platform, or be a bug that would definitely cause the product not to ship.
Every product has these sev 1 bugs. The more you have active, the less stable your product really is. The goal is to keep no more than ten of them on our plate from milestone to milestone.
The biggest issue you are going to see if you implement a severity bar in your MAT is a mass-resolve of bugs just prior to a milestone. Easiest solution: tell them that reactivations of sev-1 bugs count towards the 10. It may seem cheap, but so is trying to get around the submission guidelines.
Milestones are there for one reason and one reason only: to act as a constant heartbeat for a project. Publishers pay when they feel the pulse. If your product doesn't have a decent pulse, then it's crisis time.
Click here to read more of Rom's Rants.
Seapine's Professional Services group conducts FREE online product demonstrations several times per week. After downloading and installing Seapine products, sign up for an online demonstration and get answers to your questions right away!
 |
StickyMinds.com
|
Click here to read the full StickyMinds.com article.
This article by Mike Clark originally appeared on StickyMinds.com. |
|
|
 Subscribe |
Reading someone else's copy of the Seapine View?
|
Seapine's knowledgebase is a great place to find answers to technical support questions and learn new ways to extend your use of our products.
|
Saving the Workflow Diagram in TestTrack Pro Web |
|
Downloading the Surround SCM Integration Patch |
|
Configuring Apache to Display Unicode Characters in TestTrack Pro Web |
|
SourceOffSite Cannot Find the Encryption Key (TestTrack Pro) |
|
SMTP Send Mail Error in TestTrack Pro: 5.5.4 Invalid Address |
|
TestTrack Pro Server on Mac OS X 10.2 Cannot Connect to Oracle |
|
Customizing TestTrack Pro Web Images |
|
Integrating Surround SCM with Macromedia Homesite |
|
Database Statement Limitations for Excel and Text Files in QA Wizard
|
|
Minimum Level of Rights for QA Wizard |
QA Wizard can use checkpoints on a Web page or application window for a specific word or text string. You can configure script settings that make it easier to create checkpoints across multiple objects, then create a checkpoint to validate the existence of the word or text string. To find out more, read the following article in our knowledgebase: Checking for a Specific Word or Text String.
Seapine Software, Inc.
5412 Courseview Drive, Suite 200
Mason, Ohio 45040
Tel: (888) 683-6456
Email: sales@seapine.com
www.seapine.com
|
Subscribe |
Latest Product Releases |
Share Your Knowledge |
|
Contact
Us |
