Skip to Content
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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Thanks for the Blog Yaniv!  The SDN QA team would be really interested in hearing from other QA Teams out there (Portal teams or not!); maybe we can share experiences and processes and trade some QA gems …
    There must be loads of QA folks out there who dip into SDN – maybe we could even think about starting up a small area on SDN which specifically addresses QA processes on technical projects such as ours?  Let us know what you think!
    (0) 
  2. Thomas Alexander Ritter
    Nice introduction to automated testing. I think the biggest drawback of automating is that you only follow one path all the time instead of being creative by using stuff like exploratory testing. I never liked using record and replay tools like eCatt for anything else than load testing and such but maybe that is just me. You might want to follow the following blog: http://blogs.msdn.com/micahel/default.aspx. It is not only about automated testing but Michael definitely knows what he is talking about.
    cheers Thomas
    (0) 
  3. Former Member
    My team is responsible for testing and QA of portal applications and would be interested in further discussions on this topic.  We use the HP QuickTest Professional and HP Load Runner software and will be using Quality Center to manage our testing efforts. 
    (0) 
  4. Robert Russell

    Hi Yaniv,

    I realise this blog is from the past and for another site SDN, but it was interesting the way your name was highlighted during my use of SAPvisi for analysing SDN points.

    Very interesting blog and I am assuming the details in the blog answers my question but here it is.

    During testing QA, I assume you have test users and setup multiple accounts all over the world with your name?

    A search for your name shows multiple entries

    http://search.sap.com/ui/scn#query=yaniv+bar&startindex=1&filter=scm_a_site%28scm_v_Site11%29&filter=scm_a_resourceType%28scm_v_resType294%29

    The reason behind the question was I did get all the SDN points together previously. And for the #SAPVISI contest and your name (*namesake) appeared as a user in Rwanda, Nambia and Libya.

    So for my entry I focused on overall countries and not on individuals as your name was top of the list ๐Ÿ˜‰ of averages. So can you confirm that your name was used in testing all over the world. My SAPVisi for the contest for SDN points can be found here.

    http://scn.sap.com/docs/DOC-33391

    Cheers

    Robert

    (0) 
    1. Yaniv Bar Post author

      oh my, sorry, just saw your question now (but hey, it’s not even a year since you posted it)… all appologies… in the past I used my name when testing SCN registration almost every day so there are some dozens of users called Yaniv Bar. Nice to know someone was using me for testing.

      happy new year

      (0) 

Leave a Reply