Wednesday, August 24, 2011

ECF Conference at SAP LAbs

    “Engineering Cross Functions” Days (ECF Days). Wow!!! The very title of the conference to be held at SAP Labs was mind boggling to me. Well, when I was given the opportunity to represent my company at the conference, I grabbed it with both hands. The conference was to be held on 2 days, the 17th and 18th of August 2011 and we were scheduled to be there on the 18th of August. The broad objectives of the ECF Days was for SAP to understand how their customers test the SAP Products and for customers to understand how SAP tests their products internally and also provide a platform for both SAP and their customers to share the best practices of testing SAP products.
    The ECF Day began with the welcome and introduction of us customers at SAP Labs. Apart from MindTree, the other customers who had been invited were – Vodafone, TVS, HUL, Infosys, GMR Holdings and ABB. The IT - head of Vodafone shared some of the best practices in Testing followed in Vodafone, it was great to see that at Vodafone they followed a pretty robust methodology of testing using one the best automation tools available in the market for SAP Testing – SAP TAO (Test Acceleration and Optimization). It was also very interesting for us to note that Vodafone also used the Business Process Change Analyzer (BPCA) to track all the changes that were made on the SAP systems, monitor those changes and modify your automated test scripts to take these changes in to account during execution.
    This was followed by presentations by the other clients of SAP in their respective pods. We had a slot for two hours, where we could share our best practices with the testing folks at SAP Labs. We spoke to them about how we use Mind Mapping techniques to document myriad information like test environment, functionalities, test steps, questions, bugs, etc… which is especially useful when testing in an agile environment. We also talked about how we use ‘SAP GUI Scripting’ to automate some parts of the test which are repeated over and over again. The response from the folks at SAP Labs was terrific and enthused us to deliver the sessions again and again to packed audiences.
    Post lunch, we had sessions by the testing folks at SAP Labs where we got to see demos of a lot of cool stuff that the folks there were using to test SAP Products. There was a demo on SAP TAO and having worked on TAO, I must say it is one of the coolest tools to work on and the way it seamlessly integrates with HP Quality Center and SAP Solution Manager is fantastic. There was also a session on ‘Model Based Exploratory Testing’, a new tool that makes it possible for users to create, modify and execute test scripts on the fly and I should admit that I can’t wait to get my hands on the tool and start using it. There were also sessions in the ‘Extended Computer Aided Test Tool’ (eCATT) and how it can be integrated with HP Quick Test Professional. Another really cool session was where we were shown how we can do performance testing on SAP ECC using ‘Transaction Codes’ (TCodes) like ST05, ST30, ST33, STAD, SE30, etc… which are already inbuilt in the SAP ECC system.
    Well, in total I must say that this was one awesome conference where I got to learn a lot of really cool stuff on the topic of testing SAP Products and hopefully people could also learn something from me. At the close of the conference, we met with the Senior Management in SAP Labs who briefed us of their plans to have more such testing events in the future and collaborate a lot more in the SAP Testing space and also give us access to their new products and tools. Well, hopefully this initiative comes through and we get to work on the cutting edge technology that is being developed at SAP Labs very soon. Until then, there is a lot of research and learning that I need to be doing in the SAP Testing space from what I learned from the conference at SAP Labs.

Friday, August 12, 2011

SAP Automation Tool for Free...

