Форум: "Прочее";
Текущий архив: 2011.07.17;
Скачать: [xml.tar.bz2];
ВнизИщу что-то типа 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-х человек "никак не привязанных к теме вопроса трудовым соглашением".
Я употребил термин "привязанных трудовым соглашением" не спроста.
← →
Германн © (2011-03-25 02:22) [23]
> Чтоб лучше понять, четко сформулируй и выпиши в столбик
> то, что система должна делать.
Сегодня в личной встрече обсудили. Точнее начали обсуждать.
Пока предложил им посмотреть три варианта. Trac, Redmine & Bugzilla. Что они посмотрят и что решат для меня пока непонятно. Ибо двое из трёх учили в школе немецкий, а третий вообще нигде никакой иностранный язык похоже не учил. :)
Лично для себя я ищу такую программу, которая помогла бы им " грамотно управлять своими замечаниями". Ну хотя бы чтобы она им помогала понять, что они заметили, когда они заметили, когда они занесли это замечание в базу. Ну и чтобы они узнавали, что что-то по их замечаниям сделано.
← →
Akex Konshin (2011-03-27 14:21) [24]На самом деле тул не играет такой важной роли, как кажется. Намного важнее организация процесса.
Я сейчас в PTC занимаюсь автоматизацией тестирования.
Насколько я понимаю, ты только начинаешь с этим иметь дело. Не удивлюсь, если вообще весь процесс разработки не поставлен. Я настоятельно советую почитать в интернете теорию прежде чем пыпаться что-то делать на практике. Что именно почитать - не знаю :). Начни хотя бы с википедии. Иначе слишком много дров наломаешь прежде чем всё устаканится. Тебе нужно для начала выбрать модель из ряда модных сейчас. Спроектировать процесс на уровне кто что когда будет делать. А потом уже подобрать тулы под этот процесс.
Просто сам по себе баг трекер на задаёт процесс, а если процесс будет спроектирован плохо, то он(трекер) может увеличить хаос. Что тольку, если тестеры будут вносить десятки-сотни новых багов/фич в день, если программисты не будут знать в каом порядке их фиксить, а тестеры не будут вовремя проверять фиксы? Если не будет правильно организована интеграция, не будет плана билдов, не будут выставляться ежедневно приоритеты, то программисты просто утонут в этих баг репортах и плюнут на на них.
← →
Alex Konshin © (2011-03-27 14:33) [25]Кстати, трудовые отношения участников тут тоже не важны, важно их желание делать продукт. Если правильно организован процесс, то не важно, кто кому подчиняется. Я участвовал в проектах, где все девелоперы работали удалёно и начальников не было. Собственно, в мире СПО именно так дело и обстоит. Если всё правильно сделано, то все оценят удобство, и это реально облегчит всем работу. Если же нет, то будет хаос и будет риск срыва всех сроков разработки, тестирования, релизов.
← →
Германн © (2011-03-28 03:12) [26]
> Насколько я понимаю, ты только начинаешь с этим иметь дело.
И да и нет.
> Не удивлюсь, если вообще весь процесс разработки не поставлен.
Я уже говорил, что нет у нас технического директора ориентированного на разработку ПО.
> Кстати, трудовые отношения участников тут тоже не важны
В этой фирме "трудовые отношения" не важны. Спорить с генеральным может каждый. И в этом споре генеральный участвует наряду с прочими как равный. По сабжу точно как равный.
На сей момент меня волнует в этом вопросе только формат представления замечаний разработчикам и формат ответа разработчиков тестировщикам.
Формат TXT меня лично не устраивает никак.
← →
4eptyxa © (2011-03-31 12:36) [27]Германн
Совсем не ясно чего не ясно. Если разработчики это не "генераторы кода" а разработчики, которые могут и тз и тех спец составить то формат постановления замечаний - любой гугл докс, сетевая таблица и т.п. "Ответственный", "тем" , "приоритет", "тип(разработка\тестирование)", "описание". Каждый вопрос описывается в описании, разработчик смотрит что ответственным выставлен он, и смотрит "чего там". Исправляет, и меняет ответсвенного и тип, на тестера. Если тетстер нормально отыграл, закрываете. Если вас 4 человека то самый простой вариант, мороки мало, а всё тот же баг трекер.
Формат замечаний разработчикам можно формировать как "КОЛЯ НИЧЕГО НЕ РАБОТАЕТ" так и "при вызове функции 3, и вводе параметра х, выпадает ошибка н" и потом если что перед людьми далекими можно отчитаться - "я блин всё написал, это коля виноват".
Если разработчик - генератор кода, то в обязательном порядке кто-то будет вынужден взять на себя обязанности человека ставящего задачи, т.е. переформулирующего бизнес требовани "надо всё синим цветом сделать" превращает в задание программисту "надо сделать эти то поля такого-то цвета, и выпустить новую версию".
Тут либо все молодцы и функцию главного разработчика на себя взяли, либо стадо баранов и нужен пастух (куча деталей и клей).
← →
Суслик_ (2011-04-01 01:41) [28]Полностью поддерживаю Алекса Коншина - главное процесс как таковой, а тул любой может быть.
← →
Германн © (2011-04-01 02:56) [29]
> Суслик_ (01.04.11 01:41) [28]
>
> Полностью поддерживаю Алекса Коншина - главное процесс как
> таковой, а тул любой может быть.
>
И я его поддерживаю.
Но я не генеральный директор. И, следовательно, "ограничен в возможностях".
Главное то, что благодаря ответам на сей вопрос, я предложил руководству несколько вариантов баг-трекеров. А эти варианты явно помогут фирме при разработке собственных продуктов.
← →
Германн © (2011-04-01 03:19) [30]И не важно буду ли я разрабатывать.
← →
KilkennyCat © (2011-04-01 03:21) [31]
> Но я не генеральный директор. И, следовательно, "ограничен
> в возможностях".
даешь революцию! захватывай власть, не ограничивай возможности :)
смена руководства для решения программно-аппаратной задачи - это тоже метод, ничем не хуже других.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2011.07.17;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.004 c