Top 5 Manual Testers’ Questions About Automated Testing
Hey everyone! I’m Olya, mobile app tester at hh.ru. Our team has a YouTube vlog, where we tell about our way of mobile app development. Now we’re starting a new topic — the testing of all those developments. For those who are interested, we created a separate playlist of videos about testing and automation.
This article covers TOP-5 manual testers’ questions about automation. Click to see a video version.
Who will benefit from this article?
- Projects that are under development and are starting to think about test automation.
- Manual testers who want to get into automation.
Question #1. Why do we need automation when our manual testers handle it?
Indeed, before you introduce automation to a project because it’s “À la mode” and everyone has it, it’s worth considering the following factors:
- How long the project will last, what is its scale, how much and how often it is changed.
- Evaluate how labor-intensive it will be to write autotests in each case. Maybe it will be much harder, longer and more expensive to automate your functionality than to test it manually.
- Also, if your project is expected to “cut out all the old and write new from scratch”, the time for autotests has not come yet.
But if your project is:
- is steadily developed and growing,
- increasing number of developers,
- the application that begins to acquire new functionality,
then the testing time will start to increase in direct proportion. Sooner or later it will come to a critical point, when regress will take more time than the development. This means that it is time to think about automating testing.
Autotests will ensure that the old stuff didn’t fall off while the developers were building cool new features. Especially if this new stuff was done in completely different parts of the code. Manual regresses are good in this case, of course, but there is also the human factor, a washed out eye and unpredictability of places where bugs can pop up. At the same time, manual testing is not completely abandoned because the new functionality will still be tested manually. There’s no sense in automating things that probably won’t fly high and will be kicked out in a week or sent in for revision.
But instead of keeping a manual tester busy writing test cases for new functionality, supporting documentation and constant regresses, you can give him at least one day a week for automation, to help with the initial configuration of the infrastructure, and after a few months you will have the first autotests, your tasks will be many times faster to the releases and at the same time you will become more confident in the stability of the released code.
Still, automated regression allows testers to devote more time to useful tasks, such as exploratory testing. In addition, there will be a better understanding of how the application works under the hood, which will definitely come in handy even in manual testing.
Question #2. Is it possible to start writing autotests in a one-day time?
You can start writing autotests right away, but it’s better not to rush and to take a thoughtful approach to the question.
If the project has not yet had automation, you should definitely start with research on existing tools, frameworks, and approaches. Read about the problems users face and how quickly they are solved. Evaluate the pros and cons, and choose the most suitable, which will be easy and pleasant to work with. The price of a mistake at the start is much lower than when you are actively automating and suddenly realize that the framework you have chosen is not convenient and does not suit at all.
If you’ve never practiced autotests before, it can seem difficult at first… It’s not easy to start writing autotests right away if you don’t have any examples and nothing to lean on. Fortunately, there are a lot of various articles with a lot of good code examples available on the Internet now, which you can take, tweak to fit your own needs, and figure out how they work.
Finally, to learn to automate, you need to start automating. This really works!
After all, to learn how to automate, you just have to start automating. It really works.
It is perfect if you have developers who are willing to help you understand the code and answer all your questions at the beginning. At hh this was exactly the case — in the early days, when we first started writing our first autotests, we just flooded our guys with all sorts of questions. Thanks to them, we got to where we are today.
But it is possible that your team may not have time to assist you with autotests. Unfortunately, it is possible, and you shouldn’t blame them for that. If you are in this situation, do not despair! Our team created a chat on Telegram where we are ready to answer all the questions related to the development, testing and automation of mobile applications. Feel free to ask, learn, and start writing your first autotests!
It is also worth noting that there is a very powerful community of testers on the Internet. There are chat rooms on the very same Telegram, where they will answer all your questions 24/7 and help you figure things out.
Question #3. Is it possible to become an automator without manual testing experience?
It’s possible, if you have experience in programming. In some companies, this is precisely how it works. Manual testers write test cases (steps + expected result), the automator takes them and translates into code. In general, this approach is quite valid and working, but I see some drawbacks in it.
First, when you write autotests for a functionality that you know well, you can add some tests that you might have missed when writing test cases. Plus, you know other autotests, which you can add
Secondly, test automation is interesting and useful. You start to learn the code, expand your product knowledge, and understand how everything works from the inside. This is useful for manual testing as well. You start to understand developers slightly better.
Question #4. Is it possible to make developers write autotests?
In theory, of course, it is possible. But most likely they will not be very happy about this, and it is unlikely that anyone will be happy in general.
First, it will slow down the development process. Instead of writing code, developing product functionality, developers will be busy writing autotests.
Secondly, it’s expensive.
And third, everyone should have their own area of responsibility. Developers create the functionality, and testers test it. Everything is the same with autotests as with ordinary testing. The unit-tests are the developers’ responsibility, but the UI is the testers’.
In fact, this question is like “Why do we need testers when we can ask developers to test what they have written?”
Question #5. Is it possible to write autotests automatically? I don’t want to learn how to program.
You can give it a shot. We tried. There are recorders for such things. But the tests they create are monstrous and unsupported pieces of code.
Perhaps it would work if, let’s say, there was some button in the application that would never change. Neither the path to it, nor its functionality and position, will be changed. Then the code of this test will never need to be changed and let this test live. But unfortunately, it doesn’t work that way in practice. Tests should be easy to maintain, understandable, and readable. You can’t achieve it with a recorder.
You can use recorders in some complex areas of the application to see how you can interact with some hard-to-find element. That is, use it as an assistant, as an auxiliary tool, but not as the main means of automation.
Instead of a conclusion:
This article opens a series of articles. Next to arrive:
- Top 5 manager’s Questions About Autotests
- Top 5 CTO’s Questions About Autotests
- Top 5 Junior Automator’s Questions About Autotests
Sounds fun? Subscribe our news channel on telegram and “HHella cool stories” channel so you won’t miss new videos, articles and other news. And you can ask our engineers any questions on any topic in the comments or in hh developers’ telegram-chat.
