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

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

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

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

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

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

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

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

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

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

Спасибо!
  • Вопрос задан
  • 678 просмотров
Пригласить эксперта
Ответы на вопрос 4
urtow
@urtow
*nix, python, QA, bagpipe, folk music
Возьмите опытоного QA и он все вам расскажет, как надо делать.

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

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

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

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

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

Это уже проблемы отдела тестирования и того как они будут решать задачу, но в целом такая проблема есть, но без конкретитки тут говорить нечего.
Я знаю системы где 10к тестов держит один человек, и системы где 100 тестов поддерживает отдел из 6-7 человек.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Организация работы
software engineer
"1) Огромное разнообразие вариантов построения продуктов из блоков конструктора - что работает у одного заказчика, может не сработать у другого по разным причинам. На какой конфигурации конструктора проводить тесты?"

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

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


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

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

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


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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
MediaSoft Ульяновск
от 80 000 до 180 000 ₽
Leningrad Media Москва
от 150 000 до 170 000 ₽
УБРиР Екатеринбург
от 108 000 до 108 000 ₽