We are excited with the new release of SpiraTeam v5.3 (also including SpiraTest and SpiraPlan in case you were asking!). In this article we are going to highlight some of the enhancements in the latest version. The full list of enhancements, bug fixes and new features can be found in the release notes.(Read More)
We're very excited about the next version of SpiraTest (also SpiraPlan and SpiraTeam) coming out on April 26th. It features a lot of enhancements which will be the subject of future blog posts. However one big area is the redesign of the Incidents pages (both the one that displays the list of incidents and the one that displays a single incident when you click on it). This article explains some of the reasons behind the change and an explanation of what you can expect in v5.2. For those not heavily using the incidents module, it is still worth reading because in v5.3 we will be similarly changing all of the testing pages.(Read More)
One of the frequent pieces of feedback we have received has been that the columns in the various list pages within Spira are not resizable. We have listened to your feedback and Spira 5.1 provides resizable columns for the first time.
In accordance with the theme this month of user interface updates and user experience in general, we'd like to talk about some of the UI changes being made to our Rapise test automation product. These changes are based on the results of user testing and feedback from our customers. It's an interesting topic because it shows the dramatic impact the UI can have on an application.
The SpiraTeam development group has been working really hard on version 5. It will bring many great new features that our users have been requesting. We also get asked about refinements to the user experience. We have been equally busy carefully updating every screen, every button, and every field our customers will see and use in version 5.
The language used to define user stories in Agile projects tends to be less prescriptive than that in traditional projects. This means that many developers and testers assume that this means that they are often less testable, when in fact the reverse is true. This article explains why. (Read More)