Test Management Forum

Transcription

1 Test Management Forum 25 th January 2017 Agile Delivery Why does Testing get left behind?

2 Abstract In this session, we take a look at the expectations of testing within an agile delivery. We've heard all about the need for organisations to change mindsets and commit to supporting a new promised land of faster time to market, less documentation and increased cooperation, but does that really include the tester? I mean really include? Does this new world allow the test team to avoid highly constrained exit gates? Can the test team avoid the creation of detailed strategy and plan documents? And does a project team really get to 'Done' at the end of a sprint? The session will highlight some real-life scenarios where testing has been the forgotten son in the agile transformation, but also provides some solace in examples of where change has been allowed to occur, and the role of the tester has become more of a 'puppet master' and an engine room for setting business expectations. Don t find fault, Find a remedy; Anybody can complain Henry Ford

3 Setting the Scene An idea gains business backing We need to deliver to market quicker What about this Agile concept, everyone s doing it Excellent idea, Great, Where do I sign? And so it begins.. Points Clear backlog, clear target Teams in place What could possibly go wrong? Sprints

4 Points There maybe trouble ahead Sprints Early Sprints Technical Challenge Perceived Progress No Substitute for Quality Positivity Dev / Test on track Stakeholders happy Roadblocks found Test not being fed stories Stakeholders concerned Concentrate on Dev Complete Debt gap increases Governance heightened Stakeholders worried Development now in bug fix Release delays due to quality concerns

5 Why does Testing get left behind?

6 Here are a few of my thoughts: Why does Testing get left behind? Testing has a lack of voice in planning ceremonies Lack of clear objectives/understanding of the needs of agile Focus on development velocity without appraising the quality needs for release Lack of commitment to Quality being the teams responsibility Internal Governance and Process not updated to accommodate change in working practice Incompatible automation approaches that consequently build up debt Blog Posts:

7 Testing has a lack of voice If the tester mind-set is not used to plan stories and sprints, acceptance criteria may be incomplete. The tester needs to apply non-functional considerations to the stories and features, Done means Done : - Required Performance - Security - Usability - Regulatory Considerations Missing these from the acceptance criteria, builds pressure on the release, as change / scope creep are uncovered too late in the day

8 Lack of understanding of Agile Starting at the top, if your stakeholders do not understand why agile is being used, perception of failure and reputational risk are likely Coaching stakeholders in how to use the techniques to gain flexibility is a key challenge for any agile project. Promoting concept of Sometimes the carrot is the lack of stick Empowering the team to make decisions to deliver the product. Company needs to train other areas that may interface with the delivery team to ensure process is valid and valuable in the pursuit of working software. Working Software over mountains of documents Proof is still required, but how do you keep documentation relevant, yet not cumbersome.

9 Focus on Development Velocity If progress slows due to unforeseen circumstances, the project may choose to show development progress Concentrated period of effort that relies on the developer to code functions without direct assistance from the tester. The approach is likely to resemble papering over the cracks Builds debt without a plan of payback. Testing technical debt builds, as does the pressure of defects levels and the reputation with the stakeholders.

10 Lack of commitment to Quality being the teams responsibility Often a key factor that is missed in agile projects. Having a QA Team instantly builds walls, and creates an anti-pattern for collaboration Breeds incompatible mind-set and over the wall mentality A lack of unit tests or alignment to the acceptance criteria builds debt and reduced closure rates as defects are raised Not investing in collaborative acceptance criteria sessions, introduces potential for misinterpretation or missed fundamentals for our (M)VP ((Minimal) Viable Product)

11 Internal Governance prevents Agility? Even though project is running agile, internal governance still has a requirement for documentation, and usually housed within very detailed templates Formal gate reviews, requiring specific metrics to be demonstrated. What happens if new approach cannot capture this requirement easily? Review cycles for documents can be lengthy and require extensive rework. All of these mean there is a price to pay, specifically debt build up within a sprint

12 Inefficient use of Automation This can be applied to any project approach (e.g. Waterfall, Scrum, Kanban), lack of planning up front can lead to diminished returns and increased maintenance of automation. Is there benefit in trying to automate all user stories in a sprint? Is there benefit in focussing on front end UI automation? Has maintenance and refactoring been accounted for? Can all automation be complete in a sprint, or does it start to build a debt? Does the value of the approach still install confidence in the project team and stakeholders?

13 How can we speed up?

14 How do we include Testing? Decide what you are, Raise the question Are we built for Agile success? Commit to Joint responsibility for Quality Give test an inclusive voice, spokesperson for the team educating the business

15 Are we built for success - Organisation Work with Governance teams. Agree what Policies and Process are applicable / achievable in the agile team upfront. Review the need for documentation. Can you move forward without reams of paper and drawn-out review process? Define what acceptance looks like. 1:1 requirements mapping? Or Acceptance by users that the system is usable and improves day to day activities? Can we infer acceptance by way of roll-up i.e. 1 (Scenario) : Many (Requirements)? Requirements Requirements Requirements Stories Stories Stories Stories Scenario Requirements Requirements Stories Stories AC s Tests

16 Are we built for success - Project Do all cross functions understand the Story/Acceptance Criteria and objective of sprint? Are stories elaborated to sufficient detail, that they become a production candidate? Do the team recognise all aspects of debt across teams that could affect delivery? Do the team commit collectively to address debt and payback as often as possible? Will development and technical testers share frameworks and refactoring plans to keep consistency? Do the team commit to starting and finishing all aspects of a story in a given sprint?

17 Commit to Quality being everyone s responsibility From elaborating stories, defining acceptance criteria to agreeing frameworks, each member of the team must do so with others in mind. Close collaboration during the sprint to move stories closer to Done, collective review ( Pair testing ) shortening the feedback loop. Unit test coverage should be value driven, raising the bar sprint on sprint and flagging failure early (i.e. code commit and build)? Automation needs to be effective. Striking a balance between service layer / API tests and UI automation. How can they feed into build / CI? Leave the final sprint acceptance down to exploration, building knowledge to increase code robustness to change.

18 Test Master Educating the Business Assist with regular demonstrations of features Facilitate usability sessions. Provide users with scenarios to determine the intuitive nature of application Focus on real World scenarios to prove that the application is Viable Ask users to determine whether they can conduct their role as well, if not better with the application Triage the feedback: List of User Feedback Missed AC for MVP New Requirement Business Process Raise as a defect / backlog Update tests, automate Agree priority and place on correct backlog e.g. Current or FE Note the change and add to release note Add to user training as change

19 Coming together is a beginning; Keeping together is progress; Working together is success. Daryl Searle Managing Director, Ovate Limited Henry Ford dsearle@ovate.co.uk LinkedIn: Thank You Website: