3 free tools for software test management

Today I want to take a look on the 3 freely available tools that allow for test management without breaking the bank those are good starting point for those who are looking for an alternative for high end tools like HP ALM and Smart Bear Test Complete.

Kiwi TCMS
This is a test case management tool that allow for proper test case creation and execution with nice reporting functionality. This tool does not contain internal bug tracking but integrates nicely with big players like BugZilla (A free Bug tracking tool)

TestLink
This is a full free solution for Software test management. It has it all from Requirement management to test case creation trough reporting and up to bug tracking. Everything can be done in this tool that has a lot of documentation online and a stable version the only downside is that its look and feel very outdated and might concern some modern testers out there

XStudio
This one is a commercial product that has a free, community, edition. It has a full spectrum of software development Life cycle components and can be a great starting point for a growing QA group. The free edition is limited to 200 test cases and MySQL database installation but for a fully professional free tool it a great starting point.

Conclusions

For those that are concentrating on the testing side only I would recommend the combination of Kiwi TCMS with Bugzilla as the go-to free solution and to those who require a free full-inclusive tool TestLink will be the thing. On the other hand if you are looking to potentially invest in a testing tool in the future but need a free fully functioning starting point you probably will choose the XStudio. It is true that all the big ones like offer the free trails and if you invest money you can go with them but keep in mind that the pricing point is completely different as well.

If you know of other free testing tools for manual test managment please write in the comments below.

Comments

Proper QA estimation in Agile project

Today, I want to chat about a common issue in Agile development – story point estimation. You see, it's easy to get caught up in estimating how long a feature will take to develop and forget about the crucial Quality Assurance (QA) effort. It happens to often: your team is in the middle of sprint planning. New user stories are being discussed, and estimations are given, but there's a catch. You've estimated the development time perfectly, but you've barely even glanced at how much effort QA will take. Why? Agile talks about Development Team and you mistakenly thought that it is all about DEVELOPMENT. Sound familiar? Trust me; it's a more common scenario than you might think. So, what's the big deal? Well, when you leave QA effort out of the equation, several not-so-great things can happen: Vilocity can suffer: You might think you can squeeze more into a sprint than is humanly possible, setting your team up for disappointment and overcommitment. Quality can de

Performance testing vs Load testing vs Stress testing

Today I want to discuss a popular topic regarding a difference between Load and Performance testing. Those two types of testing are commonly used together but there are several key differences between the two. To get a better understanding of the topic lets have a real life example from one of my clients and use it to explain the difference. I have worked for a client that was building an in-house web application that provides its customers with an option to select and order different products and services. The request was, before the up-coming release, to test the performance of their product. We started the task by trying and understand what they expect from performance point of view and then went through an exercise of defining what is captured by what test. The client said that they are looking to have about 900-1300 active users on the site at a given moment, and the expected response time (for a page to load) should be less than 5 seconds. With those details what are the t

What is the velocity of an Agile scrum methodology?

Let's discuss some of the important measurements in Agile, and that is the Velocity of the Scrum team work. Based on Wikipedia definition Velocity is " ...the rate of change of its position with respect to a frame of reference and is a function of time...", which when transferred to the scrum world can be summarized as: The amount of work that the scrum team completed in a single measure of time - in a sprint. How we Calculate Velocity? Velocity is actually a very simple to calculate, it is done but totaling the number of story points of fully completed user stories from the sprint backlog. So if a current sprint included 4 user stories: 2 with 8 story points each, one with 3 story points and one with 32 story points. and by the end of the sprint the 32 one was not fully done the velocity calculation will be: 8+8+3=19 Note: the 32 story points are not part of the velocity calculation as this user story was not completed. What Velocity is used for? The v

QA Bean

Search This Blog