Which test management system to choose?

L

Leshrac2013-12-10 00:20:30

Software testing

Leshrac, 2013-12-10 00:20:30

So, the initial data: the site (not a business card, but not a highload service), TDD, a large number of different autotests, a large number of pop-up bugs, lack of time (as always) - it's time for manual testing, a team of 3 people, YouTrack as a bug -tracker.
What I would like: a nice test management system (it would be great if it integrated with a bug tracker), an intuitive interface, easy setup and similar platitudes, preferably free / inexpensive.
There is little experience with testlink. I would like to hear what is used to systematize manual tests, what are the pros / cons of the system used.

Reply

Answer the question

In order to leave comments, you need to log in

3 answer(s)

A

Alexander, 2013-12-10
@MadCat

In battle, we used TestRail and TestLodge , the test link is simply inconvenient to use.
Rail is richer in functionality, but more expensive.

A

Alexey Kiselev, 2013-12-10
@alexeykiselev

Read about cucumber . Test scripts are written in almost human language into text files and are executed from a script. They can be grouped into different files and executed depending on the duration of testing. The script files themselves are stored in the version control system, which is very convenient.
It’s hard for me to say what directly to test, here people use some kind of Webrat with cucumber .

M

Maxim Mikhailov, 2013-12-10
@carboniferous

The test management system (especially free) will not save by itself, but, on the contrary, will probably add a headache. See, Shura, the process =) To begin with, your first paragraph describes the problem - "lack of time to perform [testing] work", and its most likely causes - "a large number of autotests" and "a large number of pop-up bugs". Regarding the first reason, I advise you to take tests - evaluate the time for supporting autotests, creating new ones, the effectiveness of the autotests themselves (how many bugs were revealed by each specific test). After - rebuild the autotest package(s). The second reason is eliminated through those who introduce these same defects into the code - developers. Write more carefully, in pairs, review each other, sleep and rest more, unit test - anything to