Приветствую вас на канале для увлечённых тестировщиков.

Здесь есть:
Табличка полезностей - там собраны классические и свежие материалы по самым разным тематикам, так или иначе касающимся сферы тестирования и обеспечения качества
#синопсис - обзор новинок в табличке полезностей
#общее - общие сведения, всё обо всем
#ментор #наставник - информация о поиске ментора/наставника, детали такого индивидуального обучения
#курсы - информация и ссылки на курсы
#бесплатное - всё, что касается бесплатной информации (не пиратское, а общедоступное)
#сети - вопросы о сетях
#инструменты - всё про инструменты и их использование
#web - информация по тестированию веба
#API - информация по тестированию API
#мобилки - информация по тестированию мобильных приложений
#саморазвитие - темы про самообучение и саморазвитие
#рабочийпроцесс - темы про всяческие ситуации и вопросы о работе и взаимодействию с рабочим коллективом
#яжменеджер - серия постов про менеджерство в ИТ и метрики
#собеседование - про поиски работ, собеседования, тестовые задания и всё такое
#релиз - всё, что касается релизов и релизных процессов
#анонс - анонс мероприятий, в которых я участвую
#мероприятия - информация о проведенных мероприятиях, в которых я участвую
#опрос - проведение опросов и их результаты
#вакансия - избранные рекомендованные вакансии
#мемопауза - мемасики

#общее #курсы #бесплатное

Переношу из комментариев много полезностей:

Ресурсы для всех, особенно для начинающих.
Огромные источники информации по тестированию:
https://olzhas.notion.site/QA-Wiki-320b99ee9683424b928db83042745bb6

https://vladislaveremeev.github.io/
https://github.com/Kakha-Khinikadze/Links-QA/blob/master/Links.md

https://testbase.ru/


Бесплатные курсы:

https://www.portnov.com/ru/ - https://youtube.com/playlist?list=PL_CSTk3_YGZ8i3h8yai0Lp5yrtQ8ga92G

https://youtu.be/BmX1I3Rmt_g

https://taplink.cc/rusau.qalife - https://youtube.com/playlist?list=PLKbJd47Kcbju2Vhi-FL7AI14vItVmGYk-

https://youtube.com/playlist?list=PLZqgWWF4O-zg03RGSZ2GpHLE3BmO8bjKo

https://youtube.com/playlist?list=PLrCZzMib1e9pDKLsabJYuODdVJrHYc4Jd

https://youtube.com/playlist?list=PLiao2fIOcIztF4B1LH2r-LUhey4Gq5lK7

https://youtube.com/playlist?list=PLiao2fIOcIzvq_8lGmoCitHiLIVbczKco

https://www.guru99.com/

Добавлю ещё от себя недавно обнаруженное - бесплатная школа автоматизации: https://www.facebook.com/groups/370496047446051/

#общее

И ещё крутотеньки из комментов: роадмап развития тестировщиков и майндмапы с нужными тестировщикам скилами.

https://www.mindmeister.com/1715823304?t=E8hvheIYRp

https://www.mindmeister.com/1558647509?t=973hdS2AKb

#сети #web

Как раз думала о чем бы написать раз не спится и тут пришел в чатик вопрос: "если собираюсь работать с вебом, как джуну мне нужно понимание работы сетей на уровне вот такой статьи https://habr.com/ru/post/307252/ или это уже слишком? Хватит просто понимания, как работает клиент-серверная архитектура (и ответить на вопрос как работает интернет)?"

Сугубо на мой взгляд для джуна важно верхнеуровневое представление о том, что такое клиент-сервер, как он работает, его основные преимущества и недостатки. Хорошо, если джун представляет и даже может рассказать как примерно работает интернет. Хорошо, если джун слышал про уровни OSI (не то чтобы это нужно на любом веб-проекте, но это показывает общую эрудицию на тему сетей). Все более глубокие вопросы сильно зависят от проектов 🤷‍♀️
Грубо говоря, в веб-студии, клепающей потоком простые сайты на заказ тестировщику врядли будут нужны такие знания, а в проекте, связанном непосредственно с сетями, запрос работодателя будет более глубокий (вспомним известную компанию Veeam, требующую от джунов довольно обширных и глубоких познаний).

Еще я бы добавила, что если тебе интересно изучить тему сетей, то это будет только плюсом! 💪
Можно походить по описаниям вакансий в разные компании и пособирать из требований чего же компании хотят от кандидатов. Но надо помнить, что описанные в вакансиях требования зачастую стоит делить на два 😉

#API

