It's an okay idea with some guidelines. QA code is software. And software engineering principles should still apply. Since none of the developers know protractor, they should be trained. They may be able to add tests to their application on their own eventually.
As for who to code review, the frontend developers are probably a good choice. They might ...
Chrome provides an inbuilt function for this:
Dev Console (F12)
Switch to the Sources tab
Do action in browser to get to the state you want to inspect
Chrome will pause the browser and the Elements tab will not update until you go back to Sources and Press F8 again. While it is paused you can switch back to the Elements tab and use the normal ...
You can use tools like owasp zap to find all the API calls. It spiders through most of the endpoints in search of security vulnerabilities.
Read about different scans:
I would consider the whole idea of verifying such logic from the UI perspective as a bad practice. See info on test pyramid.
If you need to test the calculation logic of your service - you can do that on the unit and/or integration testing level, which would be much easier to do, since you will be free from external dependencies in that case.
If you have no endpoint documentation then the things are really bad. I would use the following aproach:
examine known clients which use the api
extract all possible invokations which the client can do
guess what is the client missing but might be supported by server like if you have order/create then there is a chance the server has order/update as well
Why do you view it as 'Developer' reviewing 'tester's code?
A team member is reviewing another team member's code is perfectly fine as long as
vice-versa is also true and accepted equally.
Having said that, All code is code, where the standard best practices can be applied and reviewed irrespective of any specific framework (Protractor) knowledge.
You can't really test the output of a query with unit testing. There are two broad options:
You could write unit tests that validate the expected value of the query string for given inputs. However, that would be a test of implementation rather than behaviour; if you came up with a different way of writing the query, even if the overall result was identical,...
It all comes down to finding a balance point between cost of achieving quality and quality.
Perhaps you can start by calculating average time it takes for system tests to find a bug? E.g. If it takes around 5 days for system tests to find a bug, then you can try running system tests every 5 days and keep your eyes on quality. If there is no drop in quality, ...
Pausing the application as Klynt suggested should work in most situations to find elements that appear and disappear quickly.
Still, do not under estimate the power of contacting the developers and asking them to add a good clear selector/id to elements so that the application becomes testable. Make it testable together.
It is actually about Automation best practice
There are good practices in context, but there are no best practices.
I have the understanding that Automation Scripts need to be built on a
stable build (application)
Why? What is a "stable build" in your context?
Automation in Testing serves to enhance human capabilities in testing. These ...
I don't know if an authoritative answer can be provided, but I think simple logic should suffice:
your primary use of automation is regression
developing automation scripts takes (a lot) more time than doing the same thing manually
If the above is true than
it makes sense to invest (a lot of) time in automation on something that will last enough time to ...
My approach would be to examine the network traffic.
If the application operates over HTTP/HTTPS, the easiest way to do this is to use a tool called mitmproxy as a proxy that sits between the client and the server, and examines and logs all requests that pass between them. Using this tool, you can see all the endpoints the client hits during normal ...
My experience is that even if there is some documentation, it's quite often rather vague and incomplete. So, you should never completely rely on just documentation even if it's presented to you as good documentation (you want to be a sceptical tester).
Therefore, the following points are pretty much valid in any situation - if you have or don't have ...
Unfortunately JMeter .jmx files are basically XML and in case of large test plans it might be not very easy to view the diff.
You can consider using i.e.
Ruby-JMeter which is a Ruby DSL wrapper for JMeter tests, this way the code review will look like a code-review for "normal" Ruby project
or Taurus tool which supports definition of JMeter tests using ...
To me the answers about an immediate technical solution to the problem are a simple fix to the symptoms and not for the source.
You haven't mentioned testers having limited access to developers or managers so why don't you talk to them and solve also the next problem ?
Get proper access to the sources, decide on proper processes and communication channels ...
1. Use "Element is not clickable at point (x, y). Other element would receive the click..."
I think most Selenium users have seen something similar to this:
org.openqa.selenium.WebDriverException: unknown error: Element is not clickable at point (1128, 997). Other element would receive the click...
when trying to click an element obscured by ...
How about an code review from an experienced senior developer, so that you can focus more on practical tips.
Experience is incomparable to any tool at least in the current state of the tools.
Other possible ways
If coding guidelines and standard followed.
Coding guidelines followed.
Design principle effectiveness .
I don't agree with this.Test code should not be reviewed by development team as it may get biased. You can groom people from test org. to be proficient and there are enough materials and best practices available over internet to do that. Am little harsh hear due to the reason: Test and Dev. difference culture is not good for an organisation where it comes to ...