|
What to Review If You Can’t Review Everything Payson Hall shares with us a useful list of review criteria via a case study of a troubled software development project. Reviews can be messy. Sometimes it’s hard to know where to start, particularly when you are in triage mode and can only review a small sample.
|
|
|
Writing Test Rules to Verify Stakeholder Requirements Some organizations employ business analysts who are very good at specifying requirements at the beginning of a software project. The advantage of this step is the reduction in ambiguity for the developer and tester of what should be delivered.
|
|
|
Test Documenting Over the Cliff Unless you're in a test role where full, complete documentation is necessary in order to be federally compliant or to keep people from dying or losing a limb, attempting to document every little thing is a fool's errand. Software changes. A lot. With constant change, what we document one day may be obsolete the next.
|
|
|
Help Technical Support Help Themselves This article discusses how testing teams can improve their test coverage and better communicate with technical support to uncover issues earlier than during product implementation. This kind of collaborative work can stop most defects from getting into production.
|
|
|
Manual vs. Automated Code Review It's a battle between human and machine-a theme that could be ripped straight from a science-fiction story, but it is not. This is a reality many testers face when trying to determine if human expertise and intuition can detect more security flaws than automated tests. In this week's column, security expert Bryan Sullivan weighs both sides and offers his verdict.
|
|
|
Making Sense of Root Cause Analysis Applying Root Cause Analysis (RCA) to software problems is fundamentally different from applying it to other engineering disciplines. Rather than analyzing a single major failure, we are usually analyzing a large number of failures with software. In this column, Ed Weller explains how to use RCA to your advantage.
|
|
|
Lightweight Code Reviews: Team Building for the Rest of Us The author explores the people side of peer code reviews. Besides the technical and quality benefits, peer code reviews help build better teams. Believe it!
|
|
|
The Largest Case Study of Code Reviews—Ever In May 2006, we wrapped up the largest case study of peer code review ever published, done at Cisco Systems®. The software was MeetingPlace® — Cisco's computer-based audio and video teleconferencing solution. Over 10 months, 50 developers on three continents reviewed every code change before it was checked into version control. We collected data from 2500 reviews of a total of 3.2 million lines of code.
This article summarizes our findings.
|
|
|
The Pros and Cons of Four Kinds of Code Reviews The authors explore the pros and cons of four other common styles of code reviews—over-the-shoulder, email pass-around, pair programming, and tool-assisted reviews—and see which ones is the most promising candidate for practical peer code reviews.
|
|
|
Lightweight Code Reviews A Lightweight Alternative to Inspections In this article, we explore why almost no one does "proper" inspections and set up the case for lightweight peer code review. Try it. You'll like it!
|
|