While this depends heavily on what part/functionality of a web app you want to test, there is a place and time for both.
For example you might have a pop-up for informing the user about a cookie and have him accept (or decline) it.
Typically this pop-up would only show for the first visit, making incognito mode ideal for repeatedly checking the pop-up ...
The id global attribute defines an identifier (ID) which must be
unique in the whole document. Its purpose is to identify the element
when linking (using a fragment identifier), scripting, or styling
So as per standard, ID should be unique across the entire page ( Even ...
I would say you need to test app it in both modes if you're worried about caching issue.
Most of the (functional) testing would be in incognito mode (you are testing how application works, not how it's caching data). The application must work for new users (it's even important than working for retention users) if you want to keep them coming back.
Usually, web application testing services follow the approach of covering both the browser modes during web app testing.
Testing in Normal Browser Mode:
This should be tested majorly for regular users in the app
Cache/Cookies are locally stored on a user's machine, so validation is required, that the user does not encounter any issues due to caching
In my experience, terms like "framework" get overloaded and can mean different things to different people/roles/job titles. I tend to use "library" when talking about commericial or open source tools like Selenium or Appium, as they are a collection of APIs to use to build test automation, which is a framework or collection of tests to perform against an ...
First understand that there is no software in this world with zero defects when comes to production.
Stop worrying about yourself or team that bug went to the production.
Find what kind of impact did the bug done in the production.
Do a clear root cause analysis.
If the bug impacted huge, check whether you need to role back the release to previous one.
This would mostly be up to the team or requirements for this website.
Some use unique id,'s, some don't, some don't even use id's for all webelements.
Since this does indeed make automation harder, you could have a meeting with the devs or team in general to discuss this and work out how important this is in the overall scope of the project.
data structure changes, the data will be outdated
Yes, and the failure shows that your frontend application is no longer compatable with the service.
The problem is that you are mixing semantic checking and syntax checking.
Semantic validation of a service is done by the service itself - a service knows about the business rules and entities it manipulates:...
There could be more options, some that come to mind right now:
The number of days should be an easily configurable number,
definitely not a hard-coded value. It should be possible to change it
with no need to release a new version of the application. Therefore
you can test that the system is picking up different values. You can
choose lower numbers for the ...
I'm not sure you can update sensor inputs in all other mobiles at same time by using one device, because each and every mobile has different sensors and you can invoke that sensors only from that mobile device.
try to connect multiple android devices with appium
join this chat it will help you https://discuss.appium.io/t/using-appium-to-run-tests-on-...
First of all, you can't cover 100%.
Now, the answer to your question is that prioritize your test case according to your web application.
I.e. check the highest priority test case.
Secondly, check with issues that occur mostly in the application.
Thirdly, check the cases which can impact to other processes.
I never test manual in incognito mode, now that I am thinking about it I do not see a lot of value in it. Automated tests will run against a fresh profile anyways.
Manual testing is more for exploring, not for regression-suites.
Your examples are valid, but should be seperate test-cases where you explicitly test that situation.
I finally found out why this way of verifying pdf wasn't working.
I made the false assumption that every platform (Firefox, Chrome, Edge, Safari, etc...) was displaying pdf the same way. But, this isn't the case.
So, my code was working fine using Selenium + Java because I was also using Firefox driver.
However, new relic synthetics doesn't ...
I am surprised to read that everyone is talking about tester/QA missing the test case. Most of the time, its the requirement issue. I have done the research and even the data backs it up, around 30% of the time, it's either a missing requirement or ambiguous requirement and many times, developers don't even ask questions before implementing it.
Consider QA ...