Пообещала написать про API вообще и Postman в частности и слегла с сезонной простудой 🤪
Сейчас уже лучше, так что я с вами 😊

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

Что мне помогло:
1. Осознание того, что тестирование API в основе своей ничем не отличается от тестирования того же веба или десктопа - принципы и техники применяются те же самые, просто способ ввода данных другой и формат документации отличается
2. Очень помогли коллеги, показавшие как они обычно работают с апишками и с постманом/соапюаем
3. Очень помогла документация и умение понимать xml, json и главное (для soap) - понимать xsd-схемы
4. Практика-практика-практика 😅

В простых случаях, когда API - это просто связка фронта и бека один-к-одному всё довольно тривиально: Можно создавать/менять/удалять/читать данные на фронте, в UI, а можно делать тоже самое без участия фронта, с помощью API запросов. Если на проекте есть документация для API, то всё просто - берем нужный стенд, берем запрос, вставляем в запрос нужные нам данные и отправляем его в бек, бек думает и отвечает позитивно или с ошибкой. Для rest API (наиболее популярные) пригодятся знания кодов ошибок (хорошо знать хотя бы серии ошибок: 100, 200, 300, 400, 500 - какая серия о чем говорит). В рамках прохождения курса наставничества я записывала вот такое видео на эту тему: https://www.youtube.com/watch?v=Ekjq3Pdn5uE

Когда вы имеете дело с публичными API документация должна быть очень строгой и определенной и реализовано всё должно быть в строгом соответствии, т.к. этим API может пользоваться кто угодно.

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

В тестировании API есть своя прелесть: нет UI, в котором постоянно что-то не правильно отображается, нет кроссбраузерности и т.д. И автоматизировать API намного проще и намного стабильнее, чем UI.

Про тестирование API хорошо написано тут:
https://quality-lab.ru/blog/rest-api-testing/
https://habr.com/ru/post/568360/
https://testbase.ru/?post_type=skill&p=1313

Вот тут есть пара сервисов, где можно попробовать подёргать запросы: https://testbase.ru/test-it

А еще есть https://t.iss.one/found_that_api - тут можно найти публичные апи и попробовать подёргать их за хвосты 🙃

Не знаю, стоит ли тут писать про то как работать с Postman или Insomnia, мне кажется, такие технические детали гуглятся очень легко. Но если это мне только кажется, напишите, пожалуйста, в комментах 👇

#API

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

Что такое GraphQL, история, основы: https://habr.com/ru/post/326986/

Плейлист на ютубе: https://www.youtube.com/watch?v=kZs7CXrtT-s&list=PLNkWIWHIRwMF2sVLwzRef0Cu5kzAOeRcu&ab_channel=webDev В описании к каждому видео ссылка на GitHub. Можно легко все уроки воспроизвести у себя, используя консоль и редактор кода

Основы: https://ru.hexlet.io/blog/posts/chto-takoe-graphql-s-osnov-do-pervyh-zaprosov

Как работать с GQL в Postman: https://www.youtube.com/watch?v=7pUbezVADQs&feature=emb_logo&ab_channel=Postman

https://testengineer.ru/kak-testirovat-graphql-api/ - свежая статья про графкуэль в постмане

Так же с графкуэль можно работать в инсомнии (нужна часть, которая Core): https://insomnia.rest/

#общее

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

Начнем с минусов и возможностей их нивелирования, а может быть даже превращения в плюсы:
1. Самый главный и очевидный минус - не у кого спросить. Опыта нет, насмотренности на других проектах с хорошими процессами нет, комплексного представления о том, что вообще такое "хорошие процессы" тоже нет. И в команде нет человека, который мог бы помочь и подсказать что-то с точки зрения процессов тестирования. Что с этим можно сделать? Приходить в профильные сообщества за советами. Уговорить руководство на найм внешнего консультанта для выстраивания процессов (можно это обсудить прям на собеседовании, если кажется, что начальник адекватный). Выстраивать своими силами по крупицам. В любом случае вся остальная команда должна тебя поддерживать, т.к. перестройка процессов будет касаться всех. Про выстраивание процессов напишу потом отдельно, это очень большая тема 😊
2. Естественное сопротивление людей всему новому. Даже если команда в целом понимает, что им необходимо тестирование, по началу всё равно будет сопротивление изменениям, таковы уж мы, люди 🤪 Что с этим делать? Запастись терпением и действовать маленькими шажочками, постепенно внедряя изменения и показывая команде, что так становится лучше жить всем.
3. Огромный объем новой информации по специфике проекта. В совокупности с предыдущими пунктами это даёт колоссальную нагрузку. А если руководство прям с порога требует каких-то результатов и давит сроками, то совсем тяжко. Что можно сделать? Прям с самого начала договориться с руководителем о том, к кому и в какое время приставать с вопросами. Завести себе блокнот (физический или виртуальный - кому как удобнее и лучше запоминается) и записывать все нюансы, даже те, которые вот прям сейчас кажутся очевидными. Это спасёт тонну твоих нервов, поверь 🙃
4. Если объем работ на проекте большой, а взяли только одного джуна, то нагрузка будет огромной. Что с этим делать? Ещё «на берегу», т.е. при обсуждении оффера договориться, что будете принимать на себя задачи постепенно, по маленьким кусочкам, а остальные кусочки в это время будут жить так же, как и раньше. Если руководитель адекватный, он оценит и поймёт 🤓
5. Огромная вероятность выгорания от всего вышесказанного. Джун в такой ситуации либо сгорает, либо очень быстро растёт. Но вероятность выгорания, насколько я вижу, больше. Что с этим делать? Минимизировать факторы выгорания, о которых написала выше ✊

