To give you some ideas in which scenarios you could use Zeta Test, the following examples contains description of usage scenarios.
You are the project manager of a software vendor company developing a content management system (CMS) called "EasyWebsite" that is also being sold through the company’s online shop.
The version of EasyWebsite currently on the market is 7.0; the version under development is 8.0.
You want to test version 8.0 and make it available to all new and existing customers afterwards.
Therefore, you have to ensure that both new customers that do not yet own version 7.0 - as well as existing customers that will update from version 7.0 to version 8.0 - will be able to successfully work with the new version 8.0.
Since you have a rather heterogeneous customer base, you will have to take differing operating systems as well as different language and regional settings into account.
Methods to achieve the task:
You create a plan
- Which target systems have to be tested?
- Which test must be performed?
- How many testing users and test managers do I need?
You can carry out these planning steps directly within Zeta Test by creating test cases and test plans. In addition, you define the required target systems and environments to test for.
After that, you let your administrator set up and configure the appropriate hardware test environment (or indeed as a virtual machine).
The testing users then carry out the tests you defined. With the integrated bug tracking database interface, the developers of EasyWebsite immediately get notified if a test fails. They can then correct the errors reported, probably after discussing the issues with the testing users.
As soon as all errors have been corrected by the developers, a new version of EasyWebsite is deployed into the test environment and all tests are carried out again
This workflow is repeated until you as the project manager decide (by looking at the reports generated by Zeta Test) that the new version of EasyWebsite is stable and mature enough to ship to your customers.
After successful completion of the tests, you have strong proof that your software will run on your clients computers successfully.
You also get a full documentation of all tests and test results. For upcoming future versions of EasyWebsite, you have a test plan basis that is easy to enhance with the new features.
After all, you have a well-tested application with a minimum of time spent: and your users will be satisfied customers.
Example: New version of an internal application to record travelling expenses on a local area network (LAN)
You are the administrator in a company with 100 employees that sells products through a network of regional sales employees.
You use an internal application "EasyDrive" within your local area network (LAN) to record and bill traveling expenses. EasyDrive currently runs in version 2.3.
Approximately 30 regional sales employees use EasyDrive to record their traveling expenses on a daily/weekly basis. An interface to your existing ERP system enables EasyDrive to pass on the data.
The vendor of EasyDrive recently shipped an update to version 3.0. Due to your current maintenance contract, your company receives the update free of charge.
You want to roll-out the update and ensure that this happens as seamlessly as possible.
Since you want to ensure that the new Version of EasyDrive runs correctly on all installed workstations, you have to create a test environment (as hardware or as virtual machines), describe test cases and perform tests.
The protocols of the tests performed will help you to decide whether EasyDrive runs as expected and can be deployed into a live business environment.
Methods to achieve the task:
You create a plan:
- Which tests have to be performed?
- Who are the testing users and who are the test managers?
You do these planning steps directly within Zeta Test by creating test cases and test plans. Since all employees use the same type of PC hardware and operating system, you define a single test environment that corresponds to the workstation PC of an employee.
After that you let your administrator set up and configure the appropriate hardware test environment (or indeed as a virtual machine).
You receive the new version 3.0 of EasyDrive from the vendor and deploy it into your test environment.
The testing users perform the tests that you defined previously. If errors occur during these tests (i.e. tests are failed), a test manager generates a report with all failed tests at the end of a test run and forwards these errors to the vendor of EasyDrive.
The vendor of EasyDrive corrects the errors, provides you with a new version that you again deploy into your test environment. After that the testing users perform all tests again.
This workflow is repeated until you as the project manager decide (by looking at the reports generated by Zeta Test) that the new version of EasyDrive can be deployed into a live business environment.
Since EasyDrive is a high-availability application, you have to perform all tests in the live production environment again, to ensure that the application behaves as expected there too. Therefore, the testing users create copies of the test plans for the test environment and perform the tests in the live environment.
If tests in the live environment fail, a rollback of the deployment is implemented and the previous version is restored. You will notice the vendor of EasyDrive and the tests will start again in the test environment.
If everything then works correctly in the live environment, the tests are finished. For revision purposes, you can generate reports of the individual test runs at any time.
Due to using Zeta Test, all functions and behaviors of the new applications were extensively tested.
You can support the go-live of the application with a smaller team then you would have done without Zeta Test because the feedback from the users will be less than ever.
Overall, your users will have high levels of satisfaction with the software.