Being A Testing Toolsmith
Releases are getting faster and faster, well most of them. Delivering good testing is becoming an ever increasingly difficult problem. Teams are turning to tools to assist them with their testing. The most common of these tools are for creating automated checks. In creating such tools, many testers develop a proficient level of coding skills.
Why stop at automated checks though, they, you, could build so much more.
I'll share my experiences of being a testing toolsmith. I'll share tools I've built that are outside of automated checking. I'll elaborate on how I identify which tools to build. I've surprised myself in realising how much programming knowledge I've amassed. We will also look in detail at how these tools have helped the teams I've has been in.
I believe the toolsmith role is the progression of the ‘automation tester / SDET’, bringing those skills back to the core of testing, delivering tools that really assist the testing efforts. Allow for deeper, faster testing, by supporting the testing process.
Richard Bradshaw is an experienced tester, consultant, trainer and generally a friendly guy. He shares his passion for testing through consulting, training and giving presentations on a variety of topics relating to testing. With over 12 years testing experience, he has a lot of insights in the world of testing and software development.
Richard is currently the BossBoss at the Ministry of Testing, co-creator of the Automation in Testing (AiT) namespace, blogs at https://automationintesting.co and https://thefriendlytester.co.uk/. Tweeting over at @FriendlyTester and also the creator of the YouTube channel Whiteboard Testing.
Whatever you do don't call it DevOps
There is a lot of talk about DevOps recently, the tools used and how it will help your teams move faster. With terms like CI, CD, infrastructure as code, automation at every level of development and even DevSecCon. It almost sounds like once you're “DevOps-ing”, your teams will magically move faster than ever before and that it only involves Developer and Operations. It is called DevOps after all!
But if you ask anyone within your team what is DevOps I can guarantee you that they will all give you a different explanation and the majority will involve some sort of tools or sets thereof.
DevOps is not just about the tools, it's so much more than that. It's how you fundamentally work as a team and more importantly as an organisation. DevOps is pulling together all the different threads in what we call agile into a more coherent way for teams to work.
In this talk, I'll go into the brief history of DevOps to better understand what it is and why it is more than just tooling. This will help you to see the broader picture and ultimately lead us into exploring why we should stop calling it DevOps.
- History of DevOps to better understand what it is
- Three principles of DevOps: Flow, Feedback and Continuous learning
- How applying them to your work will help your teams succeed
- How a principles first approach to DevOps is needed rather than the tools first approach typically adopted by teams
- Why calling it DevOps is hurting our teams’ ability to adopt the core principles
Jit has 15 years experience working with a wide variety of companies from Mobile manufactures to OS builders and app developers.
He is currently the Test Team Lead for the BBC Mobile Media Playback Team defining their test strategy. He also supports other teams across the BBC adopt DevOps practices by helping them understand that it's more than just tools that enable teams to be successful.