Test failed after upgrade KS to 7.7.1

Hello there!

I have a collection what run perfectly in KS version 7.2.1. After download and activate version 7.7.1 I tried to execute this collection on exactly same enviroment, but some test cases failed.
After two execution, not the same cases failed.
Need I to upgrade the cases too?
Anyone any idea?

Hi @David_Varhelyi

Please share the message of the failed test case or the full stack-trace.

The error reasons are so different, for example one cases failed cause:
It seems it can not find a web element

"com.kms.katalon.core.exception.StepFailedException: Unable to click on object ‘Object Repository/VehicleEditFormsaveVehicleModificationButton’
at com.kms.katalon.core.webui.keyword.internal.WebUIKeywordMain.stepFailed(WebUIKeywordMain.groovy:64)
at com.kms.katalon.core.webui.keyword.internal.WebUIKeywordMain.runKeyword(WebUIKeywordMain.groovy:26)
at com.kms.katalon.core.webui.keyword.builtin.ClickKeyword.click(ClickKeyword.groovy:76)
at com.kms.katalon.core.webui.keyword.builtin.ClickKeyword.execute(ClickKeyword.groovy:43)
at com.kms.katalon.core.keyword.internal.KeywordExecutor.executeKeywordForPlatform(KeywordExecutor.groovy:73)
at com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords.click(WebUiBuiltInKeywords.groovy:617)
at com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords$click$2.call(Unknown Source)
at Fleet_linking_entities.run(Fleet_linking_entities:89)
at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:339)
at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:330)
at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:309)
at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:301)
at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:235)
at com.kms.katalon.core.main.TestSuiteExecutor.accessTestCaseMainPhase(TestSuiteExecutor.java:191)
at com.kms.katalon.core.main.TestSuiteExecutor.accessTestSuiteMainPhase(TestSuiteExecutor.java:141)
at com.kms.katalon.core.main.TestSuiteExecutor.execute(TestSuiteExecutor.java:90)
at com.kms.katalon.core.main.TestCaseMain.startTestSuite(TestCaseMain.java:157)
at com.kms.katalon.core.main.TestCaseMain$startTestSuite$0.call(Unknown Source)
at TempTestSuite1603793757234.run(TempTestSuite1603793757234.groovy:39)
Caused by: org.openqa.selenium.ElementNotInteractableException: element not interactable
(Session info: chrome=86.0.4240.111)
Build info: version: ‘3.141.59’, revision: ‘e82be7d358’, time: ‘2018-11-14T08:25:53’
System info: host: ‘W10TESZTPC’, ip: ‘192.168.100.117’, os.name: ‘Windows 10’, os.arch: ‘amd64’, os.version: ‘10.0’, java.version: ‘1.8.0_181’
Driver info: com.kms.katalon.selenium.driver.CChromeDriver
Capabilities {acceptInsecureCerts: false, browserName: chrome, browserVersion: 86.0.4240.111, chrome: {chromedriverVersion: 85.0.4183.87 (cd6713ebf92fa…, userDataDir: C:\Users\DEVELO~1\AppData\L…}, goog:chromeOptions: {debuggerAddress: localhost:60338}, javascriptEnabled: true, networkConnectionEnabled: false, pageLoadStrategy: normal, platform: WINDOWS, platformName: WINDOWS, proxy: Proxy(), setWindowRect: true, strictFileInteractability: false, timeouts: {implicit: 0, pageLoad: 300000, script: 30000}, unhandledPromptBehavior: dismiss and notify, webauthn:virtualAuthenticators: true}
Session ID: 162e97f1bab492da881f0910b273a340
at org.openqa.selenium.remote.http.W3CHttpResponseCodec.createException(W3CHttpResponseCodec.java:187)
at org.openqa.selenium.remote.http.W3CHttpResponseCodec.decode(W3CHttpResponseCodec.java:122)
at org.openqa.selenium.remote.http.W3CHttpResponseCodec.decode(W3CHttpResponseCodec.java:49)
at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:158)
at org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:83)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:552)
at com.kms.katalon.selenium.driver.CChromeDriver.execute(CChromeDriver.java:19)
at org.openqa.selenium.remote.RemoteWebElement.execute(RemoteWebElement.java:285)
at org.openqa.selenium.remote.RemoteWebElement.click(RemoteWebElement.java:84)
at org.openqa.selenium.support.events.EventFiringWebDriver$EventFiringWebElement.lambda$new$0(EventFiringWebDriver.java:404)
at com.sun.proxy.$Proxy17.click(Unknown Source)
at org.openqa.selenium.support.events.EventFiringWebDriver$EventFiringWebElement.click(EventFiringWebDriver.java:417)
at com.kms.katalon.core.webui.keyword.builtin.ClickKeyword$_click_closure1.doCall(ClickKeyword.groovy:69)
at com.kms.katalon.core.webui.keyword.builtin.ClickKeyword$_click_closure1.call(ClickKeyword.groovy)
at com.kms.katalon.core.webui.keyword.internal.WebUIKeywordMain.runKeyword(WebUIKeywordMain.groovy:20) "

That means the element in question is not ready to receive input - click in this case.

Try using Smart Wait and/or try waiting until the element is ready.

image

@Russ_Thomas
My smart wait settings are exactly same as you show. These elements are interactable
under KS 7.2.1 version. (with same settings)

Two things you should be aware of…

  1. Katalon is constantly changing with each new release. You can expect that it will get faster over time.

  2. The faster a test case runs, the more likely you are to see it run “too fast” for a browser to keep up. Browsers are slow - very slow.

By all means, if you prefer, keep your tests as they are. Then you get to watch them failing more often as Katalon gets even faster.

Your call. :upside_down_face:

@Russ_Thomas
I have a sad experience, when I made upgrade from 5.4.x 7.2.1. I just thought there is an easier way than rework all my cases again. The time is so important for me because now I have 178 cases in 8 suite :slight_smile: The run time is 194 minutes now.
I agree the browser more slower day by day //and my virtual machine too// :slight_smile:
Well, the final solution is the wait mechanism upgrade on each parts where the problem occure?

There is - a better test design and approach.

Very similar to mine - and I don’t see those problems.

I didn’t say that. Browsers are getting faster but they will never approach the speed of test cases running in memory. Browsers have to wait for servers to respond with HTML/JavaScript/CSS and data.

(Aside: Do you use Tiddlywiki? Reason I ask, //stuff// is how you do italics in Tiddlywiki.)

No, change your design philosophy:

//imports...

// Wait for the page to load

// Wait for things like AJAX to finish (Smart Wait helps here)

// Wait for EVERYTHING you are going to touch (inputs, buttons, etc.)

// If you're completely paranoid, WebUI.delay(2)

// Start your Test Steps here...
2 Likes

@Russ_Thomas
I appreciate your advices! It will be helpful for the future. By the way my newer cases are following these approaches.
“(Aside: Do you use Tiddlywiki? Reason I ask, //stuff// is how you do italics in Tiddlywiki.)” No I don’t, it is just a coincidence :slight_smile:
for the topic of…“browser more slower”… I thought the end of the long runtime, browser or server or VM more slower than in the begin of run. It depends more likely “hardware” than software.
Thank you so much for your answers!

If the server or vm is slower, contact your infrastructure / it team.
If the vm is hosted on your local machine, reconsider your hardware administration/devops skills

1 Like