Ищу что-то типа SVN, но не для разработчиков, а для тестировщиков

← →
Германн © (2011-03-21 03:58) [0]

Собственно проблема такая. Тестировщиков, как таковых в фирме нет. Фирма маленькая. Есть техотдел из 4-х человек (не включая меня). Каждый из них почти кровно заинтересован в том, чтобы фирма создала своё собственное ПО для своего железа. Проблема в том, что каждый из тех 4-х получает зарплату не за тестирование, а совсем за другое.
И вот тут у меня возникают проблемы как "синхронизировать" работу этих "тестировщиков"? Чтобы мне не приходилось каждый раз лично спрашивать мнение 3-х о замечании/предложении 4-го! А им не приходилось слишком много тратить времени на изучение того, что уже предложено другими тремя.
Может кто чего подскажет?

← →
Германн © (2011-03-21 04:16) [1]

Поправка.
"А им не приходилось слишком много тратить времени на поиск того, что уже предложено другими тремя."

← →
Ляпа (2011-03-21 04:31) [2]

TestLink ?

← →
Германн © (2011-03-21 04:42) [3]

По глубокому размышлению, вопрос снимается. Такого ещё не придумано.

← →
brother © (2011-03-21 07:39) [4]

Яб завел сетевой файл (например ексел) с пометками о регистрации, списками проблемм итд...

← →
brother © (2011-03-21 07:40) [5]

имхо, для синхронизации действий самоее оно...

← →
_matt (2011-03-21 08:16) [6]

Microsoft Test Manager
Bugzilla
HP Quality Center

← →
_matt (2011-03-21 08:18) [7]

Можно и Jira заточить под это дело

← →
jack128_ (2011-03-21 15:09) [8]

SVN - система контроля версий, а те судя по описанию баг трекер нужен.. У нас Trac стоит.

← →
clickmaker © (2011-03-21 15:32) [9]

TestTrack

← →
Омлет © (2011-03-21 15:57) [10]

Лучше Redmine ничего не встречал. SVN совсем для другого.
http://ru.wikipedia.org/wiki/Redmine

← →
DVM © (2011-03-21 18:25) [11]

> Германн © (21.03.11 03:58)

Для ПО пишут автоматические тесты обычно, для железа+ПО очевидно делают железные стенды + тестирующее ПО.

← →
Германн © (2011-03-22 02:16) [12]

> DVM © (21.03.11 18:25) [11]
>
>
> > Германн © (21.03.11 03:58)
>
> Для ПО пишут автоматические тесты обычно, для железа+ПО
> очевидно делают железные стенды + тестирующее ПО.
>

Ты, Дима, в какой компании зарплату получаешь?
А вот как ты, например, предлагаешь "создавать автоматические тесты" для тестирования ПО самому разработчику ПО?

← →
Германн © (2011-03-22 02:22) [13]

> jack128_ (21.03.11 15:09) [8]
>
> SVN - система контроля версий, а те судя по описанию баг
> трекер нужен.. У нас Trac стоит.
>

Мне нужно что-то среднее.
Хотя может и некий баг-трекер сойдёт.

> Германн © (21.03.11 04:42) [3]
>
> По глубокому размышлению, вопрос снимается. Такого ещё не
> придумано.
>
Не придумано как заставить "этих тестировщиков" пользоваться этим баг-трекером.

← →
DVM © (2011-03-22 14:25) [14]

> Германн © (22.03.11 02:16) [12]

> Ты, Дима, в какой компании зарплату получаешь?

А какая разница?

> А вот как ты, например, предлагаешь "создавать автоматические
> тесты" для тестирования ПО самому разработчику ПО?

А что тут удивительного? Тесты все делают, кто озабочен качеством продукта и хочет чтобы его продукт был защищен от ситуации - тут поправили - там упало.

Обычное дело - написал функцию библиотечную - напиши тест к ней. Написал класс, сколько нибудь самостоятельный - напиши тест к нему.
Тесты у некоторых компаний по объему кода превышают код продукта.
Но если в крайности не впадать - сильно облегчают работу как и любая автоматизация. И код помогают писать более правильный ибо хаос и плохой код не автоматизируется.

Тесты - сила. Но их очень лень писать всегда, хотя в ряде случаев без них вообще никак.

С железом аналогично - тестовый стенд паяют и он во всех режимах прогоняет тестируемый девайс.

