Hello ,
I am a Junior SQA and I want to ask how to move from Manual Testing to Automation, From where I can start like what do I need to do. Kindly give your suggestions.
Thanks,
5 Likes
Maybe everyone won’t agree but take a look at Katalon Studio. I’ve been using it for a bit and seems a great tool for UI tests and does a great job with API as well. It’ll help take the pressure off the coding side whilst you familiarise yourself with some of the basic concepts.
The idea of selecting automated tests, managing them and the test data, how they can get “flaky”, how automated tests fit into the overall test strategy are all important concepts to get before you start with getting in depth the coding (technical) side.
Is there any test automation at your current company or project?
If so, I think a great place to start is to learn what you have there and pair with a more senior person
1 Like
Completely depends on “Context” what priority you take these steps, I’ve merely laid them out in an order that they come to me.
- Get all the tools you currently use together, and I mean “all of” the manual testing equipment, understand what it does and what needs updating.
- Work out which tools can “autonomously” perform basic checks for you, these checks need to be very simple things like can I login to the app or install the app, nothing more. Script them up and verify what environmental impacts cause the checks to break.
- Speak to the devs and learn about the build infrastructure and how to start chaining post-build steps in. (nightly or chron test script runs are also good, but post-build or “build-time triggered” automation is more useful initially.)
- Choose to automate only the checks that give “you” value and save you manual testing hours. Keep it small, baby steps. I call them “smoke tests”.
- Once confident the checks are robust and not flakey. Then, add checks that speed up your dev team, like a build sanity test that verifies every single build that builds is “deployable”.
- If deploying a build takes a long time, work out how to deploy only what you need to deploy so that things can speed up.
All of the above need to be interpreted in your context, but you will be evaluating a load of tools and tech stacks and even deciding if you need to build your entire testing stack yourself if a tool does not exist. The sheer volume of mental overload and changes here is scary, but make sure that each thing that helps you gets kept and things that slow you down get chucked out.
3 Likes
Adding to @conrad.connected 's excellent comment, I’d point out that “automation” isn’t just tests. While there’s a lot of overlap with DevOps, it’s just as important to figure out how to consistently configure test environments, test agents, trigger workflows in CI/CD, add merge gates in the VCS, etc.
Unless you work for a giant company where you can just put your head down and knock out a lot of automated checks, there’s likely a lot more value in the DevOps-ish bits of “automation” than there are in the automated e2e tests you’re likely going to focus on.
So, in terms of practical advice about how you move to automation, focus on learning some kind of programming language. I usually suggest python since it’s become the lingua franca/Swiss Army knife for utility scripts and tying things together, and then start automating your daily pain points. It might be as simple as scripting together some build scripts, configuration, deploys, etc. Focus on small, iterable bits, not on a Selenium or Cypress test.
2 Likes
100% cannot more succinctly back up what Ernie is saying here. The “goal” of test automation is to save time, time to free you up do more good “human-driven” testing, and to save your developers time. By verifying builds are “good enough” almost as soon as they pop out of the compiler you, will be saving the devs time. In many cases for the most of us today test apps are non-trivial web-like things, that install using some kind of deployment engine.
As an automation person, you will start getting closer to the developer team, and all these install or deployment toolstacks. If you thought you have a good grasp of the “system” architecture before, you will be getting even better at understanding it. Make time to chat with the devs over coffee to learn more about how the system deploys, and speak to them about “testability”, which is a whole new automation-specific topic. Just be careful to not go too deep into the “OPS” world. You will be busy enough trialing out things like “codeless automation” and so on. You will definitely start getting onto friendlier terms with the folk who “write the code”; so let them teach you some basic scripting language, they love to share and teach. It’s a long journey, baby steps.
Hahaha, the wording here confused me for a second 
Doh! I am beginning to feel like a comedian. I'm so glad I've reached a point where I don't take all of my errors too seriously. If I did I would be in imposter syndrome jail by now. March 2020 will be behind us soon, and so I'm going to have to find another excuse to use for old age. I can imagine we might make a podcast between us, it would be a hose. Will edit that right away!
I just recall an entire year of my automation career where the only thing that drove me forward was “faster and faster build verification”, to speed up the loop between code getting committed into the source repo and giving devs a positive “integration looks good” pass signal so they can move on. I raised zero product bugs that whole year, most test failure were a stroll over to a developers desk to say, “That code you committed 2 hours ago, it’s loading the wrong api version”, total time to fix 5 minutes. That is all about finding bugs before they make it anywhere near the master codeline. Not everyone will have the same automation journey, I hope you can see the different experiences here @umair1429
I think, version-control and branching control part of automation is another big change for people moving from manual to automated testing. The ability to “cheaply” test a small feature-branch that only 2 people are coding on to the exact same confidence level as the tests normally done only for the master branch. So yes, automation will mean you will have to learn much more about feature branches and version control. But it will buy the whole team time back once you do.
Though moving to automation from manual seems quite an easy job due to the large community and tools available out there, the real hassle is all about adapting to the change. Most of the time, newbies struggle at the very first stage of planning the test process for automation as it needs to define the test cases that must be automated.
Since you are already associated with manual testing, I believe it will work as a base for you to follow automation testing. A few things that you can do to quickly shift are:
- Explore different frameworks available
- Start with small goals as your requirements
- Always be clear of what must be automated.
I am working as VP Delivery and Operations, I believe this ebook on Manual Testing Vs. Automation Testing will be of great help.
2 Likes