Отличный пост про оценку компетентности джуниора. Я полностью согласна с позицией авторов — чем больше опыта, тем больше самостоятельного принятия решений и ответственности за них.

Важно, что под "принятием решения" я имею в виду не упертое "будем делать так, и всё тут", а именно что умение задать правильные вопросы, учесть мнение тех, на кого эта задача напрямую повлияет, и выбрать оптимальный исход.

Мне кажется, именно умение взглянуть на ситуацию с разных сторон, учесть риски и ограничения и определяет существенное различие между опытным и начинающим специалистом, потому что второй пока умеет выполнять задачи только по заданной модели. И это ещё одно доказательство того, насколько же многогранная штука наша профессиональная идентичность, и насколько же формальны "грейды": можно спокойно принимать решения в одной области и не уметь действовать за рамками представленной модели в другой.

Обновила описание канала, добавив туда ссылку на GetMentor — да, теперь меня можно попросить стать вашим ментором на раз или на длительное время.
Небесплатно, потому что моё время стоит денег, однако стоимость пока не выставила — буду смотреть, исходя из длительности и сложности взаимодействия.
Кроме того, я пока в процессе формирования стоимости своей работы в качестве индивидуальной наставницы, и первые встречи планирую провести за донат.

Из других новостей: я воооот на столечко 🤏🏼 близка к тому, чтобы стать преподавательницей ещё одного курса. Буду рассказывать, что и как, а пока, чтобы не скучать, поделюсь парой ссылок, которые в последнее время часто открыты в моем браузере — раз уж мы заговорили про обучение 🙂

📖 https://devqa.io/ — типа Хабра, но англоязычного и суховатого :) В принципе, там довольно много интересных статей, в том числе с примерами кода а-ля "стартуй свой первый проект". Поковыряться на досуге — самое то.
📖 https://codernet.ru/books/ — онлайн-портал с книгами, видео и статьями. Правда, раздел Books вызывает вопросы: я вполне допускаю, что это пиратство (хотя, конечно, соблазн скачать все и сразу велик). В описании заявлено, что всё это для программиста, но не верьте: QA тоже найдет там много крутой информации.
📖 https://www.freecodecamp.org/ — бесплатный англоязычный портал с курсами на разных ЯП. К слову, там есть раздел QA, в который очень приятно заглянуть: там есть и тренировочные проекты, на которые надо писать автотесты, и курсы, и сертификация — можно пройти курсы и получить красивое подтверждение (я не уверена, что сейчас можно кого-то этим впечатлить, но некоторых такие вещи мотивируют — приятно же!).
Также там есть раздел с подготовкой к интервью — задачки, челленджи, вот это всё.

На этой ноте желаю всем продуктивной недели 💪🏼

Ну всё, теперь окончательно могу поделиться обновленями и радостью — я теперь часть программного комитета ближайшего, пятого, сезона конференции Podlodka QA Crew!

Пока что не буду спойлерить ни тему, ни другие крутые штуки — всему своё время. Но, думаю, многие из нас уже успели посмотреть хотя бы один из сезонов этой конференции (а если нет — бегом смотреть! Это совершенно крутейший формат, подстроенный под онлайн, с кучей полезной информации в разных активностях — от классических докладов до лайвкодинга, круглых столов и "барного" нетворкинга), а значит, не нуждаются в отдельной рекламе — потому что по прошлому опыту помнят, что будет очень круто.

Это не первый мой опыт бытия частью ПК, однако прошлая конференция — SECR 2019, — была больше научной, чем IT-шной. Сейчас же есть отличный шанс сделать свой вклад в контент, который смотрю я, мои друзья, коллеги, приятели. Короче, догфудинг как он есть 🙂

Вопросы к будущей команде

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

https://telegra.ph/Voprosy-k-budushchej-komande-cheklist-08-04

Сложно — это хорошо?

Кратко: однозначно да!
Длинно:
https://telegra.ph/Slozhno--ehto-horosho-08-17

Алгоритмы написания автотестов

Недавно в рамках менторинга мне поступил вопрос: можно ли написать пошаговый алгоритм, следуя которому команда сможет писать автотесты, даже если раньше с ними не работала? (при условии, что выбран инструмент автоматизации, и есть достаточно знаний ЯП/фреймворка/библиотеки, с которыми будет идти работа).

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

Написала отдельно про два случая:
🔹 API-тесты
🔹 GUI-тесты
— для удобства чтения, обсуждения и навигации.

