In the era of agile and DevOps, release decisions need to be made rapidly—preferably, even automatically and instantaneously. Test results that focus solely on the number of test cases leave you with a huge blind spot. If you want fast, accurate assessments of the risks associated with promoting the latest release candidate to production, you need a new currency in testing: Risk coverage needs to replace test coverage.
The way we think about what necessitates test coverage being “complete” influences how we test and the cases we create. After all, you wouldn't design tests for situations that don't occur to you—and you can't test what you can't see. It's time to take off the blinders. Here's how you can find where the bugs in your products are occurring, and then adjust your strategy to pinpoint them.
As an advocate for quality, you look at the product, take into account time, budget, and other business constraints, and recommend fixes to ship a product with the best possible quality. ... And the businesspeople in production don’t want to fix it. How can you communicate bugs and risk to people who don't want to listen? Instead of getting frustrated, you need to frame issues in a meaningful way—and, if you have to, let people fail.
DevSecOps is a growing movement to incorporate security into DevOps practices in order to ensure flaws and weaknesses are exposed early on through monitoring, assessment, and analysis, so remediation can be implemented far earlier than traditional efforts. By failing fast with security testing, organizations reduce risk of a security incident and decrease the cost of rework.
Undoubtedly, your organization has disaster plans in place for recoverable situations. But what about for going out of business? Thinking about your obligations to clients, users, customers, and partners before the worst happens can make the transition easier for everyone. Here are some people and things you should incorporate into your apocalypse plan.
When testing software, most of us identify risk seemingly effortlessly. But do we really understand the process we’ve undertaken? Do we know what methods we’ve called upon? Are we aware of how we’re identifying risks? And therefore, are we identifying all the important risks? David Greenlees uses models to assess these questions.
Making proposals can be a discouraging task if there’s no clear presales process in mind. When we talk about IT business proposals in terms of selling solutions, a technical approach is often viewed as the best solution, but you need more than a simple idea to produce results.
Prioritization is a key ability leaders must have to manage project goals and ensure they are aligned with organizational strategic goals. Priority management is a very complex task, and it should concentrate on these issues by taking care of the business needs, goals to be achieved, budget, and risks. Read on for details.
Like quality management a decade ago, project risk management has become such a “check-the-box” exercise in some organizations that vocal critics are clamoring for its elimination as pointless overhead. In this article, Payson Hall suggests that you consider a grown-up conversation with the leaders in your organization about the capabilities and limitations of your risk management efforts.