It might seem that from the title, that this is hardly a tip. In fact, with any thing in life, this saying applies. But I wanted to take a moment to talk about this in the context of test automation, because it is something that can make or break whether someone is successful in learning the skill properly. During my many years of automation testing, I’ve seen many occasions where companies have wanted to get everyone involved with the automation effort. Even manual testers who have no previous automation or programming experience. This is so that they can help write tests for their work stream and help build the test suite. So many times, I’ve seen people become disillusioned with the idea of automation, when they’ve tried to do too much when they start out and just lost all enthusiasm for it and felt like it’s beyond them.
That isn’t a slight at those who did that, it’s actually an issue with the way that some companies choose to introduce people to automation. When someone who has no programming experience sees the code that they will be working on or adding to, then it can be quite daunting and intimidating, especially as quite often, the code that they are looking at has been perfected over many iterations of refactoring. Code that uses areas of the language that in its first version may not have been present, or even thought of as being a suitable way of doing things. So this aspiring automation tester sees all this lean and efficient code, and straight away thinks “Wow, no way can I write code like that?”
This means that when they eventually come to writing their first test or first class, they are trying to be too clever, think too hard about simple problems so that they feel they have to write complex and clever solutions for something that really doesn’t need that at all. Or they try and be consistent with the code they have seen elsewhere, which means them trying to use parts of the language that they’ve never even seen before. This can cause confusion and frustration, which left too long will only lead to a feeling of not being capable. Once someone hits that stage, it’s often very hard to turn that around and get that enthusiasm back.
Because of this, in my later roles, where I’ve needed to coach or mentor people in this situation, I’ve always told them to walk before they can run. To not stress over how few lines that method is when you thought it would be ten times longer. To forget trying to be clever or worrying about code that they might have seen that makes no sense, because chances are, when those people who wrote that code first started out, they would have had no idea what that code did either.
When people first start out, I constantly reassure them to just write code that works. Don’t worry if it doesn’t look tidy, and don’t worry if you think that you’ve gone the long way about doing something, it doesn’t matter for now. The key thing is that you just write something that works. In this first step, you are learning the basics of the framework without even realising. When learning to code, it is so important to just get on and code. That might sound obvious, but it’s so difficult to just get caught up in the idea of reading textbook after textbook, and reading Stack Overflow for all these examples. But truth be told, until you actually use it in practise, it’s just knowledge that will only make sense for that particular scenario it’s trying to solve which 99.9% of the time, will not be the scenario you need to use it in. So just code and get familiar with the framework you’re using, make mistakes on code that doesn’t compile and learn from fixing it. Intellisense is hugely powerful in helping you see how methods can be used, and how different classes can interact with one another. Don’t feel like you’re being lazy in using it all the time in the beginning, even the most accomplished coders still rely on Intellisense.
If you are teaching yourself to code outside of work, then it can be more difficult. My advice in this situation would be to have a clear objective in mind, have a goal you want to achieve. Sitting in front of Visual Studio expecting to write code when you have no idea of what it is you want to write is near impossible. Start with something simple and try build a basic framework, using the tutorials on this site or others, and get yourself in a position where you can write tests at home. Then just write small and simple tests to begin with, pick a site that you visit a lot at home and automate small areas of it. The aim is just to get used to how to write a test and becoming familiar with the basics of code.
The next thing to learn is about that untidy or inefficient code that you were worried about. Here is where the best learning experience comes from, in my opinion. Refactoring. When you write code, no matter how much experience you have, it will never be the best version it can be the first time of asking. Never. That is why I tell people not to stress about how your code looks at this point, because firstly we just want it to work, then secondly we want it to work well. So going back over your code and just recognising areas you think you can improve is great in itself, and it is here that you are better served using sites like Stack Overflow and Code Exchange, because at this point you already understand what it is you’re trying to achieve and the code you’re trying to improve. But guess what? Even after going over your code and reducing the line count by half, it’s probably still not the most efficient code it can be. That for loop you changed into a foreach statement can be made in to a LINQ statement. That clever set of if statements you wrote to reduce the amount of declared variables can be turned into a switch statement, and so on.
But that’s besides the point, what matters is that you have now written a test that works, and has now been improved and written in a way that looks like those other tests you thought you couldn’t write just a few days ago. Now your next test you write will already be better than the first one you wrote because you now know the better way of doing things because of the refactoring work you did in the first test. This is what I mean by refactoring being one of the best ways to learn. Because every time you refactor, you learn a new and better way of doing things which you carry in to the next piece of code you write, and then when you refactor that code, you learn a better way still. This is how you improve as a coder and it really is the most efficient way to learn.
Another thing is to not be afraid of copying code or using code from the sites mentioned above like Stack Overflow. If you have a problem you need to solve and you’re stressing over the best way to do it, chances are that it’s already been done, hundreds of times by some extremely clever people. This doesn’t make you lazy, it almost makes you efficient. Why reinvent the wheel? The only issue with doing this is using code that you don’t understand. When reusing code, make sure you at least understand what it’s doing and how it’s doing it. Otherwise, not only are you not learning, you’re also making it extremely difficult to fix if the test fails later on and you need to fix that reused code.
Now it’s important to stress, that despite all the things I said, when starting automation work, you should be supported by the tools in which you’re provided as well. So the framework you’re using to develop tests with, that should have been written in a way that makes test writing as simple as possible, and if it hasn’t, then it’s the fault of the more technical automated testers. Secondly, when worrying about untidy or unreadable code, your company or QA department should have coding standards in place that outline how tests should be written and the structure they should follow. Without these, it isn’t just the inexperience that can make writing tests difficult, it will be the inconsistency displayed across the test suite that will add confusion and provide no clear direction on how tests are written. Imagine trying to write a test when every tester contributing has written tests in their own way, how are you supposed to know the correct way or if there even is one?
So it’s vital that a company has these things in place when they are expecting less technical testers to add good quality tests to the test suite.
I hope by reading this article, you have learnt that starting automation shouldn’t be a daunting task, it should be fun and an ongoing learning experience. Don’t fret over that first test you’re about to write, embrace it and remember it. One day, you’ll look back and laugh and be passing on the same advice to someone else who will be going through the same thing.
The post Tip – Walk Before You Can Run appeared first on Learn Automation.
