How Web Apps Should Be Built For The QA Engineer
The article is a short brief overview of how web apps should be built for the QA Engineer to automate tests easier.
Let’s all admit it – automated tests, whether these are unit tests or end-to-end tests, are the future. Not only are they faster, but they are also more reliable.
While there are some things humans can do, we can let machines handle more work, with the regression tests being a prime example. Humans tend to be bored after repeating the same task over and over again, thus missing bugs, scripts always check it the same way and not miss a thing.
Besides, unit tests check your code upon compilation, so you know about bugs in the app even before QA gets to test it, whereas end-to-end tests can be run before each final release. In the end, we all have the same goal – to make the app great.
Read more-> Automation Testing Services
Taking good practice into consideration will definitely help. In this article I will provide you with some examples of how you can make your app easier to test using automated tests.
Readability Is The Key
Just like with styling elements with CSS, tests interact with objects using selectors (also called locators). These can be anything – XPaths (extremely heavy), CSS selectors (e.g. body> div > a) and more. However, there is one group that stands out – classes/IDs.
They are the best ones, as selectors should be both unique and, if possible, short and descriptive. Therefore, it’s great to name classes and IDs according to what element they represent. If you have an element an
<img> which displays a profile picture, consider adding a
That way QA Engineers (and you) will immediately know what this element is exactly. Dynamically generated names like
class=”dg5Tfd” won’t do.
I understand – sometimes you need to use the same CSS class for more than one element. That’s perfectly fine with me. However, if you reuse the same class across a couple of elements, you should consider adding IDs to them.
By definition they should be unique, which makes them perfect selectors. Not only for QA’s, but also for you, to style those elements separately.
Consider such situation – you have a list and each element of that list has some text. Unless it’s COMPLETELY necessary, try to keep using same tags for this text (or actually DO use tags in the first place, as I stated earlier).
The reason why we need it is for tests looping over the list – it’s easier for us to reuse the same selector and just iterate over the list (e.g. with
:nth-child()), rather than create various selectors for each element.
Otherwise things may be slightly more complicated for us – in turn our tests will work slower or become less readable.
Keep It Clean
This is somewhat similar to the previous tip, but mostly focusing on warnings and (more often)
console.log()s. I get it – you need them when you debug your app, they help you out (about the latter) or, for whatever reason, you have to do something that way (about the former). But they’re just junk later.
I understand it, errors are super visible due to the red background, but digging through a lot of console log (yes, I had the displeasure of having to do it once) is far from pleasant and is nothing but a waste of time.
Wait, what? What are you talking about, what tests? You’re supposed to write tests, aren’t you? – I bet a lot of you wanted to ask this question right about now. As I said at the beginning of my article, automation is the future, and this also applies to unit tests.
Obviously, QAs are responsible for end-to-end testing, but who knows the app better than the person or the people that wrote it? By adding unit tests not only do you help us with the code coverage, but also make sure we don’t accidentally miss anything. The added benefit will be you writing cleaner code in the future.
These are only few tips I can give you to make your app better for QAs and test automation. Obviously, a lot of them are just general coding rules, however too many times have I seen them being completely ignored.
And due to the fact that QAs not only test the app but also improve the whole development process I feel responsible to help all of us out that way.
Thanks to you spending slightly more time applying these tips we spend a lot less time writing our tests or coming up with workarounds. In the long run, it is the project we’re working on that benefits the most. And this is the most important thing to remember.