The BQA acronym comes from Business Analyst/Quality Assurance and since neither role is properly defined in Scrum, we combined the roles to fill the void. This bridge between technical expertise and customer satisfaction is something we’re passionate about and have written about in the past. Today, we’ll go over the 6 gates of quality our BQAs implement to ensure quality in the process while maintaining business functionality and value throughout every phase of the development cycle.
By being involved in the project from start to finish and assuring clear and concise requirements, BQAs identify defects sooner in the project lifecycle. This is important because eliminating and preventing imperfections is one of the biggest factors that determine whether a project is successful or not. When it comes to organizational spend caused by faulty software, the data is staggering:
71% of failed software projects are traced to poor requirements – CIO Magazine
$357 billion will be spent on software development by the end of 2017 (Gartner)
In 2016 software failures cost the economy USD $1.1 trillion in assets (according to research by tricentis.com)
On top of such significant (yet preventable) costs, companies must also consider ongoing developer costs to find and fix issues, and a potential loss in revenue due to unsatisfied clients. The fix? For BQAs is all about quality.
Gates of Quality
The BQA quality process can be broken down into 6 steps:
1) Creating a Quality Strategy
BQAs are in charge of creating a quality strategy that:
Identifies the types of quality verification (testing) that are in and out of scope
Identifies business complex challenges that could impact quality
Identifies any quality-related deliverables/artifacts the client expects
Specifies what tools will be used for testing
Identifies any risks that could impact quality, coming up with ways to mitigate them
Defines what the “reject vs defect” reporting strategy will be on the project
2) Concise User Stories and Acceptance
As you know, scrum is all about efficient communication within the team so to this point, the BQAs also create consice user stories and universally understood acceptance, leading to:
Better business functionality
Clearer Acceptance Criteria (Requirements)
More easily testable user stories
Creation of additional user stories to fill gaps and edge cases
Bridging the gap between business and tech
Getting things right the first time!
3) Creating Test Scenarios
Outside of Acceptance Criteria BQAs also create scenarios / use cases with expected results and outcomes. In fact, we make developers aware of these scenarios before they code so they know what to expect. These scenarios also provide input into coding and TDD (Test Driven Development) / Unit Testing.
4) Pair Testing with Developers
A key tenet of Agile development is to favor individuals over processes and tools. For this reason, BQAs work hand-in-hand with developers to help them test their own work. This includes testing code before it is merged into the master codebase, giving a more in-depth view of the business intentions, and making developers aware of edge cases and alternate paths. The ultimate goal here is to have developers that excel at testing their own work, thus improving their code time after time.
5) Performing Manual Verification
Pair testing leads to code that’s top-quality and bug-free before it is even merged into the master codebase, an important early win. On top of that, although creating automated tests is paramount in software development, our BQAs also perform manual verification and functional testing, including: exploratory testing; end-user emulation; usability testing; and manual regression testing.
6) Automated End-to-End Regression
When necessary, BQAs perform end-to-end automation. Automation allows the team to easily check if new changes break or modify existing functionality; these automated tests can run day or night, at every build, and at each code merge. Another advantage of automated testing is that it can be simultaneously executed in different environments, ultimately reducing the time it takes to run regression testing.
Value Added. Always.
In light of the mind blowing statistics mentioned above, why not empower the people who normally find the defects/bugs in your software to make a difference earlier on in the process? After all, an experienced quality resource is often so adept at finding bugs that they can predict the bugs they’ll find in a feature before they start testing said feature. After collectively spending tens of thousands of hours doing QA and logging bugs, our team has devised a way to allow quality resources to be more than just “testers". Industry statistics have shown that a defect prevented in the requirement phase can save you 100 times the cost than if it is detected in production.
Ideally, most defects can be found before coding. This results in:
Substantially reduced time to fix
Substantially reduced costs
Increased team velocity and efficiency
Faster releases, giving the ability to our clients to provide value in a matter of weeks