Уже расхотелось принимать такой оффер? Подожди, мы еще не обсудили плюсы! 😊
1. Самый первый и очевидный плюс: у тебя будет работа в сфере тестирования, за зарплату, с перспективами роста! Значит будет накапливаться какой-никакой, а опыт! Само по себе уже неплохо.
2. Если удастся сделать всё боле-менее правильно и не выгореть, то тебя ждет взрывной рост! Обычно, когда в небольшой проект/стартап решают взять первого тестировщика, через какое-то время понимают, что нужен еще тестировщик. А значит у тебя будет либо опытный руководитель (если решат взять человека с опытом), либо, что более вероятно, будет еще один джун, только совсем зеленый, по сравнению с тобой и ты уже будешь в роли ментора! А, как известно, когда что-то объясняешь кому-то другому, сам начинаешь понимать это лучше! И тут у тебя появится опыт не только тестирования, но и обучения нового сотрудника и опыт менторства джуна, а это не мало!
3. Если ты попал в растущий стартап и смог выжить, скорее всего набирать будут постепенно не одного тестировщика, а целую команду, а ты, как самый первый и самый опытный, будешь претендовать на роль лида. Именно так становятся «куа лидом за полгода» как в тех историях с хабра 😉

#общее

...продолжение поста про джуна-попаданца - первого и единственного тестировщика на проекте 😅

Ну как, зарядился позитивом? Тогда несколько советов-рекомендаций для тех отважных джунов, которые принимают офферы в такие проекты:
1. Общаться-общаться и еще раз общаться. С разработчиками, с аналитиками, с продактами и прожектами, с руководителем, с поддержкой – со всей-всей командой. Даже если кажется, что «как же я буду отвлекать их по таким пустякам, они ж так заняты, работают». Если у тебя есть вопрос, ответа на который ты не можешь найти самостоятельно в течение 20 минут, надо либо задать вопрос (если он не позволяет продвинуться дальше), либо записать вопрос, чтобы пристать потом к нужным людям со списком вопросов сразу, а не дёргать каждые 5 минут. Если есть тема для обсуждения – закинь её в чат команды! Если работаешь в офисе, ходи пить чай-кофе, обедать с коллегами и общайся неформально, это очень полезно для рабочего настроя и для того, чтобы чувствовать себя частью команды.
2. Смежный с предыдущим пунктом, но всё же отдельный совет: не стесняться спрашивать и уточнять до тех пор, пока вопрос не будет прояснён окончательно. Почти все джуны стесняются переспросить и делают вид, что поняли, хотя на самом деле в голове та самая обезьянка с тарелками и мысль «нихрена не понятно» (сама такой была). Надо держать в голове мысль о том, что лучше за один присест прояснить вопрос до конца, чем потом через время снова задавать тот же вопрос. Когда ты через время задаёшь тот же самый вопрос, который мы уже вроде как обсудили и ты сказал, что всё понял, это нервирует и накапливает раздражение. Создаётся впечатление, что «сколько ни объясняй, всё забывает». И потом это может стать причиной непрохождения испытательного срока, например. А если сразу за один присест прояснить вопрос до конца, до понимания и осознания, записать и не возвращаться больше к нему, это вызывает уважение и создаёт впечатление основательности и позитивной дотошности.
3. Не пренебрегать написанием тестовой документации, рисованием схемок и майнд-карт, отмечать прохождение проверок ✅ Да, кажется, что это никому не нужно, потому что тестировщик то только один! Но поверь, тебе самому это точно пригодится! Тем более в лавине новой информации. Нам, людям, свойственно забывать всякие мелочи, а именно в мелочах и кроется дьявол, как известно! К тому же, тестовую документацию можно показать команде, обсудить с ними нюансы проверок и несостыковки требований, нарисованных в схеме или карте. Такие материальные свидетельства вашей работы вызывают уважение.
4. Отдельно от предыдущего пункта хочу порекомендовать сразу завести себе и команде привычку все баги заводить в баг-трекер 🐞 Даже если кажется, что баг полная фигня и «я уже пофиксил, не заводи». Это опять же материальное свидетельство вашей работы. А еще это артефакт, в который можно заглянуть спустя месяц и вспомнить в чем была причина и кто это фиксил. А еще можно будет потом вести статистику по багам найденным на проде и найденным при тестировании, например. Хотя бы просто для себя, а то и для руководства – как подтверждение успешности тестирования
5. Проси фидбек по своей работе. Договорись с руководителем (если он первым не предложит) о регулярных встречах 1-на-1. По началу это может быть каждый день или два раза в неделю или как договоритесь, но по началу лучше почаще, а потом всё реже – по ощущениям необходимости. Обсуждайте на таких встречах твою работу, что ты делаешь, какие от тебя ожидания, туда ли ты движешься. На таких встречах можно обсуждать и повышения зарплат, и оплату обучений, и какие-то личные проблемы, которые могут мешать работе и всё, что угодно. Пусть у тебя будет выделенный час времени для любых разговоров с руководителем 🤹