Буду рада узнать от тех, кто регулярно работает с автотестами: что бы вы добавили, что бы убрали? Какими лучшими практиками вы пользуетесь?

Немного ранее я писала и делилась радостью, что вошла в состав программного комитета нового сезона небезызвестной конференции. Пришла пора наслаждаться результатами работы :)

Итак, мы готовы анонсировать новый сезон Podlodka QA Crew — погружение начнется 13 сентября!

Во время первой недели обсудим интеграционное тестирование:
- Будем учиться тестировать интеграции внутренних и внешних сервисов;
- Узнаем лайфхаки реализации интеграционного тестирования необычных систем;
- Разберемся, как эффективно тестировать микросервисы.

Вторую неделю посвятим тестированию с ограниченными ресурсами:
- Узнаем, как бороться с легаси;
- Поймём, как наладить процессы QA в команде;
- Будем учиться строить процесс QA, в который вовлечена вся команда.

Это тот случай, когда я действительно горужсь тем, что получилось: огненная программа, классные опытные спикеры, много активностей и холиварные — в хорошем смысле — обсуждения :)

Подробности и билеты уже на сайте!
До конца недели действует скидка ⚡️

Внезапно спикаю на GDG Kaliningrad 25-26 сентября. Подключайтесь послушать, если есть возможность!

Между тем, SQA Days выставили в открытый доступ плейлист с записями 28-го сезона конференции ☺️

И я там была: рассказывала про систему автоматизации тестирования в VK и про то, как красиво (и не очень, you know, it ain't much, but it's honest work...) стабилизировать непослушные тесты для GUI.
На самой конференции доклад встретили супер позитивно. Надеюсь, и в записи он кому-то окажется полезен и интересен!

Послушать можно тут: https://youtu.be/at0GZJXZ5bc

Офигенная заметка о декомпозиции больших метрик и о неочевидных «бытовых» факторах, влияющих на общий результат.

Time-to метрики

Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.

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

Или шли налить себе кофе → кружка на другом этаже → вернулись, а в кофе машине кончилась вода → наполнили бак → ещё и кофе нужно насыпать → «ой, не больно то и хотелось». В результате вы ушли на очередную встречу раздражительнее, из-за чего она прошла менее конструктивно.

На какое ещё время можно обращать внимание?

– Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
– Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
– Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
– Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
– Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?

В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?

Use case и тестирование требований

Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.

#база_тестирования
#записная_книжка

Вроде в проде?

Однажды жизнь в лице сообщества QA sisters связала меня с потрясающей тестировщицей, лидкой, евангелисткой computer science в тестировании и просто вдохновляющей девушкой — @alexpshe.

Когда мы переписывались в общем чате, я ещё не знала, что приду в Semrush, и мои первые деньки пересекутся с последними рабочими днями Саши перед уходом в команду Qodana; я не думала, что с Сашей я проведу одну из самых огненных сессий на 5-м сезоне Podlodka QA Crew, и уж точно представить себе не могла, что спустя какое-то время мы выпустим своё детище — подкаст!

Дамы и господа, представляю вашему вниманию первый выпуск "Вроде в проде" — подкаста про качество в IT и не только!
Теперь нас можно не только читать, но и слушать :)
В первом эпизоде мы говорим про то, с чего начинается любая работа тестировщика: собеседования, и даем себе из прошлого советы, которые сейчас сильно упрощают жизнь.

Твиттер, Spotify, Apple Podcasts, Soundcloud и Яндекс.Музыка (coming soon) — слушайте, делитесь, пишите Ваши мысли и вопросы!

За офигенный джингл спасибо @alloshmallo, а за юзерпик — https://www.instagram.com/abazhanova_v.
Ребята, благодаря которым появилась наша айдентика — это отличный пример тех, кто делает качество вне IT :)

Привет!

В последнее время в канале появились новые лица, так что предлагаю познакомиться чуть ближе 😉

Меня зовут Настя, я работаю QA-инженером (в трудовой это записано как "старший инженер по тестированию и автоматизации тестирования", хотя на лычку senior я себя очень редко ощущаю) в продуктовой компании в команде, которая занимается разработкой инструментов аналитики ключевых слов для продвижения в поисковых системах.

