Why do we wait to discuss releases and deployments until the last minute? Is this a result of our lack of planning and knowledge, or is there a deeper reason why we fail to plan properly? Joe Townsend digs into the release and deployment portions of the SDLC to try to shed some light on why we tend to neglect these crucial steps.
"There's that same kind of bug I found last week. When will they learn? When can I apply my energy to preventing bugs instead? Isn't that a more noble profession?" says the disgruntled tester. You may think that Quality Assurance is the next logical step in your testing career, but Danny Faught has been down that path and he begs to differ. In this week's column, we find out he's not the only one who feels that way.
Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.
One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense.
The cloud and the rapid migration to mobile devices and the Internet of Things have made traditional software licensing schemes obsolete. Omkar describes new software monetization based on business, pricing models, and usage.
The iterative agile methodology provides a clearer vision, smaller time scale, and closer planning horizon. The authors look at approaches to estimation and planning, from product backlog grooming to task-estimating tables and more.
Larry Putnam Jr., co-chief executive officer at QSM, sits down to talk about the importance of the proposal when executing a successful project, five key questions that should be answered before any project starts, and how software estimation ties into the proposal process.
Cognitive scientists tell us that we are hardwired for deception, which makes accurate estimation almost impossible. We must simply accept that our estimates are best guesses and continually re-evaluate as we go, which is the agile approach to managing change.
When will you deliver that feature? How much will this project cost? Which features can I have in four weeks? These are all reasonable questions that both management and customers need answered, and traditionally, we’ve used estimates to provide such answers. But estimates can turn into commitments, dollars get spent based on misinformation, features end up misaligned with business needs, and all parties involved end up feeling misled and frustrated. The key question is, can we still make decisions without traditional estimates? Join us as our panel of experts discuss this question and many more. The panel will explore how teams can use #NoEstimates thinking to meet the needs of their stakeholders, how to maintain alignment without estimates, and pragmatic ways to move the focus from estimates to metrics and measures that enable teams to deliver high-quality products that will delight their customers.
Are you puzzled about why your estimate turned out wrong, or stressed from working to meet an impossible deadline? Some teams on inaccurately estimated projects suffer stress, burnout, and poor quality as pressure is applied to stick to an unrealistic schedule. Such project teams also descend into irrational decision-making—with potentially catastrophic consequences. Frustratingly, even when teams perform well, they are often judged by their failure to meet impossible deadlines. Andrew Brown will show how estimation errors are caused not just by new technology or intentionally manipulated estimations, but also from limitations in the way we think. Andrew will explain how cognitive biases contribute to estimation errors and show how to mitigate these biases. Learn how the planning fallacy, anchoring effect, and optimistic bias contribute to estimation errors and lead to irrational decision-making.
Isn’t it amazing? Stakeholders drop software on our desks and expect us to test it—without any requirements, design, or product knowledge whatsoever. About the only clear thing is the absurd and unrealistic deadline. We are expected to bend over backward, spread magic pixie dust, and heroically test quality into a product we have never heard of before. But testing in the dark is not impossible, and as Rob Sabourin shows, it can even be a very valuable and fun experience. Learn strategies to emerge from a murky fog into clear, meaningful quality insights and leverage unlikely sources about what stakeholders care about and what users really need the software to do. Rob introduces you to methods of reconnaissance-style, charter-driven, and session-based exploratory testing and help you provide meaningful estimates to stakeholders with minimal hard information about the software under test.