| 1 | After the 30-day trial period ends, which features will no longer be available in the free version? And how data will be handle after that? |
|---|---|
| 2 | How can we effectively automate negative test cases in Katalon Studio? Are there any recommended practices for validating error messages and failed scenarios? |
| 3 | How does Katalon Studio support regression testing? What are the recommended ways to create, organize, and execute regression test suites? |
| 4 | What is the recommended approach for locating web elements? Which locator strategy or best practices should we follow to create stable and reliable test scripts and how to |
| What is the best way to handle dynamic dropdown values in Katalon Studio? |
I remember, several years ago, there was a table in the Katalon’s web site that summerizes the comparison of the Enterprise version and the Free version. But today in the Katalon Studio: test automation built for testers site, Katalon publishes no information that answers to your question immediately. I suppose that they intentionally removed that table. Possibly they want to promote the Enterprise version only on the site; they don’t want to spare space for the Free version.
Practically, you will find the answer only after the trial period.
By the way, I personally use the Free version. It’s enough for me.
“automate negative test cases” — what do you mean?
Do you expect Katalon Studio can fix (rewrite) the failing test cases automagically without involving you in debugging?
What do you mean by the term “regression testing” ?
You should define your term with more detail first, then others would be able to start thinking about it.
Which locator strategy to use — it depends on the target page given. Which exact HTML node you want, how the page’s HTML is coded and how the page moves (possibly by JavaScript). If a target is clearly set, surely you would be able to chose a locator strategy to apply to the case.
It is pointless to chat about the locator strategies on its own without a concrete target set, I think.
In many cases, it is only you who has enough access to the target page; people in this forum can not see it. If you want to raise a question “which locator strategy to follow this case”, you need to disclose all the necessary information to public. Idealy, the target is public to the Internet and you tell us it’s URL. This case, it’s easy to share. But if your target is a private one (not immediately available for others), you need to copy & paste a lot of information in your post in the forum, which many questioners tend not to do.
The question “which locator strategy in this case” is too difficult to answer in the forum format. You should rather ask somebody skilled enough to sit down beside you to do pair-programming. Hopefully he/she would be able to answer to that question.
Not every manual test can be automated. Saying that, your “negative test cases” done in Katalon Studio will be the same as you do them manually. For me, when I get to the point when I expect a result, negative or not, I put in a “FailureHandling.STOP_ON_FAILURE”–you will see what I mean after you use KS a bit.
WebUI.verifyTextPresent("Status Incomplete.", false, FailureHandling.STOP_ON_FAILURE)`
or
WebUI.verifyElementText(findTestObject('myPath/message'), "Status Incomplete.", FailureHandling.STOP_ON_FAILURE)`
If by Regression Testing, you mean to determine changes in your web site from the way it used to be to what it is now, that’s what I do. However, if ANY of the objects in your web site have had their “pathway” changed, then it is up to you to determine if this fails your regression or not. Just last week I found two fields that had been removed from the page, which I recorded on our system. A developer had changed the page but had accidently dropped those two fields–personally a good catch. Sometime our developers want to try something new and need the object name changed to do it (like a new javascript effect). I don’t call this a fail; you might be different. Unfortunately, almost all the new area of your web site will still have to be manually tested as you are testing how your site was like the old (i.e. regression), so you won’t have anything on the new. Katalon’s “Healing” just will not work in this case.
Finding web element pathways is unfortunately a difficult call to make because I think it would be based upon which technology your pages are based on. If you have static <id>, I would use that since it works for me but your app or technology may be different. However, if you have dynamic <id>, then I was told to start with labels and move your pathway to the web element–you should know either XPath or CSS for this.
And with dynamic drop-downs, my suggestion is to treat them like web tables. This is how I do it for our application. However, Katalon Studio has several methods that work on a <select> tag, like: selectOptionByLabel, selectOptionByValue and selectOptionByIndex. If you do have a <select> tag, you might be able to use Regular Expression to match on your items–RegEx does a wild card comparison, not a direct match–just set the boolean parameter to “true”. Read up on RegEx to see the power that it has!
Edit: after 30 days, you lose the use of Debug. I don’t use it myself, so okay. You cannot change some settings, but Katalon Studio is usable like it is. Otherwise, companies (people) wouldn’t be using it. I think you are (only) allowed 2000 test cases per month, which should be ample for you to get started with. There is also a “Start from Here” option that is NOT available, but it was flaky for me, and I didn’t organize my test cases for it, so neigh. (I’m not sure what you mean as your data; are you planning to attach to a database, spreadsheet or data table? I believe the database would be Enterprise, but the other two can be done after 30 days–equivalent to the Free version.)
You can start with the Spy and AI as your assistants, but you can move on after a while to using the Script tab and really improving your test coverage. Katalon is not a “no-code” application, but you can do lots without coding.
Except the 1st question , rest are not related to katalon tooling , those are just approach related questions and only you can answer those
As monty mentioned earlier, except 1st one, rest all depends on your use case
The first thing you should do is to analyze how the target “dynamic dropdown” is coded in the HTML. Open the page in Chrome browser. Open the “Developer tool” and give focus to the “dynamic dropdown” and see how the DOM around the element looks like.
This is the absolute minimum starting point.
Most of Question depends on your usecases,
You need to have negative testcases created based on your criteria, such as incorrect amount shouldnt be added to the textfield in some application. or tyring to test validation on text fields etc.