Many projects today, and maybe projects that you are working on have testing at the end, usually with less time than promised and with release date (or simply going to the pub) approaching fast. It’s easy to see why time is so important and I’ll try to answer for you on 3 main questions that will help you to make most of your time:
- How to test/automate
- Who is going to test/automate
- What to test or what to automate?
Let’s look at these questions in more detail.
How to Test/Automate
In today’s world pace of change is tremendous. The most advantageous companies in our industries, like for example Amazon, are releasing every 11 seconds. Feel free to check that, I didn’t believe it also. Therefore, it is not acceptable for the test team to live separately from developers. The closer together they are, the less noise and less bugs will be in the code. New technologies are increasing development speed and new functionalities are added to the product before you can test them. Nowadays, test automation is a must. But how do you decide where to invest your precious time and what to choose from the large pool of automation tools?
Being in the right place at the right time I was involved in selecting a test automation tool for AngularJS application just as Protractor was launched. This is the story about our experience…
So what change from those days? It is much easier now to debug now with
browser.pause() or browser.debugger() (and yes, test code also needs debugging J)
One thing that was missing when we started was something similar to Selenium IDE. Now we have Element explorer. Start it, go to some url and paly with objects on that page.
And finally waiting for element to appear, which was one of the biggest problem so far, is now much easier with Expected Conditions. It is easy to pinpoint element and action on that element that you are waiting for (for example you are not only waiting for some button to appear but you are waiting for that button to become clickable).
…and that is why I believe that Protractor is the answer to the first question – how to test/automate?
But tool itself and all these add-ons are just something that you learn and use…however we have experienced that most problems comes from incorrectly implementing what we already know.
Let’s take a look at this setup:
Project is starting – there is more development work and planning and grooming but not so many automation going on (other than preparing framework if you’re starting new project)
Or take a look at a later stage – Project is getting close to finish, all features are already implemented and testing is in full swing.
What usually happens is that QA team is not stuffed in phase 1 and later on new people are added and they need to get familiar with environment. Worst thing to do is to just stuff-up QA team in second part of the project and to expect good quality.
Similar to above, once developers are done with implementation they are changing focus to new projects or next release reaming available only for bug fixing.
- Developers will learn how will we test their code and they will know what they need to expose to us (and save us and them a lot of time)
- Developers will get larger picture (about the product) while automating simple e2e scenario (because they usually work only on one component)
- Test engineers will benefit from help and coding but they still need to produce valid scenarios to be automated!
- Lowering project costs with reusing developers as developers in testing
Who is Going to Test/Automate
Developers are using Karma for unit testing, on service level choice of weapon is usually SOAP UI or similar tool but what about UI? Even though your product is working fine on service level if customer can’t use nice new features through the UI you are done.
Here is what we have found to work well for us:
Cover your functionalities with BVT (Build Verification Tests) – they should be small and fast and will give you quick stability information about you latest deploy.
But more important – find critical end user paths (work with BA and support!) and automate them (on UI level, mimicking user’s actions)
What to automate?
One methodology comes handy in this and its ACC – Attributes, Components, Capabilities. It’s a risk base planning and its main purpose is to define scenarios for manual exploratory testing.
You describe your software using its Attributes (Fast, Secure, Consistent…), your Components (UI, DataBase…) and Capabilities (ability of components to satisfy an attribute)
Highlight the risk with colors and add numbers to indicate amount of ways to prove a capability.
And this is how you’ll get your focus area for your test scripts.
About the Author:
Aleksandar Ristic is a test consultant based in Dublin, Ireland. He leads a testing team of 20+ people in 7 cities across 4 countries and delivering testing and quality assurance services to our clients. Over the last 15 years, he has held a number of positions, including Test Engineer, Test Automation Engineer and Test Manager and has worked with clients from various industries – from storage, telecommunications, gaming, education to public sector. He is very passionate about testing, finding and submitting bugs, as well as analysing problems and finding new ways to break software under testing. He is constantly working on identifying new tools and technologies that can help him and his team deliver better software to their clients