Hello, DAI testers!
I’m taking a first stab at a web testing model (geared to exploratory testing) and I was curious if the structure I’m starting with holds with what others are doing or if there are better architecture recommendations anyone may have.
My Initial State holds a couple Actions that clear the SUT desktop, opens the browser to the app and logs in, and then Initial points to another State for the Main page with Actions underneath that reflect all the available buttons and the navigation menu entry point. All these Actions contain just code snippets.
Any of the Actions in the above Main State that take a user to a page with meaningful workflow point to another State with that workflow as the State name, and that State has Actions that - instead of being snippets - point to a Submodel that contains detailed Test Cases.
That structure is basically repeated throughout the top-level model, ending in a Final State for logging out and ending the test session. While there are many Submodels representing meaningful workflow for multiple pages (which does seem a little unwieldy) it seems like a good model but I want to be sure.
Curious how others are approaching their web testing models.
Thanks in advance!
Hi Chris,
That’s an interesting post! We’ve been licenced for DAI for several years now but we haven’t made much use of it other than for scheduling regular smoke tests each day for systems in our development environment. Would you be happy to share any resources/links that you used to pilot the approach you’ve taken, because this sounds like the way to go if we pick it up again. And - what do you do to manage the size of logfiles on the message queues that it uses? This was part of the reason we dropped it, it seemed to be hard to clear voluminous amounts of disk space that it consumes as a consequence of running tests. Storage is cheap but ultimately it needs to be easy to manage. Keysight hinted that there are mechanisms for working with the persisted logs but we never got to the bottom of how. Anyway, sounds like you’re unlocking the potential of the tool and I for one am envious!
Kind regards,
Jerry
1 Like
Hey, Jerry! We’re just getting started so I suspect answers to your excellent questions won’t be available for a while. Right now I’m focused on design and getting an exploratory test model for one app running. Sorry to disappoint, but will definitely be sharing experiences once available.
Have y’all taken a stab at exploratory testing utilizing models in DAI yet?
DAI has built-in REST API endpoints specifically for data maintenance. You can script a regular cleanup job (e.g., via a weekly cron job or CI/CD pipeline) that hits the execution history endpoints to purge test results and associated logs older than a specific threshold (e.g., 14 or 30 days)
1 Like
Would you be willing to share any resources or links you used when piloting this approach?