Who are we and what do we do?
We are the QA team, which is part of the SDN platform team. In a nutshell, the QA team is responsible for making sure every piece and part of SDN/BPX is properly working for you, dear users of ours.
That means ongoing verification of different functionalities of the site, alongside with verification process of our monthly deployments which include bug fixes and launch of new functionalities for internal and external use. Some of these are rather small, but others are big and complicated and require a deep inside knowledge of SAP NW EP technology, which is the platform we use. Many of these new functionalities and developments eventually find their way to the EP product, as used by our customers.
As you must have read in the fabulous A week in the life of .... by Ciara Mathews (who just happens to be my boss), our shrunken team consists of the international man of mystery - Herr E (which is still due to write his own blog - beware!), of Ms. N (our part time Swedish collaborator), of Vinay - our new recruit from India and....
Who am I and what do I do?
... me! Reading Ciara's blog, you must have wondered who this star superman QA engineer she described was. Well, it's time to unveil - I am the Israeli Mr. B.
Test automation and you
So now that we all know each other, it's time to talk business.
I chose to introduce the topic of test automation as this might be very relevant for quiet many users of SDN/BPX:
- Managers - who might want to make their teams work more efficiently and achieve much more
- Developers - who need to QA their applications, or work closely with QA colleagues
- QA persons - who take advantage of SDN and BPX to learn more about applications and platforms they are testing (and as a respectable runaway from boring testing)
- And others...
Test Automation is using automatic tools in order to perform testing on numerous types of applications. Would have been great if it was that simple, but it's not. On the other hand, it's not rocket science and it does introduce many advantages.
How does that work?
We in the SDN QA team use the Mercury's QTP tool for creating and running our automatic test scripts. This software is supplied (amongst others) with an SAP addin, which enables the tool to handle object classes used by SAP EP.
The scripts are based on an object repository (where an object can be pretty much every part of a page, from a single button or field to a table or a whole page section) and on actions you perform on these objects (click, set, close and dozens of other possible actions).
In addition to all these, the script should include "checkpoints", which are actually the things you want to check and verify.
Well, from this point on the level of your scripts is totally up to you and what you make out of it. It can be as primitive as just clicking one button and verifying a specific image appears. It can, on the other hand, use a couple of applications, perform all possible actions in it, retrieve specific outputs from the one and use it as an input in the other - scripts can be as complicated and flexible as you make them. You have all options to use parameters, loops, cases as you want, just as programming any other object oriented code. It is also possible to use VBScripts.
But... you don't have to use all these. For creating more simple scripts you can simply record (using QTP itself) a couple of actions you do on-screen, and add simple checkpoints to this recorded scripts.
How complicated? Up to you...
To better explain this idea, I will use a simple example. Let's say you want to test the log-in process to your application (based on user name and password).
Easiest and fastest way would be to record yourself entering a user name and password and then clicking a button. All you have to do now is to add some verification that you actually see something you expect to see on the screen when you are logged in.
A smarter way, however, would be to code (or record) a reuseable action (which you will be able to later use in other scripts as well). The parameters you will use in this script will retrieve a user name (or names) and a password(s) from an Excell sheet or from other applications you run, and you will be able to run as many itterations and combinations as you want using this data, and also use sophisticated verifications that will ensure your UI is really displayed as it should.
That would be a bit harder to create, but your automatic script will be much more flexible, reliable and useable.
When is it good?
Definitely not in all cases. The application tested should be in a relatively mature and stable condition. When you have a stable application that is not being changed too often and on which you have to run time-consuming or repetitive regression tests, you are very likely to benefit from using an automatic testing tool.
Automatic testing offers some important and noticeable advantages: No human mistakes, tiredness and after-lunch fatigue. The scripts can be relied on to follow exactly what they were meant and coded to do. The scripts can run whenever you schedule them to run, also during the night or weekend. It might also enable QA persons to spend much more of their time doing much more QA, instead for running tedious regression tests.
When is it bad?
Applications that are still undergoing massive development or which objects are still due to many changes are most probably a waste of time to automaticly script, as time required for maintaining the scripts or for analyzing the failures of the scripts will most probably exceed the time it would actually take to manually test the application. The scripts are also very likely to fail when the application is not properly running.
Automatic scripts do require maintenance to some extent and that requires time and effort, but that depends on the amount and scope of changes in the application itself.
Definitely for applications that are very small or easy and quick to manually test, automatic testing might be over-doing.
1, 2, 3 - Dismissed
This has only been a very short overview. Test automation is quiet a big topic, and if there is a demand for it, I would be happy to blog more (and get more of these holy points) about related and more advanced topics.
While I was mainly using examples of usage of automatic testing over EP platform, the same applies to all other products and applications you might be developing, whether it is based on SAP techonolgy or another.
