The testing you carry out using the previous techniques will inevitably lead to observations, such as:
Functional testing has shown that the recipient address is not correctly copied into the new message when replying to an existing message.
Load testing has shown that the system does not respond in a sufficiently timely manner to requests made at 530 simultaneous sessions.
Usability testing has shown that people expect the Previous and Next buttons in the Mailbox view to be at the top of the page, not the bottom.
These observations are relatively useless without the tabulation of corresponding action points. For the issues outlined previously, you may raise action points as follows:
Please ensure that the recipient, when replying to a message, is automatically set to be the sender of the message being replied to.
When 530 sessions are active, divert users to a "service unavailable'' page explaining that the server is not able to process their request at this time.
Move the Previous and Next buttons in the Mailbox view to the top of the page.
These actions are all simple enough. But on a larger project, you may have hundreds, even thousands of action points: bugs that need fixing and tweaks for fine tuning. How do you keep track?
In the last part of this chapter, you'll encounter a fault management system known as Mantis, a freely available package currently available from http://mantisbt.sourceforge.net.
The purpose of Mantis is to allow you to effectively keep tabs on all faults and defects in your projects, assign them to developers for resolution, and allow developers to pass comment on them where appropriate.
Mantis is a Web-based application written in PHP (what else?) that would typically function as an extranet. Whether you choose to open it up for access to your clients is entirely up to you. When working with smaller clients this can often be beneficial because it allows them to feel part of the QA process. Mantis supports multiple users, each with his or her own access levels and rights, so you can offer different access to yourself and, say, your developers.
Many other fault management systems exist, of course. We have chosen to look at Mantis specifically because it is freely available, easy to use, and written in PHP. This means that you could, in theory, modify and extend it to better suit your needs if so required.
Download the Mantis installation archive from its Web site and unpack it in the usual manner:
# tar -xzvf mantis-0.18.2.tar.gz
This will create a directory called mantis-0.18.2 containing all the source and configuration files for Mantis. You should have a Virtual Host in Apache's httpd.conf configuration file pointing to this location as follows:
<VirtualHost 192.168.168.2> ServerAdmin email@example.com ServerName mantis.example.com CustomLog /home/ed/logfile_mantis common ErrorLog /home/ed/errlog_mantis DocumentRoot /home/ed/public_html/mantis-0.18.2 </VirtualHost>
If you are using some Web server other than Apache, you should set up a virtual server to support Mantis in the manner in which you are accustomed.
Mantis is dependent on MySQL, so you need to have this installed to be able to go any further. We have thus far in this book advocated almost exclusively the use of PostgreSQL in preference to MySQL, but as Mantis is an off-the-shelf product we don't have a lot of choice. If you feel strongly, Mantis is rather well written in that it uses a database abstraction layer of sorts, found as core/database_api.php in the installation. You could, in theory, adapt it to function with PostgreSQL instead.
Assuming that you have better things to do with your time, Mantis includes a wizard to get MySQL set up with the necessary database tables for you automatically. Simply create a database called Mantis, and pipe sql/db_generate.sql into that database as follows:
# /usr/local/mysql/bin/mysqladmin -uroot -p<your root password> create mantis # /usr/local/mysql/bin/mysql -uroot -p<your root password> mantis < sql/db_generate.sql
If your MySQL server is not running on the same server as your Web server, you will of course need to include the -h directive, for example:
# /usr/local/mysql/bin/mysqladmin -hservername -uroot -p<your root password> create mantis # /usr/local/mysql/bin/mysql -hservername -uroot -p<your root password> mantis < sql/db_generate.sql
This will create a blank database. All future database changes can be done using Mantis itself.
All that remains now is to tell Mantis where to find the database. Copy the file config_inc.php.sample to config_inc.php in the installation directory; then open it in your text editor of choice.
There is a huge number of options for you to adjust, but the most important of them are the name and location of your database. Amend the lines in question so that they match your setup:
# set these values to match your setup $g_hostname = "db"; $g_port = 3306; # 3306 is default $g_db_username = "root"; $g_db_password = "myrootpassword"; $g_database_name = "mantis";
Note that in the previous example we are using root as the user to connect to MySQL. This is probably a bad idea on a production system, and you may want to use mysqladmin to create a less privileged user with access only to your Mantis database, and specify this as the connecting user in your configuration.
You are now ready to log in to Mantis for the first time.
Fire up your Web browser and point it at the virtual host you created earlier. You should see a login screen similar to Figure 23-1.
Now, log in as administrator. By default, the password has been set in the MySQL database generation script to be root.
After you've logged in, you should first lock down your Mantis installation. The best way to do this is to create another account, not named administrator, and with a more secure password that you can use for day-to-day administration. This is particularly important if you are able to access your Mantis installation over the public Internet.
Everybody who will have access to Mantis that is, yourself, your development team, and maybe your client's representatives will require a user account.
To create an account, click the manage link when logged in as an administrator. Manage users is selected by default, and accordingly you will see a list of user accounts on the system. Creating a new account is as simple as clicking Create New Account. Don't forget to set the access level to an appropriate level; anyone whose only task is to report bugs or defects need be only a reporter, whereas you want your own account to be administrator.
After you have created all necessary user accounts (including at least one with administrative privileges), you can completely remove the administrator account.
After you have created a user, you can modify even more properties of that user's account by clicking his or her username. Figure 23-2 shows a typical user editing session in Mantis.
Crucially, you can use the Edit User screen not only to edit the user's details but also to add that user to a project. By default, a user does not have access to any projects, which means that even if he or she has a reporter status, that user can't report any bugs.
To add the user you are editing to a project, select the project in question (if this is your first time using Mantis, you won't have any yet) and click Add. If a project is marked as public, you can skip this step because all users will have access. This is very rarely desirable, especially if you have clients using the system.
It is worth pointing out that when creating an account your new users will automatically be sent an e-mail containing their username and password, and the URL for accessing this installation of Mantis. If this behavior is not desirable, you can disable it in the Mantis configuration file you were editing a few moments ago.
There is no limit to the number of projects that Mantis can support.
To create a new project, select Manage Projects. A similar view to that shown in Manage Users will be shown, with all current projects displayed on-screen. To create a new project, click Create New Project.
Initially, you will be asked to specify a project name, status (which is an arbitrary flag for your own reference), view status (which should be set to private for the reasons discussed previously), description, and an upload file path. The upload file path is the place where any binary files (such as screenshots of the bugs being replicated) attached to bugs lodged in the system will be stored. This must be writable by the Web server, which you may need to effect by manually changing the permissions of that particular folder on your server.
After you have created a new project, you can edit its finer details by clicking its name. The most important detail you will want to set is the categories for the project. Each defect entered into the system can be placed in a category, and you will want to define as many as you see fit. Figure 23-3 shows a typical project being managed in this way, with bug categories being added to make the project ready to use.
You may want to have categories similar to the following:
Design and Appearance
Functionality: Business Logic
Functionality: Desirable (out of scope and chargeable)
Functionality: Missing (but detailed in specification)
Functionality: User Interface
Project Management and Administration
Systems and Infrastructure
After you have created a set of categories, you can easily reuse these on future projects by using the Copy From and Copy To buttons judiciously.
With your project set up, you may need to select it whenever you log into Mantis in future, especially if you have more than one project on the system. The small drop-down list box in the top-right corner of the screen allows you to flip among projects by name.
Now that you have the project set up, you and your team can start entering bugs. Don't forget to translate the faults you have found into more specific tasks rather than simply announce the problem. For example, "Move the pagination bar from the bottom to the top of the page'' is more productive than "The pagination bar is in the wrong place.''
To report a bug, simply select Report Bug from the main navigation.
You will need to select a category for the bug; this list will be generated dynamically from the selection of categories you entered earlier.
Other information you need to enter includes:
Reproducibility if this is a fault rather than a simple request, state how frequently the problem can be reproduced. If a request for a new feature, select N/A because there is nothing to reproduce!
Severity this list is hard-coded into Mantis and relates to the impact the fault is having on the project. Most of these are self-explanatory. Feature refers to a fault at feature-level and implies that a key feature is either missing or rendered completely unusable by the fault. Block means that other testing is being held up as a result of this fault!
Priority the priority with which the fault must be attended to by the development team.
Summary a brief one-line summary of the fault or, if insufficient space, the area in which the fault is developing, for example, "Auto-completion of text fields when replying to e-mails.''
Description further detail on the fault.
Additional Information any additional points that may aid the developers in resolving the problem.
Upload file if you wish to associate a binary file with this fault (for example, a screenshot showing the fault in action) you can upload it here. It will be stored in your server in the location you specified when you set up the project.
Report Stay if you check this box, you will be taken back to the report new bug screen when the bug is successfully entered. This allows you to batch-enter bugs more easily.
After you have entered a bug, you will be able to view it under View Bugs from the main navigation menu. One key point worth noting is that the bug is not yet assigned to anyone. This is the next step!
After bugs have been entered into the system, you will doubtless want to use your own Mantis login to assign their resolution to one of your development team.
Select the bug by its number from the list shown under View Bugs and you will see a drop-down list of users next to the button named Assign To. Select the user to whom you wish to assign the bug (which can be yourself) and click the button.
The user lucky enough to be given the task of resolving this bug will be sent an e-mail with a direct link to the bug.
You can also bulk-assign bugs from the View Bugs screen. This can be useful if you are working on a small project and you want to assign all open bugs to a given user. Place a check mark next to the bugs you want to assign, select Assign in the drop-down list box at the bottom of the list, and click Go. You will be invited to select a user, and the checked bugs will then be assigned to that user in the same way.
Your developers may want to take issue with a bug you have raised or, alternatively, add their questions or comments.
They may do this by viewing the bug, entering text in the relevant text box, and clicking Add Bugnote. The comment will be recorded against the bug, and a copy is sent to the person who raised the bug in the first place. The bug raiser may then want to add their own comments (in reply if necessary), which will in turn be sent to the developer, and so on.
A developer may also want to make use of the resolution status of the bug to indicate his or her progress on the task at hand, or reaction to the bug overall. This includes such flags as "not a bug,'' "won't fix,'' "fixed,'' and so forth. Any changes in status also generate notification e-mails to the bug raiser.
After a developer has fixed a bug, he or she simply marks it as resolved by clicking the Resolved button. This changes both the resolution status and the overall status of the bug to "resolved,'' firing e-mails to the bug raiser in the process.
If the project administrator agrees that the bug is resolved, he or she may set its overall status to "closed.'' If he or she disagrees that it is resolved, it can be set back to be assigned and the resolution status is set to "reopened.'' Again, the developer will be notified that the bug has been reopened.
Both status flags are of particular use in the View Bugs view, in which filters may be applied to see only bugs of specific statuses. Color coding is used to indicate the status of bugs at a glance.
Despite being quite straightforward to get started with, Mantis is a hugely powerful package that requires and deserves in-depth attention.
There is not the space here to touch on all its power, but the Mantis Web site at http://mantisbt.sourceforge.net features in-depth instructions, including a useful FAQ.