Только хотел написать анонс про митап в Райффайзенбанке, который планировался в марте, как коллеги рассказали, что регистрацию на него прикрыли из-за короновируса и карантина. Чувствую, такими темпами все перейдут скоро на вебинары. Ну, а картинка просто в тему) Не болейте!

UPD: пока митап перенесён на апрель, подождем-с.

Документация на проекте

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

Но выход есть:

1) Начать писать тестовую документацию прямо сейчас, даже если вы только пришли на проект. Для этого общаемся с разработчиками, аналитиками, саппортом, девопсами, продуктовыми менеджерами - со всей командой. Общаемся и пишем.

2) Выстраивать процессы обмена информацией внутри команды. Хорошо, если есть единомышленники - продавливайте с ними свои идеи, пресекайте любые попытки вам помешать. Документация - это часть обеспечения качества. Нет документации - нет контрактов между интерфейсами, нет API, нет тест-кейсов, нет проекта.

Если первый пункт зависит целиком от вас и вашей QA-команды, то со вторым все намного сложнее. Документация разработчиков может выглядеть лишь поверхностным описанием работы приложения в Confluence, это в первом приближении разумно, так как в случае чего всегда можно посмотреть более точный источник - код. Но могут ли его посмотреть QA, другие коллеги? Далеко не всегда, да и в большинстве случаев не должны. Пусть аналитики напишут требования, а разработчики напишут, как они эти требования реализовали - они и только они владеют этой информацией.

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

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

Напишите мне в личку - @pavelthai, как у вас построен процесс обмена информацией, какие инструменты используете, все ли делятся информацией? Независимо от того, где вы работаете - это процесс везде плюс/минус одинаковый. Самые интересные и полезные идеи опубликую в одном из ближайших постов.

Работа в Yandex

Моя подруга Мила (работает QA Automation Engineer в одной зарубежной компании) успела до пандемии коронавируса попасть на экскурсию в Яндекс и поделилась своими впечатлениями.

Далее Мила от первого лица:
«Я сходила на экскурсию в офис Яндекса для технических специалистов (было это 26-го февраля - да, улиточка во мне не дремлет! Или как раз дремлет).

Кто может попасть на эту экскурсию? Любой технический специалист в сфере информационных технологий, который зарегистрируется на сайте https://yandex.ru/promo/on-site. Сейчас, впрочем, надо дождаться окончания периода самоизоляции. Приглашают они не всех. Как выбирают, кого позвать, а кого нет - не знаю. Меня позвали, а коллегу, который прислал мне ссылку с предложением зарегистрироваться - нет.

Что было на экскурсии? Водили по офису и показывали, как у них там хорошо. Есть кабинки, похожие на телефонные будки - в этих кабинках можно уединяться, если вдруг захотелось. Даже кресла для интровертов имеются - с высокими спинками и боковыми стенками - сядешь в такое и никто не достанет. Много разных кухонь с запасами различной еды в виде мюслей, каш, чая, печенек и еще чего-то подобного.

Офис очень зеленый, вся зелень настоящая с автоматическими поливалками.

Кстати, в самом офисе на лестничных площадках есть карты с указанием того места, где вы находитесь и всех помещений, что находятся с вами на этаже.

Приятный парень, работающий в Яндексе бэкенд-разработчиком, рассказал об условиях работы: оплачивают фитнес, занятия английским, участие в конференциях, ДМС со стоматологией с первого дня работы (насколько я помню), даже выдают деньги на покупку квартиры - на 3 года без процентов или на 10 лет под 3% годовых.

Помимо заработной платы каждому сотруднику начисляют 9700 рублей для обедов. Этими деньгами можно оплачивать обед в большинстве кафе и ресторанов, что находятся в шаговой доступности от офиса. А также каждый день на карту падает некоторая сумма до 10 утра, которую можно потратить на завтрак. Если вовремя не потратить, то деньги сгорают, конечно, потому что начисляются на пропуск, с которым сотрудники проходят в офис. Им же и производится оплата в кафе и ресторанах.

Что может быть интересно девушкам - в офисе есть комната матери и ребенка. Все сотрудники без проблем могут приводить в офис своих детей. Которым там точно будет, чем заняться.

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

А ещё в Яндексе дают премию своими же акциями. Но не совсем акциями, потому что вроде как они есть, но дивиденды будут начисляться только через 4 года после их получения и только если все эти 4 года работать в Яндексе. Каждый год активируется четверть полученных в виде премии акций».

Как вам условия? Хотели бы работать в Яндексе?)

Обратная связь

