Our QA team has been using Silk Test to create web ui tests. I've recently been tasked with taking a look at this from a development perspective and from what I can see the current approach is very ad hoc / unstructured.
I was wondering if someone here could comment on the basic feasibility of a more structured/modular approach to creating and maintaining web ui tests in silk test without doing a deep dive into documentation, since this is atm a side task of mine.
Instead of the current approach we've been using which is just each tester creating a test/s per page using the visual workbench along with an active data file they structure and create on their own... I'd like to do something that mixes in generic tests that can be included into more specific tests.
e.g. a lot of our pages have data entry grids. The basic functionality of the grids is the same across all pages. They each have different data sets, different column counts, different subsets of column filtration methods, etc; but the basic functionality is essentially the same.
While I'm not familiar with Silk Test, I could sit down and write a collection of scripts to inspect a page, detect the existence of a grid, inspect the grid to gather information about it like number of columns, data values in each cell, etc, and use all of that to generate data and to test basic functionality like column sorting and row filtration.
So (after the boring intro), my question is: Can I do something like that in Silk Test? i.e. generic DOM inspection/manipulation via jQuery or similar. And can I then use that to create a generic set of, say, grid tests that another person could just include in their page specific test without having to recreate that work? Would that require something like Silk4J? Or can you do that in the Workbench?
What I was envisioning was having a more development focused person/s create a set of more complicated generic tests that a less development oriented person could just include in their own test as a sort of black box. That way we can have more resources available to create tests for individual pages/flows while having a subset of resources focused on creating more complicated/generic tests that everyone else can use.
Does that make sense?