Выбрать главу

Выкладка кода в тестовую среду. Продуктовый сайт – это сайт, которым пользуются реальные пользователи. Это конечный пункт назначения. Залив на него новый код, можно столкнуться с непредвиденными проблемами. Их устранение может привести к простою сайта. Это, непременно, вызовет большое недовольство пользователей или даже приведет к финансовым издержкам. Быстрая починка багов на продуктовом сайте может принести еще большие проблемы. Поэтому, как только клиент одобрит новый код, его следует выложить в тестовую среду (Stage environment). Он представляет собой полную копию продуктового сайта (иногда даже с базами данных). Это позволит узнать, какие проблемы могут возникнуть на продуктовом сайте, а также произвести тестирование в условиях приближенных к реальным. Задача тестировщика – проверить работоспособность сайта после выкладки.

Выкладка кода на продуктовый сайт. Выкладка кода на продуктовый сайт – это наиболее ответственный этап во всем процессе разработки. Выполняется он по такому же сценарию, что и выкладка кода на тестовый сайт. Если Вы используете один сервер, то всю процедуру нужно выполнить максимально быстро, чтобы сократить время простоя сайта. Использование нескольких серверов немного снижает риски, но увеличивает трудозатраты. При таком подходе один из серверов отключают. Вся нагрузка распределяется на оставшиеся серверы, поэтому выкладку лучше выполнять в часы с минимальной нагрузкой (выясняются опытным путем). Затем обновляют код отключенного сервера, тестируют его и включают обратно. Вся процедура повторяется до тех пор, пока не будут обновлены все серверы.

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

Начало Работы

Попадая в команду, новый тестировщик оказывается в “колыбели”. Вся наиболее сложная работа проделана более опытными коллегами. Новичку, скорее всего, доверят тестирование какой-нибудь новой фичи, по которой уже собраны все требовании и написаны чек-листы (Check-list – список того, что нужно проверить при тестировании). После новичка всё еще раз протестируют. Здесь как раз можно хорошо проявить себя, поэтому вначале мы рассмотрим подходы к тестированию c наиболее распространенных элементов приложения.

Начнем с формы с несколькими полями, в которые нужно что-то ввести. Данные будут сохранены при нажатии на кнопку. Для простоты в начале на нашей форме будет только пара текстовых полей и собственно кнопка – “Сохранить” (Submit).

Первым делом нужно проверить, что форма хоть как-то работает и готова к тестированию. Для этого выполним самый позитивный кейс (case). Кейс – это тестовый случай. Если весь процесс тестирования разделять на кусочки, то кейс – это минимально возможный кусочек, как квант для энергии или фотон для света. Под самым позитивным кейсом понимают действия, которые пользователи будут выполнять чаще всего. Например, в поле “Имя” пользователи чаще всего будут вводить значения типа “Иван”, “Петр” и т.д., а затем будут нажимать кнопку [Submit]. Это и будет самый позитивный кейс. Начинать тестирование всегда нужно с самых позитивных кейсов. Это непреложная истина тестирования. Начинать тестирование поля “Имя” с ввода строки типа “?><@!#” – дурной тон. Скорее всего, Вас посчитают дилетантом или человеком недалеким. Если позитивный кейс не прошел, то возвращаем эту форму на доработку с комментарием: “Плохое альфа-тестирование. Позитивные кейсы не проходят”. Альфа-тестирование – это тестирование, которое должен делать программист перед тем, как отдать новый функционал (feature) тестировщикам. Он должен проверить позитивные кейсы. Программисты нередко ленятся это делать, считая тестирование чем-то недостойным их величества, за что могут получить от руководства, ибо потратили время тестировщика впустую. Тестировщик должен искать сложные баги, придумывая разнообразные ситуации, а не открывать форму и видеть, что ничего не работает.