When you work for a large company, you sometimes need to expand your automation efforts beyond Selenium browser-based testing.
What happens when you also need to create automation for applications like Embedded Systems, SaaS or ERP?
In today’s episode you’ll discover how to automate embedded, SaaS and ERP systems, so prepare to learn
some useful tips and best practices as we Test Talk with Ali Khalid, a test automation expert and enthusiast who has a ton of consulting experience working with all kinds of automation projects.
About Ali Khalid
Ali has been in the industry for about 10 years with a wealth of experience in diversified products. He has worked on and delivered multiple automation frameworks for for Embedded, SaaS and ERP products. Over the years has conducted trainings in automation framework design and invited as a guest speaker and a moderator to meet-ups on occasions as well. He is passionate about finding new techniques to design successful automation frameworks and help out companies in their automation ambitions.
Quotes & Insights from this Test Talk
- I’m a big advocate of planning out things. I think it just happens to start off with me working with safety-critical applications, we didn’t have the luxury to make mistakes, like in the Agile process. We had to can stuff. Without omission, I think you can do trial and errors, but it’s a long path, and planning is really important, especially for developing our omission framework. That planning part, understanding the application in a test is really, really critical. Of course, if you understand the characteristics of an embedded SaaS or ERP, that makes your job a lot easier.
- Understanding that nature of the product is paramount. For SaaS, the experience I’ve had, typically you might not see as much business logic, compared to ERP. An ERP would have lots of business logic, lots of user flows, naturally, lots of test data transactions; but for a SaaS, you wouldn’t have that much. The application is really fast-paced. It can change quickly, and an ERP is not that easy to change, or doesn’t have frequent changes, with the exposure that I’ve had. In a SaaS, a problem would be object recognition, on the UI side. That would be more of a challenge, because that would use more logistic technologies, really dynamic elements like AngularJS, Node.js, Sentia. An ERP, if they haven’t revamped, might be using some older versions, like simple jQuery, perhaps, so UI is not that tough for ERP. But each of these has their own difficult problems.
- Typically, when management thinks of automation, they have the picture in their mind, perhaps they’re sitting somewhere, and they just press a button, and the testing is done, and the whole system just runs. The truth of the matter is, some things are not good for automation, and that was one part. I have to say, though, we had a different product which we did, again, embedded test automation for, and that was a good candidate.
- I think for a framework design, the most important things are firstly, robustness. Most of the time, automation falls into the trap where our scripts are not robust enough, and they’re not performing. So that’s one important aspect; maintainability is a really important aspect. Time and again, we’ve seen where a certain team has been automating and a person leaves, and you have a new hire, and they just don’t have a clue of what’s going on. Even the one’s who are working , if they have to update it sometimes, it’s really tough, and they spend a lot of time just trying to update some previously written code. That’s a very important aspect. Then again, scalability is a really important thing to embed in the framework.
- I got this idea from some of our products in the safety-critical space, where they were really big-time on documentation. That aspect of those products, I really loved. I see that in the Agile transition. Of course, documentation just for the sake of it has had some impacts on the industry, but removing it altogether is also not a good idea. They had this concept of coding guidelines. They would have a bunch of stuff in there; for instance, they had really clear guidelines for naming conventions, especially for commenting, function headers, file headers, wherever there was different logic line comments, and the best part, which we are following as well, was they would use some coding documentation tool. We are using Natural Docs here.
- Definitely maintainability is a big thing. Within maintainability, I have seen that test data is something which usually I did not account for, to be honest. Over the years, I’ve discerned how much test data can differ between all these three. For instance, in the embedded realm, test data is really complex. You would have a user value, but then you have to give a different corresponding value to your hardware, which might be a different voltage; for instance, one click here means 10 milliamps, or something You have multiple layers of data there: one of them is the user value, then the corresponding hardware value; managing all of that test data is really important. The same goes for SaaS and ERP again. For SaaS, initially what we did was, we used to generate all of our data first in the test, then use it.
Resources
- Code Complete, by Steve McConnell  (for a comprehensive guide)
- TestCompleteÂ
- Microsoft Naming Guidelines
Connect with Ali Khalid
- LinkedIn:Â alikhalid
May I Ask You For a Favor?
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.
Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!
