SmartTest400 modules
Software bugs are costing the world economy billions according to the National Institute of Standards and Technology (Nist).
Testing has never had the grand appeal that adorns some areas of the computer industry. However, industry experts all agree that IT companies need to implement an effective and comprehensive testing strategy to ensure key applications continue to function after general maintenance, new developments or upgrades.
It is easy to cut corners in the testing phase; most projects do. But this will inevitably lead to increased maintenance, loss of production time and even company profits.
It is estimated that 25 to 35 percent of the entire software development life cycle should be allocated to software testing. The benefits gained from automating the development and change management phases of the life cycle also apply to software testing.
Important as unit testing is, it fails to test the overall functionality of an application as a "system". Just because each functional component works as designed through the construction of its unit tests, that doesn't mean that those components, when brought together into a coherent application, will work together to meet the system's overall functional requirements.
System-wide regression and functional testing are vital phases in the deployment of any application. However, the tools to enable full system testing are either cost prohibitive or overly complex, often to the point that system-wide testing is done only cursorily or a human being is forced to test each functional area manually.
Human testing can never (and arguably should never) be completely removed from the testing process. However, improving the testing, by using automation, of key business processes (order entry - billing - distribution) can free up time to allow programmers and testers to focus on specific changes or areas that can't be automated.
SmartTest400 has been designed and developed to meet the growing need to find a more effective and automated testing strategy for System i applications, without changing the current development methodology or establishing a separate dedicated testing department.
SmartTest400 will enable companies to automate over 80 percent of their functional and regression testing. As a result this will save considerable time and money and provide a better level of service to the end users.
SmartTest400 is the route to automatic, repeatable, accurate and efficient testing. It is a superior testing strategy that, within days, will start to improve software quality and save development time.
SmartTest400 is easy to learn and easy to use, but still ensures that testing is done thoroughly every time you make a change. The sooner errors are detected, the more time you save. Even without auditors looking over your shoulder, thorough testing just makes good business sense.
SmartTest400 is made up of three modules:
1. Test Scripts: Enables the tests to be created, written, documented, executed and audited. The script manager has access to all the other modules.
2. Data Environments: Allows testing environments to be configured and files protected. During testing, checkpoints can be created that allow environments (databases) to be reset or advanced to a particular point in time, allowing test scripts to be rerun.
3. Record and Play (5250): Allows key business processes to be recorded and played back, to automate both functional and regression testing of System i applications.
Test Scripts harness the power of the other SmartTest400 modules by enabling tests to be documented, written, executed and audited. For a test to be meaningful it should be repeatable and have an expected result. SmartTest400 provides repeatability through test scripts. You can use a test script to monitor database files, replay a record and play event, check a file rule, compare a database member, check spool file output and produce a signoff report for the test manager.
Test Scripts hold the knowledge of a test enabling it to be rerun time and time again, even if the creator has moved on.
Test scripts can be created against an application (regression test) or modules (functional test). The test script is linked to a test type and a data environment. Test script documentation can be added or a link to a word document introduced.
The test script has access to all the SmartTest400 modules to enable the test to be defined, with prompt facilities to suggest appropriate test commands to use. Any record and play cases created will be stored with the test script. The test script is a collection of command macros that enable a test to be defined at a number of levels.
These include:
The test script can be executed in batch or run interactively. If run interactively, a script progress screen is available to monitor the script.
Once the test script has been run, a comprehensive set of results are available that enable the user to drill down and inspect the actual screens replayed, database transactions and spool files generated. Management and audit reports are preserved with the test script run until purged by SmartTest400.
Data Environments enable testing environments to be managed and protected ready for testing to commence. During testing, logical checkpoints are created that allow testing environments to be reset or advanced, allowing test scripts to be rerun. Once a test script has executed, the database effects can be viewed, showing the before and after image of each record that has changed; including program reference information. Additional functionality that allocates testing environments and refreshes libraries when file formats change, simplify the management of the testing environments.
Data Environment commands can also be embedded within the test scripts, so you can test the impact on the database concurrently with testing the impact on the user interface.
Testing environments can be made up of one or more data libraries. Once configured, they can be protected (journalled) so that the testing environment can be reset or advanced after a test script has run.
Each time a user requests a test, a data run is started. From that point, until the data run is closed, all the database effects will be recorded to that run instance. Any number of data runs can be active at any time in multi user testing environments.
Each time a data run is started, a new checkpoint is created if no other data runs are open. Checkpoints mark the logical testing boundaries within the database and provide pointers to rollback or advance the database. Checkpoints are used to manage and control the integrity of a multi user testing environment.
Data rules can be constructed to check specific records and fields in a database to determine if a test has passed or failed.
Record and Play automates the manual task of testing interactive processes for business analysts, developers, testing departments and users.
You can build test cases incrementally by stacking scripts that include commands, and playing them back, as a set, any time you need to test your application. You can even call Data Environment commands from Record and Play, so you can reliably reconstruct the correct starting point in the database and test the impact on the database while testing the user interface.
Captures screen images, both those sent by the host, and the data entered by the user, and stores them in a database file for later replay. The device used for capturing the images may be any device that can be attached to a System i.
Once a test script sequence has been recorded, it may be replayed in interactive or batch mode. As screens are replayed, they are compared to the original to ensure that the test is proceeding successfully. Record and Play highlights differences between the before and after screens, and the tester uses command keys to accept the difference and continue, or reject the difference and abort the test.
Areas of a screen, like date and time, may be masked to exclude them from the compare, speeding up the testing process. Field display attributes, such as reverse image and highlights may be either included or excluded in the replay screen comparison.
Since no real display devices are required, several replay tests may be run simultaneously to automate volume replay and performance testing. Replay any combination of previously recorded tests to observe the impact and interaction between different modules or applications in a controlled environment.
Another advantage of not requiring a physical device for test runs is that they may be scheduled to run after hours, leaving machine resources available to others during prime time. Also, there is no potential security risk because no devices need be left switched on or logged on.
For more information on SmartTest400, discuss your requirements or book any on-line demonstration contact sales@thenon.com or phone +44 (0)20 8607 9336.
All trademarks are the property of the respective owners. All rights acknowledged.