Our development teams are good on writing unit tests and also for using the same framework (rspec in our case) for writing integrated tests.
There is a strong desire to increase automated UI testing. The desire has been expressed for the QA group to spearhead this.
When actually trying to do this however we have run into a lot of obstacles, such as:
ui element tagging tends to be brittle. We decided that using
data-attributesand specifically in our case data attributes that start with
data-qeeg-to effectively namespace them to our QE Area for the eg application. We'd like to have full control within this name space but we are getting a lot of feedback from developers about the exact names we use.
testers tend not to have some of the technical skills or experience that developers do. It's quite hard to find testers who are have a strong technical skills set in programming. this tends to perpetuate the (terrible) idea of testers as 2nd class citizens who are 'not good enough' to be the programmers they 'would really rather be'.
duplication of effort. There is frequently push back from developers saying they have already written unit or even integrated (but non-ui) tests. Why do we need to duplicate a lot of their functionality?
Co-ordination with developers. Having to follow all the same processes for change that developers use, does not seem to work well when we are making small changes to the UI to make automated UI testing easier. Developers have a tendency to want folks they work with to be skilled and experienced in other areas and can get frustrated with testers who are not. This seems to lead to a lack of trust and a 'always need to review it' mentality.
Code reviews for element tag changes. The need for reviewing the code that is actually doing the automation seems reasonable and for that we fit into our organizations code review rules. However for the tagging of web UI elements that is an essential part of our work we are constantly slowed down by needing review and then often lengthy discussion of what are essentially naming conventions. We like to do peer review but when all our work if effectively dependent on 'programmer approval' it slows us down, demotivates us and makes us feel like 2nd class citizens.
QE's have a role in each ticket. Manually testing tends to be quick and easy and fits within the times being spent on the ticket during its other phases. A problem arises when we want to automate the manual steps in that the automation takes a while to write and the 'needs testing' queue starts to back up and pressure build to just 'get the ticket out'
How can we overcome these obstacles and successfully introduce and grow Automated UI testing in our organization?