English | EN 
I’ve taught test automation lessons to our consultants. It’s always fun for me, conversing with people and talking about the best test automation practices and hearing real interest from the participants: Why did you do this? Why you didn’t do that? Why does this work? How does it work? Why do you need this to do that for that to work? It’s always better to ask for more clarifications than not. Remember, there are no stupid questions.
And when you can help someone to figure out an answer to their question, it’s a shared joy of enlightenment. But it requires presence from both of the learning parties, the teacher and the student. It’s about communicating ideas and saving those ideas into the long term memory of your brain. But it’s also about giving the student a clear vision to strive towards, to realize, what value test automation can provide for your software development and the steps needed to get there.
One of the most common questions, but also one of the most difficult, is how to introduce new people to test automation. Do you start with the big picture and go down further into the smaller details, or do you go the other way around, and start with concrete test automation example scripts and move to larger ideas from there? There is no right or wrong answer here, there are multiple ways to succeed in communicating the basic test automation principles.
I like to start with just talking about test automation, why we do it and what it does. I think it’s important to lay down the biggest philosophical foundations first. Not everything, just the top-level stuff. Like, what benefits can be gained through automation (cheaper, faster, repeatable testing) or when to automate stuff (solid functionality, lots of manual steps) and when not to (constantly changing requirements, ad hoc testing).
Test automation, like all testing, is there to provide information about the state of your software. It’s about verifying the stated software functionality works as it should. That is the main goal and that should always be in the back of your mind while designing automated tests. The tests should verify functionality appropriate to the testing level. If we are doing integration level testing, we should concentrate on verifying connections to external modules. If we are doing acceptance tests, we should consider, what constitutes as the acceptance criteria.
After we get through the basic principles, I like to go straight into practical examples. And usually that means automating your first browser test. I’m a hands-on-learner myself and get the most out of doing stuff during the lesson, not just by listening. To me, learning to automate browser behavior is one of the most valuable skills a test automation developer can have. As years go by, we have seen a massive shift in user interfaces towards moving into the web browser. Even complex systems today, usually have some sort of front-end web browser UI. This means that once you learn browser automation, you know how to automate the majority of new software interfaces. Mobile test automation is the other big venue for automation, but it requires more stuff (and a phone!) to get started.
The biggest hurdle in teaching practical examples, is always getting the development environment up and running for all the students, preferably even before the lesson starts. There is always that one student whose laptop refuses to install all the required software. But once everything is setup, we can start to go through the basic principles of writing test scripts in our preferred test automation framework.
I start by showing an example script and running it to show what it really does. I talk about the key lines in the script and what they do. Then I give an exercise question that uses those previously mentioned key lines but in a slightly different way. The students get 15 minutes to try to script the exercise question during which I help struggling students personally. After the time’s up, we go through the exercise example answer together and talk about the difficult parts of it.
Finally, remember, teaching is a skill in itself and not all learning styles are the same. Each time I’ve held a lesson, the next lesson was better, simply because of all the helpful feedback I’ve gotten from the participants of the previous lessons. Small typos and factual errors get fixed before the next lesson. I’m still learning new facts and best practices about test automation from our colleagues with each lesson. The better you know the subject matter, the better you can teach it. Never stop learning.
