Читая лекции студентам в одном из технических вузов (а я им рассказывал про тестирование), я заметил, что никто из них не планировал в будущем стать тестировщиком. Я учил будущих разработчиков, менеджеров, дизайнеров, системных администраторов -- и ни одного будущего тестировщика. Но при этом по статистике процентов 20 из них в итоге всё таки попадали в тестировщики, и нисколько не были разочарованы. Почему? Что это за профессия такая?
Непрестижная или просто неизвестная? Чем вообще тестировщик отличается от разработчика или системного администратора? С точки зрения постороннего человека все они "компьютерщики" или "айтишники". Но заглянув на внутреннюю кухню разработки компьютерных программ, можно выяснить, что разные тестировщики отличаются от друга весьма и весьма сильно (впрочем, некоторые разработчики также отличаются друг от друга гораздо сильнее, чем тестировщик отличается от разработчика). Приходите, я расскажу вам о том, чем занимаются эти странные люди, про которых все думают, что они "ломают программы".
Я много размышлял о проверках и тестах и том, как заставить их гармонично сосуществовать, и подумал, что мы упускаем что-то важное, создавая проверки. Я сконцентрируюсь на автоматических проверках, но думаю, что мои мысли применимы и к неавтоматическим.
Некоторые команды сейчас достигли неплохого прогресса в создании автоматических проверок. Они перенимают передовой опыт. Классы, методы и объекты грамотно названы, и совершенно очевидно, что именно они делают. Условия ясно сформулированы, и если они не выполняются, об этом сообщается четко и внятно. Проверки создаются с хорошим уровнем абстракции и повторным использованием кода, они достаточно производительны и выполняются быстро и надежно. Все это очень здорово выглядит.
Но почему эта чудесная, хорошо составленная и удобопонятная проверка вообще есть? Почему она существует? Почему из всех вариантов проверок была выбрана именно она? Я могу ее прочитать (как я уже говорил, она хорошо написана), я вижу, что именно она проверяет, но этим информация о ней исчерпывается. Как я пойму, что шаги и условия проверки соответствуют ее первоначальной цели? Что именно в этой проверке или этом поведении системы сделало их достойными кандидатами на автоматизацию? Я не знаю.
Случалось ли, что вы бесились, пользуясь компьютером?
Для такой реакции есть тысячи причин. Долго грузится сайт. Дурацкие сообщения об ошибках мешают вам работать. В пунктах меню совершенно невозможно найти то, что вам нужно.
Каждый раз, когда вас бесит что-то подобное, вы сталкиваетесь с тем, что в тестировании называют багом. Проще говоря, баг - это что-то, что вас раздражает, а моя задача - предотвратить проникновение багов к вам.
Чтобы сделать это, я разговариваю с людьми бизнеса, которые заказывали программу, с дизайнерами, решающими, как она будет выглядеть, и с аналитиками, определяющими, как именно она будет работать. Я вспоминаю прошлый опыт и стараюсь предотвратить повторение старых ошибок.
Я сижу рядышком с разработчиками, пишущими код, и подмечаю проблемные моменты, пока они трудятся. Иногда они что-то упускают, или я могу не согласиться с их подходом.
Когда программа готова, я проверяю, работает ли она. Я раздумываю, какими способами люди могут, случайно или намеренно, сломать ее, и стараюсь убедиться, что программа с этим справится. Я удостоверяюсь, что она работает на разных компьютерах и мобильных устройствах. Я проверяю, удобно ли ее использовать, отзывчива ли она, безопасна ли.
Все это время я занимаюсь тестированием. Я тестирую, когда я общаюсь с людьми. Я тестирую, пользуясь приложением на своем компьютере. Я тестирую, создавая автоматические проверки, которые можно прогонять неоднократно, чтобы убедиться, что различные части программы правильно работают.
Тестирование помогает устранить раздражающие вас штуки. Люди должны быть счастливы, используя программу, и тестирование вносит в это важный вклад.
Большая часть тестирования сейчас отдается на аутсорсинг. Я живу в Индии и полагаю, что большинство популярных веб-продуктов тестируются именно у нас. Мне повезло - недавно я получил возможность подключиться к тестированию реального продукта и отследить его путь от истоков до релиза.
Когда я учился, мне рассказывали о множестве видов тестирования. Я узнал о куче концепций - белый ящик, черный ящик, интеграционное тестирование, проверка исправности, тестирование ядра, компонентов, и так далее. Мы активно пользовались этими определениями, нанимаясь на работу. Если эти строки читают выпускники ВУЗов - готовьтесь, сенсационное сообщение! Реальный мир очень отличается от книг!
Итак, предлагаю вам свою историю и свой опыт по тестированию реального коммерческого продукта. Сразу скажу, что "минутка час бережет" - отличный лозунг тестировщика. Тестирование должно начинаться как можно раньше - в идеале, с первого же дня старта проекта. Хорошие методики тестирования должны быть гибкими и подстраиваться под ход разработки. Наша команда приступила к тестированию с первого же дня.
Хм-хм. А что проверять-то в первый день? Еще ничего не сделано, нет никакой функциональности, так что же нам тестировать?
Концепцию предвзятости я понимал смутно, пока не прошел курс Джеймса Баха "RST". Смысл понятия в том, что зачастую мы видим то, что наш мозг, наша психика хотят видеть, а не то, что существует на самом деле.
В целом, такая профессия, как тестировщик, существует именно благодаря предвзятому отношению.
Представим разработчика, создающего страницу регистрации для нового приложения. Он регистрирует нового пользователя, вводя свое имя, почту, дату рождения, и получает сообщение "Добро пожаловать, Стюарт Кук!"."Все работает", заключает разработчик, и переходит к следующей интригующей задаче.
Можем ли мы сказать, что регистрация была протестирована? Разработчик ввел данные, увидел то, что и хотел увидеть - приветствие системы - и убедился, что все работает как надо.
Все мы попадались на эту удочку не раз (я, по крайней мере, попадался) - один тест ничего не доказывает. Осознание, что мы склонны делать вывод "все работает", исходя из одного-единственного подтверждения - ключевой момент курса "Быстрое тестирование".
Ввести данные и получить сообщение "Привет, Стюарт" - неплохой старт. Но до финиша еще далеко.
Вдруг это просто сообщение? Что, если учетная запись не была создана? Мы можем проверить базу данных, или попробовать войти в систему, чтобы убедиться, что учетную запись можно использовать. Если разработчик еще не создал страницу авторизации, придется ограничиться базой данных. Вы же собирались ее проверить, правда?
А если мы зарегистрируемся как Вася - мы тоже получим сообщение "Привет, Стюарт"? Мелочь, а неприятно. Что, если поля регистрации будут принимать значения любой длины? А если мы введем туда полную ерунду - удастся ли создать учетку?
Наиболее распространенный подход к определению серьезности бага в той или иной формулировке встречается в большинстве источников. Например, у Романа Савина:
Критическая – системный сбой, потеря данных, проблемы с безопасностью.
Значительная – зависание, блокирование использования, кодирования, тестирования
У тестировщика миллион способов завести баг так, чтобы разработчики на него забили. Учитесь ставить такие задачи, которые будут исправлять.
1. Выберите тип
Разработчики не боги, они не могут делать все и сразу. Им нужно понимать, с чего начинать. Они сортируют задачи по типу — сначала новые функции, потом ошибки, потом все остальное.
Какие бывают типы задач:
Баг — ошибка в программе.
Улучшение — все ок, но хотим с перламутровыми пуговицами.
Новая разработка — такой возможности нет, а очень хочется.
Допустим, заказчик захотел новую возможность, а вы завели ее не как новую возможность, а как баг. Разработчики весь месяц делали другие новые функции, и до вашей не добрались. Заказчик в ярости: вы же обещали... А виноват постановщик задачи — умей выбирать тип!
У туриста мало времени, поэтому он выполняет конкретную задачу, ни на что другое не отвлекаясь. Он бегает по казино, или осматривает достопримечательности, или посещает деловой семинар. Что угодно, но что-то одно.
Вы нашли баг — но не можете его воспроизвести. Вы нашли баг, он успешно воспроизводился — но на следующий день больше не можете его воспроизвести. Вы нашли баг, он успешно воспроизводится — но только на вашей машине, а на других всё работает нормально. Вы нашли баг, он успешно воспроизводится — но только не на машине разработчика и он не может пофиксить его. Вы нашли баг, он успешно воспроизводился, и вот сам собой исчез, хотя разработчики говорят, что ничего не исправляли. Знакомо? Наверняка. Что делать в таких ситуациях? Писать в баг-трекер или не писать? А был ли баг вообще? Поверят ли вам? Сколько времени потратить на попытки воспроизвести хитрый баг? Я расскажу вам свои правила и маленькие хитрости, как действовать в этих случаях.
