Basic rules for beginners in automation testing
By DeviQA on Tue Aug 08 2017 00:00:00 GMT+0000 (Coordinated Universal Time)
Few people doubt that testing should be. A lot of people doubt that they do it well. You will always see beginners and more experienced QA members should share their knowledge with new generation.
The main task of the article is not to explain specific tactics or show unique tests. This is not about tools or frameworks. Article was created in order to give beginners useful tips and rules which will help them to automate their tests correctly. So you may consider it as tutorial for beginners.
Analyze everything. You are not a robot and your product managers are not robots as well.
Analyze documentation and requirements. You could find a lot of defects even on that stage and in such way you will save valuable time of your team.
Do not be afraid to ask questions. If you do not know something specific about project please ask questions to relevant person. Do not do some time consuming things in your own and even without request. Your time and time of whole team is very expensive
Do not be afraid “to google”. All regular questions can be asked in the internet because so many times they have been already asked that some people just decided to place a resolve in the internet so everybody could see it. Nobody loves when it is impossible to work because of answering regular questions the whole day.
In your tests pay attention to functionality at first, and only then to visual part. Of course, visual part will be definitely spotted by customers but functionality bugs are harder to fix then visual.
So reporting functional bugs at first stages will save time for dev team.
For your tests choose most popular device at first and perform full sanity. You will see weak spots at App that you are testing so you will be able to apply deep pressure on these spots during testing in less popular devices.
Do not forget about usability checks. Most of the time you will not find such requirement in your documents but it is because usability should be by default. If you are not sure because your project is specific - ask about it. Of course if your device and app were designed for secret agents then there should not be usability.
- Bad internet connection
- All types of unexpected pop-ups (SMS, notifications, calls, alarms and low battery notifications).
- Different device modes (low battery, silent, airplane etc.)
- When device is connected via usb to laptop
- Different timezones
- Some extreme configurations like blind mode or very large font.
Even if you are sure that you have chosen correct mobile platform and you think that all functions were covered properly, give yourself some rest.Take a walk on fresh air then sit back and try to think about process from different angle. Ask someone from another team to have a fresh look. It could help to find missing scenarios or obvious bugs.
Found your own code system. For example I had an application where each customer has special name, email, signature etc. For testing purposes we created really a lot of records and found that the easiest way to create them. We take current time e.g. 16:46 = 1646 and add 0001 in the end with (inc) for each next records. So in such way we receive email@example.com etc. So develop your own coding which will be easy to understand and easy to use.
Write your code gently. Make it readable and obvious. It is very hard to review aliens’ code. First of all (if you are not only automation at company) ask someone to show you common design for code and reports.
The more information and descriptions you submit in your report, the more likely it will be to fix and reproduce the defect. Here are basic tips for reporting:
Write all preconditions even if you think that they are not relevant. Once you will gain experience you will be able to separate relevant and not relevant for report preconditions.
Write steps and try to mention here all actions that you did.
Include surroundings and settings you used while testing:
- Device type
- OS version
- simulator/emulator which was used
- If defect is not actual anywhere you should also mention it here
- Actual result
Very important part. Write here result that you received during execution. Try to make it simple but do not lose any important things.
- Expected result
Here you should explain what is the correct behavior in your specific case. Usually expected result may be taken from documentation or direct requirement.
- Additional information
Any screenshots, videos, logs will help devs to fix the bug. Some-times it is hard to reproduce the bug just for video or screenshot but for dev it will be much harder
Use notebook. I mean real notebook and not a laptop. It is very useful to do handmade schemas in order to understand some features and functional. Sometimes it is very complicated and requires a lot of TCs to cover it. In such cases it is almost unreal to write TCs which will not cover each other. So if you want to measure this effect try to prepare some schema before writing and notebook will help you with it.
Probably as a beginner you will start to write tests for regression testing. So in order to write such autotests you should pay attention to several things:
- TCs for manual testing contain a lot of material for your auto tests
- Someone on the project probably did automated regression or manual regression. Try to cooperate with this person and ask him for some advise
- You should receive confirmation for each regression test that you are going to write.That's it. Be cool but also be warm.
That's it. Be cool but also be warm.