Моя специализация — веб. Большую часть времени я пишу автотесты (Golang + Testing plugin; Kotlin + retrofit 2 + TestNG; Kotlin + Selenide + TestNG), но кроме этого также тестирую руками, пишу тестовую документацию и с недавних пор не боюсь настраивать пайплайны в CI 🙂

Ещё я одна из создательниц сообщества QA sisters, со-ведущая подкаста "Вроде в проде", преподавательница Stepik Academy и Нетологии и авторша и лекторша курса по тестированию.

Этот канал я заводила году в 2019, потому что тяга к делению знаниями была слишком велика, а ещё я немного использовала его как "уточку" для рассуждений о работе, когда было совсем одиноко. Сейчас стараюсь писать сюда регулярно, вкидывать что-то полезное, дублирую свои выступления на митапах и конференциях и в целом довольно охотно делюсь полезностями из других каналов классных айтишниц и айтишников.

О чем можно почитать/посмотреть, если вы тут недавно:

🔹 Список тестовых песочниц, если надо на чем-то потренировать навыки тестирования
🔹 Наш с коллегой доклад про базу знаний в компании: как организовать и зачем
🔹 Моя статья про тестирование на основе моделей
🔹 Мой доклад про локаторы в вебе и их применение
🔹 Заметка про оффбоардинг
🔹 Заметка про вопросы будущей команде
🔹 Пошаговая инструкция, на что обратить внимание при сетапе автоматизации в проекте
🔹 Мой доклад про лайфхаки автотестирования UI с SQA days 28

О чем рассказать на митапе?

*прочищаю горло и включаю режим бабули*

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

Сейчас всё в разы проще.
Во-первых, пресловутый опыт: чем его больше, тем легче собраться и с первого раза всё сделать правильно.
Во-вторых, количество онлайн-событий кратно выросло по сравнению с ситуацией пару лет назад, а значит, появилось больше возможностей для выступления тем, кто может рассказать интересное, но стесняется выступать перед живой аудиторией.

Это накладывает и определенные сложности. Митапы в онлайн-формате чаще идут под запись — а это значит, что темы надо выбирать более тщательно: я часто мучаюсь в сомнениях, что тему, которую я выбрала, кто-то рассказал до меня (и намного лучше меня).

Итак, вас зовут выступать на митапе, — или же вы сами хотите, — но пока не знаете, о чем поведать. Или же у вас есть идеи, но вы боитесь, что будете не уникальны в своей теме.

Я бы предложила в этом случае ответить на несколько вспомогательных вопросов, которые в итоге помогут принять оптимальное решение.

1. Есть ли у меня идея, о чем я хочу рассказать, или же это просто желание выступить?

2. Если идеи нет: действительно ли мне нужно выступление? Что я хочу получить, побыв спикером? Как ещё я могу это получить?

3. Если идеи нет, но выступление всё равно хочется: в чем я хороша? 

4. Если идеи нет, но выступление всё равно хочется: что я могла бы рассказать коллеге помладше? Коллеге из другой сферы?

5. Если идея есть, уникальна ли она?

6. Если идея есть, подкреплена ли она моим опытом?

7. Если идея есть, решает ли она какую-то проблему слушателей?

8. В каком формате я хочу донести идею?

9. Могу ли я как-то улучшить содержание доклада?

10. Сколько времени мне требуется на подготовку?

11. Есть ли у меня план?

Ответив на все эти вопросы, вы получите более полное понимание, о чем вы можете рассказать — и нужно ли вам выступление прямо сейчас. После этого можно переходить к более решительным действиям: составить план выступления, показать его друзьям или коллегам и начать работу над “мясом” вашей темы.

А ещё я всегда рекомендую сразу же определить цель выступления: что вы хотите донести? Какую основную мысль должны вынести слушатели после вашего доклада?
Это можно сделать и в другой момент подготовки, но если всё определено заранее, проще готовить содержание выступления: цель спича всегда будет маячить впереди, как путеводная звезда, и помогать не отвлекаться от темы — и не забывать рассказывать попутно важные вещи, которые в ином случае можно упустить (потому что мы-то погружены в контекст своего доклада и может не заметить, что не донесли до слушателя какие-то ключевые детали).

А если хотите послушать классных спикеров и вдохновиться, приходите на митап в четверг, 11 ноября!
Питерское QA-сообщество проводит офлайн-митап (разумеется, со всеми мерами эпидемиологической безопасности) с интерактивной трансляцией на ютубе.

В программе доклады про регрессионное тестирование, работу с Android Auto в условиях пандемии и выступление Артема Ерошенко об организации процесса тестирования (если вы не знаете, кто такой Артём — срочно поищите! Это человек из команды, подарившей нам экосистему Allure 🙂).

Начинаем в 19:00 по Москве. Онлайн трансляция будет тут, а если вы из Питера и хотите прийти лично, то вам сюда.

Так как моё внерабочее время сейчас целиком и полностью занято подготовкой курса по тестированию, то, чтобы канал не пылился, спешу поделиться анонсом хорошего митапа.

Ребята из Factory Talks очень приятные: они делают некоммерческие митапы без рекламы и хантинга. Когда-то я и сама подобным занималась! И, честно говоря, надеюсь вернуться к такому движу в будущем, — а пока с радостью слушаю коллег, и вас зову с собой ☺️

Программа:
🧐 19:05 Как понять хороший ли я наставник для стажера? / Станислав Яковлев, Юла
📚 QA Team Lead Станислав Яковлев расскажет о том, когда пора нанимать стажера и как погружать его в работу тестировщика, а также по каким параметрам оценивать, насколько ты хорош в качестве наставника.

🧐 19:30 Чудаки в IT и как с этим жить / Василий Кирнос, Авито (Товары)
📚 QA-инженер с опытом работы более 10 лет Василий Кирнос поделится кейсом о том, как менять жизнь, выбирая работу с теми, кто тебе нравится.

Начало в 19.00 по московскому времени.
Уведомление о трансляции можно поставить здесь.

Кстати, в рамках упомянутого курса мы с коллегами делаем прикольные материалы, которые могут быть полезные начинающим (да и не только, чего уж там) QA.

Вот, например, пара коротеньких видео:

1. Метод шаурмы
Тут я самозабвенно рассказываю про "метод шаурмы" (или, как говорят петербуржцы, шавермы). Сначала я услышала про него от коллеги на каком-то митапе, а потом нашла похожую статью. В целом, эта эвристика полезна в случае, когда нам надо быстро сориентироваться, как комплексно тестировать любой продукт. Мне кажется, такой метод прикольно также использовать для прикидывания грубой оценки времени на тестирования (ключевое слово — грубой. Конечно, впоследствии нужно подходить к разбору задачи более детально).

2. San-Francisco Depot
Тоже про эвристический метод, который сокращенно называется SFDPOT, — звучит как сокращение от английского "вокзал в Сан-Франциско", или San-Francisco Depot. Подробнее об этом хорошо написано тут; метод придуман и описан Джеймсом Бахом, которого я бесконечно уважаю.
Как и метод выше, SFDPOT полезен для организации полноценного, комплексного тестирования, и позволяет понять, не забыли ли мы учесть какой-либо аспект обеспечения качества.

Зачем практика построения системы CI/CD в продукте нужна QA-инженеру?

Да потому что это ещё один способ контролировать и обеспечивать качество, — и, что особенно приятно, делать это во многом автоматически, заходя на территории, куда обычно тестировщик не заглядывает: качество кода от кодстайла до линтера, анализ тестового покрытия и многое другое.

Мы с Сашей в новом выпуске подкаста "Вроде в проде" поговорили о том, какой вклад может внести QA в качество продукта через CI/CD.
Мне кажется, этот выпуск вышел особенно удачным, поэтому с радостью делюсь им в канале 😌

Уже доступно на Soundcloud; сегодня появится в Apple Podcasts, Google Podcasts, Spotify и Яндекс.Музыке.

В это непростое время многие остаются без работы. Я всегда была противницей риторики «тестирование — простой вход в IT», но сейчас становится очевидно: любой вход в цифровую профессию, позволяющую работать удаленно, важен, и гейткипинг — худшее, что можно сделать для других.

Важно помогать друг другу по мере сил. У нас с Сашей, моей коллегой и подругой, хорошо получается обучать и менторить, поэтому в рамках подкаста «Вроде в проде» сделали гайд по вкатыванию в тестирование: где и чему учиться, на что обратить внимание, как собеседоваться.

https://vrode-v-prode.notion.site/ab63240989444beab694393e33f7a5d2

#почитать #англ
Software Quality Assurance online course

Если вы давно планировали подтянуть QA-терминологию на англ, то вот тут появился простой и понятный (бесплатный) курс для этого.
В нём можно найти минимум необходимой информации, без воды (как мы любим) и квизы, чтобы лучше запомнилось.