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