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.
It’s important that test authors keep in mind the inherent authority their tests possess. After all, an application’s tests are sometimes the first lines of code a new developer will read when acclimating to a new codebase. Tests aren't the only kind of documentation you need, but automated tests in a CI environment can provide a lot of useful information.
With the rise of technology like AI and practices like DevOps, teams everywhere are looking for ways to speed up testing without sacrificing quality. The articles in 2017 reflect that, with the most popular topics being test automation, testing machine learning systems, next-generation exercises, and the future of software testing. If you're looking for cutting-edge testing techniques, check out this roundup.
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.
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.
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.