Testing, Agile and DevOps: Are they a Separate conversation or a progression of capability?
Testing, Agile and DevOps have shared environments that facilitate working together. These three methods are more than simply adopting new tools and processes and the synergy involves building a development and a stable Continuous Integration (CI) infrastructure, as well as an automated pipeline that moves deliverables from development to production. They can work together and the entire build process should be transparent, and it should enable and support development and operations. This transformation depends on: significant changes in culture; roles and responsibilities; team structure; tools and processes.
The Round Table session is the last of the joint morning session with the other two co-located events. This session is for 45 minutes of which there will be around ten minutes for a general summing up at the end. The speaker at each table will have a set theme and delegates join any table that they are interested in. They are given all the topics with their joining instructions and again at the time of registration and so make their choice on the topics that they want to attend. This is a discussion group and so no presentation slides are necessary, but please submit a topic if you would like to chair a discussion on a topic related to Testing, Agile and DevOps.
Benefits of attending:
We are looking for speakers willing to share their experiences and stories about your work in the field of Testing. If you wish to submit a proposal to present at this event please fill in the speaker’s response form.
Topics we are looking to be addressed include:
Paul Gerrard, Principal, Gerrard Consulting
Dorothy Graham, Software Testing Consultant
There are many places to visit it the world and it can be interesting to see "where you've been". There are many places in the software for tests to visit, and seeing "where the tests have been" can be very interesting for testers.
Dot Graham explains what coverage is, and why it can be misleading to talk about 100% coverage. Coverage is a relationship between the tests and the software being tested, and is an objective measurement of some aspect of thoroughness of the testing.
There ways in which the term coverage is mis-used, and four caveats of coverage which you should be aware of.
So is coverage a good thing to have? In other words, should testing be thorough? Not necessarily; sometimes testing should be more like strawberry jam than butter or margarine. Whenever you hear the term "coverage", there two important questions that you should always ask: Coverage of what? and Why?
Maria Ball and Terry Bowen, Senior Project Managers, Media Services, BBC Design & Engineering Platform
When the stakeholder "just" wants something simple done, they tend to expect it to be done quickly. What happens when there is more than one team involved?
In a large organisation, teams often work in silos, use their own flavour of Agile, and have their own roadmaps. It can be challenging to get the alignment and the flexibility needed to deliver a simple request. This is then complicated when the requirements evolve from the initial request to something more. Maria Ball and Terry Bowen discuss the complications they faced in managing the development and delivery of a project that required three internal teams and an external supplier, while using Agile methodology. They will share how they were able to resolve the conflicts and software limitations they came across to deliver the feature.
Kevin Rutherford, Software development coach
This talk presents a simple visualisation tool that helps software teams self-organise, deliver, and communicate more effectively. The talk uses examples from recent software development projects in a variety of organisations, showing how this technique has improved both the rate of software delivery and the engagement of key stakeholders.
Andrew Fullen, Digital Consultant, Sogeti UK
It isn’t science fiction anymore: Artificial intelligences have tackled chess, quiz shows and can even drive a car. Now they face the greatest challenge ever. Testing. How will we cope? How will they deal with us? And how do we test a computer system that knows more that we do? How can we trust the answers and what do we do when it gives us an answer that we don’t agree with?
Find out how you will start testing the world of tomorrow.
Steve Challis, Plutora
Test management is only one piece of an efficient software testing process. Enterprise IT teams need to consider test environment management and release management as well in order to successfully shift left.
Mark Smalley, The IT Paradigmologist, ASL BiSL Foundation
A fast-moving, entertaining and insightful session in which you’ll learn about:
♦ 'Selling' the value of DevOps to business executives
♦ Discovering the weakest link in the business-IT-business value chain
♦ Identifying effective collaborative behaviour between business and IT
♦ An ancient DevOps proverb “If you meet DevOps on the road, kill it”
♦ Language Constraints and Agile Coaching, Thomas Hoyland, Agile Delivery Lead, Sky Betting & Gaming
♦ Test Automation, Dorothy Graham, Software Testing Consultant & Author
♦ Approaches to Iterative Delivery, Seb Rose, Cucumber
♦ Environment Management, Steve Challis & Matt Drury, Plutora
♦ Test Automation Mobile, Jitesh Gosai, Team Lead / Tools & Infrastructure, BBC Digital
♦ “Put the spanner down Dave”: Intelligent testing on intelligent systems by intelligent testers Andrew Fullen, Sogeti
Stephen Mounsey, Agile Coach
Are you really listening? Listening is an important skill for any human being but for a tester an essential skill. If part of testing is about information gathering and interpretation then Listening is a key component.
A look at the art of listening, parallels drawn between listening theory and how we test.
Ash Winter, Consulting Tester and Speaker
API design looks easy, right? Lots of material, methods and examples to look at. However, we've not been on a team that hasn't struggled to build a clean interface for their consumers. From unconventional use of status codes, difficult to parse responses to endless debates about what to name endpoints. This is coupled with iteratively built API's, which potentially realise value and feedback earlier but may suffer from inconsistency over time.
By testing first with effective automation, common errors with API design can be flushed out quicker, even before the code has been written. Design and architecture should not be left to the developers and architects, by following some of these guidelines, as a Tester you will be able to contribute to a consistent, transparent and maintainable API.
Seb Rose, Cucumber
When you invest in the stock market you’ll often be warned to “remember that the value of investments can go down as well as up”. For over a decade User Stories have been the rock steady investment of agile adoption - and they’ve come a long way since XP called them “a placeholder for a conversation”. It’s time to re-evaluate what user stories are trying to achieve, what they’re good for, and why so many of them suck. In this session we’ll explore what a good user story should look like and discover why so many of them fail to live up to our expectations. We'll look under the covers of the INVEST acronym, popularised by Mike Kohn to help people write better user stories and look at why, in many cases, it doesn’t seem to have helped. It's time to stop investing in the boring, formulaic user stories that litter your boards, choke your JIRA and stifle your meetings. Today we're going to see how to make user stories RIVETing again.
