How to Find Your Way in the Automation Framework Jungle with Wim Selles

For our sixth Friday talk at TestBash Manchester, we’re joined by @wswebcreation to explore how to choose the best automation framework for your context.

This is something I’ve definitely struggled with myself, have you?

Use this thread also to your questions during the talk and we’ll do our best to get them all answered live. Remember that liking any questions already asked will increase the chances of them being answered live in the talk :heart:

And remember, the conversation doesn’t have to stop just because the talk has :wink:

If you had to pick one, what would you pick as the King/Queen/Ruler of the framework jungle?


Wim, what advice would you give to a team that are stuck in the jungle, and constantly ‘playing’ with new tools, because there’s so many new tools coming out ALL the time, and the team doesn’t progress to produce any value at all (because they are trapped in the jungle)


How does this advice change if the person that believes the team needs to leverage automation work more effectively is not “technical”?


Are there any factors which are more important to a testing project than the choice of testing tool? Code designed to be testable or buy-in from teams for instance?


(I recognize this is a "how long is a piece of string question! But…)

How long does it typically take to go through the process you described? What factors make it go faster or slower?

1 Like

Hi Vernon,

Thanks for asking. For me there is no silver bullet, I have some tools that I really like to use, but it’s up to what the team wants to use. This might also be an extra opportunity for you to learn new tools, so always a win-win

1 Like

Hi Leigh,

Why didn’t you ask this question during the session :wink:? Just kidding, one of the things you could do when you’re trapped in the jungle is shout for help. Hopefully a PO might help you get you out of that jungle and focus back on the product.
The second thing is to look at the map, the map which holds your requirements and get back to where it all started. The requirements that, together with the rest of the steps, intended to be the guideline through that jungle.
If that doesn’t help then I hope there will be a manager that has set some goals for the product, features to release, quality to be guaranteed and so on.
Last but not least, if in the end all those steps don’t help then I think you have an awesome assignment where you can just play with tools, get payed for it and never need to deliver a product. I would then stay in that jungle :laughing:


In the end he/she it not this person that needs to decide which tool will be used, its, imho, a team decision. I don’t mind having a healthy discussion about some pro’s and cons. Those discussions might result in new insights

1 Like

You can invest a lot of time and money in a tool, but when the app itself is not testable, check @friendlytester his talks, then the tool will not help you.

1 Like

The time I had when I was doing my research was 1 sprint. This included all steps. The longest part was learning the tools, but also one of the most important ones. Because using the tools gave a good insight about the learning curve and a pro’s and cons.
If you think you might need more time, then discuss this with the team, or try to get some help if you don’t have that time

We were talking this week about this topic ,- questioning why we were allowing the team to explore more tool options when we have already invested in a tool/started training in it. This talk really tied together why we were allowing this to happen - the team need to be happy with the choice, rather than forced upon. I really just want to shout out my appreciation for this talk. I’m going to rewatch it as soon as it is uploaded!


Thanks for your feedback!