Пишите в комментах, какие темы еще раскрыть подробнее 👇

#общее #саморазвитие #рабочийпроцесс

Сегодня хочу быть краткой, поэтому разберем локальный, но важный вопрос: учиться (имеется в виду развиваться по своей профессии) прямо в рабочее время — это нормально?

Если совсем коротко: да, это нормально 🤓

Немного разверну свою мысль. Когда и при каких обстоятельствах это нормально и даже круто:
• Если в работе есть простои (что само по себе очень круто). Во время этих простоев можно заниматься разными полезными вещами (подробнее о том, чем заниматься во время простоев и почему это круто напишу в одном из постов, не переключайтесь 🙃), в т.ч. и саморазвитием.
• Когда есть договоренность об этом с руководителем. «Как это?» - спросишь ты. При хорошем процессе у тебя с твоим лидом/менеджером должна быть договоренность о периодических тет-а-тетах. Это могут быть регулярные встречи, а могут быть встречи «по запросу». Вот на такой встрече ты озвучиваешь лиду свою потребность в саморазвитии (хочу пройти курс N или хочу изучить тему M или еще что-то) и спрашиваешь, будет ли ок, если ты будешь заниматься этим саморазвитием в рабочее время (всё-таки вопрос то рабочий). Конечно, это не означает, что ты вместо работы теперь будешь только учиться. Нет! Можно договориться о, например, часе в день на учёбу. Или о том, что будешь учиться в периоды затишья между задачами, если в вашей команде они достаточно регулярны. Главное озвучить, что это не будет во вред проекту. Что если будет горящая задача ты будешь заниматься задачей, а не учебой посреди пожара 🧑‍🚒🚒
Тут, конечно, важный момент: если у тебя на работе пожары – обыденность, то договариваться надо о том самом «часе в день» несмотря на пожары ☝️

Я, как лид, только приветствую желание сотрудников развиваться и поощряю это стремление. Помогаю чем могу.
Конечно, твой лид может быть не с такими взглядами, но, я считаю, что договориться можно почти всегда. Главное найти правильный подход и обосновать своё стремление. Как пример: «Я научусь делать N и внедрю это у нас на проекте, будет круто и удобно!» 😇

Делитесь в комментах что думаете по этому поводу. Удаётся/удавалось ли вам учиться в рабочее время. Обсуждали ли вы это с руководителем. И что в итоге – получилось или забросили? 🤔

#общее #рабочийпроцесс

Cегодня поднимем тему простоев в работе 👻
Классическая ситуация: команда работает по скраму, спринт длится 2 или 3 недели, в начале спринта разработчики кодят в поте лица, а тестировщики… 🤷‍♀️

Опытные тестировщики знают, что полезного можно сделать в это прекрасное «свободное время». А у начинающих тестировщиков происходит паника. Потому что кажется, что «я ничего не делаю, меня уволят, я в команде лишний/лишняя». Знакомая ситуация? Тогда читай дальше!

