Home

Автор: Флегентов Илья (Haulmont)
Оригинальная публикация

Начнем с того, что в народе всех quality assurance инженеров (“по-нашенски”, инженеров отдела качества) обзывают тестировщиками. Это не совсем правильно, в реальности тестирование — это только часть задач QA, но кого бы это волновало. Поэтому пойдем в общем тренде и будем использовать привычное всем погоняло.

Итак, что же определяет хорошего тестировщика? Не будем опускаться до банальностей и говорить: внимательность, усидчивость, терпение, любопытство, талант все ломать и другую чепуху. Это все, конечно, важно, но не главное. В первую очередь у человека должно присутствовать чувство здравого смысла и ответственности.

Вот например, говорят, главное — иметь талант все ломать. Часто можно услышать, мол, что он в руки ни возьмет, все сломает. Это, конечно, похвально, но в работе тестировщика не главное что-то ломать. Тут к нам на помощь придет определение, которое нетрудно найти в Википедии.

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

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

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

Тестирование и не только

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

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

Вы уже понимаете, что история на этом не кончается.

Тестировщик попытался объяснить пользователю, в чем тот не прав, нарвавшись на порцию негатива и негодования. Пользователь усадил его рядом и открыл требования, на основе которых писались спецификации. Одно из этих требований почти дословно гласило следующее: ”Атрибут должен отображаться на каждом экране”. Одно предложение, а сколько смысла! Затем он открыл приложение и начал рандомно навигироваться на разные экраны, приговаривая: “И где же этот атрибут?”. Понятное дело, что пользователь откровенно издевался, но формально он имел на это право. Беда в том, что дальше пошла эскалация, и в процесс обсуждения проблемы вовлекалось все больше народу. Под конец пользователя убеждали, кроме самого тестировщика, несколько ПМов и толпа аналитиков, а тот был непреклонен и требовал уже невозможного.

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

Без фанатизма

Идем дальше, весьма иронично, сам процесс тестирования характеризуется бородатым анекдотом:

Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар.

Заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qwerty кружек пива.

Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают.

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

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

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

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

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

Язык мой — враг мой

Далее… Проблемы с документацией могут быть не только у аналитиков, но и у тестировщиков. Неоднократно было замечено, что не только разработчики не умеют внятно описать содержание тикета в соответствующем его поле, но и сами тестировщики не могут нормально написать порядок действий, вызывающих ошибку. Это большая проблема. Кто-то просто не понимает, из-за чего ошибка возникает, и не заморачивается выяснением шагов. У кого-то вообще проблемы с грамотностью.

Что это все за собой влечет? Тут ответ и ежу понятен, но на примерах, конечно, интереснее.

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

С грамотностью же все сложнее. На моей практике был случай, когда QA лиду нужно было исправить описание нескольких десятков тикетов, т.к. они должны были отправиться заказчику в отчете о проделанной работе. Это случилось потому, что большая часть команды не смогла грамотно сформулировать свои мысли на английском.

Но и с русским тоже бывают проблемы, слава богу, реже. Тут все то же самое, плохо написанное описание приводит к тому, что тикет, как футбольный мячик, начинает скакать между людьми, не попадая в ворота. Хорошо, если команда сидит вся в одном помещении и может просто поговорить, не вставая от монитора. Сложнее — если команда распределенная. Совсем плохо, если разноязычная. Самое худшее, что может произойти в итоге, это то, что тикет будет сделан неправильно из-за недопонимания и будет переоткрываться тысячу раз. А то и к заказчику улетит в одном из релизов с вывернутой логикой.

Личное пространство

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

А вот дофига чего… Если у кого-то есть доступ на сервер заказчика, с одной стороны — это удобно, можно посмотреть проблемы из первых рядов и не ванговать ошибку по фотографии. Но тут есть риск испортить данные заказчика, что может привести к серьезным последствиям. Я уже молчу о тех случаях, когда такой доступ вообще запрещен законом.

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

Такая же ерунда и с данными от заказчика. Опять же, я не говорю про случаи, когда это запрещено законом. Если есть возможность работать на реальных данных — это прекрасно, но с этим надо быть осторожным. Все наверно слышали истории про случайные отправки писем или сообщений с тестового сервера реальным пользователям. Так вот, это не шутки. Такое реально случается, причем достаточно часто. Ладно, если эти сообщения озаглавлены как тестовые и имеют вменяемое содержание, но бывает, что люди куражатся и пишут то, о чем потом жалеет вся команда разработки приложения.

Организационные моменты

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

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

Однажды тестировщика поставили на новый проект. Поскольку он его плохо знал, ему дали задание разобраться и записать наблюдения. Так как это было нечто неформальное, договорились, что писать будет в гуглдоке. Человек начал выполнять задание, через неделю это задание было проверено, тестировщика похлопали по плечу и он продолжил работу. Шли месяцы, у начальства появилось беспокойство, почему в багтрекере нет тикетов и ничего на проекте не делается. Начали разбираться, оказалось, что человек продолжает писать в том самом гуглдоке. Никто же не сказал “Горшочек, не вари” и не остановил тестировщика, а он исправно продолжал разбираться и записывать наблюдения, при этом никак не давая о себе знать. Баги есть, и он их нашел, но никому не сказал, а лишь записал в файлик, о котором спустя неделю уже все забыли.

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

Нередко недостаток информации создает ощущение о плохом тестировании продукта, что не была протестирована та или иная часть функционала. Чтобы такого не возникало, нужно составлять подробные отчеты, это особенно важно на крупных проектах.

Заключение

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

А если человек ответственно и со здравым смыслом подходит к своей работе, то ему удастся избежать большинство проблем на своем пути, не только в профессии QA.

Обсудить в форуме