Related Content
Looking beyond the Tester-to-Developer Ratio Many companies have some notion of an ideal tester-to-developer ratio, or the number of testers they need for every certain number of developers. It may seem like a superficial standard, but it's rooted in a very real need to understand staffing requirements and budgets. Let's dig deeper into the team balance. |
||
A Tester’s Role in Requirements Exploration Agile is supposed to get people to talk to each other in real time. However, many teams still lack a shared understanding of what they are going to build, even as they start coding. As testers, we can explore feature specifications early, contributing to successful and timely delivery through defined requirements. |
||
Testing at 43,000 Feet: Reporting Risk That Matters Many teams' daily testing gets broken down into numbers. If you're used to dashboards, it can be easy to forget the prime objective: to raise up quality issues—or, in the case of safety-critical devices, potential hazards. Graphs are comfortable, but do they really provide the information we should be looking for? |
||
Wisdom from Consulting: Getting and Vetting Advice When you hire a consultant, they may appear to have a wealth of experience and knowledge—and may actually have it. But accepting their advice without question is dangerous. Here are some good practices to keep in mind when you're receiving advice, including asking questions, exploring alternatives, and analyzing risks. |
||
Guaranteed Methods to Ruin Your Test Automation After working to develop the test automation patterns used by experienced practitioners to solve common test automation issues, Seretta Gamba started to consider what can ruin a test automation effort instead. Here she shares two sure-fire methods that can destroy your test automation. Steer clear of these examples! |
||
Signs of a Project Headed for Trouble Projects rarely get in trouble suddenly. More often, the descent into trouble is gradual, and the signs are easy to miss—but they are there. If you detect any of these potential signs of possible failure, it would be wise to take steps sooner rather than later to address them and get the project back on track. |
||
Improving Requirements with Preemptive Testing Most product defects are created during requirements definition. To significantly reduce and prevent requirements problems, consider making their management your software testers' responsibility. They can identify requirements defects as they are being developed, as well as work out mitigations for their root causes. |
||
5 Factors That Could Be Making Your Project Estimates Go Wrong Why do our estimates for a project or a testing phase so often turn out wrong? Whatever causes underestimation, we clearly do not learn from experience, as we repeatedly make estimation errors, despite feedback showing previous errors. It’s a chronic problem. What could be driving these errors? Here are five factors. |