Icy: Defect Tracking & Test Case Management
Performance Optimizations vs. Scalability: In the early days of development, we had a single and small SQL Server machine that also hosted the IIS server. CPU processing was expensive. We also only had a team of about 25 people to serve with a long term potential for maybe 100. Because of these factors, and because most development groups are under 150 people in size, the architecture derived from those days has been retained. To make the most of the SQL Server, many variables are loaded up into the IIS session object when a user logs in. This is why we must log the user out after N minutes to avoid runaway memory consumption. Memory becomes an issue if everyone logs in at the same time. However, it also means that after an initial ten or fifteen SQL queries, most page views can be served with a single SQL query. This is one of several reasons why ICY appears to be quite fast.
Scalability is not a Concern as long as your dev and test teams are under 150 people and don't plan on having more than a few hundred thousand bugs across your many projects. We've seen some deployments with several million test case regressions without suffering performance impacts. Furthermore, there is no reason to believe ICY cannot scale beyond that. Indexes are built into the schema along with the relational integrity.
Multi-User Concurrency issues arose when we passed 20 concurrent users. A complete review of the transactional nature of the stored procedures occurred along with proper error handling for future cases. The revised system is fully multi-user capable, with the only confusion being that two entries on an issue might be made concurrently without the authors being aware of the other's comments or intentions. In such a race condition, both comments will survive.
Email Support is provided in a very limited fashion. In past implementations, and in other products, email tends to draw discussion out of the tracker and into the email system. This meant that decisions and research is forever separated from the issues they are about. We also found that many users would ignore the email, processing it with a rule off to some folder for deletion. For these reasons, email support is limited to notification that "an issue needs your attention" along with a URL to that issue. We also attempt to only notify the user to which the issue is assigned, or the user that originally entered the issue. For brevity, if that happens to be the same person that edits the issue, then no email will be sent.
Bug Classifications include the typical title and description as well as a severity and separate priority value. You can also attribute bugs to particular components and identify which build it was discovered in.
Search Results are displayed in pages. Click Prev(ious), Next or a number to page through the results. We'll remember what page you were on in case you want to go into a bug/case and come back later.
Session object variables are used to track your session variables (current query, project, milestone, builds, etc.). After N minutes of inactivity, you need to re-auth to restore these variables. The default timeout is fifteen minutes, see your IIS sysadmin if this value needs to be increased. We try to make the re-auth process as painless as possible, in many cases you may not even notice it. Let us know if you have suggestions to improve it further.
HTML Tag Support in bug comments is very limited. At present, we support the use of <br> (but just use carriage returns, we'll take care of it), <code>, <pre> and tabs (chr(9)) are replaced with non-breaking spaces, which doesn't look so good unless it's wrapped in a <code> tag. Anyway, if you need additional ones, let us know. This has not yet become a customizable feature.
Password security is provided through JavaScript using the RSA Data Security, Inc. MD5 Message-Digest Algorithm and encrypted by the client prior to transmission. This is fairly secure as it prevents the admin(s) from easily determining user passwords, but does not protect against replay hacks. Since this is typically deployed over a LAN, additional security has not been given a priority. If you need more security than this for your issue tracking system, we suggest using SSL.
Graphic Reports are available through the use of MRTG. Default reports include "open vs. regressable bugs" and "passing vs. total test cases." All may be queried by MRTG on a per project basis.
