Тестировщик Омега: когда ты один в поле
В фильме «Человек Омега» Чарлтон Хестон сыграл роль учёного-солдата — единственного выжившего после того, как чума уничтожила человечество. Ну, не совсем единственного. Ему ещё пришлось сражаться с ордами мутантов-зомби. Как это относится к тестированию? Независимо от того, является ли проект низкобюджетным или же ваша команда стремительно пробивается к режиму гибкой разработки, многие команды недоукомплектованы. Скажу даже так: если ваша команда пока ещё работает в полном составе, будьте уверены — это ненадолго. Многие тестировщики работают над своими проектами в одиночку. И даже если вы состоите в большой команде, ваши сотрудники могут работать над другими элементами продукта или просто оказаться разбросанными по всему миру. Как Чарлтон Хестон в фильме, «тестировщик омега» должен быть внимательным и находчивым.
Как бы вы ни пытались, всегда останется что-то, что вы не сделаете. Только не говорите, что сможете делать несколько дел одновременно. Многозадачность — для менеджеров и других людей, которым не требуется делать что-то, что требует особых умственных усилий. В тот момент, когда вы садитесь и начинаете тестировать что-то конкретное, любые другие элементы продукта, любые совещания, любые ваши приготовления и самообучение — всё должно быть отложено на потом. Когда вы тестируете, вы становитесь однозадачной программой, не заботящейся о растущей очереди из других дел.
Вы слишком заняты, чтобы планировать и готовиться. У вас всегда будут мануалы, которые надо проштудировать, разработчики и пользователи, которых надо опросить, тестировочные программы и виртуальные платформы, которые надо настроить, всегда будут встречи, на которые было бы неплохо сходить. Вам нужно достаточно узнать о продукте, чтобы представить себе риски и обозначить для себя стратегию тестирования. Однако, как только появится готовый билд, разработчик начнёт давить на вас: «Тестируй, тестируй, тестируй, холоп!»
«Да погодите же!» — скажете вы — «У меня тут проект в разгаре, я не имею права перескочить на другую задачу, пока не покончу с этой».
Да, для нас, тестировщиков, было бы очень здорово, если бы этапы тестирования были жёстко привязаны к этапам разработки. Но дело в том, что в большинстве случаев это просто невозможно — это совершенно несимметричные процессы. Поспешно завершённая разработка часто приводит к затянувшемуся тестированию. Представьте, что программист просто берёт несколько баз данных, ляпает их в одну и отправляет вам на тестирование. ЕМУ не потребуется много времени на такого рода «работу». Что же до вас… Добро пожаловать в Дом Боли! Вам незамедлительно потребуется написать сотни страниц запутанной тестовой документации. Конечно, можно просто пропустить этот шаг и сделать несколько записей для затравки. Но какими словами вы станете себя клясть, когда должны будете перейти к глубокому тестированию и просто запутаетесь в том, что уже сделано, а что нет? А ведь разработчики постоянно будут добавлять что-то новое, ожидая, что вы тут же бросите всё и приступите к тестированию именно вот этой приколюхи. Они создают функционал, но при этом всегда автоматически создают проблемы с производительностью, надёжностью, удобством и прочим. Добавить подобных проблем им ничего не стоит (ни разу не видел пункта “накинуть багов” в списке дел разработчика, но поверьте, он всегда найдёт время, чтобы впихнуть парочку), но вы потратите много времени и ресурсов, чтобы отловить их все до единой.
Вы слишком заняты, чтобы поддерживать самоорганизованность. Когда вы тестируете, вы учитесь. Вы создаёте текстовые файлы и делаете в них заметки. Ваш рабочий стол оказывается захламлён, записи всё копятся и копятся. По мере продвижения проекта, чем дальше, тем сильнее начинает казаться, что на вас повесили долг, процент по которому постоянно растёт. В такой ситуации нужно сделать перерыв в тестировании и потратить немного времени на то, чтобы упорядочить свои заметки и тестовую документацию, обновить список рисков и обозначить для себя способы их устранения. Если вы успеете подготовить подобную базу заранее, то ощутимо повысите собственную эффективность. Однако нередко может оказаться так, что такая эффективность — роскошь, которую вы не сможете себе позволить. И впрямь, какой пожарный станет заправлять машину прямо во время пожара?
Вы слишком заняты, чтобы проявлять любопытство. Когда тестируете, вы исследуете эвристическим методом. Это значит, что вам не известен самый правильный способ найти то, что вы ищете. Есть несколько базовых методик тестирования, но их редко бывает достаточно для наилучшего результата. Этот самый наилучший результат потребует нечто большее, чем поиск привычных багов в привычных местах. Вы должны включить любопытство. Тестирование должно стать для вас игрой. Вы должны с предвкушением готовиться к неожиданностям (как бы парадоксально это ни звучало). Многим тестировщикам очень трудно понять и принять это. Вас будет снедать ощущение, будто вы увиливаете от работы вместо того, чтобы делать что-то полезное. Из-за этого любопытство очень легко отложить в сторону (особенно когда не продохнуть от накопившихся дел), но в таком случае вы становитесь чем-то большим, чем игрушечная заводная машинка, но чем-то куда меньшим, чем настоящий опытный тестировщик.
Никто не понимает, какой вклад вы вносите. И программисты, и тестировщики делают нематериальную работу.
Разница в том, что у трудов первых есть материальный конечный результат — готовый продукт. Результат же работы тестировщика не столь материален, и чтобы сделать его таковым, потребуется потратить много времени на работу, которая к тестированию имеет посредственное отношение. Многие люди думают, что тестировать легко («просто запусти и посмотри, работает ли оно!») и очень удивляются, узнав, сколь много времени приходится потратить, чтобы найти все эти «очевидные» баги. Когда вы работаете в большой команде, то можете хотя бы разделить со своими коллегами необходимость объяснять в сотый раз, что невозможно протестировать что-то досконально. Будучи же одиноким «тестировщиком омегой», в какой-то момент вы почувствуете, что окружены толпой мутантов-зомби, которые считают, что именно вы — монстр, а не они.
Что со всем этим делать? Мои советы «тестировщику омеге» состоят из ряда технических и социальных идей.
Технические идеи
Забудьте о тест-кейсах и готовых инструкциях. Продумывайте механизм тестирования и историю тестирования. Когда я тестирую, я не думаю «Щас бы тест-кейсов понаписать», я думаю о тестировании. Иногда результатом может оказаться очень специфичная тестовая документация и прочие странности, которых трудно избежать при аврале. И бог с ними. Написание тест-кейсов — не тестирование. Настройка продукта, работа с ним, его изучение и оценка — вот это тестирование. Из-за того, что вы и так перегружены, я лучше предложу вам продумать, что необходимо сделать и что нужно подготовить, чтобы это сделать. Детализированная тестовая документация не попадает ни туда, ни туда. Сосредоточьтесь именно на тестировании или обдумайте доклад по проведённому тестированию (он может быть даже устным) и тогда вы сможете сделать куда больше полезной работы.
Пусть риск будет вашим компасом. Распространённой тестовой стратегией является организация тестирования вокруг определённого образца, типа спецификации или технического задания. Разумеется, всё это очень важно, но я бы предложил контроль рисков. Под этим понятием я подразумеваю фокусирование на наиболее важных элементах продукта и поиск самых критичных багов. Поначалу вы будете слабо улавливать, что за риски следует брать в расчёт в первую очередь, но не прекращайте спрашивать себя «о каких именно элементах мы сильнее всего беспокоимся ПРЯМО СЕЙЧАС?» и по мере того, как проект будет продвигаться, вы начнёте понимать это всё лучше.
Тестируйте короткими, точными, непрерывными сессиями. Выделяете отрезок времени (я предпочитаю 90 минут), ставите на стол табличку «УШЁЛ ИСКАТЬ БАГИ», выбираете самый подверженный риску элемент продукта и начинаете тестировать именно его.
Делайте при этом краткие записи о текущей сессии (предложение-два о предмете тестирования). Это важно, потому что вы, как одинокий тестировщик, должны очень чётко осознавать свой прогресс. Слишком уж легко позволить электронным письмам и личным встречам отвлечь вас от самого процесса тестирования, и в конце-концов вы можете обнаружить, что провели весь день, толком ничего и не сделав.
Используйте неожиданные перерывы для самоорганизации, подготовки и переосмысления. Такие перерывы будут возникать более-менее регулярно во время работы над любым проектом. Я говорю про то время, когда вы ждёте новый билд, потому что разработчики не смогли что-то там правильно установить на тестовом сервере, или про другие случаи, когда по какой-то причине вы не можете выполнять свою работу. Вам нужно пользоваться этими возможностями, чтобы пересмотреть свою стратегию, попытаться продумать что-то заранее или привести свои заметки в порядок.
Пользуйтесь сокращённой тестовой документацией. Я имею в виду списки, наброски и таблицы. Я люблю использовать для этого вики-движок или гугл-диск. Используйте нечто доступное онлайн, доступное для совместного использования, что-то, что имеет историю записей. И когда я говорю «сокращённое», я имею в виду, что вы должны записывать только то, что вам нужно, и не более. Таблицы, наброски, списки. Никаких детальных инструкций. Не расписывайте очевидные для вас вещи. Если вы не ищете баги в Microsoft Word, излишняя писанина уж точно не поможет вам в тестировании (про форматирование текста я вообще молчу).
Используйте записывающие инструменты, чтобы сократить время исследования бага. Говорят, что сценарное тестирование эффективнее, чем исследовательское тестирование в ситуации, когда дело доходит до изучения бага. Это абсолютно неверно. Список шагов, который вы написали пару месяцев назад, куда менее полезен, чем список, который вы написали только что, особенно учитывая, что вы стали на целых два месяца мудрее, а ваши свежие записи держатся в голове куда лучше. А в и идеале вы вообще не должны расписывать свои шаги, потому что они уже будут автоматически записаны специальными программами. Есть множество как платных, так и свободно распространяемых инструментов для этого. Мне нравятся BBTestAssistant, TestExplorer и Spector. Помимо них ещё есть, например, бесплатный Wink. Не забывайте, конечно, и о логах, особенно если вы тестируете что-то онлайн. Ну а если вам лень заморачиваться, просто на цифровую камеру снимайте.
Соблюдайте баланс между исследовательским и сценарным тестированием. Это значит, что вам следует тестировать согласно сложной поведенческой модели реального пользователя, сосредоточенной вокруг последовательного сценария. Главной недостаток этого метода заключается в том, что вам потребуются в помощь реальные пользователи в случае, если вы не понимаете в полной мере то, как они думают и что они будут делать с вашим продуктом. Подобный вид тестирования напоминает бета-тестирование, организованное на высоком уровне и сосредоточенное не на повседневных, а на усложнённых ситуациях, и выполняемое людьми, страдающими манией искать баги.
А теперь к социальным идеям. В отличие от Чарльтона Хестона, за которым большую часть фильма гонялись зомби, вам потребуются социальные навыки, чтобы стать по-настоящему хорошим «тестировщиком омегой». Именно ваши социальные навыки вас спасут.
Социальные идеи
Подчеркните своё желание принести пользу. Работая с командой разработчиков, я объявляю им список вещей, которые я обязуюсь сделать. В нём перечислено несколько обещаний, которые я им приношу, будучи тестировщиком. Я не хочу, чтобы они считали меня балластом. Я не хочу стать мухой, бесцельно жужжащей им в уши. Я хочу облегчить их ношу, не утяжелить её. Я хочу служить своей команде всеми доступными мне способами. Убедившись, что меня услышали, я часто получаю такое же отношение в ответ. Это облегчает мою работу, потому что их помощь жизненно важна для меня. Успех любой идеи из перечисленных ниже начинается именно с этой.
Снизьте планку требований к вам. «Урааа, мы наняли тестировщика! Теперь у нас не будет багов после релиза!» Люди думают, что тестировать легко. Они думают, что ваша работа заключается в том, чтобы просто «проконтролировать качество». Вам следует разрушить эти иллюзии сразу же.
Вы должны объяснить, что нет какой-то теории тестирования, нет каких-то верных практических техник, нет программы, которую можно запустить и увидеть, что баги отсутствуют. Ну вот совсем нет.
Всё, что вы можете пообещать — упорно и внимательно поискать проблемы. И забудьте это словосочетание — «проконтролировать качество». Вы помогаете своей команде создать качественный продукт. Вы являетесь важным винтиком в рабочем процессе, но вы не являетесь тем, кто контролирует качество. Лишь глава проекта можете заявить, что обладает этой властью (на самом деле, он тоже не может проконтролировать качество, только не говорите ему об этом).
Пересядьте поближе. Конечно, устроиться за тем же столом, что и программисты, зачастую не в вашей власти, но постарайтесь подсесть как можно ближе. Ваша продуктивность значительно повысится, если вы будете находиться в шаговой доступности от людей, которые создают продукт. По моему мнению, она возрастает аж в два раза по сравнению с разделяющим вас расстоянием в десяток миль, и в четыре раза по сравнению с расстоянием в десяток часовых поясов.
Тренируйтесь, тренируйтесь и тренируйтесь объяснять механизм тестирования. Недостаточно уметь тестировать. Если вы работаете в одиночку, поздравляю, теперь вы должны быть готовы объяснять механизм тестирования, расписывать его пользу, учить ему. Снова и снова. Зачастую — одним и тем же людям, потому что они постоянно будут забывать ваши объяснения. Неплохой способ попрактиковаться в этом — вести блог о тестировании, или же давать людям советы на форумах тестировщиков.
Требуйте тестируемости. Тестирование и разработка не симметричны. Небольшое изменение, внесённое дизайнером, не стоящее ему особых проблем, может добавить вам много лишней работы. Вы должны аккуратно подобраться к нему и вежливо (то есть, без мата) объяснить, что следует учитывать, как сильно усложняется работа других участников проекта в зависимости от того, что меняется или добавляется. Не думайте, что кто-то поймёт, что такое тестируемость, пока вы им это не объясните. Суть тестируемости — два больших вопроса: А) Это изменение можно увидеть? Б) Это изменение можно проконтролировать? Поэтому я всегда упрямо добиваюсь подробных логов и настраиваемого интерфейса (конечно, я радуюсь, когда у меня имеется специально приспособленный для тестирования интерфейс, но когда я могу подстраивать его под себя, у меня есть возможность контролировать и видеть продукт лучше.)
Требуйте адекватного предварительного тестирования.
Это не так важно, если вы сотрудничаете с хорошей командой тестировщиков. Довольно трудно заставить разработчиков работать немножко более методично. Ещё труднее не выглядеть при этом нытиком. Но если вы тестируете в одиночку, у вас просто нет иного выхода. Вы должны достучаться до них и объяснить, с какими трудностями вы сталкиваетесь. Если они не тестируют базовые элементы сами, или не работают в парах, или не занимаются чем-то подобным, позволяющим выловить простейшие баги до того, как билд отправится к вам, то вы будете завалены жуками, как Имхотеп из «Мумии». Будете, как участник Форта Боярд, пытаться загрести побольше монеток, и всё равно оставить большую их часть нетронутой. Если вам нравятся спортивные сравнения, объясните своей команде, что вы хороший вратарь, но даже величайший вратарь не способен отбивать мячи, летящие со всех сторон, особенно если часть этих мячей накидывает своя же команда.
Избегайте бюрократичных баг-репортов. Поиск багов и написание отчётов по ним требует много вашего времени. Чем больше времени вы потратите, тем меньше у вас останется на поиск новых багов. Но если вы работаете рядом с программистом, чей код вы и тестируете, вы обнаружите, что многократное повторение приводящих к багу шагов и написание отчёта становится бессмысленным. Он видит, что именно вы делаете, и немедленно реагирует на обнаруженные проблемы. Я на своём опыте понял, что это лучший способ протестировать что-нибудь на ранних стадиях. Я работал над проектом, в котором моим тестировщикам приходилось использовать допотопный баг-трекер. Это напоминало заполнение налоговых деклараций. По нашим подсчётам оказалось, что мы теряли около 30 минут лишнего времени на каждый баг-репорт. Помимо всего этого, нам не было позволено разговаривать с программистами. Мы никогда не слышали и не видели их. Ужасающая прорва времени пропадала впустую. Если вы работаете в одиночку, намекните своему менеджеру, что принесёте больше пользы, если будете искать баги, а не писать отчёты.
Мой главный совет Тестировщику Омеге
Если вы «тестировщик омега» и чувствуете, что окружены существами, внешне похожими на тестировщиков (руки-ноги-голова, ДНК и прочее) и всё равно невероятно отличным от вас, не отчаиваетесь. Подружитесь с ними. Добейтесь, чтобы они стали вам помогать. Вот маленький секрет: люди будут помогать вам тестировать, если вы сделаете этот процесс простым и весёлым. Назовём таких людей бета-тестировщиками.
Бета-тестировщики могут помочь вам в тестировании, но не заставляйте их делать какую-то бумажную работу. Мне довелось однажды побывать бета-тестировщиком одного из первых планшетов (самых-самых первых, он назывался Magic Link или как-то так). Я только через пару недель понял, что в «Сони» ожидали, что я буду писать чуть ли не поминутный лог, в подробностях расписывающий всё, что я делал с их железякой. Ха. Ха. Ха. Неа, я просто натыркал каких-то левых данных и вернул её.
От профессионального тестировщика ожидается очень многое. Вы должны уметь писать доклады, объяснять свою стратегию тестирования и свои догадки. Вы должны понимать риски и уметь использовать тестовые инструменты. Но ни в коем случае не перекладывайте эти обязанности на бета-тестировщиков. Лучше создайте праздничную атмосферу старой доброй охоты за багами. Когда под моим началом работает команда тестировщиков, я сначала проверяю, все ли они сыты, потом усаживаю по парам и даю каждой паре колокольчик с наказом звонить, если попадётся что-то, похожее на баг. Бета-тестировщики получают замечательную мотивацию, если чувствуют, что их уважают и слушают.
Ещё неплохо показало себя поощрение за поимку критических багов. Можно награждать деньгами, а можно устроить что-то вроде аукциона, на котором за вашу игровую валюту можно получить приятные ништяки (второй метод, кстати, не даст вашему бюджету внезапно вырваться из-под контроля).
Кто же Настоящие Зомби?
Если вы по-настоящему крутой «тестировщик омега», в какой-то момент вы обнаружите, что другие члены вашей команды через некоторое время (может потребоваться несколько проектов) станут уважать вас и полагаться на вас. В ином случае, если вы предпочитаете разводить бюрократию, пессимизм и уныние, в конце-концов ваша команда будет считать именно вас зомби-мутантом. Первый признак — они начнут убегать, едва завидев вашу фигуру, шаркающую в их сторону и вытягивающую руки к их мозгам с явно недвусмысленными намерениями. Не надо так, хорошо?
Текст: Джеймс Бах, тестировщик ПО, автор книг по тестированию, консультант и тренер.
