QA HELP

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

Поэтому смотрите сами и выбирайте то, что вам интересно: ссылка на плейлист

https://youtu.be/eE-jDVuYtJM

Тинькофф сегодня проводит Agile-конференцию в Москве для руководителей, продактов, тимлидов IT-компаний. И наконец-то оффлайн! Очень полезные и интересные доклады: их читают параллельно в двух аудиториях. А я решил посетить воркшопы (сами доклады посмотрю потом в записи). Разобрались с ребятами из Сбера, Яндекса и многих других компаний с итеративным делегированием в командах, чуть позже напишу пост про это😍

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

Культ карго - термин, которым называют некоторые религиозные движения в племенах Меланезии (в таких странах, как Папуа-Новая Гвинея и некоторых островных государства - Фиджи и т.п.). Зародились эти движения примерно в ХХ веке, когда в силу военных действий на эти острова было сброшено самолетами множество грузов - консервы, обмундирование, прочие продовольствие. Для островитян, которые раньше в жизни ничего подобного не видели - это было настолько в диковинку, что они начали этим вещам поклоняться (особенно, когда эти грузы перестали падать к ним с неба). Они заманивали самолеты, строя на своих островах деревянные диспетчерские вышки, всячески имитировали действия солдат, которые ранее жили на островах, делали наушники из половинок кокосов и взлетно-посадочные полосы из пальм. В общем, такое вот поклонение вещам случилось в некоторых племенах.

Сейчас выражение «карго-культ» используют в переносном смысле, когда некий человек/общество/компания перенимают и воспроизводят какие-либо технологии и методы, которые по всем признакам должны привести к положительным сдвигам, но лишь имитируют это (при этом не вдаваясь в детали этих технологий, не имея четких целей, либо сознательно пренебрегая этими деталями). И тут меня вдруг осенило, что в паре компаний, где я работал ранее, мы с командой на все 100% были заложниками карго-культа, внедряя Agile-методологии (SCRUM’ы, Kanban’ы и т.п.), особо не понимая, для чего это нам нужно и какой профит это нам даст, а просто из-за того, что это модно и “все так делают”. Осознавать такие вещи - оч классно, чтобы не наступать на те же грабли в дальнейшем

Провёл пару вечеров за перечитыванием отличной настольной книги для тестировщиков, тимлидов, автотестеров (в Google автотестеры называются разработчики в тестировании - звучит красиво:)

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

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

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

Ошибка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lockdown, bye!

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

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

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

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