Мантра начинающего тестировщика⁠⁠

Я глубоко убежден в том, что в большинстве it-проектов, где вовсю полыхает костер конфликта "тестировщики vs программисты", чаще всего дровишки подбрасывают именно тестировщики. Они не понимают нужды конкретного проекта, по-своему истолковывают требования заказчика. Многие из них даже не в курсе, в чем заключается работа тестировщика вообще. В итоге имеем то, что поднять вопрос о престиже профессии не поворачивается язык даже у самых отчаянных и радикальных их последователей. Никто в здравом уме не идет в тестеры целенаправленно, по призванию или так как с детства мечтал быть тестировщиком. Чаще всего вхождение в тестеры происходит спонтанно, по связям, из-за отсутствия вакансий после окончания вуза, из-за нужды в деньгах, по советам знакомых айтишников или по другим необъяснимым для человека причинам. Короче, случайных людей в тестировании хоть отбавляй. Далее я попытаюсь изложить свои мысли насчет того, с каким настроем бы относился к своей работе, будь я тестировщиком с относительно небольшим опытом работы в какой-либо продуктовой или аутсорсинговой it-компании средней величины.

1) На текущем проекте я призван играть второстепенную роль. Все до безобразия просто: либо снимаю розовые очки и работаю, либо закрываю дверь с той стороны. Отношение ко мне со стороны программистов мерзкопакостное, как к человеку, который получает деньги за просто так, кликеру по формочкам и эксперту по никаким вопросам. Я сейчас не прокачан настолько, чтобы попасть в крутые компании (речь даже не об уровне Microsoft или Google), где тестировщик воспринимается как равноправный человек. Поэтому и веду себя соответствующим образом: выполняю свои непосредственные должностные обязанности, пытаясь уложиться в поставленные начальством сроки. Не строю из себя всезнайку, примадонну, строгого судью, тонкого психолога, способного подловить собеседника на лжи по взмаху его ресниц. В случае зазнайства надо быстро снять корону и положить ее на дальнюю пыльную полку до лучших времен (которые в нынешней конторе вряд ли настанут). Я не потираю ехидно ладошки, когда в состоянии потока в результате часового пиксель-хантинга под IE 6 нашел поехавшую верстку. Наверняка об этом не следует знать никому другому на свете и любой, кто поднимет подобный вопрос, будет исключен из общего чата. Кстати стоит хорошенько задуматься, почему я настолько уныл, что битый час тестирую фронтенд на наличие минорных багов, хотя поручено было проверить функциональность и логику работы программы.

