1-2-minute video commercial to play during the breaks at Automation Guild ## Structure - If you're building a house, you'll probably want tools like these. - We choose the best one for the job - Often, we approach our testing tools the same way. - When really, what we need is something like this (multitool) - Building a house is not like testing software - Every new tool adds complexity, not to mention effort in learning it. - Making sure tools work _together_ is often more important than that they work on their own. - Selecting multiple tools increases your chances of silos in your team, as experts of one tool become siloed from experts of another. - The best testing tool is a multitool - It reduces complexity and effort to have one tool and one language that the team has to learn. - With one tool, you only have to figure out how to add it to your CI/CD pipeline once. - Instead of one team knowing how to use a tool, you could have multiple teams of developers, testers, and operations engineers that all know how to apply the same tool to different activities. - Check out my session _In search of the best pokémon: browser automation and load testing in one script with k6_ ## Script The traditional way of looking at tools is to choose the best one for the job. It's what we do when we're building or renovating a house. And many people, including myself, have done the same thing when testing software. The problem is that building a house isn't like testing software. - Adding new testing tools to a stack ADDS complexity, not to mention effort required to learn how to use each new tool or language. - For those of us doing or working towards doing continuous testing, it may be even more important that tools work _together_ than that they work on their own. - And selecting multiple tools increases the likelihood of silos on a team, as experts of one tool become siloed from experts of another. So the "pick the right tool for the job" approach is a little limited when it comes to testing, because rather than having an array of tools, what most of us actually need is something like this. (multitool) We want something that can work in a lot of different situations: - load testing - browser automation testing - chaos testing - API testing all in one package and one language so that scripts can be reused, knowledge can be shared across teams, and everything fits neatly into an automation pipeline.