На самом деле, периодические простои в работе сотрудников полезны и для команды, и для проекта, как бы парадоксально это ни звучало {здесь должна была быть ссылочка на источник, но я так и не нашла, где я про это читала. Это был то ли Дорофеев, то ли Стратоплан, то ли еще кто-то. Если знаешь – напиши, пожалуйста, в комментариях хотя бы наводку} UPD замечательная Оля Артемьева мне подсказала где можно про это почитать/посмотреть: Дорофеев - Эффективность неэффективности и Теория ограничений Голдратта, можно почитать, например, в книге Цель

Суть такая, что если плотно планировать «утилизацию ресурсов» (бррр…ужасное выражение по отношению ко времени и силам сотрудников, но его очень любят особенно в больших компаниях), то на плане всё будет выглядеть красиво и замечательно – все сотрудники заняты всё рабочее время – 40 часов в неделю, красота же! Но на деле из этого получаются обычно нехилые такие овертаймы (переработки), потому что мы люди, а не роботы, у нас редко что идёт строго по плану, обычно происходит классическая ошибка планирования, реализуются всяческие риски и т.д. и план летит ко всем чертям. При таком постоянном овертайминге сотрудники выгорают и, как итог, увольняются.

Если план подразумевает не полную загрузку, то у сотрудников периодически появляется (обожемой) свободное время (имеется в виду время без чётких задач). И это время можно посветить очень крутым вещам на пользу себе и проекту!

Тестировщик в свободное время может:
0. Попить чай/кофе, поболтать с коллегами о жизни (это можно и нужно делать вне зависимости от загрузки задачами 😅)
1. Внимательно и вдумчиво изучить документацию на готовящиеся к тестированию задачи
2. Обсудить все возникающие по документации вопросы (обычно это влечет за собой правки в документации, а правки в документации до написания кода – это просто прекрасно!)
3. Финализировав требования можно вдумчиво и аккуратно написать тестовую документацию (тест-кейсы или чек-листы), что позволит не упустить каких-то деталей, т.к. не будет спешки и суеты.
4. Можно пообщаться с продакт-овнером или лидом команды или еще кем-то, кто занимается планированием задач на команду: обсудить дальнейшие планы на следующие спринты, напроситься в командировку к пользователям или на какие-то еще активности, чтобы лучше понимать боли и радости пользователей.
5. Заняться саморазвитием (см. предыдущий пост)
6. Привести в порядок бесящий кусок регрессионных тестов (наверняка есть такой)
7. Привести в порядок базу знаний, написать туда полезных статей, поделиться с коллегами
8. Разобрать залипшие в баг-трекере баги (наверняка такие есть везде)
9. И т.д.
UPD доп. варианты из комментов 😊
10. Устроить сессии исследовательского тестирования
11. Упорядочить хаос на рабочем компьютере/на рабочем столе

Пишите в комментариях, что еще полезного и классного можно сделать в такое «свободное» время, пока задачи еще не передали в тестирование ✌️

#общее #рабочийпроцесс
Одна и самых животрепещущих тем для джунов-тестировщиков, на мой взгляд – умение формулировать свои мысли так, чтобы донести до собеседника информацию за минимальное количество итераций переспрашивания. В частности, это касается умения задавать вопросы ☝️

Казалось бы, что сложного в том, чтобы задавать вопросы? «Это вам не мешки ворочать», - скажут некоторые 🥸

Давай посмотрим на пример вопроса. Представь, сидишь работаешь, а тут приходит в чатик коллега и происходит следующий диалог (К – коллега, Я - я):
К: Привет, <usrname>! Можно задать вопрос?
Я: Привет, да, конечно
К: Тут такое дело, не могу понять что в требованиях имеется в виду
Я: Таааак..?
К: Там что-то про алгоритм…
Я: Какие требования? Какой алгоритм?
К: А, ну требования по задаче Х, там алгоритм работы Г
Я: Хм…не помню что за задача, дай ссылку
К: <ссылка на задачу>
Я *изучаю задачу по ссылке, не вижу требований*: А где требования?
К: А, ну требования то вот тут - <ссылка на требования>
Я: Ага, вижу, а в чем вопрос то?
К: Да вот не понимаю как там в алгоритме Г обрабатывается ситуация Д
Я: Аааа, так бы сразу и сказал, это делается так-то и так-то. Попроси аналитика дописать это в требования, чтобы потом опять не мучаться

