The “Failure-Effect-Aversion” approach is an effective way to prioritize test cases, as is described later in this guide. As part of the built-in test planning tools GATES shows the cumulative time required for 1 tester to complete the scripts by priority intervals (for which sub-totals are produced). So if you have 5 testers and you expect 6 hours keyboard-time per tester, for two weeks, time available is 5 x 6 x 10 days = 300 actual hours. The test coordinator simply selects the FEA rating (usually 1 – 125) that shows as feasible within that time limit, so that GATES presents no test scripts that are of a lesser priority (FEA rating over the limit).

Another feature of GATES is that it can keep track of information about the data you work with. For example, if you make a deposit to an account, it can actually track an account total so that you can verify that this process is performed correctly. Of course, this does not apply to all testing, but if it does there will be test steps where a window pops up that asks you for specific information in a “Data Field Content Input:” form and a description of what information is asked for within the body of the form.

When the GATES process detects previously completed test scripts it will ask if you want to repeat those tests. This is a global selection: if you repeat one test you will repeat them all (for example, if the tests failed and the software is fixed and submitted for retesting, you start over). If you simply want to continue where you left off, just say “No” to a repeat of completed tests, so that only pending tests will be performed. There is no further prompting from that point forward.

Unless you are a script writer (explained next) there is not much more you need to know about how to employ GATES as a test manager. You can have as many script worksheets as you need within a workbook that enables you to manage a full range of testing. This includes the ability to share testing across a number of testers, but under a caution that you need to split the work without corrupting the GATES software.

In this guide we emphasize that the analysis stage of QA Testing is a major contributing factor to overall cost savings. We do not just deliver a tool, we deliver a complete methodology that you can integrate with your System Development Life Cycle (SDLC) to help you manage the project risks. Project managers must realize that if you can detect bugs earlier rather than later the potential cost impact is greatly reduced. That should be common sense, yet too many projects leave QA Testing until the final stages: it makes you wonder if there is a commitment to quality in these projects.

One of the major contributions of Deming was his unrelenting emphasis of the simple fact that you cannot add the quality to a product once it comes off the assembly line. As demonstrated by the Japanese (who took Deming to heart), you have to address the workflows that create problems and then fix these problems at the source. Software development is no continuous process like manufacturing: what we have accomplished with methodology is error detection as close to the source of the problem as possible, simply by growing the testing collateral in line with developing a better understanding of the application system we are trying to create.

By preventing these errors from being propagated until they are detected at the end of the SDLC we prevent the rework and afterthought programming that compromises the reliability of business applications. GATES addresses the risks inherent in new software development so that you have a better picture of where you stand with respect to your chances for delivering the ultimate product. It takes methodology to make things work, and to get the most out of the testing effort, which is what we documented first. By understanding the uses of the data you will be producing it makes more sense determine why we produce these data, and if there are alternatives to achieve even better results.

The role of GATES is to supplement a formal test script repository, such as HP Quality Center™. As we compare how GATES is used with a formal repository (the similarities and differences) that reflect limits of a simpler solution we note that GATES is very cheap by comparison to tools like HP Quality Center™, and that we use a paradigm of simply creating a new set of scripts when required rather than to manage existing scripts.

The term “Test script” is commonly used to refer to a test procedure specification, especially an automated one. In GATES we see this as a “template” for a series of related tests that reflect different test cases, explained below. In manual testing, that reflects a set of instructions on how to perform one or more test cases. In GATES we extend this definition of a script as a common definition for a series of tests, while in automated testing a script generally refers to the corresponding logic that enables machine-executable instructions. A test script then strings multiple tests together to run in one sequence either manually or in an automated fashion.

A “Test Case” means a set of input values, execution pre-conditions, expected results, and execution post-conditions: these are developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. These steps can be stored in a word processor document, spreadsheet or database, or in GATES we incorporate test cases as part of the script generation collateral. The test description field can be used to provide additional information about what the test case purpose is. If the description refers to a test set, it can be used to describe what the test set purpose is. The test description field must be completed for all test cases, giving as much information about the test case as possible.

To avoid confusion in terminology, in GATES a test step description column contains an explicit description of action/information required for the tester to execute that particular test step. You see a description of what should be expected after a test step is completed. This is in the column beside test step description so that for a multi-step script the matching inputs and results are shown side-by-side. It does not matter much to the tester: he/she sees these two descriptions in one window, but it is important that the action and result information appear properly matched. Specific work instructions and actions a tester must perform to execute the test case must be complete, clear and measurable.

The tester is the person who is officially assigned to execute the test case. This name can be populated prior to executing the test during scheduling but is automatically over-written by GATES with whoever last amended the test (or the name of a tester if an additional instance is created). If additional testers are used to execute certain test steps within the test case, the additional tester’s name must be documented in the actual test step results field. The reason for this is that developers need to know where to get clarification of test feedback.

The role field is another one of those definitions that raise heckles, before people get a clear understanding of the intent. The role might reflect the specific job-role of the tester who executes the test case (e.g. a clerk, an analyst or a buyer) in a User Acceptance Test context. The role should be interpreted as the tester paradigm that is reflected in the script. Any tester is a user-defined field used primarily for test searching purposes. The role setup and environment for testing might align to the security role for the component being tested so that the different job-roles’ security authorization can be tested as well.

The task of developing Test Scripts is made easier with GATES and if we keep the compatibility requirements in mind we can even use the same scripts for archiving in a test repository. There is architecture behind scripts to efficiently manage the work done by testers. Although the testers are not directly controlled, they are also not tied to a server that restricts who can access what tests. GATES runs on any PC that uses MS-Excel™: that is pretty well any PC, anywhere in the world where there is E-mail access.

