О QA за гаражами

Есть ли у Вас документация на проекте? Что бы к этому списку добавили Вы и почему? Пишите в комментариях, давайте делиться лучшими практиками.

«Работающий продукт важнее исчерпывающей документации» именно так зачастую коверкают один из постулатов Agile-манифеста. Я уже затрагивал как-то артефакты тестовой документации в разрезе принципов работы с ними. Сегодня же хочется затронуть наиболее критичные для работы QA артефакты наших коллег по цеху. Требования. Как много в этом слове, для сердце тестировщика сплелось… и как редко они на деле встречаются. А ведь без них зачастую и тестирование толком не провести, особенно если сухо следовать канцелярскому определению этой процедуры. В них выделяю кратко основные аспекты: - функциональность - полноту - непротиворечивость В разных компаниях существуют различные стандарты формирования и описания бизнес- и технических требований. Первым шажком к успеху становится именно наличие такого стандарта, как такового. Ведь по сути это, простите за тавтологию, требования к требованиям. И несоответствие этим требованиям при наличии стандарта уже можно вменять его авторам. Комментирование кода. Хорошо комментированный код проще читать новичкам и смежникам, но на его комментирование так лениво зачастую тратить время… Хорошим аргументом к грамотному оформлению кода становятся все те же стандарты, их, к слову, можно номинально реализовать с помощью линтеров, которые будут бдеть не только за качеством/чистотой самого кода, но и за его читаемостью. Еще одним подспорьем станет организация осознанного code-review с подключением тех самых новичков и смежников, например, тех же QA-инженеров. Добавьте в онбординг новичкам-программистам ознакомление с кодовой базой продукта на самом старте, а к процессу код-ревью подключите QA (это полезно и для QA в том числе) и они тут же незамыленным взглядом смогут подсветить неявные моменты в коде. QA Notes. Заметки на полях от разработчиков при передаче задачи в тестирование. На что обратить особое внимание, нюансы технической реализации задачи, которые помогут очертить круг предстоящих испытаний. Также сюда следует добавлять перечень необходимых манипуляций/зависимостей для приведения ПО в тестопригодное состояние (скрипты, миграции, сервисы или их моки и т.п.). За такие комментарии тестировщики от души поблагодарят их автора. Но важно помнить и о том, что даже здесь QA стоит включать здравый скепсис и воспринимать эти пометки, как рекомендации, а не строгое руководство к действиям. В нашем деле лучше перебдеть, чем недобдеть;) Артефакты тестирования. Про них уже упоминалось ранее, в двух словах, по результатам тестирования должен прикладываться понятный и легкий отчет по проведенным испытаниям (что было протестировано и с каким результатом), а также список багрепортов (с информацией достаточной для воспроизведения/локализации коллегами). Release notes. Могут быть внутренними и содержать важную информацию, которую необходимо учесть при выпуске задачи (частично может совпадать с QA Notes) для её корректной работы. Чаще сталкиваемся с публичными release notes, в которых сообщаем пользователям о содержании обновления, как правило, это совокупность наиболее критичных изменений в удобочитаемом облегченном виде. Цель публичных RN уведомить пользователей о произошедших изменениях, тем самым скорректировав ожидаемый результат пользователей, когда и где это необходимо. Эксплуатационная документация. Ну и наконец документация по эксплуатации ПО, которую можно увидеть не так уж и часто. Однако, одно дело если Ваш продукт легок, прост и интуитивен для его пользователей, а изменения небольшие и едва заметные, и совсем другое дело – если продукт сложный или обновление серьезно меняет пользовательский опыт. Тут без документации не обойтись никак. В ней важно изложить суть изменений, а также рекомендуется дать небольшие комментарии о причинах, которые повлекли за собой эти самые изменения. Это позволит сделать коммуникацию с пользователями более аргументированной, понятной и прозрачной. А специалистов технической поддержки Вашей компании избавит от лавины однотипных вопросов/ответов (ну или позволит им хотя бы ссылаться на эту документацию в своих ответах, а не писать все каждый раз с нуля).

Обложка-мем к посту ниже:)

