— Что хуже: безграмотность, бескультурие или безразличие?
— Я не знаю, и мне похер!
Не уверен, что выбрал правильное название. То, о чем я собираюсь рассказать, по большей части относится к общей психологии, к общим же проблемам в сфере информационных технологий, и иногда просто к последствиям неправильного выбора профессии. Должен также отметить, что значительная часть нижеизложенного относится ко мне самому: человеку свойственно замечать в окружающих свои собственные проблемы. Тем не менее, все эти «особенности», как мне кажется, приводят к общему неприглядному виду отрасли, и профессии тестировщика в том числе. Большую часть примеров я набрал на собеседованиях, и, думаю, те, кто тоже этим занимались, найдут похожие детали.
Итак, за что я ненавижу тестировщиков, как встречаемых лично, так и виртуальных, например, посетителей профессиональных форумов?
Свой самовар. Привычки – это нормально. Отсутствие адаптации к команде – уже плохо. Я обычно делаю скидку на то, что большинство тестировщиков происходят из больших компаний, со своими правилами, дресс-кодом и прочими заморочками. Их поведение определяется тем, как их учили, и менять это поведение они не хотят, потому что так удобнее им. Наиболее яркий пример – нежелание осваивать принятый словарь – набор ключевых слов в описании проблем. Когда тестировщик приносит свой словарь с собой, в базе ошибок появляется невероятное количество дубликатов. «Был убит ударами молотка», «поскользнулся и ударился о молоток 5 раз», «множественные раны, нанесенные тупым предметом» – все это описание одной проблемы, но разным языком. Я считаю важным для тестировщика, чтобы он работал с принятым в команде словарем, процессами, и так далее. Иногда становится очевидно, что что-то в команде делается не так, но худшим аргументом будет «нас учили по-другому». Никого не волнует, как тебя учили. И как ты привык. Команда заинтересована в успехе команды.
Апатия. Для тестировщика это вообще смертный приговор. Вот перед нами окно с двумя полями ввода, текстовым и числовым. Ну конечно же, граничные значения, спецсимволы, обработка ошибок… Так выглядит формальное тестирование. Да, с точки зрения теории это правильно. Да, протестированный с таким подходом продукт будет работать без ошибок. Но есть большая вероятность, что продукт этот будет никому не нужен. Просто потому, что он уныл и бесполезен. Нельзя тестировать то, что тебе неинтересно. Не стоит вообще заниматься тестированием или любой другой работой, которая тебе не интересна. Здесь можно возразить: ну бывают же случаи, когда просто нужны деньги? Да, бывают. Бывают программисты, которые приходят на работу только потому, что их наняли «писать код». Бывают те, кто привык копать отсюда и до обеда. Или не копать до ужина. Но не надо ссылаться на прецеденты. Если тебе неинтересно – займись чем-нибудь другим. Мир очень велик, и у большинства людей есть возможность заняться тем, что им интересно. И что приносит им радость. Когда твоя работа радует тебя, результат её наверняка порадует кого-то еще. Кандидаты такого рода легко определяются на собеседованиях – у них стабильный послужной список, они не задают лишних вопросов и к решению любой задачи подходят с формальных позиций. Впрочем, я, похоже, отвлекся и забежал немного вперед. О карме мы еще поговорим.
«Стимулированная» апатия. Бывает очень похоже на первый случай, но есть нюанс. Нанимают на работу тестировщика, показывают, где лежат лопаты, дают ключ от ящика с ними, говорят, где копать, – и бросают. Метод Тургенева, безусловно, имеет право на существование, но Герасим все же за собачку свою переживал. В нашем же случае самомотивация работает некоторое время, а потом – оп! – и уже неинтересно. Или например, совершает человек ошибку, и ему больше не дают серьезных задач. «Чукча, покорми собак и смотри, ничего не трогай!» Лопата заменяется на напильник, получается этакая Золушка, углы заметать и фаску снимать. Можно подумать – а где же здесь вредные привычки, ведь во всем виноваты окружающие? На самом деле, связь (или общение) обычно требует участия как минимум двух сторон. Тебе кажется, что тебя бросили? Крикни что-нибудь сам – если нужна помощь, расскажи о том, что делаешь, дай людям знать, что ты еще не умер. Поставили в угол с напильником? Съешь «Растишку», сделай что-нибудь действительно хорошее, и похвастайся. В крайнем случае, если ничего не помогает – просто собери удочки и иди сверлить лунки на другом катке. Только не будь овощем.
Неуверенность, скрывающая безответственность. Здесь несложно спутать симптомы. Иногда тестировщик обращается за помощью к программисту, или к другому тестировщику, когда он чувствует неуверенность и хочет исследовать проблему более глубоко. Это хороший признак. В других же случаях он, обнаружив проблему, долго ищет, с кем бы поговорить об этом, ищет программиста, чтобы удостовериться, что он действительно нашел «баг», долго с ним это обсуждает, и в результате спускает все на тормозах. Одно из худших последствий такого поведения – проблема теряется, благополучно переживает все итерации тестирования, потом всплывает у пользователя и возвращается уже в виде инцидента. Нормальное явление – когда обнаруживаются не все ошибки, такое бывает, и приводит только к улучшению тестирования. Ненормальное – когда уже обнаруженные ошибки замалчиваются. Помните легенду о появлении термина «баг» в тестировании? Каждая ошибка должна быть аккуратно пришпилена булавкой к странице, описывающей её поведение. Багрепорт – это точка зрения, и каждая точка зрения заслуживает поддержки. «Я закрыл свой багрепорт, потому что программист сказал, что это не ошибка» — хороший пример безответственности. «Программист сказал ,что это не ошибка, но я нашел еще двоих и мы ему навешали люлей» — уже чувствуется движение в правильную сторону. Если ты высказал свою точку зрения, потрудись её отстоять, попытайся понять, почему она не совпадает с другими.
Любовь к процессам, скрывающая неумение работать. В речи такого тестировщика наиболее часто можно встретить: «давайте договоримся», «не буду тестировать без спецификаций», «не буду программировать без ТЗ», «уйди, противный!», «а вот если бы у нас был RUP…». Время течет. Мир вокруг меняется. Практика показывает, что в большинстве случаев универсального решения не существует. Почти каждая проблема требует своего собственного подхода. Ничем не поможет инструкция «перенеси вес на правую ногу, сделай шаг левой», когда ты в невесомости. Вообще эта часть должна быть в главе «апатия», потому что люди ведут себя так, когда им все равно. Тебе все равно? Займись чем-нибудь интересным.
Самоуверенность. Вот это, пожалуй, моя болезнь. Применяемый мной подход к тестированию хорошо описан в анекдоте о технаре, которому предлагают изучить китайский язык. «Методичка есть? Сейчас докурим и пойдем сдавать». Этот принцип позволяет очень быстро выявить серьезные проблемы, лежащие на поверхности, но упустить массу мелких дефектов, которые убьют продукт. Не понимаешь, что тестируешь – не берись. Понимаешь – сверь с кем-нибудь в команде, что понимаешь правильно. Только не надо на несколько дней уходить в подвал и приносить потом оттуда дохлую крысу.
Деградация. Что тут сказать? Резюме такого человека выглядит примерно следующим образом: «Админ. Программист. Программист. Тестировщик.» Все мы знаем, что люди часто ошибаются в выборе профессии, и потом внезапно находят свою родную специальность. Был крановщик – стал пианист. Был пианист – стал слесарь. Другие люди точно так же ошибаются, но «залипают» в своей области. Поступление в университет: проходит зачисление на «высшую» специальность, непопавшие в студенты бегут в деканат, быстро переписываются на следующую по списку специальность, идут на зачисление. И так далее. Такое поведение вполне можно понять, самокопание и разочарование свойственно человеку. А тестирование принято считать «низшим классом» в ИТ-отрасли. Вот они и думают, «раз я плохой программист – может, попробовать тестирование? Я плохой тестировщик – может, пойти компы собирать?» Нет, не может. Я в разговорах постоянно ссылаюсь на некий опросник, который я проходил в еще прошлом веке в Центре профориентации. Очень просто, 3 или 4 шкалы: человек-человек, человек-природа, человек-знаковая система, еще что-то. Если ты видишь, что в ИТ не получается – остановись и подумай. Может быть, ты всю жизнь мечтал быть лесником, но большие города и зарплата от полутора штук заставили тебя переступить через собственную мечту. Печальное зрелище.
Профессиональная стагнация. Королева сказала Алисе: «нужно быстро бежать, только чтобы не остаться на месте» (не уверен в точности цитаты). И это совсем не сказка и вовсе не гипербола. Начинающий тестировщик читает пару книжек, работает пару лет «обезьяной» на каких-то проектах, наконец находит вакансию своей мечты, устраивается на новую работу, и – торжественно засыпает на ней. Ему уже не надо подавать ключи, он сам крутит гайки, и, в общем, вполне этим доволен. «Что читаете в интернете? – Нууу, захожу на этот, форум такой, тестировщиков». «Работаете над этим проектом несколько лет? А на чем написано приложение, и как это влияет на тестирование? – Эээ… как-то не приходило в голову узнать». «Как себе представляете автоматизированное тестирование? – Не знаю, я им не занимался». Большие люди самых разных специальностей все как один повторяют: «первые десять лет работы я только учился, потом начало что-то получаться». Некоторые спрашивают на форумах – «Чем бы заняться тестировщикам в промежутке между проектами?» Самый простой ответ – учиться дальше.
Художники. Необходимым условием существования этих людей является система багтрекинга с поддержкой приложения файлов. Багрепорт чаще всего выглядит так: «Увидел ЭТО. Смотри аттач.» Скриншот – это фотка графического интерфейса. Интерфейс меняется. В результате уже по прошествии небольшого времени из картинки нельзя понять, что происходит, и в чем проблема. Некоторые говорят, что снятие скриншота экономит время. Я пробовал – написание детального отчета действительно занимает больше времени, чем снятие картинки – редактирование её в пейнте – приложение её к отчету… Но мне нравятся хорошо сформулированные багрепорты, которые остаются актуальными даже через несколько лет, и которые отлично ищутся по ключевым словам.
Выстрелил и забыл. Очень удобно, когда хочется поиграть с разработчиками в виртуальный теннис, или чтобы они за тобой побегали. Как делать: увидеть проблему, максимально сократить шаги дял повторения (здесь даже возразить нечего, короткий путь действительно необходим, даже в книжках так пишут), закинуть в систему отчет об ошибке. Забыть. И получить его через пару дней обратно как «не повторяющийся у разработчика». Загрузить снова свою измученную тестами базу, запустить приложение, ткнуть пару кнопок, повторить проблему, отправить обратно как «у меня все очень даже повторяется». Когда отчет вернется снова, пожаловаться менеджеру. Весело? Не очень. Вообще говоря, ошибки бывают у всех. Человеку вообще свойственно ошибаться, некоторые даже думают, что человек и сам – ошибка природы. Но, перефразируя Канера с друзьями, можно сказать: отчет об ошибке – это доверенное лицо тестировщика. И если отчет плохой, тестировщик теряет доверие. Его не побегут спасать от волков или от вируса, убивающего осколками монитора. Сообщенные им проблемы будут исправлять в последнюю очередь. Потом, ясное дело, депрессия, апатия, ну и так далее, выше там было написано. Чтобы этого не было, нужно постоянно заботиться о своих отчетах, кормить их новыми подробностями, интересными аттачами. Присматривать за ними. Ошибка долго не исправляется? Значит, либо отчет потерялся, либо он просто плохой, а недавно пришедший разработчик просто еще не в курсе, что не он виноват в «неповторимости» проблемы. Мне кажется, неплохой практикой может быть, например, пересмотр своих отчетов в конце дня или через день. Только не совсем сразу, ему нужно немного дозреть, а автору – подумать немного. Насколько я знаю, похожий подход используется при написании вообще любых текстов: написать, отложить, через некоторое время вернуться и сделать лучше. В терминах разработки это будут те же итерации, только продукт в нашем случае – отчет о найденной и исследованной проблеме.
Бездумная автоматизация. «Как автоматизировать тестирование биллинга?» – спрашивает такой тестировщик на форуме. Он не задается вопросом, что такое биллинг, как его протестировать, ему просто нужно, чтобы все крутилось само. Вообще это странная тема. Я никогда не работал в компаниях, применяющих средства тестирования графического интерфейса, так что могу только предполагать, как это выглядит. Большие пацаны читают рекламу средства тестирования (как правило, мягко обходящую тему затрат на это дело), звонят в отдел кадров и нанимают отряд обезьянок. Надо же ведь просто кликать по кнопочкам, значит подойдут и идиоты. Пучок за пятачок. Не знаю, как там у них все это проходит, но читал недавно у кого-то, что до 90% времени, потраченного на автоматизацию GUI – просто зря потраченное время. На самом деле, автоматизация – очень полезная штука, и часто она стоит затрат, но думать, что автоматизация тестирования – это когда робот вместо тебя кнопает по кнопкам и кликает по ссылкам, совсем неправильно. И уж совсем неправильно заниматься автоматизацией, когда не понимаешь, зачем это и чем это поможет конкретно тебе и твоим коллегам.
Вертикальная карьера. Лично мне кажется, что во всем виновата неправильная реклама. Существуют, в принципе, два направления развития – рост вверх по карьерной лестнице, и «утолщение» в профессиональном плане. По каким-то причинам считается, что вертикальная линия более правильная. Да, в каких-то случаях это так. Но многие забывают, что реальный рост – это в большей степени не расширение полномочий, а увеличение ответственности. На этом строится стандартная шкала «взросления» – Junior-Engineer-Senior, где джуниор не стыдится попросить помощи, а сениор в основном только и делает, что помогает другим. В нашем же случае кандидат, претендующий на позицию «ведущего специалиста», заявляет: «ну, я могу раздавать задания». Ну надо же! Говоря в терминах собеседования при найме – решите сразу, кто вам нужен. Талантливый управленец или талантливый специалист. Если действительно нужен управленец, и кандидат проявляет хорошие способности к этому – почему бы и нет? Если он из разряда «кто не умеет – учит» – оно того не стоит.
Ссылки по теме:
