Hi Sandy
1. It looks like not all web apps are amenable to automated testing
Especially those which are not developed inhouse and the identifiers are
dynamic.
I’m not sure I agree with that statement. Some AUTs are challenging, yes. But as the answers posted on this forum can prove, even where IDs et al are dynamic in nature, there is usually a way to pin them down.
There will be a need to update and testthe script for every
release.
Of course. In fact, more frequently than that. We test against multiple development branches 24/7.
If the testing is being done by development team, that will put
additional burden on the overstretched development team.
Of course. If works needs to be done, it can only be done with adequate resources (which must include people, too).
2. Coming back to dynamic test objects, what is better Xpath search or
CSS from performance,scalabilility and maintenability. Any links to CSS
selectors? I have not worked on CSS.
From a performance perspective, CSS:
but do pay attention to the dates here. It’s possible some absolute metrics and results have changed though I’d suspect they’ve all moved pro rata and still favor CSS.
However, from a testing perspective, the speed of execution between CSS and XPATH are largely irrelevant: your test code needs to wait in units of seconds or large fractions of a second while the browser performs millions of operations on the page.
In terms of application of CSS/XPATH, you choose which best suits your purpose based on your own proclivities. I prefer to use the tools that the page is built from – excluding the HTML itself, that is JavaScript and CSS.
My only excursion into the world of XPATH was way back when it was relatively new – I worked on XSLT processors in XML and found XPATH a worthy tool. But that was 20 or so years ago and since my CSS and JS knowledge is longer and deeper, I now don’t need XPATH.
Aside: it’s frequently pointed out (to me, anyway) that CSS cannot traverse in reverse: i.e. there are no “parent” or “ancestor” rules in CSS. This is true. However, using JavaScript and CSS, it’s not an issue. And again, sticking to these two is using what the browser uses and using what the browser manufacturers focus on most when they try to improve their performance. Said another way, improving the performance of XPATH is of no benefit to end users – so why would they even bother to do it?
So, if anything, the metrics as published in that SO thread above are likely more in favor of CSS (and JS) today.
3. I keep hearing stories of how small teamsimply gaveup on automated
testing and decided to enter the test cases themselves manually. And
this team develops the web app themselves.
In my org, all developers do some testing (lower level unit testing). We also apply broader testing for “user stories” to the AUT as a whole (this is where Katalon is used).
4.Anyone using this tool for creating test data - the intention being to load date before running processes to extract data?
Kind of. I use specialized groovy classes (factories) to enter data into forms and verify the results and outcomes. These factories are consumed by multiple Test Cases. A Test Case then becomes the conductor, guiding the moves a user might make through the AUT and orchestrating the factories in the correct sequence(s).
I considered using data sources like CSV/Excel but decided that would be “one moving part too many”. Consequentially, I spend zero time thinking outside Katalon – i.e. I don’t need to “put my Excel hat on”, ever. I have no need to create a “mental map” between Excel and Katalon when thinking/reasoning about my data and code and its use by the AUT. And believe me, my AUT is huge – it handles a ton of user data which needs to be mocked up in my factories.
Hope that gave you some food for thought.