Друзья, не забудьте поздравить своего тестировщика с профессиональным праздником! Ну а всем коллегам по цеху хочется в этот день от души пожелать стабильных релизов, зеленых тестовых прогонов, поменьше пинг-понга с разработкой, побольше понимания с продактами, поменьше багрепортов, пошире тестового покрытия, поменьше инцидентов в проде, побольше прокаченных компетенций в ИПР, крутых фич и отличных коллег! С Днём тестировщика!

Проходку на начинающуюся завтра Podlodka QA Crew было решено отдать Сергею Никифорову ака @End_spiel, автору комментария: «Кароч, у нас было: Три графика по zbp, два графика по стоимости беклога, солонка, наполовину наполненная графаной и метриками по 500 в критичных ручках и целое море разноцветных дешиков по SLA Не то, чтобы это все работало, но это было нужно, чтобы просто выжить Страх вызывал только расчет инцидентов в деньгах. Я понимал, что если мы уж начали копать инциденты, то когда-то опустимся и до этого ...» судя по которому, Серега (он, к слову, ищет себе бойцов в команду, не стесняйтесь писать ему в личку) явно знает толк в метриках и сможет докинуть интересного на самой конференции. Приходите и вы, будет интересно и познавательно;)

На следующей неделе залечу с интервью о метриках на Podlodka QA Crew. Поделюсь опытом внедрения, работы над, анализом и улучшением показателей метрик в плоскости QA. Будет интересно! Считаете ли Вы, что они только мешают нормальной работе, или, наоборот, что без них никак вообще нельзя? Делитесь в комментариях вашим отношением к метрикам и опытом работы с ними. В воскресенье вечером автор самого интересного комментария традиционно получит промокод для посещения Podlodka QA Crew (онлайн-сессии утром и вечером + записи + общение в коммьюнити).

Давненько не было от меня новостей. Отчасти потому, что последние несколько месяцев активно включался в работу на новом месте. Было непросто, но благодаря совместным усилиям моей команды, руководителя, HR и коллег с других направлений все получилось. ИС пройден и теперь могу с гордостью рассказать, что теперь тружусь директором по качеству в «Одноклассники». Случился своего рода come back в Mail.Ru Group, который нынче VK. А потому хочу вкратце поговорить о важности и контенте онбординга нового сотрудника по ту сторону баррикад. Я неоднократно рассказывал о важности онбординга и в деталях давал рекомендации по его построению. Сейчас для меня эта тема стала особенно актуальной, надеюсь что найдет отклик и в сердцах читателей. Ведь грамотный онбординг на гибриде или удаленке вдвойне востребован, так как дает сотруднику чувство плеча коллег и ощущение причастности к общему делу. ——————— Попадая в новую компанию очень важно получит базовые представления о предстоящем онбординге, компании в целом, её ценностях и культуре, рынках, на которых она работает, специфики аудитории и т.п. Следующий слой знаний, которые необходимо получить содержит больше специфики о конкретной команде, её участниках, процессах работы, традициях, инструментах, необходимых доступах. Особое внимание стоит обратить на последовательную подачу новой информации, чтобы не завалить новичка всем и сразу. Также стоит помнить о важности выделенного наставника, который сможет оказать необходимую поддержку новичку, ответить на его вопросы самостоятельно или сориентирует к кому обратиться. Не стоит забывать о необходимости двусторонней обратной связи на всем протяжении испытательного срока, чтобы подсветить позитивные стороны адаптации и точки для роста (как сотрудника, так и компании). В идеале сотрудник должен в любой момент времени понимать, что предстоит сделать, какие у него задачи и цели и справляется он или нет. Это нужно и после прохождения испытательного срока, но во время ИС это вдвойне важно. Иначе все может закончиться, как у одного из моих знакомых тимлидов разработки, который как-то пришел расстроенный и рассказал, что его новый разработчик ушел на обед и не вернулся, написав короткую смс «онбординг отстой, мне уже прислали оффер, я увольняюсь». А как построен онбординг в вашей компании?

Делитесь опытом, используете ли вы уже в своей работе нейросети? По личному опыту, почти перестал на собеседованиях задавать вопросы уровня «протестируй поле», там и раньше уже всем все понятно давно было, так тут еще и нейросети подъехали, которые решают такие задачи на раз-два. Это в целом и неплохо, ведь такие решения могут и в работе помогать с тест-дизайном, а при определенном подходе можно и требования составлять, делать аналитику данных метрик и так далее. Лишь бы AI работал не так, как на картинке.