В этом выдуманном диалоге прекрасно всё, это квинтэссенция плохо заданного простого вопроса. Если задать этот же вопрос хорошо и правильно, то он решится не за 20 минут нервной переписки, а за 3 минуты и без нервов. Например, можно было спросить так:
К: Привет! Подскажи, пожалуйста, по задаче <ссылка на задачу>. Там в требованиях <ссылка на требования> есть такой момент: <цитата нужного куска требований или картинка из требований>. Мне тут не очень понятно, как обрабатывается в этом случае ситуация Д.
Я: Привет! Ситуация Д обрабатывается вот так-то и так-то. Попроси, пожалуйста, аналитика дописать это в требования, чтобы потом не забыть.

Итак, что же отличает хорошо сформулированный вопрос от не очень хорошо сформулированного?
В первую очередь – это контекст. Необходимо ввести в контекст вашей проблемы. Одно из самых популярных когнитивных искажений – считать, что окружающие знают тоже, что и ты. Именно отсюда растут ноги у плохо сформулированных вопросов. Не бойся быть кэпом и говорить, на твой взгляд, очевидные вещи. Это поможет быстрее решить твой вопрос.
Второй важный компонент – подкрепляющие вопрос материалы. Это могут быть ссылки, цитаты, картинки и т.д. – всё, что помогает быстро погрузиться в контекст вопроса и, соответственно, быстро дать ответ.
Третий компонент очевидный, но всё же скажу про него – это вежливость. Никому не понравится отвечать на вопрос, заданный без принятых вежливых оборотов и с интонацией «мне все должны»

Не забывай про эти составляющие и формулируй вопросы правильно!
Да пребудет с тобой сила 💪

Картинка не влезла в пост, поэтому будет висеть отдельно 😅

#общее #собеседование
Сегодня хочу поговорить о том, что на собеседованиях/в тестовых заданиях (рассматриваем только собеседования на джунов-тестировщиков без опыта или с минимальным опытом) можно считать в пределах нормы, а что "за гранью" - по моему разумению, конечно. В комментариях пишите-добавляйте или оспаривайте, буду только рада 🙃

1. ✅ На собесе вас спрашивают какие-то сложные темы, которых вы не знаете. Погодите возмущаться и негодовать, что мол для джуна такие знания странны. Скорее всего собеседующий просто хочет прощупать границы ваших познаний. Не бойтесь отвечать, что не знаете. Лучше всего будет ответить примерно так: "какой интересный вопрос, я этого пока не знаю, но почитаю что найду. Может что-то посоветуете?" и записать. Вы великолепны! ❤️
2. ❌На собесе звучат вопросы личного характера, например, про жен/мужей, про детей, про планирование детей, про ипотеку, про возраст, сексуальную ориентацию, религию и т.д. Тут стоит взвесить все за и против и действовать по обстановке:
* Если вопросы исходят от эйчара в отсутствие технического собеседующего (возможного будущего коллеги или начальника), надо помнить, что это вполне может быть самодурством конкретного человека. Можно задать встречный вопрос - мол "для чего вы это спрашиваете? Эти факторы никак не влияют на мою работу". Если ответить на такие вопросы для вас ок, то можно и ответить. Если не ок, можно сказать, что не хотите на собеседовании обсуждать личные вопросы.
* Если вопросы исходят от технического собеседующего или в его присутствии (и он не останавливает эйчара с такими вопросами), то это звоночек и повод задуматься хотите ли вы работать с человеком, для которого на собеседовании важно выяснить личные вопросы, не касающиеся работы. Вполне нормально в такой ситуации сказать "я бы не хотела обсуждать личные вопросы на собеседовании", а если будут настаивать, можно и уйти, сказав, что они вам не подходят. Это тяжело, кажется, что это некрасиво, некультурно и всё такое. Но свои границы стоит отстаивать, я считаю 📛
3. ✅По результатам тестового задания вам не дали подробного фидбека, просто написали, что вы не подходите команде. Это, конечно, не очень информативно, но так часто бывает. Чтобы проверить все тестовые задания от всех кандидатов и написать хорошие фидбеки для каждого нужно очень много времени и сил. Зачастую такого количества времени и сил у лида/менеджера просто нет. Если уж тебе ну прям очень любопытно что же там не так, попробуй спросить. Напиши в ответ, например, так: "Спасибо за ваш ответ! Очень расстроилась, когда его прочитала, но понимаю, что такова жизнь. Если вас не сильно затруднит, напишите, пожалуйста, пару слов о том, почему моя работа вам не подходит. Я бы очень хотела поработать над своими ошибками и, возможно, когда-нибудь снова попробовать попасть к вам". Такого рода ответ обратит на тебя внимание, очень вероятно, что тебе дадут фидбек, а еще есть вероятность, что дадут второй шанс с другим тестовым заданием 🤞
4. ❌ По результатам тестового задания вам дали фидбек из серии "всё фигня, ты ничего не умеешь, гуляй отсюда". Т.е. хамовато и без конкретики. Не расстраивайся! Всё скорее всего не так плохо, как они написали. Скорее всего это такая корпоративная "культура". Чаще всего этим страдают госы. Предлагаю применить тут мысленное упражнение посылания на йух и возблагодарить Ктулху, что тебе не придется работать с такими людьми 🤬