The architecture for GATES actually lends itself to support test script automation. Not just for generating scripts to be executed manually, but to use that same innate capability to transform basic automation scripts into executable automation modules. We used an analogy of scripts operating as movie reels where steps in test execution act the way still images in a movie contribute to the illusion of live movement. Many testers prefer high-level test cases because of the challenge to maintain scripts that use current data in detail steps: GATES has tools to eliminate that difficulty and to generate detailed scripts as required (including the latest test data). You can establish takes one scene after another, or you can pay attention to the details captured in each frame of film.

Automation operates like that: it captures each keystroke or mouse movement to replicate tester action in finite detail. We don’t have to go that far: automation is initially limited to entering keystrokes to assist the tester, as opposed to replacing the tester. The goal of a high level script is to define scenes: test cases that define what a tester is expected to do as a complete bundle of work. The goal of automated scripts is to define how the scenes unfold one frame at a time. Each frame is equivalent to a step that defines one small part of the total scene that represents a complete bundle of work, a level of detail some people equate with test automation.

You cannot run test automation directly from within GATES, but with detailed test scripts for a step by step execution you can capture tester actions: just be sure that the tester performs a predictable, repeatable process. After you capture the actions (or collect operation definition – or OPDEF – macros) you can generalize these captured operations so that in playback you can perform all kinds of variations. We do not cover this capability until the end of this course, because it adds much complexity that simply confuses people if we are not careful. We use a 3rd-party scripting tool, just as we use a 3rd-party screen capture tool to collect evidence. You can actually use whatever tool you prefer so long as we have the ability to invoke the script execution tool from the GATES Excel™-VBA environment.

A caveat is that uploading these scripts that include test automation options can seem confusing for HP Quality Center. That is why we embed the automation just like manual script steps, but clearly marked as “AUTOMATE” instead of the test step number. There is no reference to the detailed script code, just to the high-level routine(s) that should be invoked to make that script work. So why do we bring this up when the details are yet to follow? Because you need to understand the rationale for creating a versatile process that is extensible if everyone follows the rules. That includes a more detailed breakdown of test scripts so that it is possible to evolve into test automation.

Script generation is part of the PERFORM processing included in GATES. This makes the life of a QA Testing Analyst much more enjoyable because we separate out the data from the script. We use a framework to explain how the process is triggered and executed, and what you can change to affect the outcome. For each script worksheet we plan to produce we need to declare an OUTPUT SCRIPT command as shown below. This output takes the column-assignments (declared above) and adds column titles as illustrated in the screen image below. You can have multiple script output sessions within a single PERFORM SCRIPT block.

GATES is a “table-driven” test engine that needs to be told where to look to find the appropriate data for script generation. Note that the actual data will likely be in some external source and imported into the named worksheet, so make sure it is formatted as required to work with the script template. The DATA command includes several specific parameters that will be explained in more detail in the training materials. The data table itself is just like any other worksheet, where GATES “walks” the data until it finds 50 consecutive blank rows (where there is no information for the match column). If there is content but there is no match the logic searches for matching content between the data and the defined script formats. There is no content validation on contributing data values, although we have a trick up our sleeve to make sure we don’t generate script rows that cannot be executed. You can even refer to an external library (another Excel workbook) to share common data, as in a SharePoint repository.

There are two ways in which we can employ dynamic script content. Ideally we use the data from an external source to drive the script generation, so that the necessary values are compiled right into the script. This is the matching process described already. This does not always work for data that evolve during script execution: you do not want to ask the tester to continually write things down and then to refer back to it, because that will cause extra work. In manual scripts we often ask testers to write down any intermediate data values for future reference, but that can become an onerous task. By contrast, if you use the GATES script execution engine and prompt testers step by step you can intercept this tracking process and make it “pseudo-automatic”.

We regard this kind of automation as more useful than the use of a testing robot, because you don’t have the dependency on a perfectly complete GUI (Graphical User Interface) before you can interact properly with the application under test. The complexity of interacting with an application to navigate to where you need to be is potentially significant: with GATES we let the tester take care of navigation and we assist with the typing if required. One of the issues in testing is always to confirm the correct result from entering a into an input form. With this dynamic script content we are now one step removed from permitting a highly powerful calculation option to be included in the process.

Incorporating calculations or other Excel™ formulas do not make the scripts simpler, but you do not have to use all the options available to benefit from what GATES has to offer. We realize the tendency for test organizations to want to enter scripts into repositories with a paradigm of static information. We recommend you archive the completed scripts as static information for reference, but retain dynamic content within GATES to be responsive to changes in the live data that you will inevitably be affected by. As you gain proficiency in dynamic script architecture the abilities of what the tool has to offer will eclipse those of many tools that are ridiculously expensive compared to what they offer in return.

Learning Formats       PMAP_GAT

This course is currently available in a classroom setting (public or company private) with approximately 30 contact hours (5 days).

PDF – Certificate Of Completion

Each course offers a certificate of completion that identifies the course, the student, and a brief description of the course. To receive a certificate the student must have attended at least 80% of the course sessions. This personalized certificate is forwarded to the student by Email.

PDF – Course Notebook

Each course includes a notebook in PDF format that provides the minimum knowledge the student must master in order to obtain the certificate. In the notebook you will find references to other study materials. Students receive the notebook by Email when their registration is confirmed.

PDF – Program Overview

An overview of this study program can be downloaded from the website by right-clicking on the program link on the enquiry page.

PDF – Current Training Schedule

A list of upcoming training sessions can be downloaded from the website by right-clicking on the schedule link on the enquiry page.

Registration – Service Providers

To register for any training course please look on the enquiry link page of your service provider (from where you accessed this website). On the page you will find a registration request form where you can order the course that you are interested in. The availability dates will be provided to you, along with payment instructions if you decide to go ahead.