На днях закончился конкурс технических статей от Хабра "Технотекст 2022", где мне довелось побывать в роли судьи и были подведены его итоги. По совокупности судейских оценок призовые места заняли абсолютно заслуженно статьи "Колхоз. Большая история фермы устройств Яндекса" и "Мутационное тестирование: опыт внедрения на 1500 сервисов"! Но справедливости ради стоит отметить, что в шорт-листе номинантов было много интересных и полезных статей, рекомендую ознакомитсья и почитать, кроме вышеуказанных призеров, я бы пожалуй отметил еще статью "Как дизайнеры тестируют, или Что такое дизайн-ревью". Ну и в конце хотелось бы напомнить о недавном интервью о написании технических статей с моим хорошим другом Артёмом Комаренко, что выходило у меня в блоге. Оно будет полезным для тех, кто в самом начале пути и хочет начать писать технические статьи, возможно, стать номинантами или даже призёрами Технотекста в будущем;) Дерзайте!

Качество есть? А если найду? Одной из важнейших задач современного QA является популяризация идей обеспечения качества ПО среди коллег! Да-да, по сути QA-инженер часто выступает эдаким евангелистом качества, приходит на рабочие встречи и подсвечивает важность необходимых перемен в работе команды для обеспечения качества ПО! Тут хочется сразу слегка тормознуть перфекционистов потирающих ручки с мыслями «сейчас я им устрою». Безусловно QA-инженеры часто являются пассионариями от мира разработки, страстно желающими воплотить (и зачастую воплощающими) свои свежие идеи по улучшению процессов. Однако, стоит помнить, что одним из важнейших этапов формирования СМК является: «Прогнозирование потребностей, технического уровня и качества продукции» Что это значит на человеческом? Для разных продуктов степень их качества, то есть соответствие продукта его техническим условиям может быть совершенно разным. Давайте поясню на совсем «загаражном» примере: Уровень качества Hyundai Accent и Bugatti Chiron будет кардинально отличаться друг от друга, как в силу совершенно разных потребностей потребителей, так и их технического уровня и конечного качества. Причем разница эта не будет однозначной в пользу того или иного продукта. Например, различия потребностей потребителей связанных со стоимостью покупки и эксплуатации отличаются, а значит и уровень соответствия авто этим требованиям будет также разительно отличаться, как, например, и их скоростные характеристики, или требования по качеству топлива заливаемого в них. Что это значит для QA? Перед внедрением любого рода улучшений и инициатив, важно определить потребности пользователей, технический уровень и качество продукции, которые мы собираемся удовлетворять и обеспечивать. И только после этого выдвигать инициативы, запрашивать ресурсы под их реализацию и объявлять Крестовый поход за Качеством. И в этом вопросе опять же должна участвовать вся команда! Определены ли потребности пользователей, технический уровень и качество в ваших командах, и как это помогает в работе?

А как вы относитесь к переработкам/кранчам/работе вечером/ночью/в выходные? Думаю многие из нас грешили этим делом по молодости, получая новые знания и опыт, вредные привычки (привет кофе и энергетики) или даже болезни🙈 По личным наблюдениям, чем более зрелым становится сотрудник, тем чаще он старается выдерживать пресловутый work-life balance (или даже life-work balance). Что в целом довольно логично, так как мы обрастаем ответственностью, активностями и большей осознанностью по отношению к нашей жизни и работе. А что думаете об этом Вы, мои читатели, друзья и коллеги?;)

Попалась под руку очень годная статья про «коммерческое» и «профессиональное» образование на примере QA. Статья хорошо дополняет и расширяет мои собственные заметки по о теме (тыц и тыц). Однозначный must read для тех, кто хочет «войти в айти», особенно для тех, у кого еще не сняты розовые очки и есть мысли уровня «куплю диплом – получу работу». Да, жестко, да в лоб, но лучше так, чем поддаться на маркетинговые уловки и сформировать для себя ложные ожидания о профессии. зы: в конце этой заметки должна быть вставка «приходите ко мне, у меня все иначе»:))) но её не будет, временно не беру в работу новых джунов на менторинг, однако, это не значит, что я оставлю ваши вопросы без внимания, пишите в личку, если нужна помощь и совет🙏🏻