2) Я не вмешиваюсь в работу остальных отделов со своими сверхценными и безусловно полезными советами. Не проявляю бредовых инициатив, не пытаюсь жирафить или лезть в командиры. Если где-то и существует креативная, разносторонняя личность, то это точно не я. Проблема как раз и заключается в существовании синдрома фонарного столба: я ищу там, где светло, а не там, где потеряны ключи. Я, к сожалению, воспринимаю проект только с позиции узколобого тестировщика и не имею полной картины происходящего. Именно поэтому иногда мне чудится, насколько же кардинально можно улучшить наш проект, стоит только чуть побольше внимания уделять тестированию. Разработчикам, без руля и ветрил, сломя ноги надо броситься внедрять TDD, писать до ночи юнит-тесты, обеспечить стопроцентное покрытие кода. Менеджерам наивысшим приоритетом для проекта ставить качество проекта с точки зрения тестировщиков, всегда немедля ни секунды принимать положительное решение об исправлении каждого заведенного мною запроса. Техническим писателям лучше вчитываться в документацию, чтобы искоренить грамматические ошибки. Дизайнеру проверять макеты на предмет того, что можно еще улучшить и думать только об удобстве интерфейса для пользователя. Бизнес-аналитику чаще размышлять над двусмысленными требованиями в техническом задании, интересоваться мнением заказчика о качестве продукта посредством анкетирования, доносить до него мнение отдела тестирования по всем возникающим вопросам. Менеджеру по продажам акцентировать внимание клиента на том, что наша компания сертифицирована по ISO и производит только высококачественные продукты... Все перечисленное звучит вроде правильно, да? Но как известно, благими намерениями дорога в ад выстлана, а лучшее враг хорошего. На самом же деле, я дилетант широкого профиля. Кроме тестирования я по сути ни в чем не смыслю даже поверхностно: ни как грамотно руководить людьми, ни как писать работающий код, ни как делать полную документацию, ни как эффективно продавать продукт, ни как строить переговоры с заказчиком. Менеджер это понимает, поэтому я настолько максимально отстранен от решения реально возникших проблем, насколько это возможно. О моем существовании вряд ли узнает заказчик. Иначе при встрече с ним я на ломаном английском начну нести такую ахинею про бороздящие просторы вселенной космические корабли, что расхлебывать потом будем месяцами, долго и мучительно. Я максимально избегаю философских споров и разговоров ни о чем, на что точно не могу оказать влияния. Я ловлю себя на мысли, когда на собрании тестеровщиков с пеной у рта коллеги спорят о велосипедных будках при проектировке атомных электростанции, — сейчас надо держать свой паршивый рот на замке. Даже если из дерзкого монолога другого коллеги-тестера, который высказывает свое единственно авторитетное мнение, можно собрать bullshit bingo. Не надо так, рубить правду-матку с плеча. В любых организациях значительно безопаснее ошибаться вместе с большинством, чем быть правым в одиночестве.

3) Я начинаю узнавать, что такое тестирование на самом деле. Это не проверка того, соответствует ли программа предъявляемым к ней формальным требованиям, которые прописаны на бумаге. Тестирование — это техническое исследование программы для получения информации о ее качестве с точки зрения заинтересованных лиц. Тестировать — значит ломать чужие иллюзии о том, как работает программа, давать другим участникам проекта информацию о том, с какими проблемами пользователи могут столкнуться при работе с продуктом. Это инженерная специальность, где для успешной работы и дальнейшего роста необходимо знать множество деталей относительно процесса разработки ПО хотя бы поверхностно и быть готовым постоянно учиться. К качеству же я имею весьма посредственное отношение. Качество — это значимость для некоторого человека, чье мнение на проекте играет решающую роль, является определяющим для всех остальных участников. Грубо говоря, если я вдруг в день релиза звоню во все колокола с криком о том, что качество на проекте скатилось ниже плинтуса — это не повод задерживать релиз. Я как тестировщик не обеспечиваю качество. У меня нет на это полномочий. Я не определяю, какие проблемы будут исправлены в следующем релизе, какие фичи более приоритетны, кого надо нанимать, увольнять, кому выплатить премию. Я не приглашен на обсуждение архитектуры нового проекта, не имею права голоса при выборе языка и фреймворков для разработки, не устанавливаю методологию разработки. Это дело менеджмента определять то, какой уровень качества для проекта приемлем. За 80% проблем качества отвечает менеджмент. Когда после переговоров с заказчиком на месяц сокращен срок выполнения проекта при сохранении scope, когда не хватает толковых разработчиков и наспех набирают вчерашних студентов, надеясь вывезти за счет количества — это все намекает о культуре компании и, как следствие, влияет на качество ее продуктов. Я лишь малюсенький винтик, необходимый для создания впечатления заказчику, что на проекте присутствуют люди с лычкой Quality Assurance, следящие за качеством. Я могу предложить улучшить продукт, конечно, как и любой другой человек с улицы, но вообще-то лучше просто тестировать продукт. Усидеть на двух стульях крайне сложно: либо я пытаюсь хорошо протестировать и оставляю суждения о качестве на совести лиц, принимающих решения, либо я заморачиваюсь вопросами качества, хотя мне за это не платят, и из рук вон плохо тестирую продукт. Я должен думать над собстенными профессиональными возможностями, стараться определить пути для их повышения и никогда не действовать вне рамок своих компетенций.

