Alexej Simakov

Я в свое время пользовался Mantis BT, там есть функция т.н milestone - т.е. набор тикетов (тасков, багов) можно сгруппировать, и сказать вот это мы релизим сейчас, а это потом. И API у него есть, но мне ей и не приходилось пользоваться, ничего конкретно по ней сказать не могу. Eще он очень гибкий, т.е. позволяет заточку под свои нужнды.
Я думаю конкретно такую фичу, что при выполнении всех подзадач релиза собирается и отсылается автоматически релиз-мейл тем кто требовал эту фичу, врядли можно найти. Она слишком специфична заточена под определенный воркфлоу. А багртрекеры как категория приложений, обычно предоставляют платформу на основе которой уже строится конкретное решение под проект.
Ну вот тут я находил указание на то что для jira нужно писать свой обработчик события. Но может появились готовые плагины.

Вобщем, думаю без программирования вы не обойдетесь, просто решите под какую платформу вам писать будет проще.

Я вам расскажу про среднестатистических тестировщиков. Не про талантливых, а про обыкновенных.

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

Если тестировщик никак не проявляет инициативы - тоже плохо.

Спрашиваешь тестировщика:
- Чем ты сегодня занимался?
- Тестировал.
- Что тестировал?
- Все тестировал.

яркий пример того, что тестировщик не понимает, что его продукт - информация. Или ему вообще не обьяснили чего от него хотят. Проблема скорее руководителя.

Если тестировщик не производит информации - он бесполезен.

Еще нельзя тестировщиков сажать в отдельное помещение. В изоляции они будут неэффективно работать.

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

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

Чем чаще вы будете оставлять тестировщика "за бортом" тем менее эффективно он будет работать.

Нужно чтобы тестировщик чувствовал свою отвественность за продукт. Для этого он должен быть частью команды. Чем больше отвестственности вы возложите на тестировщика тем быстрее он вырастет. Будете относиться к нему как к чуваку для мебели - он таким и станет.
Если вы не знаете, что хотите от тестировщика - то он не знает тем более. Разработчик без задания тоже не знает что делать. Нужно поставить тестировщикам задачи. И желательно с письменной отчетностью. Скажу вам сразу это все не так просто, и дополнительная работа для руководителя. Но можно взять тест-менеджера. Он знает как использовать тестировщиков эффективно. Как поставить отчетность и пр.

Еще о предубеждениях.
Часто получается разделение на лагерь разработчиков и тестировщиков - это слышно по лексике употребляемой в общении. Если тестировщик считает, что он должен "сломать продукт", "найти в нем баги", если он думает что он работает "против разработчиков" или если разработчики считают, что работают против тестировщиков - все это нонсенс от которого надо избавляться сразу. Когда клише сложатся - будет поздно. Для этого нужно серьезно относиться к тестировщику и нагрузить его конкретными обязанностями.

Если вы не знаете какие задачи поручить тестировщику - решите этот вопрос в первую очередь.

Например, можно, кроме всего прочего, поручить им замечать, какие сценарии очень трудны в выполнении или выполняются чаще всего, т.е. являются кандидатами на автоматизацию. Если вы начнете вводить автоматизацию, у вас уже будет набор первичных целей.

Подведем итог: чем конкретнее задача поставленная тестировщику - тем (внезапно) больше пользы от его работы.

Например все типы артефактов и задач получают свою компоненту. Модели, текстуры(это и скины тоже), анимация, полиграфия, медиа, звук. Или сделайте общую компоненту маркетинг для печатной продукции и веб сайта.
Например на маленьком сайте у нас было так "графика, текст, верстка, скрипты, база данных".
Обычно я рапределяю по тому в каком месте нужно над этим работать: работы отверточные, работы молоточные, покрасочные. Тогда задачи по компонентам будет легче группировать и обрабатывать в один заход.
Сборка это этап разработки перед выкатом продукта, другое дело если у вас есть сервер который нужно настраивать, тогда это "конфигурация" или "devops" или deployment или предрелизная подготовка, например. Надо продумать компоненты так, чтобы под каждую задачу или баг нашелся свой горшочек, чтобы не было такого что "ну оно как бы и туда и туда относится". Все.

Вы сказали подрядчику сделать систему и не сказали, что она должна уметь, а теперь не знаете как проверить, что сделал подрядчик? Эээ.. и никто не знает.
Как выйти из этой ситуации. Конечно, подрядчик скорее всего внедрил какое-то типовое решение, раз он согласился на выполнение без перечня требований. Нужно выяснить, что за решение он внедрил и какие возможности оно дает. Тогда уже и сверять годится ли система для выполнения ваших бизнес-сценариев или нет.
С другой стороны у вас есть бизнес сценарии, берите и проверяйте можно ли с предложеной системой их реализовать. А в случае если не понятно где кнопка "создать новый проект" звонить подрядчику и выяснять как работать с системой, либо просить его это это изменить под понятную вам последовательность действий.