Кстати, часто разработку модуля начинают с тестов.

В Delphi для тестов есть DUNIT.

Для тестирования интерфейса тоже есть приблуды какие то, но я не использовал, не знаю.

← →
DVM © (2011-03-22 14:32) [15]

> Германн © (22.03.11 02:16) [12]

Вообще, я не очень понимаю, что тебе нужно? То ли тестировать, то ли багтрекер, то ли какую то "SVN для идей".

← →
MsGuns © (2011-03-22 15:38) [16]

Да ему просто пообщаться захотелось с умными людьми :)

← →
Kerk © (2011-03-22 15:45) [17]

> Германн ©

Пусть наймут программиста.

← →
Иксик © (2011-03-23 02:19) [18]

По описанию действительно нужен не контроль версий, а трэкер. Я тоже за trac - чегтовски удобная штука!

← →
Иксик © (2011-03-23 02:20) [19]

Кстати, посмотрите на http://www.assembla.com - там у них и trac, и svn в одном флаконе. Очень удобно.

← →
Германн © (2011-03-23 03:17) [20]

> MsGuns © (22.03.11 15:38) [16]

Да.

> DVM © (22.03.11 14:32) [15]
> > Германн © (22.03.11 02:16) [12]
>
> Вообще, я не очень понимаю, что тебе нужно?

Я тоже пока плохо понимаю, но пытаюсь понять.

> Kerk © (22.03.11 15:45) [17]
> Пусть наймут программиста.

Они уже наняли одного. Меня. Но с большим скрипом! (Но я не нанимался как просто программист. Я вообще-то нанимался как разработчик ПО для собственного железа, которое эта фирма решила производить). Всё руководство фирмы заточено на торгово-монтажную деятельность. А собственные разработки они решили/согласились вести только недавно. Хорошим решением было бы нанять кого-то типа "администратора проектов", но на это руководство не пойдёт. Я тоже не очень хочу выполнять подобные служебные обязанности. Я просто хотел "с толком", но спокойно, провести свои последние трудовые годы.

> Иксик © (23.03.11 02:19) [18]
>
> По описанию действительно нужен не контроль версий, а трэкер.
> Я тоже за trac

Пока мои предложения об использовании баг-трекеров встретили "глухо".

← →
DVM © (2011-03-23 07:58) [21]

> Германн © (23.03.11 03:17) [20]

> Я тоже пока плохо понимаю, но пытаюсь понять.

Чтоб лучше понять, четко сформулируй и выпиши в столбик то, что система должна делать. Всем станет понятнее и тебе тоже. Пока получается хочу то не знаю что. Ну и сюда этот список.

← →
Германн © (2011-03-24 01:45) [22]

> DVM © (23.03.11 07:58) [21]
>
>
> > Германн © (23.03.11 03:17) [20]
>
>
> > Я тоже пока плохо понимаю, но пытаюсь понять.
>
> Чтоб лучше понять, четко сформулируй и выпиши в столбик

Сегодня (24.03.10) постараюсь это реализовать на фирме. Но вероятность решения не более 30%. Трудно чётко сформулировать хоть что-то группе из 4-х человек "никак не привязанных к теме вопроса трудовым соглашением".
Я употребил термин "привязанных трудовым соглашением" не спроста.

> Чтоб лучше понять, четко сформулируй и выпиши в столбик
> то, что система должна делать.

Сегодня в личной встрече обсудили. Точнее начали обсуждать.
Пока предложил им посмотреть три варианта. Trac, Redmine & Bugzilla. Что они посмотрят и что решат для меня пока непонятно. Ибо двое из трёх учили в школе немецкий, а третий вообще нигде никакой иностранный язык похоже не учил. :)

Лично для себя я ищу такую программу, которая помогла бы им " грамотно управлять своими замечаниями". Ну хотя бы чтобы она им помогала понять, что они заметили, когда они заметили, когда они занесли это замечание в базу. Ну и чтобы они узнавали, что что-то по их замечаниям сделано.

← →
Akex Konshin (2011-03-27 14:21) [24]

На самом деле тул не играет такой важной роли, как кажется. Намного важнее организация процесса.