#общее #собеседование
5. ✅ На собесе тебя спрашивают про желаемый уровень дохода. Не пугайся, тебя не хотят "развести" на минимальную оплату или "отсечь", потому что ты "много хочешь". На самом деле хотят узнать какой уровень оплаты будет для тебя приемлемым и комфортным и понять, подходишь ли ты им по этому параметру. Т.е. совпадают ли ваши оценки твоих знаний и умений хотя бы приблизительно. А еще такой вопрос может быть вызван тем, что на вакансию нет конкретного бюджета, вилка очень сильно плавающая и, если кандидат очень подходящий и запрашивает больше, чем остальные, его скорее всего согласуют и пригласят. На такой вопрос лучше всего ответить вариантами, например, "на первое время приемлемо будет Х денег, а комфортная сумма на данном этапе была бы Y денег". Это еще кстати хороший повод обсудить карьерные и зарплатные перспективы, если еще не! 🤑

#общее

Зачем нужны джуны компаниям?
Часто слышу от начинающих тестировщиков, что невозможно найти работу, потому что всем нужны опытные спецы.
Но мы же с вами знаем, что джунов без опыта тоже берут довольно много. Казалось бы, зачем это компаниям?
На мой взгляд:
1. Самое очевидное: джуны дешевле в плане зарплаты. Да, на них нужны затраты другого рода (время других специалистов и т.д.), но это временные затраты, пока джун не обретёт хотя бы минимальную автономность.
2. Джуны имеют свежий незамутнённый взгляд. Они ещё не видели других процессов и порой задают интересные вопросы, над которыми "бывалые" спецы уже просто не задумываются (пока их не спросят, конечно). Плюс свежий взгляд на продукт. Особенно полезно, если продукт не узкоспециализированный, а для широкой аудитории.
3. При менторинге джуна опытный спец тоже прокачивается. Конечно, если у него есть ресурс и желание для менторинга.
4. Джунам обычно поручаются рутинные задачи, тем самым мидлы от них освобождаются для выполнения более серьезных задач

Думаю, что у всех, кто нанимает джунов есть свои резоны для этого, вот еще статья на эту тему: https://rb.ru/young/junior-it/

#общее #бесплатное #саморазвитие

Меня иногда спрашивают, какие каналы/чаты в телеграме по профессиональной теме я читаю/пишу. Решила запостить свой список. Это не реклама, по крайней мере мне за неё не платили… пока что… может теперь заплатят 😅
Сразу рекомендация: если хочешь задать вопрос в тематическом чате на много тысяч человек, попробуй сначала почитать описание чата, закрепленные сообщения (их может быть несколько) и еще воспоспользуйся поиском. Вот если ничего не нашлось или нашлось, но маловато, тогда смело задавай вопрос. А как задавать вопрос так, чтобы не было мучительно больно я писала ранее 😉