Хотя обычно так и бывает, подрядчик делает типовое решение, а потом уже когда пользователь потыкал все и попробовал, доделывают и переделывают, годик-другой. Мало вероятно, что случайно получилось именно то, что нужно вам, так как нужно вам, если вы даже требования не обсуждали.

С другой стороны странно, когда подрядчик не настаивает на конкретизации требований. Обычно крупные конторы имеют аналитика требований котоый будет вас "пилить" пока вы не расскажете ему "все о чем мечтаете".

Есть такая бумажка: сертификат ISTQB Advanced Level Test Manager.
В него можно тыкать и говорить что вы QA Manager.

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

для небольшого проекта пользовался в свое время Mantis BT это бесплатный багтрекер, с возможностью комбинировать набор задач/тикетов в milestone. Это важная фича, чтобы решать что мы будем делать сейчас а что потом. Документы там можно прикреплять к задаче. Это действительно удобно когда к задаче прикреплены все необходимые к ознакомлению документы.

Есть системы где и багтрекинг можно делать и документы писать и рисовать и чатиться но это все будет стоить денег. Для стартапа это наверное лишная обуза. Например Jira+Trello+Confluence+Bamboo от Atlassian. Можно посмотреть zoho.com там тоже все можно делать, не знаю только можно ли установить все это на своем сервере. Можно Microsoft Sharepoint + MS Project использовать. Есть Assembla.com. Многие малые бизнесы спокойно хранят свои данные в бесплатных облачных сервисах. Я считаю что этого делать нельзя ни в коем случае. Но это кому как нравится.
Вобщем вариантов масса, и каждый из них нужно пробовать и смотреть нужно ли оно вам в таком обьеме.

я тестировал это все 1000 раз но эту комбинацию в голову не пришло сделать

может имеет смысл принять на вооружение методику pairwise и инструмент PICT.
По этой теме есть доклады, вот один из них для примера https://www.youtube.com/watch?v=Bqmuw3ZJ75g
Цель методики заключается в том чтобы из бесчисленного количества возможных комбинаций выбрать те которые обеспечат максимальное покрытие, при минимальном наборе тестов.
P.S. ну и автоматизация тестирования в обязательном порядке, если ее еще нет.

По поводу "нестандартного" мышления и подхода это однозначно Dan Ariley - Freakonomics, The (Honest) Truth About Dishonesty, и все остальные его книги думаю можно читать.
Еще можно Николаса Талеба почитать.
Рекомендую также ознакомиться со статьей на википедии "Список конгитивных искажений". Помогает иногда понимать причины поступков и решений.

Ну и так "наугад" еще кое что:
Fitzpatrick, Collins-Sussman: Debugging Teams
Barbee Davis: 97 Things Every Project Manager Should Know
Mary Poppendieck: Implementing Lean Software Development From Concept to Cash
Michael K. Levine: A Tale of Two Systems: Lean and Agile Software Development for Business Leaders
Вайнберг: Психология программирования

"Школа автоматизации процессов разработки" в Яндексе.
https://academy.yandex.ru/events/testing/spb-2014/
Вот плейлист на Ютубе:
https://www.youtube.com/playlist?list=PLJMRN_6MT0J...

Вообще это все "DevOps" называется

тестирование такой внутренней логики больше подходит для автоматизированного тестирования.
В ручную тестировать базу данных это круто, но сильно трудозатратно. Напишите простую обертку к базе на питоне например, и разработчикам не нужно будет писать иснтрукции, а можно будет писать сразу код. А ручное тестирование должно тестировать действия пользователя и результат работы пользователя. Пользователь не работает с базой напрямую. Если у приложение еще нет морды то, для ручного тестирования думаю еще рано.
Или я что-то не доконца понял..

Мне нравится Mantis багтрекер (PHP, опенсорс, https://www.mantisbt.org/). Там можно планировать вехи (milestones) и т.о. группировать фичи (эти функции войдут в первый релиз, а эти оставим до второго, это починим сейчас, а это потом; ведь правильная расстановка приоритетов - залог выполнения проекта в срок). Он довольно легко настраивается под свои нужды, хорошая документация, и есть какой-то даже коммерческий клон ( все тоже самое но с поддержкой за деньги, хостингом и красивой мордой). Он расширяется плагинами. Можно при желании интегрировать вики https://www.mantisbt.org/wiki/doku.php/mantisbt:is...
Сам им пользовался для веб-проекта. Очень остался доволен. Он умеет столько сколько нужно, чтобы быть понятным в использовании. А, вот, вспомнил, экспорт еще умеет делать. Надо кому то выборку показать - шмяк, емейл, готово.

Jira кончено умеет куда больше, но и пользоваться ей надо уметь. И если надо что то такое эдакое ее тоже придется программировать. Еще и денег стоит:) Вот мне и не ясно, зачем программировать под проприетарную платформу если можно под открытую. Но крупные фирмы любят Jira.

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

Есть свой резон держать и фичи и баги в одном приложении. Хоть на первый взгляд это может показаться странным.