Getting good test documentation is a consistent challenge. Agile proposes that you should go very light on documentation, and while test documentation does not need to be heavy, it does need to be clear and cover all that the product is intended to do so you can ensure testing is consistent and results are recorded. Here's how to overcome some major barriers to getting good test documentation.
As teams strive to move to a mature agile process, technical writers must adapt as effectively as the development personnel. This new agile process demands that knowledge dealing with software or product releases is only sparingly documented up front, making the technical writer's job of gathering information much more dependent on talking with people over reading requirements.
Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.
In this interview, Craeg Strong speaks about his upcoming presentation, meeting strict documentation requirements in agile, how agile documentation differs from traditional governance, the advantages and disadvantages to taking your documentation agile, and the art of a company turnaround.
In this interview, Kanchan Khera and Bhuwan Lodha detail how adding a team backlog to your retrospectives can help your team go from good to great. With agile's core belief of continuous improvement, learn how the team backlog can help you get there.
Although “agile architecture” may sound like an oxymoron to you, the reality is that a simple, elegant architecture is a key enabler of any successful system, particularly large scale ones. Scott Ambler describes agile architecture practices-at both the project and enterprise level-that form a middle ground between the extremes of big architecture up-front and outright hacking. Scott discusses agile modeling practices-initial architecture envisioning, proving an architecture with working code, and just-in-time model storming-that enable agile teams to benefit from architectural modeling without suffering the drawbacks of detailed design documentation. Beyond architecture, Scott introduces agile design techniques-continuous integration (CI), test-driven development (TDD), and refactoring-that build on and provide feedback to an emergent architecture.
As a tester, you're often asked how far along your testing effort is, and when it will actually be done. This is one of the most difficult-and nerve-wracking-questions to answer, especially when a project has just begun or is nearing completion. While a tool is what's needed to help gather information and effectively answer this inquiry, many companies cannot afford to purchase or implement a complex, commercial tool. But there is a solution available in commercial spreadsheet products, particularly Microsoft's Excel. Earl Burba shows you how to use the logic and formula functions of Excel along with a combination of linked worksheets to develop an easy-to-use test status report tool.
Based on her experience with software development organizations at all five levels of the Capability Maturity Model (CMM), Barbara Kolkhorst outlines simple methods for documenting and categorizing defects and how to proceed with analysis for defect prevention. Learn how these simple methods can be implemented within your organization resulting in the prevention of significant numbers of software defects.
Do you need credible evidence that disciplined document reviews (a.k.a. inspections) can keep total project costs down while helping you meet the schedule and improve quality? The project documentation we actually need should meet predetermined quality criteria, but organizations are often superstitious about writing this documentation-and they let their superstitions inhibit their efforts. This presentation dispels the superstitions and shows you how reinforcements for improving the quality of your software project documentation-such as requirements, design, and test plans/procedures-can occur through disciplined document reviews.