It’s Not Easy to Do Automate Testing in Software Project Based Company. But….
As person who have interest in software testing in general, if we look at the picture above, I personally think, where level I am at right now? Is QA in 2019 still the same as in 2008? Any difference working in product based company and project based company?
I’ve been working on GITS for 7 months now and I had a problem working on several projects simultaneously and my transition from manual tester to automate is kinda hard. The problems I face are:
1. Test are usually brittle
2. Project moves way too fast with things changing constantly
3. Handle many projects at once.
So, I looked for solutions in the online community and found a quote:
“Every single time I’ve seen people complain about automation being brittle/fragile/unreliable is because people didn’t want to put the time and energy into the project and didn’t realize it requires full stack skills and not just record and playback.”
So, I was looking for a solution and I hope it can help you too. Here are the solutions:
- If tests are brittle then they are written incorrectly. This could be either from a manual side or an automated side. If your tests are breaking, then take a look and see why they are breaking. Locators? Start using Page Object Model. Timings? Start using Fluent Waits. Assert on smaller decisions. Log your successes and failures correctly, and learn from them.
- Don’t automate EVERY SINGLE test case. Automate your smoke tests and part of your regression. Keep running those. Use automation as a tool to tell you if you broke something, not as the responsible party telling you whether or not you can go to production.
- Stay away from x-paths and start thinking about css selectors. Build your production code with IDs. Unit test your locators on a regular basis.
- With the proper automation framework, you can control what it takes to write a test. Even Product Owner have had no trouble writing automation by simply describing what they want to happen, and looking up the available gherkin statements. Gherkin is a business language that we use to write tests in a way that is easy to read by humans. All we have to do is describe each step and the order of how they happen, and place the correct assertion in place.
- Truthfully, from my experience, a lot of the arguments that I’ve seen against UI automation are from people who have tried and are looking for a different solution. Not the correct solution. Sure your product or project changes, so should your automation. As a Software Development Engineer in Test (SDET), I would rather have a software developer or a product manager tell me that the 5000 test cases around some features are no longer valid and required, than for me to sit here continuously running tests and getting failures all the time, and writing new test cases as part of our job.
- For striving in automation, the responsibilities and the work can be overbearing, but automation won’t work correctly unless the entire team is involved and using it to their advantage. It’s not impossible. Right now, I’m writing UI tests and automation framework code for several applications. If I can, why don’t you?
My conclusion is, as a QA in general, your job should be to ensure the quality of the software AND the processes. Because, most of the issues that were mentioned sound like process issues or not understanding test framework best practices.
Source: Reddit.com, Joecolantonio.com
Alif Shiddiq humbly said he is just a common guy who loves to help many people. Therefore, he does his part as quality assurance at GITS Indonesia wholeheartedly.