4) Решение об установке приемлемого уровня качества принимают управленцы на основе того, кто и как будет использовать продукт. Риски за принятые решения берут на себя они же. Им за это платят немалые деньги. Мнение технического специалиста о качестве программы подчас не является сколь-либо значимым. Я понимаю, что ужасно не удобен интерфейс, не те шрифты и не сочетаются цвета боковых панелей. Но именно у этого проекта прямо сейчас горят сроки, его надо сдать по ПМИ, стрясти за это деньги с заказчика, отгрузить и навсегда забыть. Да, адаптация красноглазых айтишников к бизнес-нуждам происходит всегда болезненно. У нас коммерческое предприятие, поэтому особенности поведения заказчика, его представления о качестве имеют более приоритетное значение. Люди всегда руководствуются личными критериями качества, которые являются эмоциональными, а не рациональными. Не существует объективного критерия оценки качества, кроме прибыльности. Если смотреть с этой стороны, то универсальным критерием качества продуктов коммерческих предприятий является рентабельность. Если у проекта по бухгалтерской отчетности за некоторый выбранный руководством период есть прибыль — то это качественный проект, если убытки — проект некачественный. И не следует усложнять: многих может смутить, что идеально исполненный с технической точки зрения и протестированный проект, который лично мне ой как нравится, заказчик назовет некачественным. Все просто: мы не уложились в сроки, за прошедшее время у бизнеса изменились требования или положение на рынке, в результате продукт стал никому не нужен, так и не вышел, мы остались в долгах у разбитого корыта. Качество — это не то, что участники проекта вложили в него, а то, что клиент из него извлек. И кстати, если я, находясь в должности рядового тестера, вдруг осознал, что полностью понял хотелки заказчика и единолично готов делать суждения о качестве проекта, то надо налить кружечку зеленого чаю, откинуться в кресле, посмотреть на пейзаж за окном и успокоиться. Должно в течение получаса отпустить. Я просто ошибаюсь по поводу того, какие очередные свистелки и перделки возжелал заказчик; надо годами ежедневно вариться в сфере деятельности заказчика, чтобы понимать нюансы в его предметной области.

5) Когда менеджер обращается ко мне, ему нужна информация о том, существует ли здесь и сейчас невыдуманная проблема, плюс можно ли нам смириться с этим? Все остальные вопросы про метрики, соотношение passed/failed и т. п. — чепуха полная. В ряде случаев целесообразно замерять затраченное на тестирование время, но всецело полагаться в будущем на полученные затраты на проверку я бы не стал. Циферки не говорят ровным счетом ни о чем. Как мы знаем, есть ложь, наглая ложь, и статистика; поэтому важно не то, какие данные были получены по результатам тестирования, а что за человек занимался подсчетом результатов и созданием красивых диаграмм в power point. Можно легко не учитывать ряд проваленных тестов, списав это на несовершенность окружения, можно незаметно подкорректировать в желаемую сторону метрики. Если менеджер говорит со мной только про неинтересные вопросы, то я настолько дискредитировал себя в глазах остальных отделов, что никто не доверяет мне даже предполагать, что является проблемой, а что нет. Мне не доверяют как профессионалу, следовательно, я не могу реализоваться на этом месте работы. Вот пример. Legacy-проект, которому уже лет пятнадцать от роду. Людей, стоявших у истоков, определявших его архитектуру, понимавших общую картину и принципы работы, давно нет с нами рядом. К проекту в течение его жизни приложили руку десятки людей, которые тоже давно пропали из виду. Велосипеды на месте, костыли держат уверенно, — стабильность, одним словом, реальных проблем нет. Но у меня этот проект вызывает ментальное отторжение. Там все плохо, кое-как работает, куча багов. Хотя проектом пользуются и жалоб от заказчика не поступало... Он успешен, так как по-настоящему унылые вещи долго не живут. Так ли надо выяснять у тимлида, почему нельзя все переписать с нуля на Ruby и сделать так, как хочет Его Величество Тестировщик? Программ без ошибок не существует. Это обычное дело, когда до конечного потребителя доходит продукт с некоторым количеством ошибок. В релиз однозначно не должны попадать критичные проблемы, приводящие к невозможности использовать продукт по назначению или большим проблемам в процессе использования. Малозначимые проблемы в частях системы, куда пользователи попадают лишь по ошибке, косметические дефекты в фронтенде, недоработки в наспех сделанной фиче — в определенных ситуациях все это вполне допустимо. Наверное, мой нездоровый перфекционизм здорово вредит экономической составляющей проекта. Поэтому надо выбрать момент, когда разумно остановиться штамповать запросы в баг-трекинг систему и считать качество продукта достаточным.

