This event is co-located with Agile & DevOps Showcase
Delegates may attend any sessions from across the two conferences.
Testers have always been at the coal face of ensuring that “stuff works as it should”. Is there anything different in the actual testing of new digital products, new interfaces with clients which must always provide the optimum user experience? How are testers coping? What are the stories coming in? What is working well and what can be done better?
At this event we are aiming to include many case studies as well as high quality technical/review presentations. We will also feature the popular and interactive round table discussions (each addressing a different testing topic or issue) where all participants can join in, shape their learning, share their own experiences, and hear fresh ideas.
There is also an exhibition alongside featuring leading service providers, consultants and testing tool vendors.
Joint morning session of Keynote presentations with Agile & DevOps
The Round Table session:This session is for 45 minutes. The speaker at each table will have a set theme and delegates join any table that they are interested in. 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
Topics to be covered:
We are inviting speakers – thought leaders, subject experts and start up entrepreneurs – to share their knowledge and enthusiasm about their work and their vision in the field of Testing.
We understand that successful projects are written up as “White Papers”. Please share these with us. But projects that did not achieve their targets – “Black Papers” – are of interest to us too. They can be a very important topics of discussion / panels that you can present. Talk to us about both, we welcome your input.
Please complete the speaker’s response form and submit a proposal to present at this event.
UNICOM’s Code of Conduct & Views on Diversity
Our approach is that our events are dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity or religion. We do not tolerate intimidation, stalking, harassing photography or recording, sustained disruption of sessions or events, and unwelcome physical contact or sexual attention. We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, Twitter and other online media. Event participants violating these rules may be sanctioned or expelled from the event without a refund at the discretion of the conference organisers. Please bring your concerns to the immediate attention of the event staff.
Diversity: In our endeavour to be the provider of knowledge to the business community, we understand that this depends on hearing from and listening to a variety of perspectives that come from people of all races, ethnicities, genders, ages, abilities, religions, sexual orientation, and military service. We welcome diverse speakers for all our events, we do not always fully achieve this goal, but it is an ongoing process.
Steve Freeman, Zuhlke Engineering Limited
We need to explain Technical Debt to people who are not technical, partly so that they can make better choices because they understand the real trade-offs, and partly to so that we understand it better too. Some of the tension between trying to get product out and developing something you can live with is an essential feature of trying to do anything new, but some is the result of a mismatch of understanding between Product and Development. The metaphor of debt does not really convey the risks that arise from poor technical quality. Instead, I will introduce some other metaphors for looking at technical risk that we think match the problem more effectively and propose some strategies to help product and development teams approach a solution.
Mark Lines, Managing Partner / DA Fellow, Disciplined Agile
We like to say that agile teams own their own process by choosing their way of working, their "WoW." This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?
There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of "agile coaches."
In this talk, Mark Lines, co-creator of Disciplined Agile, and co-author of four books on Disciplined Agile, shows how to reference the DAD "Toolkit" to help you make better decisions that make sense for your organization, for your teams, for their unique contexts. Better decisions lead to better outcomes!
Moderator: Chris Thacker, Test Manager, MoneySuperMarket.com
Position statement: Ash Winter, Tester, Diagram Industries Ltd
Improving the testability of systems to genuinely enable whole team testing is a compelling vision for the future of testing within agile and CD. Testers advocating for this will be extremely valuable team members and organisational actors.
Ash Winter, Tester, Diagram Industries Ltd
While in the big bad, world of consultancy, I was tasked on numerous occasions with 'reviewing' the testing capability of an organisation and providing recommendations on how to improve. I did exactly that on those numerous occasions, passing judgement on the testing capability and pointing the organisation in (I believed) the right direction. I thought I had a decent handle on it, providing thoughtful context, sensitive strategies.
I had the occasion to return to one of these companies to implement a something. Very little had changed. Or things had even got worse, testing (and testers) were in further distress. At first I was perplexed, then it struck me, I had engaged in inadvertent local optimisation. Testing and the state of it at an organisation was dependent on so many structural issues, that 'reviewing' testing alone was a peripheral action.
I resolved to engage with organisations with a more open mind to looking for the root causes behind the perceived testing problems, encouraging them to deal with those first. I would like to present an experience report about going beyond your remit to help an organisation and the reactions prompted by that. My testing world looked very different to me afterwards.
Duncan Nisbet, Software Test Coach, Testagility Ltd
To bastardise a quote from Joi Ito’s fabulous TED Talk Want to innovate? Be a “now-ist”“SAFe is what people do to you, safety is what you do for yourself”
In this talk, we'll look at strategies & techniques that you as a developer or their leader can use to make the most of your organisation's decision to adopt SAFe.
Whether you’re experienced with or completely new to Lean & Agile ideas, transitioning to SAFe is going to disrupt your daily life as the entire organisation strives to come in sync & harness the systems thinking approach to product delivery.
1. A high level introduction to SAFe
2. How it should help your organisation
3. Typical challenges you’ll face transitioning to SAFe
4. Strategies for overcoming those challenges (& embrace the opportunities SAFe provides)
Dr Greg Law, Co-founder & CTO, Undo
How do you go about testing a complex feature-rich multi-threaded application of highly optimised C/C++ code that is SAP HANA? A huge code base, non-deterministic factors, continuous integration and more advanced testing methodologies lead to a growing number of intermittent test failures which are often difficult to reproduce and investigate. Worryingly, these sporadic failures are building up over time, like a pile of dirty laundry nobody wants to talk about...
The SAP HANA engineering team spent months analysing logs from failed tests - often with no success. Eventually, they tried a new method: recording test failures and replaying the recording files in a reversible debugger in order to see exactly what the HANA software did.
This short talk will explore how the SAP HANA engineering team managed to catch and fix sporadic memory leaks and race conditions ... before they reached customers. Their true commitment to software quality is a big part of why they are leading the field in the in-memory revolution.
Giovanni Asproni, Principal Consultant, Zuhlke Engineering Ltd
A common phrase associated with software prototypes is “quick and dirty”—meaning that not much thought is given to good design or, God forbid, testing.
In this talk we’ll present a different approach: the story of how we created a prototype for a moderately complex Amazon Alexa skill to manage bank accounts. We’ll describe how various levels of automated testing, and an attention to clean code allowed us to create a prototype, to be demoed to prospect customers, much more quickly that also works in a very reliable manner greatly reducing the chances of the “demo effect”—when the system works perfectly always except when demonstrated for an audience.
Paul Gerrard, Principal, Gerrard Consulting
The oft-quoted four-quadrant and pyramid models for testing don’t help test much in adapting to the continuous delivery approach. The models focus on types of testing rather than what testers actually do.
Continuous delivery models usually define testing as a stage in an infinite delivery cycle. But testing isn’t a stage anymore, it’s a pervasive activity throughout the ‘infinite loop’. Paul uses his New Model to give a different perspective to what is being called ‘Continuous Testing’.
This talk looks at what testers actually need to do and focuses on the activities of testing between the requirements to delivery phase of the infinite loop.