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

Question

[2c4wr]

Доброго времени суток!

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

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

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

Наиболее частые места возникновения ошибок: стык подсистем и веб-интерфейс.

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

Видим следующие проблемы при организации нового подразделения:
1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?

2) К конструктору нет четкой спецификации (и не будет в данный момент), лишь список задач в баг-трекере, а значит тестировщикам непонятно что тестировать. Можно попробовать писать тесты на новые задачи и постепенно они покроют все, потихоньку добавлять тесты на функционал, который не попадает в новые задачи. Сработает ли?

3) Превышение возможностей подразделения по поддержанию тестов в актуальном состоянии. Скорее надуманная проблема, но тем не менее, может ли получится так, что тестов станет слишком много и при выходе новой версии продукта тестировщики не будут успевать актуализировать тесты под изменившуюся платформу?

Спасибо!

Answer 1

[Данил Бирюков-Романов]

Возьмите опытоного QA и он все вам расскажет, как надо делать.

>1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?

На наиболее часто встречающихся или приносящих основной доход.

>2) К конструктору нет четкой спецификации (и не будет в данный момент), лишь список задач в баг-трекере, а значит тестировщикам непонятно что тестировать. Можно попробовать писать тесты на новые задачи и постепенно они покроют все, потихоньку добавлять тесты на функционал, который не попадает в новые задачи. Сработает ли?

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

>3) Превышение возможностей подразделения по поддержанию тестов в актуальном состоянии. Скорее надуманная проблема, но тем не менее, может ли получится так, что тестов станет слишком много и при выходе новой версии продукта тестировщики не будут успевать актуализировать тесты под изменившуюся платформу?

Это уже проблемы отдела тестирования и того как они будут решать задачу, но в целом такая проблема есть, но без конкретитки тут говорить нечего.
Я знаю системы где 10к тестов держит один человек, и системы где 100 тестов поддерживает отдел из 6-7 человек.

Comments

[Alexej Simakov]

Данил Бирюков-Романов: расскажите в двух словах чем (может быть) обусловлена такая разница 10к тестов на одного и 100 на семерых. Ведь явно не производительностью отдельного человека.

[Данил Бирюков-Романов]

Alexej Simakov: В знаниях человека в первую очередь. Потому что 10к тестов в одиночку держать может только очень умный и опытный :)

Во вторых - разница может быть в размерах тестов, 10к тестов могут быть куском Agile, где несколько релизов в день и потому тесты в целом небольшие, а сто тестов могут быть большими (где каждый тест чуть ли не по 4 часа идет) и очень тяжелыми, где одному все просто не поддержать.

Как обычно - универсального ответа нет :)

Answer 2

[Saboteur]

"1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?"

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

2) К конструктору нет четкой спецификации (и не будет в данный момент), лишь список задач в баг-трекере, а значит тестировщикам непонятно что тестировать. Можно попробовать писать тесты на новые задачи и постепенно они покроют все, потихоньку добавлять тесты на функционал, который не попадает в новые задачи. Сработает ли?

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

3) Превышение возможностей подразделения по поддержанию тестов в актуальном состоянии. Скорее надуманная проблема, но тем не менее, может ли получится так, что тестов станет слишком много и при выходе новой версии продукта тестировщики не будут успевать актуализировать тесты под изменившуюся платформу?

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

Comments

[Evgeniy _]

Опыт показывает, что несмотря на всевозможные юниттесты - покрытие UI тестами - необходимо. То, что вернет функция - еще не значит, что frontend это отобразит и отобразит правильно )

[Saboteur]

Evgeniy _: В чем проблема написать автоматические UI тесты?

[Evgeniy _]

Saboteur: Это у вас написано "Ведь можно что-то не тестировать, а при этом оно будет работать, потому что тестировалось разработчиком в юниттестировани.". Не у меня.

[Saboteur]

Evgeniy _: Вы говорите что и так что-то не тестируете, потому что людей нет. Так какая разница не тестировать ничего, или тестировать что-то автоматическими тестами?

Answer 3

[Evgeniy _]

Видим следующие проблемы при организации нового подразделения:
1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?

Есть main product - набор всех функций.
Есть customer product * n (n - количество кастомеров)
Тестируется как главный продукт, так и для каждого кастомера в отдельности. Тк различная комбинация функций - может вызывать различное поведение и соответственно разные баги.
Это, конечно, если вы хотите избежать лишних разговоров с заказчиками.

Comments

[2c4wr]

Ну это был бы лучший вариант, согласен, но и ресурсы другие, к сожалению

Answer 4

[Alexej Simakov]

первая мысль которая пришла в голову: если проблемы на стыке компонентов возникают, может сперва над архитектурой поработать?

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

У нас например ModelView слой программы выдает минимум треть ошибок, мы делаем автоматизацию, это дорого, а надо просто нахрен выкинуть тот инструмент которым мы делаем UI и перейти на что нибудь, что будет валидироваться у разработчика на компьютере а не завтра утром на сервере после полной сборки. Другое дело что на такой шаг начальство пойти не может, они в рабстве у вендора этого инструмента. Т.е. миграция возможна но не вдруг.