Я сейчас в PTC занимаюсь автоматизацией тестирования.
Насколько я понимаю, ты только начинаешь с этим иметь дело. Не удивлюсь, если вообще весь процесс разработки не поставлен. Я настоятельно советую почитать в интернете теорию прежде чем пыпаться что-то делать на практике. Что именно почитать - не знаю :). Начни хотя бы с википедии. Иначе слишком много дров наломаешь прежде чем всё устаканится. Тебе нужно для начала выбрать модель из ряда модных сейчас. Спроектировать процесс на уровне кто что когда будет делать. А потом уже подобрать тулы под этот процесс.

Просто сам по себе баг трекер на задаёт процесс, а если процесс будет спроектирован плохо, то он(трекер) может увеличить хаос. Что тольку, если тестеры будут вносить десятки-сотни новых багов/фич в день, если программисты не будут знать в каом порядке их фиксить, а тестеры не будут вовремя проверять фиксы? Если не будет правильно организована интеграция, не будет плана билдов, не будут выставляться ежедневно приоритеты, то программисты просто утонут в этих баг репортах и плюнут на на них.

Кстати, трудовые отношения участников тут тоже не важны, важно их желание делать продукт. Если правильно организован процесс, то не важно, кто кому подчиняется. Я участвовал в проектах, где все девелоперы работали удалёно и начальников не было. Собственно, в мире СПО именно так дело и обстоит. Если всё правильно сделано, то все оценят удобство, и это реально облегчит всем работу. Если же нет, то будет хаос и будет риск срыва всех сроков разработки, тестирования, релизов.

> Насколько я понимаю, ты только начинаешь с этим иметь дело.

И да и нет.

> Не удивлюсь, если вообще весь процесс разработки не поставлен.

Я уже говорил, что нет у нас технического директора ориентированного на разработку ПО.

> Кстати, трудовые отношения участников тут тоже не важны

В этой фирме "трудовые отношения" не важны. Спорить с генеральным может каждый. И в этом споре генеральный участвует наряду с прочими как равный. По сабжу точно как равный.

На сей момент меня волнует в этом вопросе только формат представления замечаний разработчикам и формат ответа разработчиков тестировщикам.
Формат TXT меня лично не устраивает никак.

Германн

Совсем не ясно чего не ясно. Если разработчики это не "генераторы кода" а разработчики, которые могут и тз и тех спец составить то формат постановления замечаний - любой гугл докс, сетевая таблица и т.п. "Ответственный", "тем" , "приоритет", "тип(разработка\тестирование)", "описание". Каждый вопрос описывается в описании, разработчик смотрит что ответственным выставлен он, и смотрит "чего там". Исправляет, и меняет ответсвенного и тип, на тестера. Если тетстер нормально отыграл, закрываете. Если вас 4 человека то самый простой вариант, мороки мало, а всё тот же баг трекер.

Формат замечаний разработчикам можно формировать как "КОЛЯ НИЧЕГО НЕ РАБОТАЕТ" так и "при вызове функции 3, и вводе параметра х, выпадает ошибка н" и потом если что перед людьми далекими можно отчитаться - "я блин всё написал, это коля виноват".

Если разработчик - генератор кода, то в обязательном порядке кто-то будет вынужден взять на себя обязанности человека ставящего задачи, т.е. переформулирующего бизнес требовани "надо всё синим цветом сделать" превращает в задание программисту "надо сделать эти то поля такого-то цвета, и выпустить новую версию".

Тут либо все молодцы и функцию главного разработчика на себя взяли, либо стадо баранов и нужен пастух (куча деталей и клей).

← →
Суслик_ (2011-04-01 01:41) [28]

Полностью поддерживаю Алекса Коншина - главное процесс как таковой, а тул любой может быть.

> Суслик_ (01.04.11 01:41) [28]
>
> Полностью поддерживаю Алекса Коншина - главное процесс как
> таковой, а тул любой может быть.
>

И я его поддерживаю.
Но я не генеральный директор. И, следовательно, "ограничен в возможностях".
Главное то, что благодаря ответам на сей вопрос, я предложил руководству несколько вариантов баг-трекеров. А эти варианты явно помогут фирме при разработке собственных продуктов.

И не важно буду ли я разрабатывать.

> Но я не генеральный директор. И, следовательно, "ограничен
> в возможностях".

даешь революцию! захватывай власть, не ограничивай возможности :)
смена руководства для решения программно-аппаратной задачи - это тоже метод, ничем не хуже других.

Ищу что-то типа SVN, но не для разработчиков, а для тестировщиков Найти похожие ветки