Karolina Zmitrowicz Business Analyst Business Acceptance Testing When
Karolina Zmitrowicz Business Analyst Business Acceptance Testing - When Business Cooperates with IT
About me • Business analyst, quality manager, project coordinator • Lecturer and trainer in QA and BA • Author and speaker • Member of IREB Ex. Co
Agenda 1. Classic approach to BAT 2. Challenges and needs 3. Recommended approach
Did you know?
Top 10 Reasons for Project Failure • Mismatch between the project and organisation’s strategic priorities. • No pre-agreed measures of project success. • Ill-defined senior management ownership and leadership. • Ineffective engagement with stakeholders. • Poor project management technical skills. • Non-standard approach to project management and risk management. • Inability to differentiate stages of project development and implementation. • Proposal evaluation focused on price rather than long-term value for money and achievement of business benefits. • Lack of contact with senior management levels in the organisation. • Poor project team integration between clients, the supplier team and supply chain. https: //2020 projectmanagement. com/resources/risk-management/top-10 -reasons-for-project-failure
How we used to develop things…
Requirements analysis Acceptance testing System testing High level design Integration testing Low level design Unit testing Coding Deliver and verify System design Develop Define and design Classic approach to BAT
What we think would work
Classic approach to BAT Requirement specifications Models Architecture Analysis and design Test summary report Development and internal testing Stabilization Test specifications Test outcomes Code Acceptance testing Approval Production
Expectations
Reality
Reality
Why it is not working?
Challenges and needs Requirements quality Communication Business involvement Late feedback Skills and knowledge
Requirements quality But not what is really important
Requirements quality Requirements should be documented at a level that allows to ensure: • • Developers know what to implement Testers know what to test Managers are able to derive status information Business is able to derive information about needs coverage and risks
Validation and verification
Communication • We don't understand needs of business • We don't ask for feedback • They don't know the scope and the system • They don't feel involved And after that we are expecting success…
Looks familiar?
Late feedback Situation • Acceptance at the very end of the project • Time pressure • First time when business sees the system Result • Confusion • Reporting changes as bugs • No time for further development/changes Final effect • Release of a system that do not meet expectations • Delays in go live • Budget and schedule not met
Too often business users are involved only in acceptance tests execution Business involvement
Development
Business involvement
During acceptance
Business involvement What about: • Requirements elicitation and analysis? • Requirements specification? • Design? • System testing? Business is not an enemy!
Skills and knowledge Business people may not know your process They are not professional testers They need QA support You may not have deep business knowledge You need business support
Solutions More agile process Iterative business involvement Requirements review & validation
More agile process
More agile process You are not Agile? So what? These aspects are not limited for Agile: • Iterative approach • Frequent communication • Requirements validation • Thinking about business context
Iterative business involvement Acceptance is not necessary a single step in development You can plan for partial acceptance tests – lets verify increments, modules, functions when they are ready, not at the end
Requirements review & validation • Use quality criteria for requirements • Think about business context • Use business acceptance criteria • Apply 3 Amigos concept Business perspective Development Testing perspective
Recommended approach Start from requirements Create communication plan Build shared responsibility model Involve customer / business Establish a process for iterative acceptance Share knowledge
Example Project Team Mission critical software PO on the customer side Agile approach to development (hybrid of Scrum) 3 business representatives in the team 2 weeks iterations with demo Development team Release plan (JIRA) Business testers on the customer side Communication via Skype
Example Business requirements specification with functionality description provided by the customer Kick off at the beginning of the project followed by requirements elicitation / refinement session MVP defined by the customer Refinements during the project effort User stories used to capture requirements Acceptance criteria defined by PO with support of business experts
Example Pilotage deployment to collect feedback from the market Final BAT and UAT just before go live Requirements validation Refinement Business Acceptance Testing User Acceptance Testing
Thank you pgs-soft. com kzmitrowicz@pgs-soft. com
- Slides: 38