QA-непрофессионализм — главный тренд в отрасли
Как отличить мастера от дилетанта? На эту тему написаны десятки книг, проведена масса научных и около-научных исследований, однако, общего мнения нет.
Я приведу свою точку зрения: «Дилетанта от мастера отличает воинствующее сопротивление всему конструктивному, попрание всех формальных и неформальных договоренностей и стандартов отрасли, а также сваливание вины на других людей и неодушевленные предметы, которые совсем не причем.»
Проще всего пояснить что-либо на примерах, с этого я и начну:
Причина: QA получают бонусы/премии за количество найденных багов. Реализация: Особо ушлые товарищи поняли фишку и находят баги даже там где их нет, приходится постоянно доказывать что ты не верблюд, что далеко не всегда удается, потому что PM на их стороне. Типовый подход — придраться к верстке на странице, хотя команда работает над интеграцией.
Причина: QA поднимают панику на пустом месте, делая бурю в стакане воды, чтобы оправдать собственное безделье. Реализация: Некоторые QA могут неделю играться на телефоне, а в пятницу после обеда найти супер-пупер критический баг и потребовать его немедленного исправления. Разумеется баг воспроизводится только на некоторых environment-ах.Не видя особых попыток локализации/устранения, пишут письма PM или заказчику, стараясь создать видимость серьезных проблем, искренне надеясь, что в этой ситуации никто не заметит их безделья.
Причина: Большинство QA не умеет, не знает и не хочет изучать что-то новое, пытаются свалить это на кого-то другого,либо делают так, что лучше бы делали. Реализация: Некоторые QA-автоматизаторы умело дестабилизируют проект, доводя его до маразма. К примеру своими Insert-ами в БД он ломает уже работающий на таблице Hibernate Sequence, который генерируетпервичные ключи и с радостью заводит баг, ставит ему статус «critical» и поднимает всех на уши. Программисты, бросиввсе таски бросаются локализировать и за 2 дня не могут понять причину, пока случайно не узнают про Insert, сами вычищают базу, а пронившийся QA даже не делает попытки исправится, он ехидно доводит до их сведения, что мол моглибы и понадежнее сделать, раз один insert и апликуха уже нормально не работает. В итоге такой автоматизатор всегда молодец и никогда не виноват.
Причина: Мой код идеален, а виноват сервер.Реализация: Проект собирается за 4 минуты без интеграционных тестов. С тестами он собирается иногда сваливается. Виноват, разумеется, сервер или администратор или провайдер, но только не QA-автоматизатор. Не закрытые потоки, чтение файлов по 1 байту, копипаста чуть более, чем везде, дикости в коде вроде циклов уровня вложенности, приводящей к сваливанию тестов. Все это реалии автоматизации. Когда отмазки заканчиваются, применяется коронный аргумент: письмо об автоматизации, а также отсутствие стандартов на оную или проще: «все так делают». И в этот раз они вышли сухими из воды.
Причина: Многие QA не знают допустимые границы типов данных, не знают XML, не умеют пользоваться developer tools или firebug-ом в браузере. Реализация: Простейшая задача — как вычислить среднее двух чисел и ошибиться? Спросите об этом у QA, особенно у автоматизатора. Не сильно вникая в диапазон типов он, оперируя миллиардными значениями, переполняет знаковый int и затем вычисляет среднее у остатка, получившегося от подобного сдвига. Попробуйте сложить 2 + 3 млрд и поделить на 2 в знаковом int. Получается не 2,5, а значит виноват программист и это критический баг. Либо сознательно не чистят кэш браузера, что позволяет «выявить» еще много багов.
Причина: Двойные стандарты — второе имя QA. Реализация: QA очень любят писать деструктивные комменты в JIRA, либо ставить в копию письма всех кого знают, аж до вице-президента заказчика, но когда надо помочь им, просят это сделать неформально, без таска или письма. Сами отказываются тестировать что-то на локальном environment-е разработчиков. Имеют свойство давать советы по разработки, но при это жутко обижаются, на замечания о том, что новую кнопку можно и за полчаса протестировать.
Причина: «Звонок — для учителя»Реализация: Разгар подготовки релизной версии, разработчики и dev-ops в мыле, team-lead уже час на совещаниях и ему там не сладко. QA при этом в течение дня несколько раз играли в футбол, курили и обсуждали последние политические новости. Видимо, для QA существуют особые правила, а командный дух это не для них. Два бага за день уже завел — можно и расслабиться.
Причина: Без бумажки — ты букашкаРеализация: QA всегда находят какие-то письма или комментарии, в т.ч. устаревшие, лишь бы прикрыться самим, а не повышать реальное качество продукта. Сталкивался тысячу раз, когда им непонятно хоть что-то, они блокируют задачу, пишут огромное и непонятное письмо страниц на 20 с картинками и схемами и шлют на всех. Поскольку задача заблокирована, они с чистой совестью пьют кофе и лайкают котов. Вместо конструктивного уточнения, в большинстве своем они поступают деструктивно по отношению к продукту и к своим коллегам, а также начальству. При этом они страшно обижаются на волокиту в паспортном столе или БТИ. Очень странно, ведь именно там обитают ваши братья по разуму и по совести.
Причина: Требования заказчика — не является уважительной причинойРеализация:Регрессионное тестирование особенно доставляет. Даже если кусок система поменялся до неузнаваемости, или его уже нет в наличии, то регрессия всегда выявит баги и заведет их. Получив пинок от team-lead-а, эти баги закрываются, но план по багам выполнен и свои 30 серебренников за план QA получат. Браво! СССР распался, а совок живет и процветает.
Выводы: Развивайтесь, изучайте новое, не стесняйтесь своего незнания, воинствующая глупость гораздо хуже. Ну а подставлять людей — последнее дело.
За свою карьеру в IT я знал всего превосходных QA, 2 из них были автоматизаторами и 1 из них уже трудоустроен за рубежом. Никто из них не выделывал ничего из того, что я привел выше.
Возможно, если у вас возникнет вопрос, почему в IT QA недолюбливают, над ними подшучивают и часто сторонятся, то я постарался привести убедительные примеры в этом топике.