Comments 7
Шифт - смена, лефт - остался. ) т.е. остался после работы, потестировал всё )). Замечательная методология.)
Как правило, команда тестирования — это самые большие эксперты во всем продукте, связующее звено между бизнесом и разработкой.
В это слабо верится, исходя из опыта работы в банковской сфере.
Из аналогичного опыта скажу, как разработчик, что это хоть и не в полной мере так, но все же имеет некое отношение к действительности - именно они больше всех из айтишников "тыкают кнопки". Именно они знают, как оно работает с точки зрения пользователя. Именно у тестировщика я спрашиваю, "что будет если", когда пытаюсь понять поведение легаси.
На стенде тестирования проводится функциональное тестирование и тестирование интеграций;
Он один на все команды или есть командные тестовые контуры? В первом случае когда одна из команд тестирует свой код, то все остальные волей-неволей тоже его тестируют, нарываясь на непонятные чужие баги?
Какое отношение имеют к основному тексту сноски State transition и Decision table в заключении?
Тестовый стенд один.
Разработческих – много.
Разработка проводится на командном разработческом стенде, поэтому влияния команд друг на друга при разработке нет.
Тестовый стенд подключается к делу на этапе, когда разработка уже закончена, весь код разных команд собран вместе. Этот стенд – как раз для проверки интеграций и взаимовлияний.
Такой подход позволяет упростить тестирование и поиск ошибок.
Просто интересно, а почему не упоминается статический анализ кода? По идее он идёт ещё раньше или параллельно с юнит-тестированием. Или статический анализ относится уже не к команде тестирования? Хотя юнит-тесты, вроде тоже не задача тестировщиков.
Как shift-left тестирование помогает ПСБ выявлять ошибки заранее