It was a regular Thursday afternoon. I had finished my hot cup of milk and making plans for the weekend. My friends were proposing that we catch up early on Friday evening and go for a movie followed by dinner and then crash at one of our houses. I was making grandiose plans which began with me leaving office at 4 PM when out of the blue I got a call from a Senior Manager of one of the key accounts asking me if I could help out her team in testing their SAP Application because a few members of her team had called in sick today and would not be available the next day as well. I cringed initially because if I said YES it meant I would not be able to leave early but on the other hand if I said NO, it would mean that I miss out on the chance to work on a really cool SAP Application on a module which I am fascinated by.
                Well! There I was on Friday morning bright and chirpy; rubbing my hands in delight at the thought of dueling with my fascinating SAP Application. (Hey don’t get me wrong here; I had taken sufficient pains to ensure that I rescheduled my weekend plans with friends so I could have the best of both worlds). Murali, the Test Lead arrived and after the usual Howdy’s exchanged, we got down to business. So Murali, I asked what is in store for me? Give me some really challenging, exciting test cases to execute. Murali allocated four test cases and said try finishing these by end of day. Well four test cases are not really that much right and I took a quick glance at how many steps each of the test cases comprised of. On average, each test case had about 15 steps so I rejoiced thinking that I could still manage to get off early as planned initially but then I asked Murali are you sure that’s it? I could do more you know. Murali gave me a wicked smile (I would soon know the reason for it) and said you execute these first and then let’s see.
                I logged in to Quality Center and got down to the business of executing the test cases (at the back of my head, I thought hey here’s a chance for me to impress all and sundry with the speed at which I can execute test cases and find defects) . The first few steps went on smoothly and eventually I came to the monster step. Monster because here was a step, where I had to copy and paste values from an excel sheet to the SAP application for 150 rows. Sounds pretty simple so far doesn’t it? But here’s the catch, I could copy and paste only about 7 rows at a time because the limitation was that I could paste in to the table in the SAP application values only for as many rows as that were visible in the SAP table. Now that’s not the end of it, these values had to be pasted column wise because the excel sheet did not account for all the columns that were present in the SAP table and just copying and pasting from excel on to the SAP table, would lead to values being pasted in random columns which were incorrect.
                The reason for Murali’s wicked smile suddenly dawned on him and after going through the painful process of copying and pasting 7 rows at a time for about 8 columns I was completely exhausted and bored and clawed my way to Murali’s desk asking if there was a better way that he knew of in which this could be achieved. Automation was the only option that we could think of to perform this incredibly boring task. But for automation, we would need QTP and if we need QTP, we need money and loads of it which was not budgeted for in the project. So I then resigned myself to the task of completing the other test cases which were quite similar to the first one and somehow managed to survive the hazards of copying and pasting values an infinite number of times. I was relieved by the time I completed the execution of all four test cases and thanked God that it was a Friday and left office.
                Monday morning, I narrated my horror story to my team mates (which they seemed to enjoy by the way) and vowed to find a better way to accomplish this incredibly boring task. I Googled a bit, spoke to a couple of my team mates and we hit upon the idea of using “SAP GUI Scripting” to perform these kind of repetitive tasks. It was free, easy to use, and available on all SAP GUI applications and needed very little grey matter to get started on using it. I immediately got down to trying it out on one of the SAP GUI applications that I had access to and voila it was a breeze to use it. The test case that I took 2 hours to execute earlier was now easily executed in less than 10 minutes with “SAP GUI Scripting” and the use of some simple excel macros.
                Now, that was my moment of truth. All it required was just a little bit of googling, a little bit of perseverance and a desire to make things easier for the lazy me.
                Some basics of using SAP GUI Scripting –
·         Log in to SAP GUI
·         Click on the ‘Customize Layout Button’ and select the ‘Script Recording and Playback’ option
·         The ‘Record and Playback’ widget will be displayed
·         Click on the ‘Record Script’ button
·         Perform the process that needs to be automated and after recording, click on the ‘Stop Recording’ button
·         Click on the ‘More’ button and ‘Save’ the file in desired location (the file will be saved in “.vbs” format)
·         To run the recorded script, click on the ‘Playback Script’ button
Note – in some of the SAP Servers, the value of ‘sapgui/user_scripting’ parameter may not be set to TRUE. To enable scripting on the server, navigate to the ‘RZ11’ transaction, enter the ‘Param. Name’ as – “sapgui/user_scripting”.

Click on ‘Display’ button and change the ‘Current Value’ field to “TRUE” and click on ‘Save’

Friday, August 5, 2011

How to trick your Manager in to believing that you have executed all possible test cases

To all testing folks out there, just ask yourselves - How many times have you been in a situation where you could confidently tell your manager / client that you have executed all possible test cases and these are the bugs that were reported and after the bugs were fixed, you verified the bugs and retested the application and completed the rest of your testing activities and claimed that we have achieved 100% Test Coverage?
                But how many of us were actually telling the truth? To illustrate let me give you an example of a standard SAP screen for say “VA01 - Create Sales Order”. 
Assume that you are entering data in four fields present on the screen – Order Type, Sales Organization, Distribution Channel and Division. Now assume that each of the fields – Sales Organization, Distribution Channel and Division have 3 possible values for input data. So to achieve 100% Test Coverage, the tester has to test for 3 * 3 *3 = 27 possible input data combinations. Practically this may be sound, but imagine a situation where there are 6 possible values for input data. In such a scenario, there would be 6 * 6 *6 = 216 possible input data combinations. It may not really be a practical idea to execute the same test case over and over again for 216 iterations.
                To solve problems like this, we can use techniques like “Pairwise Testing” which is a combinatorial testing method. According to Wikipedia, this technique is based on the premise that “the simplest bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing”.
                Using tools like PICT (Pairwise Independent Combinatorial Testing) by Microsoft, Jenny, Hexawise, etc… testers can automate the process of arriving at the input pairs for testing where they are essentially accomplishing “Test Data Automation”. Another feature that these tools provide is – they give the option to testers to define some “input variables” which cannot be paired together and also assign priority to some “input variables” which are deemed to be critical by the tester. Features like this, can also help in cases where testers specifically want to do some negative testing by using some invalid pairs as inputs. The tools also provide an option of combining 3 or more input parameters thereby increasing the number of iterations to be executed.
                So there you have it folks a simple, guilt free, scientific way to trick your manager in to believing that you have executed all possible test cases by using “Test Data Automation” for your input values. Of course, one has to remember that 'Testing is Sapling at its best' and remember not to abuse the technique of using 'Pairwise'.
             
            If you are interested in using the “Pairwise Testing” technique, you can download the PICT tool by Microsoft –