Как стать автором
Обновить

Комментарии 7

Шифт - смена, лефт - остался. ) т.е. остался после работы, потестировал всё )). Замечательная методология.)

Это шифтрайт) Срок вправо уходит

Как правило, команда тестирования — это самые большие эксперты во всем продукте, связующее звено между бизнесом и разработкой.

В это слабо верится, исходя из опыта работы в банковской сфере.

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

На стенде тестирования проводится функциональное тестирование и тестирование интеграций;

Он один на все команды или есть командные тестовые контуры? В первом случае когда одна из команд тестирует свой код, то все остальные волей-неволей тоже его тестируют, нарываясь на непонятные чужие баги?

Какое отношение имеют к основному тексту сноски State transition и Decision table в заключении?

Тестовый стенд один.

Разработческих – много.

Разработка проводится на командном разработческом стенде, поэтому влияния команд друг на друга при разработке нет.

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

Такой подход позволяет упростить тестирование и поиск ошибок.

Просто интересно, а почему не упоминается статический анализ кода? По идее он идёт ещё раньше или параллельно с юнит-тестированием. Или статический анализ относится  уже не к команде тестирования? Хотя юнит-тесты, вроде тоже не задача тестировщиков.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий