На данном этапе моей карьеры я ещё не могу бравировать опытом работы, чтобы сказать «спустя десять лет вот что я заметил…». Но я могу уже точно указать на некоторые вещи, которые нахожу интересными, особенно для тех, кто только начинает свой путь в IT (в т.ч. QA), работает в IT недавно или с отделом QA банально не пересекался.
Сейчас для меня очевидно, и это «не совпадение, я думаю» что некоторая часть участников IT сообщества, может иметь искаженное представление о том, чем же занимаются QA на самом деле.
Я хотел бы поделиться своими мыслями и затронуть некоторые общие мифы, которые витают в нашем сообществе и около него. Сразу скажу, что «тестировщиков не любят» - враньё!). Просто иногда творческие личности не любят оценки своей работы и боятся услышать «тут не работает». Это абсолютная норма, все мы люди.
Итак, с высоты моего пусть и не самого большого, но уже опыта мы начинаем наш образовательный stand-up!
Поехали/полетели/поплыли…
Миф #1 Тестировщики вовлекаются в жизненный цикл проекта только после разработки
Это один из самых больших мифов.
И если это ваша реальность, то у меня нет для вас хороших новостей. И вот почему:
Чем позже QA подключается работе, тем выше риск потерять в качестве продукта (кэп здесь) и риск вылететь/вылетать/постоянно вылетать из графика реализации задач, поставленных бизнесом.
QA нужно столько же времени, сколько и разработчикам чтобы вникнуть в требования, протестить сие своими глазами и написать бизнес-аналитику «простите, что значит *****?». Если же этого времени изначально, т.к. QA подключили поздно, то тут появляются пробелы в понимании и трактовке требований, отсутствие плана тестирования или план «на коленке», потому что: времени нет. Уже нет.
B в итоге, если QA внедряются лишь на более поздней стадии проекта, то ничего не остаётся как полагаться на понимание разработчиков, и остальных участников команды. Понимания того КАК они переварили всю логику продукта и т.д.
И вообще-то, это откровенное, пусть и вынужденное, перекладывание ответственности («ну мне Миша сказал что вот это - вот так, это всё Миша»). И знаете что? Что-то я не встречал примеров, когда эта системная практика положительно влияла бы на качество продукта… Я хочу работать в идеальном мире?) Может быть, имею право.)
Я считаю, что QA «отдел» (даже если QA один на проекте) должен иметь своё собственное, субъективное (офкорс же) представление о логике работы продукта, ценности и приоритета фич для бизнеса и портрете ЦА. И нужно, чтобы всё это появилось у него как можно раньше.
Требования поменяются? Конечно, но ничего – QA поправит, это не с нуля вникать или вслепую полагаться на кого-то в чём-то... Всегда нужно время чтобы мастер схема проекта вообще была. И какой бы абстрактной не и неполной она не была - нужно время чтобы она «в голове улеглась».
Несомненно радует, что уже немало фирм осознают вышеперечисленное и включают QА в процесс с самого начала работы над проектом. Да, и сами QA всё чаще берут на себя всё новые и новые инициативы!
Миф #2 Тестеры не станут менеджерами проектов
Некоторые(не все) думают, что если вы тестировщик, то у вас нет/не будет карьерного роста в области управления проектами (как раз из-за проблемы Мифа #1).
«…Ну что там этот тестировщик знает о менеджменте проекта, если он только на готовенькое приходит и свой ready for test елозит туда-сюда…»
Да, чтобы стать эффективным менеджером, вам нужно приобрести такие навыки, как: управление персоналом, налаживание коммуникаций, оценка трудозатрат, кризис менеджмент и т.д. И кому-то может показаться что, это не имеет ничего общего с тестированием или чем-то еще техническим.
Но, какой он, хороший тестировщик? Каков он в реальности и что он делает?
Он проактивный. Он со всеми передружится, чтобы узнать всё что ему нужно. Он как заправский джедай с улыбкой переживет весь toxic experience в общении с теми, кто болезненно воспринимает критику. Он и за релиз может отвечать, и после релиза на мониторинге посидеть и в пятницу вечером всех по тревоге поднять, чтобы сервер поднять, чтобы репутацию свою, после факапа, с не той веткой... поднять…раунд)
К тому же, любой работающий в команде от начала и до победы специалист - приобретает насмотренность и наслушанность в разрезе менеджмента.
При вас, по сути, разрешаются конфликты: как в коде, так и в команде.
И при вас же происходят чудеса человеческой глупости и самоотверженности в работе. Так что, будучи тестировщиком, или любым участником команды, вы можете развиваться как менеджер. Вас уже и так многое поощряет, провоцирует или как минимум не сдерживает.
Менеджмент - независимая область, и любой человек с достаточным опытом и желанием вляпаться в перспективу депривации сна может стать адептом этого вида времяпрепровождения.
Миф #3 Если руководитель «не понимает в QA» это «тупик» в развитии
«... Болото... надо место менять...»
В идеале должны быть отдельные вертикали отчетности; у QA свой лид, у разработки свой и эти ваши лиды отчитываются перед ПМом и т.д. но…
Иногда, к примеру, лид отдела разработки лидирует как для Dev, так и для QA. И рядовые QA должны отчитываться перед кем-то, кто может не знать, что такое «матрица трассировки требований» и кто такой Ли Копланд. Ну, вы поняли ситуацию. Да, детали вашей работы могут быть упущены «руководством»… и это не самая классная ситуация, но это определенно не конец света.
До тех пор, пока вы(кажу на вас перстнём) делаете свою работу качественно, ответственно и занимаетесь саморазвитием (ключевое слово «сАмо» а не «самО») – ваша карьера определенно будет идти в гору. 100%.
Вы можете развивать софт скиллы проявляя терпение и понимание к тем, кто не знает нюансы QA. А можете и помочь им с познаниями в процессах тестирования. Поверьте, от этого в выигрыше будут все. Особенно вы.
Миф #4 Не смог стать «настоящим» ITшником - пошел в QA
Ха…QA это не IT да? это типа FAQ? типа поддержка штоль?
Нет, QA – отдел гарантии и контроля качества, а FAQ – это фак ю.
Очень популярный миф о том, что тестировщик это тот, кто хотел стать хорошим разработчиком, но увидел "скока там учить ваще бох мой слов многа", и проиграл битву за своё обеспеченное будущее. И чтобы совсем не упасть в грязь своим необразованным лицом – пошёл на сделку с социумом и стал тестировщиком, который лишь 29 февраля, в окне 1го этажа соседнего офиса может увидеть код или "что это там у него за..."
На самом деле, тестирование также включает в себя кодирование, в большинстве случаев. Или как минимум чтение кода.
Тестеры пишут SQL-запросы, работая с базами данных.
Регулярно работают с клиентской частью кода HTML, CSS и т.д.
Пишут скрипты автоматизации (даже будучи на позиции MQA) на Java, Python или других языках программирования для тестирования фронта и бэкенда.
И ещё QA регулярно пользуют блокнотами кода типа Sublime или полноценными IDE вроде VSC
У тестировщиков есть свои «заморочки», «сложности» и свои особенности в работе. У них не малая, а порой и более серьезная ответственность перед командой, продукт own’нером и клиентом.
Никто не спорит, что разработчик по определению более компетентен в написании/понимании искусства написания кода и знании библиотек, но то мнение что тестировщик это "разработчик-неудачник" - не выдерживает никакой критики.
Миф #5 Тестирование: это пощелкать в случайных местах…
«...Гляньте не него... сидит... тыкает... говорит: а вдруг сломается...»
Широко распространено мнение, что тестирование: это кликаешь как пользователь на разные кнопки, или по идеальной инструкции прошёл (кто б её только написал), ну и в Excel написал какой-то отчет что кнопки нажимаются.
Реальность заключается в том, что тестеры выполняют очень четко определенные шаги тестирования, основанные на видах тестирования, стратегиях, техниках и т.д. про что кстати много книжек умных написано. И эти шаги они проходят чтобы гарантировать, что UI(GUI)/API и т.д. работает в известных команде случаях. Гарантировать не на 100% конечно, что в собственно в книжках красочно и объясняется…
И случаи эти, тестовые, описываются тоже не с потолка, а исходя из опыта команды, работы с UX и ЦА аудитории (так сказать «грациозно ступая по полям маркетинга»).
Поскольку пользователь, почти всегда, не читает, не читал, и никогда, видимо, не будет читать инструкцию, то он имеет ограничения разве что в рамках собственной фантазии и предыдущего опыта использования ПО. С какими бы user story QA не работали, под любой тип расстройства поведения – опытный специалист сможет подобрать оптимальную стратегию тестирования.)
Именно поэтому перед тестировщиками стоит задача:
предугадывать поведение наших любимых пользователей
приоритизировать сценарии, коих поверьте ох как не мало…
также постараться положить соломку везде, где наш пользователь может упасть и вместе с собой чего не со зла уронить
Придумывать негативные, конспирологические и апокалиптические сценарии работы фичей в т.ч. при интеграции
А ещё бизнес есть у нас, например. И он тоже хочет там, всякое…
Не зная ничего о тестировании как «дисциплине», наша работа может выглядеть как множество случайных щелчков в случайных местах и ощущения что тестировщик вообще ничего не знает о проекте (иначе почему у него столько вопросов ко всем). Но это не так.
Миф #6 Тестирование - канцелярщина с документацией
Во-первых, позвольте мне сказать, что документация: это работа каждого, кто работает над проектом, а не только тестировщика. Этого удовольствия хватает на всех. Тем не менее, точный, полный и понятный артефакт документации – ценнейшая вещь, которой порой так не хватает (но кто б её писал только…).
Однако для тестировщиков документация более важна, потому что результат, который мы создаём - не программа или модуль, а гарантированное качество, которое принимает твёрдую форму (особенно для заказчика) через артефакты тестирования и "нулевой" отчёт о багах в проде(мастере). И да – excel молодец и никуда ещё долго в массах не денется, но лучше использовать профессиональные TMS и Wiki системы.
Миф #7 QA это низкооплачиваемая работа в сравнении с *****
Если тестировщику на проекте мало платят, то «мало» это может быть субъективной оценкой, или же, если правда мало – безусловной заслугой тестировщика. Размер оплаты зависит от множества факторов и сказать, что быть позиция QA является единственной причиной почему вам будут платить меньше, это не правда, абсолютно.
Да, в среднем по больнице QA получают несколько меньше, чем наши шейхи-разработчики. Но на частных примерах могу точно вас заверить – всё очень индивидуально и хорошие QA могут очень прилично зарабатывать. В конечном счёте всё зависит от вас.
Миф #8 QA не знакомы: слава и признание
«...сей чемпион не знал оваций, в лучах софитов не стоял...»
Тестирование иногда кажется "неблагодарной" работой. Иногда тебя могут попросить пройти регресс после релиза в 3 строчки и коммента: «на всякий случай, проверь всё, по братцки»…
Поймите, ничего личного. Иногда дело в культуре компании, команды, персональных отношениях. В том как управленцы ценят свои участников и т.д.
Но я знаю QA которые были «звездами» в своих командах и забирали себе лавры чуть не за каждую закрытую задачу в JIRA… А потом, когда они уходили в другую компанию, все рабочие чаты рыдали…
Старайтесь оставаться позитивной единой команды, придерживайтесь конструктива в решении спорных моментов и пусть ваша работа говорит сама за себя. Старайтесь не ожидать медали или похвалы за выполнение вашей работы или удачного прохождения очередной сотни тест-кейсов. Если ваш бизнес (а значит и клиент) доволен – это ваш гол.
Да, будет легче и приятнее работать, если команда и клиенты будут ценить QA. Но, если они этого открыто не делают это не значит: что работа QA не ценна, не значит что они её не видят и что вы должны как-то недооценивать себя. Бывают люди, для которых «признание» очень важно. Я сам такой, понимаю.
Варианты? Вот:
Станьте «звездой» вашей команды, почему нет.
Поговорите с ПМ о вашей потребности в оценке и положительном закреплении. Это не просто психологически, но вполне посильно.
Поговорите о своей жажде признания со своим психологом. Тоже очень продуктивно.
Миф #9 QA задерживают релизы / не дают им хода
Сразу на берегу поясню: QA не может сказать «нет, релиза будет, через мой труп». Это вообще то не его полномочия. Он может лишь довести до сведения своё экспертное мнение подкрепив его аргументами. Вот и всё.
По поводу же самого мифа:
Ключевая причина возникновения этого мифа – промашки в тайм-менеджменте команды и ошибках прогнозирования временных трудозатрат.
Проще говоря: релиз сегодня, разработка закончила только и вроде всё ок, успеваем, сейчас Егор всё наверное быстренько проверит и всё… он же у нас шустренький… (в лучших традициях качественного регресса за 2 часа XD)
Чтобы начать тестирование мне нужно дождаться того, что разработка полностью завершена и есть готовое окружение. Только после этого я могу заводить bug-репорты, разработчики фиксить баги, а я проводить ретесты и т.д. Это и создает поверхностное впечатление, что "тестирование это ваше чё то там тянется и тянется, скока можна уже…"
И да, если кто не знает, то регресс тоже надо когда-то делать. Регресс – ряд мероприятий(проверок) позволяющий убедиться, что новый функционал не сломал остальной «старый» над которым мы так много пахали… представляете объём работы?)
Таким образом можно понять, что не «тестирование задерживает выход релиза», а поверхностное планирование порождает порой крайне необоснованные ожидания. Как по срокам, так и качеству.
Заключение
Всё выше озвученное лишь моё мнение, на истину не претендую.
Прекрасно понимаю, что мой стиль изложения мыслей и мой юмор может зайти не всем, но буду рад прочитать ваше мнение, ваши случаи из жизни и/или порцию айтишного юмора любого пошива и вероисповедания.
Всем CI/CD😉.
