Manual testing scenarios

1. Backup notification test

   The purpose of this test it to check whether notification mechanisms work properly.
   Input data: ,,backup database'' page
   Output: fail if expected behaviour differs

   1. Type in correctly an email address
   2. Check ,,notify me when backup is ready'' box
   3. Click ,,backup database''
   4. Check for an email
   5. Check whether backup is really ready to download

2. Restore notification test

   The purpose of this test it to check whether notification mechanisms work properly.
   

   Input: ,,restore database'' page
   Output: fail the test if expected behaviour differs

   1. Type in correctly an email address
   2. Check ,,notify me when the database is fully restored'' box
   3. Click ,,restore database''
   4. Check for an email
   5. Check whether database is really restored

3. Naughty test

   The purpose of this test is to check how the system reacts in some unlikely and pesimistic conditions:
   

   1. User deletes a database, then presses reload in the browser, which in effect sends the same delete request once again.
   2. User orders the system to dump or restore a database, then returns to the menu and restores the same database again. As a result two processes would be inserting the same data at the same time or one would be inserting the new data whereas the other would be reading the mixture of new and old data.
   3. User has got a database, let's say MS SQL. He inserts the MssqlConnector plugin to the right directory, adds the database to the configuration file and performs the dump operation. One day later a nasty admin removes this plugin. The user comes back, chooses the dump and wants to perform "restore" operation. Of course this operation cannot succeed, because there is no proper connector. The same situation takes place when user wants to create another dump from this database.
   4. User provides a wrong path to save dump files, for example ,,C:' would be wrong on a Unix server; or a user provides the name of the directory he cannot access, for example ,,/root''. Then he tries to dump a database.
   5. User sends a dump file, which is really not a dump file but for example his favourite music video (he may have click a wrong file in the open file dialog).
   6. User downloads a dump file from database #1, which is a PostgreSQL database, then tries to put it into database #2 which runs MySQL 4. No matter how hard he tries, he cannot succeed (because of problems with e.g. procedures, triggers, views...)
   7. User downloads a dump file in a binary/ZIP format, and then tries to insert it to the database as a plain text or GZIP file.