Why Did We Change How Folders Work? | Inflectra

Why Did We Change How Folders Work?

We are really excited with the launch of SpiraTeam 5.0 this week. SpiraTeam 5 brings a lot of new features, new design, and also lots of changes from version 4.2. Over the next few weeks we will be posting a number of articles to explain the biggest changes. This post discusses how folders for test cases, test sets, documents and tasks have been reworked for a more consistent and better customer experience.

Test Case/Set Folders in Version 4.2

Since SpiraTest 1.0 (back in 2007) test case folders were essentially considered a special type of test case. Consequently, a test case folder looked and behaved in a very similar way to a test case. It could have owners, comments, custom properties, and a history of changes made to it. In the main list view, you could position test cases and their folders exactly how you wanted in one long list:

When we added test sets in v3.0 we followed the same scheme, where the test sets and test set folders also were essentially the same artifact (with a folder Yes/No attribute), they both had history, custom properties and comments:

What Were the Problems?

Over the years, having test case / set folders that were essentially a special type of test case / set caused a number of problems though:

  • It was disorienting to new users, they were used to how folders work in Windows® Explorer and other tools, and they found the Indent/Outdent model of SpiraTest non-intuitive.
  • It led to strange behavior--for new and old customers alike - filtering and expanding/collapsing folders resulted in some atypical interactions. It also meant that dragging a test case into a folder was a non-trivial operation.
  • No sorting available - due to the fact that test cases and test sets were manually positioned by the user, there was no way to sort the list of test cases / sets
  • It had major performance impacts on the system - if you frequently saw 'database timeouts', 'deadlocks' and 'refresh the database index messages', this was the culprit.
  • It was the cause of a number of bugs that frustrated some customers - for example having to fill out a required custom property on a folder that was really only intended for a test case.
  • Finally, this folder model constrained us being able to further develop a number of improvements to test cases, test sets and tasks - including support for workflows.

Task/Document Folders in Version 4.2

Conversely, Tasks and Documents had their own different type of 'folders' in versions v4.x:

These folders acted more like traditional 'containers' that had just a name and hierarchy with no other properties. They were displayed to the left of the main item list and were not filterable and did not ever appear in the main item list.

What Were the Problems?

These folders had their own set of limitations and issues:

  • Not integrated into the main list view - consequently they were often ignored by users and there was no prominent view of the current child folders in the main list.
  • No bulk operations available - since they did not appear in the main list, there was no way to perform bulk operations on a folder.
  • No way to sort or filter the folders - since they did not appear in the main grid, there was no way to filter or sort on the folders
  • No summary view - Unlike the test case and test set folders there was no way to give summary status (e.g. # passed test cases, etc.) in the main list view

Folders in version 5.0

So for version 5.0 we took the best of the two approaches and created a new folder system for all of the artifacts in the system using folders (test cases, test sets, documents and tasks), and implemented that consistently for all four parts of the system:

Folders are distinct objects to the artifacts they contain. Folders have a name, a description, and a place in a folder tree, but they have no other properties. They are containers containing artifacts only. This is similar to how folders work in most other systems.

However unlike the old tasks and documents folders, the current child test cases are displayed in the main list view and can be sorted and filtered on just like the artifacts themselves:

Data Migration Considerations

So what happened to the old test case and test set folders during the upgrade process?

The old folders will have been removed, replaced with the new simple container equivalent. That does mean that the old artifact data associated with each folder (history, custom properties, comments, etc.) will have been discarded during the upgrade.

The new folders still hold all the same items, and are in the same place in the folder tree. But that is all they do. In a lot of ways they now behave just like Windows Explorer:

  • List views for test cases, test sets, documents, and tasks have a folder tree on the left for navigating between folders.
  • Once a folder is selected on the left, it shows its contents in a list on the right, including any folders it contains.
  • If you want to move an item into a folder, you drag it from the right into the relevant folder on the left.

There are two major ways where our folders work more consistently with other applications you may be familiar with:

  • First, deleting a folder does not delete its contents. Instead the contents are moved to the 'root' folder.
  • Second, test case folders and test set folders show a histogram of the latest execution statuses of their contents

We think this new model is much easier to understand and work with. It's faster and more robust. You can sort any list by any field--no more needing to manually order things.

Transitioning from 4.2

For most of our customers, the transition should be seamless and quick and brings lots of immediate benefits. Some customers--notably those that made extensive use of the different attributes you could attach to a folder--will want to plan their migration more carefully. We recommend only upgrading to version 5.0 when you have transitioned your 4.2 data to no longer rely on the data attached to a folder.

We Have More To Do

This was a large architectural change for SpiraTeam but there is more that we can do. Currently the new folder system behaves mostly the same way as an application like Windows Explorer, but not completely. For instance, you can only drag an item into a folder on the left, not onto a folder on the right hand list view.

Over the next few months we hope to roll out refinements to the new model to make the experience more intuitive. Once the new system is as solid and easy to use as possible we may start exploring other ways that list data could be displayed to help your work in SpiraTeam be even faster.

Next Up

We hope this overview of the changes to folders was helpful. The next post about SpiraTeam 5.0 will discuss improvements to the Instant Messenger.

test cases test sets folders