Как организовать процесс тестирования с отдельным тестировщиком?
Итак, представим.
Приложение. Стейджинг. Тестирование.
Приложение падает, о чем тестировщик пишет во всех чатах. Упал фронт -> зовут фронта для выявления проблемы, фронт приходит и первым делом смотрит в консоль на вкладку Networks и видит, о боже, один запрос не отдал данные, поэтому всё и поломалось. После докладывает об этом в общий чат, где разбираться начинают бэкендеры. В итоге приложение поднято, тестировщик гордится собой, бэкендеры недоумевают из-за своего косяка, а фронт, фронт размышляет, почему позвали его? Неужели тестировщик не мог сам заглянуть в консоль, увидеть косяк в ответе на запрос и пойти пинать бэкендеров?
Думаю, ситуация вполне жизненная и распространенная.
Собственно вопрос: Как должен поступать тестировщик в таких ситуациях? Звать лишь бы кого, фронта, тех лида, менеджера, лишь бы кто-то посмотрел, в чем проблема или попытаться выявить ответственного самому с помощью минимальных манипуляций, подвластных даже ребенку (банальное открытие консоли)?
Тестировщик только фиксирует факт ошибки.
Дальше уже разбираются и фронт и бэк, потому что это их зона ответственности.
Ведь возможно, что там есть другие косяки фронта, о которых может знать только фронт.
Возможно, что на бэке всё верно, а это ошибка фронта, что он дёргает не тот метод API.
Откуда тестировщику знать,какой метод надо вызывать и что должно приходить в ответ?
Зависит от квалификации тестировщика. Если это джун или студент какой-нибудь за доширак, то какие претензии к нему?
Далее, фронт должен был сделать так, чтобы на экране была ошибка "упал бек", а самого падения фронта как такового (белый экран или что-то непотребное) быть не должно. Так что это халтура фронта в каком-то смысле.
Ну и наличие тестировщика не отменяет штатных тестов самими программистами. А в случае с вебом, да и вообще с любым сетевым ПО, или БД, или всякие разрозненные API, где всё так шатко, тесты должны быть встроены в само ПО. Тот же бек тоже не должен падать, а должен отдавать хоть какие-то данные, пусть даже это данные об ошибке. Клиент должен их обрабатывать, плюс учитывать свои ошибки, когда данные не сходятся. Ну а тестировщик нужен для отлова того, что не выловлено на этих стадиях. А если выявлено, то по текстам ошибок сразу можно найти виновника, даже если 3 часа ночи, и фронт с беком спят богатырским сном.
