- This topic has 4 replies, 5 voices, and was last updated 6 years, 6 months ago by
.
-
Posts
-
Share you opinions and suggest some of the software test automation trends which needs to be followed for more efficient as well as effective software testing.
With CI/CD, I feel integration testing on API level would be really good as this isn’t just about the UI.
Also, API testing can be extended to test RESTful web services and their resources. So for an organization, it would increase quick responses to new opportunities.
And you can read more about this topic here (Quora Link).Share your very excellent. It helped me to have much more knowledge in this field. Hope to contribute my work to my work better
[commercial content removed /mod]
Automating API Testing practices is currently at a better pace than automating the UI testing process and are expected to grow further. And, pursuing more Devops highlights on integration and automation, this have been appreciated and pursued overwhelmingly for past 4-5 years & are likely to be followed in coming years too.
If you would like to know more, you can read the automation trends here: Trending Technological Trends For Software Testing
Munish Sharma
“Don’t swim downstream, don’t swim upstream. Swim where you want to go”. Vladimir Savchenko, “Advice for beginner swimmer”
- First what you need is not what is trendy, but what you testing project needs and what you can get (and as cheap as possible: testing budgets rarely get fat).
- Be careful with trends. Examine them rigorously. Look at them through optics of your project needs, what you may get and how soon.
I saw three projects trying to implement trendy BDD. The problem was that they sheepishly followed trend, not examining if it is right for the project. What happened then:
- After wasted men-hours amounting to men-years BDD was abandoned. Framework was rewritten, but the second version also met dishonorable discharge because of bad choice of components and integration requirements. I’m sure that illusions of trendy BDD played major role in the failure.
- After wasted men-hours amounting to men-years BDD part was abandoned completely, good for nothing now. Non-trending solutions helped more.
- Project failed to expand BDD coverage significantly, various other problems led to project closing.
It is not that every project using BDD is bound to fail, but not every project benefits from BDD too, and it requires a lot of specific support. You don’t get such information from trends, you have to study this yourself and better learn not only about advertised benefits, but about failures too.
Do not forget go think about support and maintenance. Every automation needs some support, be it programmers or tester support. It can matter even more than trends.
Now on important trends:
- In trend or not, unit tests and integration tests are still good, and “automation test pyramid” is still valid. They do not have any much hype, but they really work.
- Seek tests which run fast and inform you fast. It is not what people say on trends, but it is good “invisible” trend for years.
- Make your people learn and grow. “A fool with a tool is still a fool”, you need not to be a fool. Some automation tools may actually be easily accessible or easy implemented with some skill. Not following any trend I found a few opportunities and implemented a few useful tools myself.
- Running tests off your integration system. I have troubles with recognizing integration as continuous: it is not easy to really get it right and working continuously. Anyway, if you integrate tests in your project / builds, it’s a service to the project.
- Variety of tools. You need not to stick to only one tool, language, stack. There are a lot of tools: static code analyzers, static security analyzers etc. In projects I saw having on team people using various tools is better than trying to bound everyone to one tool.
- Complex testing for complex projects. If you have in your product complex front-end, back-end, API and mobile, you probably want to test every of them.
- Randomness, in particular generating random paths through some feature of your product and comparing results. I’m not stranger to idea of random actions and started to use it years ago with different “monkey testing” tools. Now it sort of resurrects with a twist, see “Applying AI to testing” (good talk in general, not just because of randomness mentioned). I managed to implement random exploration paths without any AI during integration into our product 3d party library. So far so good: 3 bugs were discovered and reported on random paths generated by my code.
- Visual testing. This idea also was around for a while, and I think it’s time has come. Tools like Selenium work with DOM elements, but do not inform us if some page is intact in general. Adding visual comparison to it makes tests more powerful (though makes them slower as well, so don’t make all your tests visual).
- You must be logged in to reply to this topic.