Как замотивировать себя на проекте? Ответ: получить фидбек от своих пользователей. Да, нередко он бывает негативным. Да, пользователям не всегда заходит фича, которую вы готовили командой в течение спринта. Но ведь это говорит о том, что юзерам интересен ваш продукт, они используют его, находят изъяны, чем-то недовольны, а от чего-то, наоборот, кайфуют. Такая обратная связь - очень ценная вещь.

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

Lockdown, bye!

Поздравляю, более-менее все выходят из локдауна, это здорово. Для меня удаленка - это плюс 1,5 - 2 часа свободного времени, которое я раньше тратил на дорогу до работы. Знаю, что у многих получилось занять это время под более полезные вещи. Я вот взял курсы английского в Skyeng. Только мы с преподавателем решили, что это я её буду учить, а не она меня. И вот как мы это сделали: я скидываю в наш чат интересные англоязычные статьи про QA, а на ближайшем уроке мы их обсуждаем, анализируем и иногда спорим. Сегодня вот буду рассказывать Татьяне, кто входит в IT-команду, и какие задачи решают эти люди. Посмотрим, поймет ли она мои корявые объяснения на английском😜

Гайз, тут для вас подоспели отличные короткие интервью со знакомыми ребятами из самых разных IT-профессий. Как они стали айтишниками и что думают о тестировщиках? Какие инструменты используют и обучались ли на каких-то курсах ранее? Всё это - в течение ближайших двух недель на канале. Начнём с разработчиков: знакомьтесь, Дима, Java Developer ⬇️

https://telegra.ph/5-voprosov-razrabotchiku-07-14

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

Если вдруг у вас тоже появились вопросы к ребятам - смело задавайте их в комментариях к посту, ответим!
https://telegra.ph/5-voprosov-menedzheru-proektov-i-sistemnomu-analitiku-07-18

Недавно на Хабре вышел перевод неплохой статьи про два метода управления проектами - Scrum и Kanban. В IT оба метода крайне популярны, а на технических собеседованиях достаточно часто спрашивают про преимущества и недостатки того или иного метода.

В компаниях, где я работал, используется симбиоз скрама и канбана - и это действительно мощно.

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

Что же касается канбана, то с ним я познакомился задолго до того, как пришёл в IT - когда участвовал в проекте, связанным с авиастроительной и машиностроительной отраслью - недаром этот метод зародился почти 70 лет назад в Toyota.

Ничего не знаете про эти два метода? Тогда перед чтением статьи посмотрите, к примеру, Википедию, а потом уже погрузитесь в статью.

✅- я за Канбан
🔄 - я за Скрам
🎌 - я за смешанный метод управления

https://m.habr.com/ru/company/ruvds/blog/510558/

Как ищут работу тестировщики?

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

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

За опытных QA-инженеров компании готовы бороться - часто таких специалистов могут схантить знакомые HR или бывшие коллеги - в этом плане возможностей становится больше, собеседование сводится как правило только к техническому разговору с будущим руководителем.

9 сентября тестировщики отмечают свой профессиональный праздник!

Дата была выбрана не случайно: 9 сентября 1947 года ученые Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле. В отчете о неполадках было зафиксировано, что причиной неисправности машины был баг (bug - жучок). Но при этом очень многие ошибочно считают, что тогда впервые и повилось понятие "баг". Однако, этот термин стал использоваться аж с 1870-х годов, задолго до компьютеров. Вот такая история.

Похоже, вы меня потеряли: постов нет, новостей нет. Но не всё так однозначно, сейчас объясню, почему так получилось.

https://telegra.ph/Pohozhe-vy-menya-poteryali-10-20

Обещал рассказать, как проходит рабочий день? Рассказываю!

https://telegra.ph/Moj-rabochij-den-10-30

Ошибка

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

Какие эмоции были бы у меня всего пару лет назад? Обида, страх, злость, разочарование, стыд. Мы привыкли бояться ошибок, совершать их, признавать их. И работать с ошибкой в большинстве своем не умеем.

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

Ошибка подсвечивает какие-то проблемы в процессах, в работе, в нашем поведении. А это значит, что сделав ошибку, теперь-то мы точно знаем, что нужно сделать, чтобы ее предотвратить и запомним это надолго!

Есть только один тип ошибок, который действительно неприятный - это когда мы знаем, как надо, но продолжаем делать неправильно.

Но какой бы ошибка ни была - отнеситесь к ней положительно, она уже в прошлом, она - иллюзия, а вы уже всё сделали правильно😉

Мой товарищ (и он же Java-разработчик по совместительству), недавно понял, что нет (наверное) в Телеграме каналов с QA-мемчиками и, недолго думая, решил создать такой: https://yangx.top/qa_memes
Подписывайтесь и отправляйте свои мемы)