Comments 10
Может попросить тестировать/писать тесты разработчиков ?)
То чувство, когда зашёл в статью почитать про то как автоматизировали ручные задачи и поменяли подход к релизному циклу, а проблему залили людьми и стали тратить на ручное тестирование ещё больше времени и ресурсов *сложный смайл*
Коллеги, подход: у нас проблемы с тестированием, давайте наймем 1го, 2х, N-тестировщиков, в 90% случаев не работает. Вы сейчас клеете пластыри, вместо того чтобы лечить болезнь. Займитесь автоматизацией, пусть девелоперы вам напишут фреймворк если у тестирования ресурсов нет, подключайте тестирование к планированию релизов, сделайте вообще это самое планирование - не увидела в статье ничего про релизный цикл, кроме того что к вам прибегает бизнес и запихивает задачи. Делайте ретро и анализируйте какие проблемы есть у вас и с чем это связано. Я уверена большинство из них будет связано с орехами в процессе, а не с тестированием.
Я решала ту же самую проблему в легаси системе, большой команде с отсутствием планирования, и часто хреновым описанием требований, больше 1000 кейсов у нас, за полгода мы пришли к нормальному состоянию тестирования, при этом с самой командой тестирования работать почти не пришлось - все дело в том как планируется релиз, какие оценки даются, как описываются требования, какой код вам отдают на входе и тп, с процессом надо работать.
Какой прекрасный комментарий и какой "пустой" пост.
В статье действительно не раскрывается релизный цикл и планирование. Но они есть и жестко стандартизованы. Релизный цикл составляет 2 недели с 3 этапами тестирования: регресс + частичная автоматизация, ретест багов, смоук. Планирование у нас годовое, квартальное и в рамках спринта. Приоритеты задач планируются заранее и не меняются в течение квартала. Однако, статья про наши боли и их решения, а не про хорошо отлаженные процессы.
Безнес никуда "не прибегает и не запихивает задачи". Объемы постоянно росли потому что бизнес масштабировался и рос по всем направлениям. Быстрым решение с сохранением темпа был найм новых сотрудников. Вы правильно отметили, что хорошее решение - это автоматизация, мы к ней сейчас активно стремимся. Об этом мы расскажем в одной из будущих статей.
Можно сделать тестирование скриншотами и вы будете видеть только скриншоты которые изменились, а те которые не изменились будут отсеиваются системой.
То есть выполняем набор действий, делаем автоматически скриншот, сравниваем с предыдущим состоянием, если есть различия пытаемся понять стало хуже или лучше.
А как обстоят дела с автоматизацией регресса? Ведь за счет нее можно тоже освободить время ручных тестировщиков.
Процессы тестирования в условиях большого роста команды