Карма тестировщика Думаю многим знакомо такое понятие, как карма тестировщика, которая часто преследует блюстителей качества (да и не только их) как в рабочем плане, так и по жизни. Проявляется обычно в ловле самых разных дефектов и попадании в так называемые edge-кейсы, когда в моменте времени будто бы сходятся все силы мира и возникает что-то неожиданное и зачастую непредсказуемое. За годы работы в сфере QA у меня скопилась богатая коллекция подобных ситуаций, одна из последних случилась буквально на днях. Вышел на новую работу, вместе с техникой мне был отправлен физический токен для получения доступов, который ребята из технической поддержки заботливо положили внутрь коробки, сделав небольшой надрез в ней. В нормальной ситуации токен вываливается в руки счастливого владельца легким движением руки. Однако, моя карма тестировщика решила иначе. Токен не получилось достать, так как внутри коробки были остатки заводского клея, на который этот самый токен и попал в процессе доставки. Токен закономерно прилип к коробке, пришлось её вскрывать довольно эпичным способом😅 А как в Вашей жизни проявляется #карматестировщика? Мешает ли она жить, или быть может наоборот помогает? Делитесь своими историями в комментариях👇🏻

О различии тестирования и обеспечения качества в виде легкой рэп-импровизации под стать пятничному вайбу! Всем продуктивной пятницы и отличных выходных ✌🏼

Мой бывший коллега и руководитель, Павел Щербинин, у себя в блоге поднял крайне интересный вопрос о том, что помогает нам оставаться на острие прогресса. Лично я убеждён, что крайне важно научиться учиться, а также не включать ретрограда без веских на то причин. Способность принимать будущее и прогресс делает нас его участниками, а навыки обучения новому помогают не только использовать все новшества, но и становиться их создателями. Ведь сколько раз человечество за свою многовековую историю восклицало «все уже было изобретено до нас»:) А что Вы думаете по этому поводу?

В этот пятничный вечер хочется поговорить об артефактах тестирования под углом принципов их оформления, хранения и дистрибуции, а также подсветить важность для современных процессов обеспечения качества систем управления тестированием, таких, как, например, Qase.

Автоматизация тестирования – хайповая тема уже много лет к ряду. И не без оснований, ведь это по сути эволюционное развитие тестирования ручного. Сколько автоматизацией занимаются, столько и слышно про нее мифов и страхов про «всех специалистов по ручному тестированию уволят и заменят на автотесты». Сейчас вот новые страшилки ходят про «ChatGPT будет проектировать и писать автотесты, оставив теперь уже и автоматизаторов без работы». Но пока автоматизацией по-прежнему занимаются кожаные мешки, то одной из наиболее часто поднимаемых тем становится параллелизация и многопоточность выполнения тестов. Именно об этом недавно написал заметку в своем блоге боевой товарищ по компании Qase Илья Филинин. Кстати, стэк, который использует Илья в своей работе набирает обороты и популярность у современных автоматизаторов – typescript+playwright, а потому рекомендую не только почитать статью, но и подписаться на канал в целом. Особенно тем, кто присматривается к теме автоматизации тестирования и хочет в неё погрузиться👍🏻

Всем привет! Сегодня у нас интервью с Артёмом Комаренко о написании технических статей! Как-то уже затрагивал тему написания статей, где затрагивал полезные аспекты от этого рода деятельности. Но одно дело мне, опытному автору и спикеру, залетать с новой статьей или заметкой в блоге, и совсем другие ощущения испытывают те, кто только-только начинает писать технические статьи. А потому сегодня у нас будет интервью с моим хорошим другом и неоднократным боевым товарищем Артёмом Комаренко, который недавно дебютировал на Хабре со своей статье об автотестах деплоя «Как написать автотесты деплоя и сэкономить нервы DevOps-инженеров». Статья получилось сочной, с практическими примерами, проблемами и их решениями, рекомендую к прочтению!

📼📽️ Видео и слайды со вчерашнего выступления в Failover Bar доступны по ссылкам ниже: Видео Слайды Приятного просмотра. Если будут вопросы/комментарии, добро пожаловать в тред к этому посту👍🏻