I’ve recently started looking into automation and I watched a few free courses that I could find. But none of them really went very deep into any particular subject and in my company I’m the only tester, there isn’t someone that can teach me the good ways of automating tests and I don’t know really how should I continue learning. I made a few tests and run them with pytest.
The only issue that I can see is that all the tests will be on the UI level, so no unit testing because it would require “more costs” on our side. So every aspect that will be tested will run slowly and won’t test the fundamental code.
My boss also told me that all the tests should be integrated in a framework so we will have results for each of them and will be stored oganized.
Do you guys have any tips for me how should I approach this? Or some recommandations of courses or books that explain better and don’t only scratch the surface? Maybe you also know some tools that I could use.
Thank you in advance for your guidance!
P.S. I’m sorry if I didn’t use the right terms, I’m not very familiar with the subject
The only tester will test and also use automation in support of testing.
The automation is strictly at UI level.
No helpers as developers are too busy.
Must use or build a framework for the automation product.
Must have a dashboard to display results.
There must be a structure to your automated scenarios & checks
I would start by thinking of items that would make the plan.
Get the plan reviewed by other devs and the manager.
Examples of what I’m looking for in a plan:
objective, how does it fit in the overall testing strategy, automation team, overlapping of automation or testing at different levels(unit,integration,API,etc…) or teams, product environment, setup, scope(list of scenarios), guidelines of automation coding(some good practices), variation of data, hosting and management of execution, system to run on, method of automating, code storage(local, git, cloud), code location(new project, product project), code standards(follow dev. code standards?), tool stack, collaboration, maintenance plans, trigger to launch, locators, interaction level, reporting, monitoring and logging, estimations, device, support, handling failure.
A lot of automation frameworks fail the first few times. I’ve seen 8 out of 10 die for some reason.
you were hired to do the job, you would not be writing this post if you were not the right person for the job.
You are brave too. And I suspect that your next step will be to push back on some of the requirements that are more “wish-list” than “business value”. You probably already have a better ide of what’s important, at a nuts and bolt level, than what your boss may think. But they have confidence in you, so use it.
@ipstefan is right, loads of those requirements deliver no customer value at all and are expensive in terms of time and money both of which could be spent far far better. Customer value, is in a defect free product and tracking down where the bugs you ship originate from and stop them at source. None of those things seem to be linked to lower defect counts. So let your boss know that you are going to focus on stopping bugs escaping into the wild first, and then fancy dashboards can come later. I have yet to work in any company where the dashboard is still in use more than 2 or 3 years later, focus on working out what tools you have, what tools you want and then get good at using those tools.
Unit tests are the developer’s problem, pay attention to them, but don’t get involved in them at all. How developers unit test or component-test reveals a lot about the product assembly (build steps) and about the architecture. Unit test pass rates are pointless on a dashboard and pointless to a tester in your shoes. You are in the right place, you just need to gather some information, and meet with the team leaders with ideas that will slow the flow of bugs into the wild.
Most of all, you are in a good place now, you are asking. @carolinel Can you tell us a bit more about the product, does it run natively, or in a browser, does it have web services, is it in a retail or in a line of business space? Are there other clues, before we start suggesting tools, we need that context, that’s why testing is hard, most tools are very specific.
As for some context @conrad.connected the first project that I am gonna try to integrate automation is an ecommerce website with books and some miscellaneous items. We have the frontend and the admin backend that communicate. In backend is stored everything: books, authors, campaigns, promotions, users. Also this website is already in live environment.
For now I used Selenium webdriver for the tests (I did the login scenarios with happy path, wrong pass, etc.), but I watched some people saying that it’s bad, I don’t know why though, I remember hearing about it everywhere and job listings always required selenium knowledge.
Edit: Also some colleagues and my boss suggested (I don’t have to do that if I don’t want to) that I can automate with BugBug (I don’t know if some of you heard of it, because I didn’t before I came here) and I’m kinda skeptical about it because I want to do this how everybody else in the industry does it.
I think you are already on the right track with your line of questioning. Yes everyone at some point, says Selenium is bad, but we know that all poor workmen blame their tools. I would keep aside and plan one day a month to look at tool alternatives, a bit like doing training you could see it, try a different tool every so often. Not heard of BugBug, but chances are, like 90% of the tools out there, it still uses the same Selenium driver under the hood, but just uses it differently. Definitely plan for and give it a go, but know, that your context and problem is often unique. Using the same tool someone else does is like picking up a Fender Stratocaster just because Eric Clapton, David Gillmour and Jimi Hendrix used them. Nothing replaces knowing all the ins and outs, strengths and weaknesses in personal detail.
So often, the tool you know well, and fits in your hand easily, is the tool you are most adept with too. For me, that tool is Python. I just happen to use Selenium amongst the other tools, because talking directly to the test environment and configuring sandboxes still requires coding and intimate knowledge. Selenium is not amazing, but it’s just one of the tools I use, and that’s why I have never been a fan of people staying on the same tool for long or relying on only one tool. By spending a day every so often trying other tools relevant to you, you will build knowledge and have more options when you get stuck.
Take a look at Cypress as well - but most of all start looking at what the main defect areas are and choose tools that cover those areas. Is mobile for example an emerging market, if not I would be surprised. Most tools require you redo all your testing automation for mobile, you want to try mitigate, so always be aware of future business goals.
Firstly, I think what you’re experiencing isn’t something unique. I don’t mean to downplay the challenge, just that a lot of us who work in automation have this discussion around building automated checks that are valuable and focused on specific parts of the system. I also agree most courses out there on automation don’t broach this subject at all, that’s why we created courses like the Intermediate certificate in test automation.
Ultimately, for me, it comes down to risk. When I am having the discussion about what layer to automate on I communicate to my team about the risks of taking a specific approach. For example, you’ve highlighted with your UI level checks that there is a risk of them running slowly. I would encourage you to keep thinking critically about other risks as well. More system under test, means more can go wrong, which could mean more flakiness.
It’s interesting that unit checks are seen as more costly given that when UI full stack checks become flakey they take a lot longer to diagnose and fix than a unit check. So another angle is to dig into what is meant by “cost”.
Finally, it might feel a bit crass, but sometimes you have to let things play out. If you communicate the risks of an approach and they get accepted, then we sometimes have to wait to see what happens then react after that.