https://t.iss.one/qa_bad_company - чатик про работу в разных компаниях, можно найти отзывы почти на всё
https://t.iss.one/qa_courses - чатик про курсы для тестировщиков. Отзывы, рекомендации и т.д.
https://t.iss.one/qa_resumes - чатик, где можно запостить резюме в поиске работы
https://t.iss.one/qa_jobs - чатик с вакансиями для тестировщиков
https://sites.google.com/view/qasisters - сообщество тестировщиц. Только для девочек! Есть премодерация.
https://t.iss.one/uporotqa - канал моей выпускницы, которая ещё во время учёбы устроилась в классный стартап
https://t.iss.one/godoftesting - статьи про тестирование
https://t.iss.one/serious_tester - ещё статьи про тестирование
https://t.iss.one/short_QA - шикарный канал с короткими советами для тестировщиков
https://t.iss.one/radioqa - канал подкаста Радиокуа с годными мемчиками про тестирование
https://t.iss.one/qahacking - статьи, мысли, мемчики, советы про тестирование и около него
https://t.iss.one/aboutqa - канал про тестирование (в описании есть ещё чат-болталка). Админ канала - бывший старший ревьюер курса Инженер по тестированию от Я.Практикума
https://t.iss.one/yetanotherqa - как сказано в названии: ещё один канал про тестирование 🙂
https://t.iss.one/joinchat/TllK7Oepcy-4PGCs - чат проекта Хомячки, одним из организаторов которого я являюсь
https://t.iss.one/whybugs - канал одного из наставников Я.Практикума, посвящен багам
https://t.iss.one/ITbugs - и ещё один канал про баги
https://t.iss.one/mnogosdelal - канал Макса Дорофеева. Это первый и единственный в мире прокрастинотолог (потому что он сам себя так назвал))) - не про тестирование, но про организацию времени. И Макс когда-то сам был тестировщиком 🙂
https://t.iss.one/testing_and_life - и ещё канал про тестирование и около него от крутой Ольги Артемьевой
https://t.iss.one/offerpower - канал про поиск работы и всё, что с ним связано
https://t.iss.one/test_pass - канал тестировщицы про её опыт в тестировании, мысли и полезности
https://t.iss.one/just_ordinary_qa - канал тестировщицы с рассказами о будничной работе и философскими вопросами

А что читаете/пишете вы? 😊

#общее #саморазвитие

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

Самые популярные ошибки в чек-листе:
1. Употребление самоочевидных слов типа "проверка", "проверить, что" и т.д. - это делает проверки менее читабельными и более громоздкими
2. Нечитабельное оформление: проверки сплошной простынёй, без разделов, без нумерации, вперемешку, или с разделами, но без выделения заголовков каким-то видным шрифтом или заливкой. Такие работы просто сложно читать, старайтесь при выполнении тестового задания всегда думать о том, что читать это будет совершенно другой человек и надо сделать так, чтобы читать было комфортно и понятно.
3. Проверки полностью дублируют имеющиеся формализованные требования, т.е. не был проведен анализ, нет проработки серых зон и неявных требований. Не забывайте проводить тест-анализ, это наша основная работа!
4. Не хватает проверок особенностей мобильных девайсов. Если вы пишете проверки для мобильного приложения, подумайте как оно будет работать на самом девайсе.
5. Слишком много проверок особенностей мобильных девайсов, без оглядки на специфичность указанного в требованиях девайса (плеер iPod). Не стоит перечислять "всё, чему учили на курсе", надо продумать что применимо в каждом конкретном случае.
6. Тест-кейсы вместо чек-листа. Если в задании написано "составить чек-лист", не стоит переусердствовать и писать тест-кейсы, это никто не оценит 🤪
7. Отсутствуют додумки требований в части серых зон и/или отсутствуют комментарии к таким додумкам. В задании я специально указала в явном виде, что вопросы задавать нельзя, а можно и нужно додумать все неясности самостоятельно (проявить креативность и применить оракулов и здравый смысл) и при этом обязательно оставить комментарии о том что было додумано и почему.

Самые популярные ошибки в баг-репортах:
1. Составлено несколько баг-репортов, хотя по заданию нужен был один (не самый страшный косяк, конечно)
2. Не хватает некоторых полей баг-репорта, в основном это критичность/приоритет, вложения и иногда даже шаги 😱
3. В описании/шагах/результатах написано что система НЕ делает. Правильно писать только то, что система делает, это дает больше информации
4. Не хватает анализа происходящего. Из-за чего баг появился (предположения), на что баг влияет, что за собой влечёт, т.е. локализовать баг, ведь именно из этого и выявляется критичность
5. Выбран низкоприоритетный, косметический баг. Для таких заданий лучше выбирать критичный баг, это покажет то, что вы проанализировали доработку и продумали, что может пойти не так.
6. Оформление бага оставляет желать лучшего: вырвиглазные цвета выделяющие текст или наоборот вообще без выделений заголовков, сплошным текстом.

Надеюсь эти антипаттерны помогут вам в выполнении тестовых заданий, удачи! 😇

#API

На моём ютуб-канале уже целых два видео и это не потому что я записала-таки еще одну познавательную пятиминутку 😅
Наткнулась на запись экскурса в граф куэль, который нам проводил разработчик на прошлой работе, с его разрешения выложила, наслаждайтесь 😊
https://www.youtube.com/watch?v=NaXWW9_w2pQ

#общее #саморазвитие

Други, в этот прекрасный день хочу поделиться с вами своей поделкой: сборником терминов и определений в области обеспечения качества. Я составила его совместно с коллегами как внутренний документ в Спортмастер Лаб и хочу поделиться с вами 🤗