Как улучшить отдел тестирования?

Question

[notyou2]

Есть довольно большой проект который проверятся 2мя тестировщиками один джуниор с небольшим опытом, второй с большим опытом работы в этом проекте.
Есть несколько проблем
1. Регресия почти не выполняется
2. Количество багов/резолво из спринта в спринт каждый раз много
3. Времени нет на написание тест кейсов и ведение документаций
4. Тестирование фичей почти всегда выливается в кучу багов, и потом возвращается ком резолвов который мешает проверить фичи

релиз плохо протестирован
Помоги советом по улучшению

Comments

[sim3x]

А вы кто в данном проекте?

[notyou2]

sim3x, второй тестировщик который пытается улучшить качество продукта

[sim3x]

notyou2, подойдите к ТЛ/ПМ и спросите - нормальная ли у вас ситуация с тестированием

И задайте ему все пункты из вашего вопроса

[notyou2]

sim3x, ну мне пм говорить что ситуация с тестирование печальная, и нужно что-то менять.
И того что мне сразу приходит в голову
1. Расширить отдел
2. Покрыть тест-кейсами функционал
3. Регулярная прогонка тестов

[sim3x]

notyou2,
Вам ничего не нужно придумывать
ПМ/ТЛ опытнее вас - он знает решения
Вам нужно четко выполнить вашу часть работы

[notyou2]

sim3x, пм не занимается вопросом тестирования. И хочет лишь знать готов ли продукт к релизу. Поэтому отвечаю за тестирования я

[sim3x]

notyou2,

ПМ должен заниматься всем
Если ПМ не умеет в технические вещи, то ему должен помогать ТЛ
Если у вас его нет, то у вас огромная проблема

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

И после данного месяца х дней на каждый спринт выделяется на фикс багов
Юнит- и приемочные тесты теперь обязательны

Answer 1

[Alexej Simakov]

- На каких технологиях приложение?
- Какая длина спринта?
- Как у вас построен процесс написания кода и интеграции?
- Сколько разработчиков?
- Какие роли кроме разработчиков и тестировщиков еще есть на проекте?

Как у вас дела с архитектурой, если не получается добавлять функции не задев при этом значительную часть всей системы?

По идее код перед мерджем должен проверяться на тестировочной сборке. Возможно вам нужен девопсер, если у вас его нет.

Во время проверки (тестирования) можно написать на этот сценарий приемочный тест. Так у вас потихоньку появятся автоматизированные тесты.

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

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

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