I usually make the expected and actual tuples, and I compare them.

expected = ('john doe', '1111', 'something', True)
actual = (
     response ["user"],
     response ["objects"] [0] ["id"],
     response ["objects"] [0] ["event"] [0] ["type"],
     response ["reached"]
)
assert expected == actual

Run pytest with the -v switch, then it will clearly show which elements in the tuples are not equal.

You can use ExecuteScript and javascript to handle JQuery:

var driverWait = new WebDriverWait(Driver, TimeSpan.FromSeconds(5));
driverWait.Until(d => (long)js.ExecuteScript("return jQuery.active") == 0);

I have to do a performance test for application(It has UI) ,It has API requests ,how to find the browser rendering time for APIs , can we do it with retrieve embedded resource. I am quite new to this ,Can someone please guide me.

add the class name of your "a" element. In order to get an attribute value, you can use the method "get_attribute("element_name")

linkElement = driver.find_element_by_xpath("//a[contains(@class,'THE CLASS NAME')]")
attributeValue = linkElement.get_attribute("data-ftjson")
stringElement = "\"newreq\":\"yes\""

if (stringElement in attributeValue):
#do something
else:
#do something

#or by json for this you need to import json
jsonValue = attributeValue['newreq']

if jsonValue == 'yes':
    #do something
else:
    #do something

Retesting is testing this tast cases which failed and bugs were solved.

Regression tests are test which check if added or changed functionality not caused faults in existing code.

In your case retesting will be 50 in Module A and 40 in Module B.

It is hard to say how many regression tests do you need but in such a situation (many test cases failed) probably you need to test all test cases. In general you do not test everything in regression.

Automation is one time activity in terms of creating script where manual we have to perform often. While automating activity, we have to be very careful about the locators, functions, utilities, compatibility which consume times.

Prior logic should be clear before implementing what we gonna automate. In manual, we have to just pass valid /Invalid data and check the output. It does also based on the performance of the web site as well.

Clear understanding about the automation can only help to do automation speedy. Hence manual is more preferable in terms of saving time if you are new to automation. Identifying scenarios to be automate will take some time as well.

I would sum it up thusly:

• Automated tests are for finding the problems that you know about (incorrect code).

• Manual tests are for finding the problems that you don't know about (incorrect design/specs).

If you use manual tests to find problems with the code, that is inefficient. If you use automated tests to find problems with the design, that is inexcusable.

Unless you have a very low issue rate, use a database to track issue.
Make the QA process interesting by getting developers to do TDD (Test-Driven Development). It's good for them, and it gets rid of the stupid bugs.
Automate tests.
Get QA involved in the product from the beginning, not just the last 2 weeks.
Give them power. QA gets to decide when the product is ready to ship.
Give QA a real career path.

Tags can be referenced as follows:

element (by.tagName ('a'))

or

$ ('a')

If you need to check the text inside the tag for compliance:

expect (element (by.tagName ('a')). getText ()). toEqual ('text');

or

expect ($ ('a'). getText ()). toEqual ('text');

Getting the text itself:

$ ('a'). getText (). then ((text) => {
    console.log (text);
})

I usually make the expected and actual tuples, and I compare them.

expected = ('john doe', '1111', 'something', True)
actual = (
     response ["user"],
     response ["objects"] [0] ["id"],
     response ["objects"] [0] ["event"] [0] ["type"],
     response ["reached"]
)
assert expected == actual

Run pytest with the -v switch, then it will clearly show which elements in the tuples are not equal.

Usually static variables live until the program that loaded the class with this static ends. The static is initialized once, when the class is loaded by the class loader. "Usually" I wrote it because it is possible to change this behavior by rewriting the loader class, as is done, for example, in OSGI implementations

I suppose your tests change the value of a static variable, and you expect that the value of these fields will be "as at the start of the program", but this is not the case, the values ​​from the previous runs of the tests are saved in them. all tests are run within one jvm run

PS: With your tests there are 2 ways, either you manually initialize the statics as needed before starting each test, or you get rid of it and problems with it.

It found out that the FIRST_VALUE function appeared in H2 in version 1.4.198, in our project there was version 1.4.195