#общее

Для первого поста должна быть какая-то самая базовая тема, прошу любить и жаловать 🙃

С чего начать свой путь в тестирование? 🤔
Для каждой из нас путь в тестирование начинался и начинается по-своему. Но общие отправные точки на текущий момент примерно такие (исходя из требований большинства работодателей):
1. Понять в теории, что такое тестирование, какова его цель и в чем роль тестировщиков
2. Понять в теории какие есть основные виды тестирования и в чем их отличия
3. Научиться основам: тест-анализ и тест-дизайн на базовом уровне
4. Научиться задавать правильно вопросы: вводить в контекст, описывать свои размышления/попытки решить проблему
5. Базово изучить инструменты. Основные для современного тестировщика: devtools, Charles/Fiddler, Android Studio/XCode (для мобильного направления), Postman/Insomnia/curl (для API)
6. Причесать своё резюме
7. Научиться проходить собеседования/выполнять тестовые задания

Ваши дополнения/вопросы – в комментариях 🤗
Так же можно закидывать новые темы/вопросы для обсуждения

#ментор #наставник

Кто-то учится сам, кто-то выбирает курсы (платные или бесплатные), а кто-то предпочитает найти ментора.

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

Про менторов: где их найти?
Сейчас открыт набор в https://mentorintech.tilda.ws/ — это бесплатно, но отбор идет на конкурсной основе по мотивации
Крутые спецы из RFT: https://rft.qa/
Менторы по тестированию из solvery: https://solvery.io/ru/mentors/qa
Менторы по тестированию от ГетМентор: https://getmentor.dev/#tags:QA
Менторы из сообщества https://t.iss.one/qa_mentors

Накидывайте в комменты если знаете еще варианты 😊

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

Здесь есть:
Табличка полезностей - там собраны классические и свежие материалы по самым разным тематикам, так или иначе касающимся сферы тестирования и обеспечения качества
#синопсис - обзор новинок в табличке полезностей
#общее - общие сведения, всё обо всем
#ментор #наставник - информация о поиске ментора/наставника, детали такого индивидуального обучения
#курсы - информация и ссылки на курсы
#бесплатное - всё, что касается бесплатной информации (не пиратское, а общедоступное)
#сети - вопросы о сетях
#инструменты - всё про инструменты и их использование
#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. Упорядочить хаос на рабочем компьютере/на рабочем столе

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