Finding myself getting frustrated with all this 'UI Tests' are slow chat. I'm not a semantic person, I can just about spell it. But let's be clear about 'UI Tests'. When most complain about them they means tests that start with an interaction on the UI.
Those tests usually weave their way down the stack and end up hitting a database and weave there way back. Multiple times in a single test. Some would call them 'end to end'. A not so helpful term. But what they aren't is targeted.
Targeted tests are the result of great thinking, utilising in depth system & tech knowledge, team context and much more (some would call this Test'Ability', framed around a certain risk. Yes, risk! Very important word.
The industry needs more targeted tests. Understand the risk and behaviours and find the 'lowest' interface/seam you can test it on. Or should test it on.
If you know a seam should exist but doesn't, make a case for building it. Or perhaps it isn't accessible to you, get that product testability added.
Such questions/research should be asked in planning/story discussions, or similar named sessions. The main one being 'how are we going to test this'. This should trigger a conversation about options, and potential testability changes. Always ask this, even if your 100% YOU know
So what about UI Tests? Aha, yes, back to those, maybe :D The tools are better than ever these days. We have tools for testing at all seams/layers. Learn them. Look for them. Regularly add to your toolbelt.
If you do some of the things above and only know Selenium, you brain will always see a nail. Fix that. Scan github, follow developers, follow blogs, awesome tools are shared all the time. Find them, do a 'hello world' scenario and bank it.
The hello world scenario is an important step. I'm no neurologist, but when I use something I tend to remember it.
So, UI Tests. It's possible to have targeted tests on the UI these days. It could be the visual layer, the JS/HTML/CSS. But they should ideally stop there. You can achieve this by mocking/stubbing/faking the rest of the system.
Targeted tests are, well, targeted. So if you don't need to hit a thing below the UI, don't. All the thinking and modelling mentioned earlier should identify this. Work out the risk, identify the lowest interface. Get the right tool.
If you do all the above and the answer is still not targeted UI Tests, work with it, but don't settle for it. It will bite you. Believe me. Involve the team, especially the developers, they will help you.
To continue my rant, I shouldn't be harsh to myself, it's a good thread. Good automation requires alot of skills, and alot of testing knowledge. It's damn hard. Invest in continuously learning more about testing, tools and languages. Give yourself more options.
But we'll be fine as a craft right? All you need to know is how to code... We need more talk on all the above, before we lose these skills. If your looking to learn automation don't skip learning the theory. Don't stop at one language or tool.
If you're managing/coaching such people encourage them time to do the same. Give them time for new tools, to experiment, to learn.
'UI tests' do tend to mean end to end, untargeted. We need targeted. Think risk. Think tools. Evolve. Continuously review. Re-evaluate risks. Don't work alone, involve the team. Have fun. Build valuable automation.
Thanks for reading.
Thanks for reading.
