GTE series: Yes-man VS No-man in Automated Testing World
Well, maybe some people are confused with the title of this article.
I’d be happy if all of you do not understand with the content of this article.
What do you think or what do you know about Yes-man or No-man?
According to an article in womantalk website, Yes-man is a man who’s always obey to a command from someone. This type of Yes-man is very hard or maybe can not say “no” at all although he can express his unwillingness. On the opposite side with Yes-man, No-man is a man that tend to be stubborn with received command that given to him. This type of No-man expect to be hard or can not say “yes”. Which type are you?
After knowing that you are a Yes-man or a No-man, then what is the connection between those term with automated testing?
The technology about automated testing is very popular recently. Not only a QA (Quality Assurance) who learned about it, but also other profession than QA began to be interested in automation topic. But popular is not a guarantee that people are wise or know all about automated testing and tools that exist currently.
Related with that, I’ve heard some questions or statements from some people in a community or a place where I works that has some points which you can be seen in these following list :
- There are a lot of bug and we don’t have an automated testing?
- A QA must do an automation.
- Automated testing is only for a company with a product-based type.
- You can do an automation by coding only.
- Automation will never replace a manual testing.
- This bug can passed from our pre-production, is this not handled by the automation script?
- Try to implement an automation in our office. That’s very important.
- Why this feature test case not included in automation?
- Our feature is deployed to production, go create the automation directly.
For those people who is a senior or maybe a newbie as a QA, have you ever heard those kind of questions or statements?
Some of us maybe will agree or disagree with statement that mentioned above. Not a few people will feel worried if they are required to answer some of the questions above. Well, check out the following reasons and tips that might help you with automated testing.
Reason
For Yes-man
When you want to say “no” or are not ready to enter the world of automation, but you don’t say it for reasons or circumstances that are not right, you can consider the following things :
- Ask someone about the use of automation is at your work place or career path. For long-term plan or just follow the trend? You don’t have to force yourself to follow what your work environment wants just to follow a trend.
- Automation can also be implemented for project-based software. Calculate how long the project will lasts, if it is short-term (count of months) or not iterative in addition to features, then it is not recommended to use automation. You can make this as a consideration if you are in a short-term project and you have an obligation to work on automation.
- Don’t be afraid of getting a bad appraisal if you can’t do an automation, because learning something can’t be forced. Automation is not an obligation, so it shouldn’t matter if you don’t want to learn or apply it in your work environment.
- Manual testing is the right medicine to overcome the problem of breeding untreated bugs. While automation only helps to keep the system stable. For new features, the number of bugs cannot necessarily be handled by automation.
- Remember, you should always have a choice or not. You are indeed paid by the company where you work but the choice remains in your hands. The point is not to say yes by force, because the results are not necessarily as good as what is forced.
For No-man
For you No man, hey why aren’t you learning some automation tool and make a show in front of your co-workers or boss? At a minimum you have to know a little about automation and here are some reasons :
- You can learn a new things.
- You can increase your “price” in company’s eyesight. Or if you are getting bored working in the current work environment, believe me there will be many new work environments that readily accept your skills related to automation.
- You’ll never bored because the development of automation is quite rapid lately.
- Automation is not as detailed as a manual testing, but it will help you to overcome the saturation of checking some feature again and again. You should consider the role of automation in helping your work.
- If you don’t like automation with coding, the automation recorder is something you can try at the beginning. For example you can learn tools like Selenium IDE or Katalon Studio.
- Don’t be stubborn. There is nothing bad about the science, but there will certainly be a good impact even in the slightest.
- Probably some of the best things that have ever happened to you in life, happened because you said yes to something. Otherwise things just sort of stay the same. — Danny Wallace
Choose the right Tools and Test Case
For Yes-man
- Do not put all the usual test cases made by the manual tester into automated testing scenarios just because you are afraid of being scolded if a bug passes.
- Don’t make yourself great in front of the others by choosing the wrong tools just because you feel rushed to implement automation. Automation tools is not a magic. It can be a helper or disaster.
- Input from superiors or co-workers related to automation is sometimes good but not all good. You have to sort and heart to say that a case is indeed not yet qualified or even too complicated to make a case automation test.
- Think about the effects that occur if you apply the automation test case to one particular feature.
- You can enter a negative case, if after you think about the effect of making a positive case it is not profitable and you prefer to enter the negative case. Or if you have completed all the positive test cases that might be included and you want to enter the negative case, it can be done. Do not force a positive and negative case from 1 feature. Better choose one from both but the best.
- Do not make automation test cases from unstable features. Do not also use automation tools that are not stable or are still in the research stage. Make sure you are sure what cases can be entered into the automation test case before you start working on your task. But also consider it would be too late to make automation after the feature you tested was deployed to production. What is certain is that you will not be unstable because of this.
For No-man
- Inevitably you have to make a minimum positive test case from the main features developed by your team.
- If a case automation test is too complicated but it is your team’s main feature and tends to be tested iteratively or periodically yes you have to make its automation. No need to enter things too detailed but the main functional must be thorough.
- Try to test cases every major feature is run at least 1 time a day, you can use tools like Jenkins to run it automatically for a certain period. So you don’t need to be afraid of the hassle.
- You have to start learning about the element selector even though using the automation recorder tool. Yes, your knowledge will certainly increase.
- If the system or automation tool that you are using is not stable, it does not mean your steps are stopped and you are not doing anything. Observe and learn. Start repaying what you can do instead of just thinking about endless instability.
This article only tries to help you be more flexible in the world of automated testing. There is nothing wrong with being Yes-man or No-man because that is part of each of our characteristics. But for you Yes-man and No-man who have read this article, I hope what is written here can be useful for your development in the world of automated testing. — MperMperPisang
Reference
- https://womantalk.com/career/articles/tips-hadapi-orang-tipe-yes-man-no-man-yes-no-man-ymJrD
- https://addicted2success.com/life/10-ways-to-avoid-being-a-yes-man/
- https://www.goodreads.com/work/quotes/950286-yes-man
- Yes-man movie starred by Jim Carrey
