Scenario-Based Development and Testing - Doing it Right the First Time
Attend this webinar on October 23 to see how Scenario-Based Development and Testing can truly help achieve major reduction in bug reporting and major increase in requirement coverage and code coverage.
Bug reporting, bug fixing, and re-testing is a very time consuming and costly cycle that we all love to shorten. It is even worth when bugs are reported by customers after release. Not only because of the interruption it causes to operation and the frustration that it causes to users. Not only because of the time the customer has to wait until the problem is fixed, retested and released as, in many cases, they might have to wait until the next release. It is mostly because of the disappointment and the loss of confidence caused by the appearance of new bugs where things worked before and are no longer working – regression problems, sounds familiar? I am sure it does. If you have been in software development for a number of years, I am sure you have witnessed the impact of rework on team productivity. And, if you have been in a management position for a while, you probably also have felt the frustration of customers. Well, I very much have been there.
Have you ever though what type of bug reports you get from customers and why we get them? Getting answers to these two simple questions is the secret of how to minimize or even prevent those bug reports from coming back to your team. In fact, it is also the secret of defect prevention. I am really talking about the secret of Doing it Right the First Time; Something software teams have struggled with for many years. Your team might have used things like scenarios or acceptance criteria. They might have used agile, TDD, BDD, continuous delivery, continuous testing, and other seemingly promising methods. Has any of these helped your team achieve the ultimate goal of Doing it Right the First Time or even minimize the number expensive bug reports?
The Scenario-Based development and testing process as implemented in Rommana ALM has proven to reduce the number of bug reports by more than 70% and has shown a major increase in requirement coverage and code coverage. This webinar will shed the light on this process and show how you can get your team, agile or not, to start using it.
Click here to Register for this Webinar
Founder, RAG AI startup, Former FB+GOOG. Investor/advisor to startups
4 年This is basically the opposite of the 'agile development' paradigm that's sweeping all of software engineering. Also, the diagram makes little sense. Placing 'requirements,' 'user stories,' 'use cases,' and 'models' as 4 distinct inputs (and outputs?) to some sort of collaborative analysis phase implies that they are mutually exclusive concepts and begs the question of whether you really mean any of those terms. Also, you've done a sort of hazy, poor replication of a very standard testing flow. Placing the word 'collaborative' randomly and making the arrows go both ways doesn't really make it novel. What does the 2-way arrow even represent? What is the output of "Collaborative Analysis and Reviews" that is an INPUT to "user stories?" The only input to user stories is the user. Are you talking about refinement of user stories? Refinement of user stories is 'normal.' That's not a new thing you've invented.