As per my understanding, use of DS/Algos is to solve some problems.No doubt DS/Algos are rarely coded directly in your daily work in test automation here is my question do we have the use of DS/Algos other than test automation?
As you say, Data Structures and Algorithms don't seem to appear much in everyday automation work.
At a higher, architectural level however Data Structures and Algorithms are very relevant and certainly do appear in test automation work in order to provide structure and organize complexity in test automation code.
At a practical level:
1 test may not need them. 2 tests may not need them. 1000 tests will certainly need them in order to have structure and easily maintainable and extendable code so that the automation is scalable.
For an example:
Using a Page Object factory is not relevant to 1 or 2 simple tests with less than a dozen or so element selectors. When there are 160 tests and 500 element selectors however using that structure will be essential.
Without this aspect, test suites will simply grow and get longer over time and will increasingly be prone to intermittent errors. I have seen suites in Ruby grow from 1 hour to 20 hours over time at one organization. No-one ever refactored them with design pattern or algorithms and so we ended up with a big pile of crap. This is as opposed to test suites that are constantly being refactored, tests deleted, etc with the code refactoring happening as the need becomes apparent to maintain high quality tests.
In the same way that application code will become a mess over time if not constantly refactored as it grow, the same principle applies to automation code. The patterns and algorithms and structures are often similar, if not exactly the same (we're talking code here after all) as those found in application code. Some design patterns are more relevant to application or automation code.
btw, many test frameworks also use design pattern implementations
An algorithm is just a procedure to solve a problem. It can be something as simple as "Do the thing. Check that the thing was done." It can get more complex where you have to assemble a data structure (think of it as a simple object) methodically, piece by piece, and then you come back to the basic task of testing, "Do the thing. Check that the thing was done."
So yes, thinking in terms of data structures and algorithms can help your testing because it helps you to break down problems into smaller, more manageable chunks.
While performing white box testing if a manual tester has knowledge of basic data structures and algorithms, he/she can find the faults or defects in a more convenient and fast manner. Because the tester knows the limitations of the data structures or algorithms. Even the tester can suggest a better and efficient data structure or algorithm.
Besides, some companies prefer proprietary or customized testing framework as per company's requirements. Hence knowledge of data structures and algorithms is needed for creating testing framework on their own. For example: in a previous company I worked for, I needed to create a test framework for testing a product where I had to use few data structures.
There's some wrong assumption that test automation is only about automated scripts. It's not.
It's also about creating tools that support testing. So tools for:
- test data generation,
- system configuration,
- simulating external systems,
- probing and analyzing system behaviour,
- dectecting whether the system is in certain states,
- recording system or user activity, etc.
Creating those tools requires programming skills. And thus - knowledge of data structures and algorithms.
The role of data structures and algorithms in testing? You might not find a lot of use coding your own data structures or developing algorithms in the tests you write. However...
The role of testing in data structures and algorithms is an interesting topic. You may find interesting results if you perform white box performance tests by comparing the results of different sorts, searches, etc. For example in big data applications sorting algorithms often switch between various forms of sorts based on various stages. Such optimization is possible through testing.
You may not write the data structures or algorithms inside your actual tests but that doesn't mean that it shouldn't play a role in what you decide what to test.
The primary reason one learns the algorithms & data structures is to improve the general understanding of defining and solving problems more effectively.
Even though one manual tester, who does not do any coding at all, may get the benefits of seeing things more clearly and logically which might help him in test case design by covering all the edges of a feature.