The manual test cases are here to help us test ArgoUML in order to cover things that are not testable with the JUnit test cases. Since it is a little bit more cumbersome to run them, a tester must read the test cases, understand what he is supposed to do, do it, and document the result, we try to go as far as possible with the JUnit test cases and have as few manual test cases as possible. I.e. If one of these tests can be converted into a JUnit test case we shall try to do so because it can save us a lot of time. On the other hand, there are several things that cannot possibly be tested with JUnit tests, so there probably are a lot of Manual Test Cases to be written.
Anyone can run the manual tests on any version of ArgoUML. If it doesn't work, i.e. the expected result is not seen, then this is a defect in that version of ArgoUML and should be reported using Issuezilla.
At every release, the ambition is to run through all manual tests. Initially, when the amount of manual tests is small, this is done by the release responsible while testing the newly compiled release. Later on, when the amount of manual tests makes it unpractical to this during the release work, the work can be done by anyone, or any group of people within the project, after a development release is made and before a stable release is made. A signed statement with list of run tests including version number, a list (hopefully empty) of failed tests together with their Issuezilla DEFECT number, the host type, OS, JDK version, ArgoUML version, ... shall be mailed to the dev list when these tests are completed.
Adding a new manual test to the group of already existing manual tests or improving one of the existing tests helps the project forward. Remember that the first priority is to test things with the JUnit tests because they can be, to some extent, run automatically and have their result reported automatically but then manual tests are the next big improvement.
Every test has several attributes to make sure that we can identify the test and help the developers and testers.
A name
This name is the title of the subsection where the test is described.
A number
These start with TEST1 and are allocated in sequence and maintained manually in this document (TEST2, TEST3, TEST4, ...). They are never reused when made available by removing a test case.
A revision
Every test case has a revision. These start with REVa and are increased with one every time the test case is changed.
A list of requirements tested
This list is references to the requirements as stated in Chapter 3, ArgoUML requirements.
Preparations i.e. what to do before the test
This is Optional. The default is that you have just started ArgoUML.
A description on what to do an what to expect
This is a description in plain English telling the tester exactly what to do and what to expect. If this description doesn't work or is ambiguous in any way the tester should consider the test to be DEFECT and report it in Issuezilla.
This is probably best written like this:
Do: whatever
Expected output: whatever
Do: whatever
Expected output: whatever
This section contains all the tests each in a subsection of its own.
TEST1 REVa (Does not test any current requirements.)
Preparations: Download and install ArgoUML together with the modules.
Do: Start in a window that allows you to see the output on Stdout.
Expected output:
Loaded Module: Java from classes Loaded Module: GeneratorCpp Loaded Module: GeneratorCSharp Loaded Module: GeneratorPHP
Do: Press F7 (or select menu Generation => Generate All Classes...)
Expected output: A window pops up with Class Name, Java, Cpp, CSharp, and PHP.
Do: Select menu File => Import sources, then open the drop-down box Select language for import: to the far right.
Expected output: The drop-down box contains Java and Java from classes.
TEST2 REVa (Requirements tested: Section 3.2.1, “ ArgoUML shall be a correct implementation of the UML 1.3 model. ” and Section 3.2.2, “ ArgoUML shall implement everything in the UML 1.3 model. ”)
Do: Select the Class Diagram. Click the Package symbol on the Edit pane tool-bar. Click on the diagram. Click the Class symbol on the Edit pane tool-bar. Click on the diagram. Click the Interface symbol on the Edit pane tool-bar. Click on the diagram.
Expected output: The Class diagram and the explorer now contains one package, one class, and one interface.
Do: Select the class. Drag from the four quick-buttons located along the sides of the class and release somewhere on the diagram. Click on the fifth quick-button (bottom-left of the class). Select the interface. Drag from the quick-button located along the bottom of the interface symbol and release somewhere on the diagram.
Expected output: When releases on the diagram a new class is created both on the diagram, where released and in the explorer. The type of the association corresponds with the quick-button type. The association created when clicking the fifth quick-button goes back to the class itself.