На данном этапе моей карьеры я ещё не могу бравировать опытом работы, чтобы сказать «спустя десять лет вот что я заметил…». Но я могу уже точно указать на некоторые вещи, которые нахожу интересными, особенно для тех, кто только начинает свой путь в IT (в т.ч. QA), работает в IT недавно или с отделом QA банально не пересекался.
Сейчас для меня очевидно, и это «не совпадение, я думаю» что некоторая часть участников IT сообщества, может иметь искаженное представление о том, чем же занимаются QA на самом деле.
Я хотел бы поделиться своими мыслями и затронуть некоторые общие мифы, которые витают в нашем сообществе и около него. Сразу скажу, что «тестировщиков не любят» - враньё!). Просто иногда творческие личности не любят оценки своей работы и боятся услышать «тут не работает». Это абсолютная норма, все мы люди.
Итак, с высоты моего пусть и не самого большого, но уже опыта мы начинаем наш образовательный stand-up!
Поехали/полетели/поплыли…
Миф #1 Тестировщики вовлекаются в жизненный цикл проекта только после разработки
Это один из самых больших мифов.
И если это ваша реальность, то у меня нет для вас хороших новостей. И вот почему:
Чем позже QA подключается работе, тем выше риск потерять в качестве продукта (кэп здесь) и риск вылететь/вылетать/постоянно вылетать из графика реализации задач, поставленных бизнесом.
QA нужно столько же времени, сколько и разработчикам чтобы вникнуть в требования, протестить сие своими глазами и написать бизнес-аналитику «простите, что значит *****?». Если же этого времени изначально нет, т.к. QA подключили поздно, то тут появляются пробелы в понимании и трактовке требований, отсутствие плана тестирования или план «на коленке», потому что: времени нет. Уже нет.
B итоге, если QA внедряются лишь на более поздней стадии проекта, то ничего не остаётся как полагаться на понимание разработчиков, и остальных участников команды. Понимания того КАК они переварили всю логику продукта и т.д.
И вообще-то, это откровенное, пусть и вынужденное, перекладывание ответственности («ну мне Миша сказал что вот это - вот так, это всё Миша»). И знаете что? Что-то я не встречал примеров, когда эта системная практика положительно влияла бы на качество продукта… Я хочу работать в идеальном мире?) Да, может быть, имею право.)
Я считаю, что QA «отдел» (даже если QA один на проекте) должен иметь своё собственное, субъективное (офкорс же) представление о логике работы продукта, ценности и приоритета фич для бизнеса и портрете ЦА. И нужно, чтобы всё это появилось у него как можно раньше. Круто, когда это отображено в мастер схеме проекта, хотя бы в Miro).
Требования поменяются? Конечно, но ничего страшного – QA поправит, это не с нуля вникать или вслепую полагаться на кого-то в чём-то...
Также, нужно чтобы мастер схема проекта вообще была. И какой бы абстрактной или неполной она не была бы - нужно ВРЕМЯ, чтобы эта схема «в голове улеглась».
Несомненно радует, что уже немало фирм осознают вышеперечисленное и включают QА в процесс с самого начала работы над проектом. Да, и сами QA всё чаще берут на себя всё новые и новые инициативы!
Миф #2 Тестеры не станут менеджерами проектов
Некоторые(не все) думают, что если вы тестировщик, то у вас нет/не будет карьерного роста в области управления проектами (как раз из-за проблемы Мифа #1).
«…Ну что там этот тестировщик знает о менеджменте проекта, если он только на готовенькое приходит и свой ready for test елозит туда-сюда…»
Да, чтобы стать эффективным менеджером, вам нужно приобрести такие навыки, как: управление персоналом, налаживание коммуникаций, оценка трудозатрат, кризис менеджмент и т.д. И кому-то может показаться, что это не имеет ничего общего с тестированием или чем-то еще техническим.
Но, какой он, хороший тестировщик? Каков он в реальности и что он делает?
Он проактивный. Он со всеми передружится, чтобы узнать всё что ему нужно. Он как заправский джедай с улыбкой переживет весь toxic experience в общении с теми, кто болезненно воспринимает критику. Он и за релиз может отвечать, и после релиза на мониторинге посидеть, и в пятницу вечером всех по тревоге поднять, чтобы сервер поднять, чтобы репутацию свою, после факапа, с не той веткой... поднять…раунд)
К тому же, любой работающий в команде от начала и до победы: приобретает насмотренность и наслушанность в разрезе менеджмента.
При вас, по сути, разрешаются конфликты: как в коде, так и в команде.
И при вас же происходят чудеса как человеческой глупости, так и самоотверженности в работе. Так что, будучи тестировщиком, или любым участником команды, вы можете развиваться как менеджер. Вас уже и так многое поощряет, провоцирует или как минимум не сдерживает.
Менеджмент - независимая область, и любой человек с достаточным опытом и желанием вляпаться в перспективу депривации сна может стать адептом этого вида времяпрепровождения[management_love].
Миф #3 Если руководитель «не понимает в QA» это «тупик» в развитии
«... Болото... надо место менять...»
В идеале должны быть отдельные вертикали отчетности; у QA свой лид, у разработки свой, и лиды отчитываются перед ПМом и т.д. но…
Иногда, к примеру, лид отдела разработки лидирует как для Dev, так и для QA. И рядовые QA должны отчитываться перед кем-то, кто может не знать, что такое «матрица трассировки требований» и кто такой Ли Копланд. Ну, вы поняли ситуацию. Да, детали вашей работы могут быть упущены «руководством»… и это не самая классная ситуация, но это определенно не конец света.
До тех пор, пока вы(кажу на вас перстнём) делаете свою работу качественно, ответственно и занимаетесь саморазвитием (ключевое слово «сАмо» а не «самО») – ваша карьера определенно будет идти в гору. 100%.
Вы можете развивать софт скиллы проявляя терпение и понимание к тем, кто не знает нюансы QA. А можете помочь им с познаниями в тестировании как процессе. Поверьте, от этого в выигрыше будут все. Особенно вы.
Миф #4 Не смог стать «настоящим» ITшником - пошел в QA
Ха…QA это не IT да? это типа FAQ? типа поддержка штоль?
Нет, QA – отдел гарантии и контроля качества, а FAQ – это фак ю.
Очень популярный миф о том, что тестировщик это тот, кто хотел стать хорошим разработчиком, но увидел "скока там учить ваще бох мой слов многа", и проиграл битву за своё обеспеченное будущее. И чтобы совсем не упасть в грязь своим необразованным лицом – пошёл на сделку с социумом и стал тестировщиком, который лишь 29 февраля, в окне 1го этажа соседнего офиса может увидеть код или "что это там у него за..."
На самом деле, тестирование также включает в себя кодирование, в большинстве случаев. Или как минимум чтение кода.
Тестеры пишут SQL-запросы, работая с базами данных.
Регулярно работают с клиентской частью кода HTML, CSS и т.д.
Пишут скрипты автоматизации на JS, Python или других языках программирования для тестирования фронта и бэкенда.(часто даже будучи на позиции MQA)
И ещё 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?.
