You need to understand what are the core issues with these repeated breakages before you decide how to fix the problem.
Relying on (more, improved, better, faster, etc) testing may not be the most effective solution here. It might not even help at all.
Do you have code merge issues? Are fixes becoming undone because of that?
Do you have new bugs ...
A key strategy for me is to convince the business of what needs to be tested where, otherwise... they'll end up directing testing everything through the UI... So the two key main points I am making to my business are the need for test automation that performs well in terms of two key factors:
Success in both speed and reliability for ...
Adding couple notes to Niels's great answer.
Here are the top 36 things I check for in Code Reviews
All Code Reviews
Linter is being used
English readable code
Lines are not too complex
Typos for spelling and grammar
Methods are short (<= 5 lines is ideal)
Dependencies are mocked for unit tests
Classes are short (< 100 lines if possible)
Debug Statements that were not removed
Protractor is Selenium, but then integrated with tooling and helper methods. If you know programming and Selenium it should be relative easy to pick up.
Protractor is an end-to-end test framework for Angular and AngularJS
applications. Protractor is a Node.js program built on top of
WebDriverJS. Protractor runs tests against your application running ...
You could start with unit tests, while the application is being developed. In Java you can use JUnit for this.
If you don't have a fully functioning system yet, you can use mocking to mock objects. In Java this is done with Mockito or JMockit.
Look into unit testing and TDD (Test Driven Development).
Once you are ready to integrate different components, ...
For writing Selenium tests itself, none. Selenium does not use SQL.
Now if the application under test uses SQL, maybe you need a bit of knowledge to setup test data for your tests. For basic SQL knowledge have a look at the free SQL course at Codecademy. This should probably be enough.
"Programs should be written for people to read, and only incidentally
for machines to execute".
-- "Structure and Interpretation of Computer Programs" by Abelson and Sussman
UI automation code is just another piece of "code" hence all the code best practices applies in the same way.
If I have to pick one thing, I would say code shouldn't read like ...
Estimate working load, how many test cases are there to be migrated from UI tests?
Estimate how much time you can spare in each sprint and discuss with your team leader and your fellow members regarding you want to spare some time in each sprint to work on test case migration.
Prioritize automated UI tests, there is a chance a portion of them are no longer ...
It is hard to draw reliable conclusions about an organization from two paragraphs in StackExchange, but it sounds to me as if you're going too fast. The fact that you are constantly changing the product suggests it is fairly new. With new products and new companies, when most of your users are early adopters, it may be more important to release quickly ...
Waiting for few seconds is fragile.
Your Java code is running in some terminal. Make it to prompt for for text input and wait. Entered input will be the solution of the CAPTCHA, which your code then enters to the page. Voila, you have as much time as you need to solve the CAPTCHA!
Of course even better solution would be to have special test instance of ...
I somewhat followed the transition process as below:
variables, loops, conditions, functions.
Once I grasped the basic concept of async execution, learned what ...
Web service testing independently is needed to ensure the API calls working as expected independent of the web page. In this way, we can confirm that the API calls are working as expected irrespective of the web page elements/functions.
There are many points where tester doesn't feel confident about the application. When a tester performs Automation testing there may be many challenges so web service testing is still very important to know what they need to do, rather than doing it first to learn costly lessons later. The trick is to have an automated tool which can shorten the testing of ...
Both approaches have advantages and disadvantages:
Separation into multiple projects means better separation of concerns. You can build your framework in a modular fashion like this. Where shared libraries are pushed up to some versioning tool like Artifactory and imported into each of the individual projects. But you will also more time managing ...
Normal approach should we automate only functional flow not caring
about the UI things like font of text, font type of text, color of
text, background color, images, different panels on page etc.
In short, DO NOT DO THIS. Automating text/fonts/images is a terrible idea because they can change. Does your marketing team (if you have one) have access to ...
Generally you should think of tests as doing
Given X, When Y happens, Then expect Z
This actually occurs at two (or more) levels:
Entire test suite
Certain files, constants, database commands, etc. need to be run before the entire test suite. Often there is no 'tear-down' in this area.
Each test should also have the ...
One possible way is to force a change in a parallel session or in the database with a script. Then you can keep polling for some seconds until the new data becomes visible.
I would expect the feature is not to refresh the page, but to refresh to show new data. Test the feature, not only the known behavior, thus test why the page refreshes instead. Ask ...
There might be better ways (code-wise), but avoiding Thread.Sleep can be easily done by using SpinWait.SpinUntil which is in the System.Threading namespace.
It will loop until either true, or the set timeout has passed (then the code execution simply continues).
An idea for your implementation in half pseudo-code:
public void ClickWhenVisible(this Element ...
Let's first wrap our heads around the definitions:
Protractor is a library that is built on top of WebDriverJS adding a lot of convenient and handy functionality on top. And, at the ...
Actually you should test web application after your WebService testing is done.
Web Service is an architectural pattern that just allows you to invoke the functions remotely using a widely known HTTP protocol standard (unlike some other remote functions invokations approaches). That is why the client (in your case - a web page) is just one of the possible ...
If I would approach to the goal like yours I would:
Introduce some proxy between your front-end and back-end that would log the requests to your Back-End
Run all your tests for UI
Parse the proxy logs so that I have all the endpoint calls grouped by the endpoint addresses (and possible the parameters - depends on what cost of the migration we can afford)
ui element tagging tends to be brittle.
The tool you end up using will find elements in different ways. So you'll likely change up based on the tool you use. Hopefully the tool you pick makes it easy to change 'selectors' (find element logic).
testers tend not to have some of the technical skills or experience that developers do.
Look into using Telerik ...
There are several tools available over the web but my favourite one is Octopus Deploy, because after a relative simple configuration it can deploy your build, setting up automatically your testing environment.
The configuration can be done through a user friendly interface and, it's important at least for me, it's free for a limited number of "tentacles" (...
If your only concern is layout bugs in the UI; you can give fighting-layout-bugs a try.
Its an open-source java library that checks for layout bugs. You can find more info here
In addition Selenium can come handy in creating a automated regression suite. You raised a question of these tests being fragile; ...
A reply equally broad as the question, but that does answer it:
Go to https://www.testtoolreview.de
Filter tools based on your specific situation
Compare the available options on specifications that matter to you
Pick a winner
You should research a bit more before asking generic questions like that.
Agreeing on good element and attribute identifiers is essential with web applications.
Identifying elements is done by developers, designers and automation programmers.
In a traditional waterfall environment with most of the requirements and specifications placed up front you can agree that, for example all elements that will be used, checked, clicked on ...
You can use the Actions API for that, given that the browser you use supports it. The following should do the trick with Chrome:
Moves the mouse over the "Admin" button
Waits until the "User Management" button is visible
Moves the mouse over the "User Management" button
Waits until the "Users" button is visible
Clicks the "Users" button:
Seems Coded-UI does use UIA underneath, but also some other technology.
Coded-UI test is a Record & Play automation tool which uses the
Microsoft UIA Library underneath. Since being a tool compared to
writing code in C# it improves QA productivity for recording more test
Regardless of the method you use to generate your request date, you're going to need to do this somewhat dynamically.
The simplest method is in the code to test each scenario, you do a call to get the current date, and then add or subtract days from it. You don't really care what precise date gets used in the request so much as that the response is what you ...