3

I'm currently developing a framework for automated GUI-testing of an application that is well underway in terms of development.

As the test project has been at a stand-still for quite some time, development of the application is further down the road. The result of this being that I have to write a whole bunch of tests, once I have a suitable framework to use. At this point, most of the underlying services, DB structure and business logic is stable / implemented.

Ultimately, my question is this: When is a good time to develop new automated test, and who should be responsible for this? Can the developer of a task be assigned with the responsibilty to determine and, if neccesary, implement an automated test?

Improve this question

4 Answers 4

Reset to default
1

As always, it depends.

If the application developers have been building unit and integration automation that runs with each build, you aren't as far behind as you would be if no low-level automated checks existed.

QA is usually in charge of automated GUI checks and may also be in charge of some of the high-level headless automated checks (such as API testing and the like). Depending on how many people are available, this can be the responsibility of a dedicated automation group, or it can be something the "regular" testers do (in which case, if time is not explicitly allocated your situation happens).

My preference if it can be done is to build the framework early and plug in the specific high-level tests once the API/GUI/whatever has stabilized. If your business logic is handled by API, you can (and should) run most of your business logic tests through the API rather than the GUI, and minimize GUI automation (it's always going to be slower and more fragile).

Some suggestions for catching up:

  • Start with automating the low-effort, high-ROI tests - these are the areas of the application that get most use and/or are most bug-prone. Your goal should be to have GUI automation covering the 20% of the application that will get 80% of the use (this is one reason why automating login is one of the first things many automation projects do).
  • Use a data-driven approach wherever possible - Unless your application is very different from most larger projects, there will be a lot of tests that use more or less the same process but differ in data. If you can run each set of these through one set of code with a data repository (ideally stored outside the automation code) you've made a big step to keeping your automation code clean and DRY. You've also made a significant investment in maintainability.
  • Remember that automation code is code - It will have bugs, and should be reviewed. It will also be very likely to be more complex than the application code since you are writing code that manipulates other code without full access to the other code.
  • Don't just automate your manual tests - I can't stress this enough. Automated tests need to harness what computers are good at: doing repetitive tasks over and over without changing anything about how they do it. This is perfect for things like entering multiple different orders into an application and checking that the tax calculations are correct. It doesn't work nearly as well for things like testing usability or layout.
  • Look to what the test is trying to achieve - every test has a purpose which isn't necessarily what it does. That purpose might be ensuring that logged in users see only what their permissions level permits them to see (log on as low-privilege user) or it might be to simulate a particular user role (log on as cashier and perform a shift close). Once you've decided the purpose of the test, you can work out the best way to automate it (or if it's worth automating: if an action is likely to happen once a year it may not be worth automating compared to something that will happen daily).
Improve this answer
3

When is a good time to develop new automated test, and who should be responsible for this?

Developing the structure of the automation can begin very early on in the process. Once the requirements are set the objects can start getting built out, be put into classes and a lot of the assertions can be built that way all that remains is ToDos that hook into the UI itself to grab the data from the application.

Who should be responsible for this is really an unanswerable question. Ultimately, whoever gets paid to do it/your company feels is responsible for it.

Can the developer of a task be assigned with the responsibilty to determine and, if neccesary, implement an automated test?

Yes, anyone can do it. Typically speaking it would fall into the hands of QA but if your company lacks the resources for QA to be able to manage it than having development handle it will usually lead to be a better product and less calls in the middle of the night.

Improve this answer
1

Usually developers write unit tests (because unit tests are close to the code developers know well).

Automated GUI test use different instrumentation (Selenium?) so need a bit different skillset. Sometimes might be even developed in different language: because GUI tests are inherently slower, it might make sense to use language like Python which allows you to develop tests quickly and in form more readable to domain experts, than if main app is developed in say Erlang.

So GUI tests usually fall under QA team responsibility, if it has capacity and skills.

Of course if:

  • you have just few manual testers,
  • and want automated GUI tests quickly,
  • and cannot hire test engineers for QA,

then the only developers available are your core developers. :-)

But IMHO core developers writing automated GUI tests would not be ideal. Not only they need to develop knowledge in a toolchain not relevant for core development, but also employing another set of eyes to read the specifications and implementing test might reveal subtle misunderstanding which would not surface if same person (with same misunderstanding) develops both.

Improve this answer
0

GUI features are dependant on underlying DB, Services, Business logic. Before the gui is stabilized you can focus on automating services, db layer. This would help you focus on sub-systems. Also, when you need to do End to End tests, example- GUI - Service - DB level tests it would help reuse those validations.

I would recommend GUI automation when the underlying services, DB, business logic are stable / implemented.

Improve this answer
2
  • 1
    Thanks! I actually forgot to mention the fact that the conditions you mention are met, it's just the GUI tests themselves that are lagging behind the rest of the project.
    – Nicklas Pouey-Winger
    Commented Jul 15, 2015 at 11:50
  • Then If it's stable you can focus on automating priority GUI cases which involves leveraging API's / DB level cases. It also depends on further UI that you may need to update your automation script as needed. If the GUI is finalized and stable you can start automating.
    – Siva
    Commented Jul 15, 2015 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.