6) Отдельная песня — источники информации о тестировании. У соседа приколочен диплом ISTQB на стену в кубике — мне немного завидно, так как лень вызубривать терминологию тестирования для его получения по предоплате. Хотя это выглядело бы так же смешно, как у программистов диплом об окончании двухнедельных курсов Java. Принадлежать к организации профессионалов тестирования и быть профессионалом в сфере тестирования — сильно разные вещи. Еще я давно понял, что на форумах и конференциях выступающие заняты самопиаром и продажей себя (или продуктов компаний, в которой они на данный момент работают). Делю на сто смело все их обещания со сцены, что новомодный фреймворк для тестирования спасет планету от нашествия багов, а уникальная методология перевернет мир, попутно решив все мои насущные проблемы. Последние места, куда я лезу в поисках информации о тестировании — это русскоязычные блоги и википедия. Все имеет контекст: что в одной фирме ценится и прекрасно работает, в другой дико не приживется. Играться с технологиями за деньги заказчика было бы увлекательно, но слишком нерационально. Разве станут в открытую для конкурентов трещать о том, что так классно работает? Станут безвозмездно выкладывать на github многолетние наработки, сделанные внутри компании? Скорее всего, доклады и выступления евангелистов сделаны с целью, чтоб я после конференции бросился внедрять принципиально новые идеи в жизнь, попутно натыкаясь на все ошибки и описывая свой опыт для более рациональных коллег, кто решил учиться на чужих ошибках. А в open source попадают частенько достаточно сырые, но разрекламированные поделия для автоматизации тестирования. Должно пройти хотя бы несколько лет, чтобы дела устаканились, появились первые объективные отзывы о достоинствах и недостатках. Поэтому я в речи не употребляю слово «правильно»: что это такое за зверь не знает никто. Вместо него лучше употреблять: подходит для нас в данный момент, наиболее целесообразно в текущей ситуации, приемлемо на этом этапе развития. И вместо слов «бага» и «ошибка», которые имеют негативную эмоциональную окраску, я использую: недочет, проблема, замечание, несоответствие. Не мне решать, что бага, а что нет. Может выясниться, что на самом деле все нормально. Это я сел в лужу, не по инструкции настроив окружение или поправив не те конфигурационные файлы методом copy and paste. А я уж поспешил похвастаться соседям найденным блокером. Мда… Problem exists between keyboard and chair, как говорится. Да и какому программисту понравится, когда радостно тыкают пальцем в монитор, ехидно щурясь, а в глазах так и читается: «бага, ха-ха! Я нереально крут, я нашел ошибки в твоем коде, их много и ничего не работает! И пока ты не исправишь, я не отстану!». Добавлю, разработчиков желательно стараться не отвлекать до самого последнего момента, в разумных пределах. Если появились подозрения в некорректной работе программы, то после тщетных самостоятельных попыток разобраться следует идти к коллегам, далее к тестировщикам старше по должности, тест-лиду, и уже затем к программистам. Сор из избы не выносить не стоит, выставляя себя посмешищем для окружающих.

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