#общее #собеседование
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

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

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

Други, на ближайшей Подлодке я буду выступать с докладом про мой любимый ленивый рационализм. И в целом в этом запуске Подлодки темы все очень классные, не пропустите! 🤗
https://podlodka.io/qacrew

Други, для подготовки моего доклада на Подлодке прошу пройти анонимный мини-опрос - буквально от 1 до 3 вопросов в зависимости от ваших ответов: https://forms.gle/oBjyRBFcu83RCmeC6.
Опрос только для тех, кто сейчас работает тестировщиком. Пожалуйста, не тестируйте форму опроса, а, отвечайте честно как есть 😅 Будет очень интересно посмотреть на статистику.
Результаты обязательно опубликую здесь же 🤓

Спасибо всем, кто поучаствовал в опросе! Всего собрано данных от 277 тестировщиков. По ссылке можно посмотреть результаты: https://drive.google.com/file/d/1-_pRThfcm7mr911ta4SuCJ9EJ_TTy3Ze/view?usp=sharing

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

Сегодня крутой день! Делюсь с вами, мои дорогие!
Моё первое выступление на Подлодке, поговорили про мой любимый ленивый рационализм: https://youtu.be/FIz4uX1LfIM
И сегодня же замечательная https://Fidelina.ru выложила наше интервью, где мы поговорили про ручное тестирование: https://youtu.be/oL-r4dR0krI

#общее

Как я вписалась в Подлодку и успешно провела плаванье.
Давно была мысль выступить на конференции, еще тогда, когда конференции были только офлайновыми и фактически единственной для тестировщиков была SQA Days. Но всё как-то не хватало уверенности, все темы казались высосанными из пальца и не стоящими...
Как-то более осязаемо желание выступить проявилось, когда у нас в Спортмастере эйчары попросили составить список в каких конференциях мы будем участвовать в качестве спонсоров - со стендами, докладами и т.д. В ходе обсуждений я вызвалась участвовать с докладом на той самой SQA Days и в декабре 22-го надеюсь таки там появиться 😊
И примерно в это же время в нашем уютном чатике QA Sisters девочки стали обсуждать предстоящую Подлодку и как попасть туда в качестве спикера. А я возьми да и впишись тоже. Когда узнала, что тема запуска – оптимизация процессов тестирования я сразу подумала о своём любимом ленивом рационализме и, порассуждав, придумала тему про его применение для оптимизации ведения тестовой документации.
Замечательные Аня Принц и Марина Куликова из программного комитета Подлодки безумно помогли мне в подготовке – поддерживали, подсказывали как сделать лучше, что добавить, что убрать, в каком ключе лучше рассказывать. Была проделана огромная работа! Спасибо, девчонки! Без вас я бы не справилась! 😍
За месяц с небольшим мы вместе отточили презенташку, провели пару прогонов, которые придали мне уверенности. И всё равно я очень нервничала, это моё первое публичное выступление. До этого я выступала только для своих и вела вебинары для студентов Практикума 🤪
Доклад прошел, на мой взгляд, отлично! Я получила массу интересных вопросов и классных отзывов, аудитория была просто огонь! Очень дружелюбная и поддерживающая! Спасибо всем, кто смотрел, комментировал, задавал вопросы и поддерживал! Вы лучшие! 🤗
Что хочу сказать в итоге: мне всё очень понравилось, надеюсь получится поучаствовать еще, буду рада! И главное: если вы задумываетесь выступить с докладом, но никогда раньше этого не делали, то Подлодка точно для вас! Дерзайте! 🦸‍♀️
Помимо прочего это еще и возможность посмотреть остальные доклады и поучаствовать в комьюнити 😉

Други, готовлюсь к следующему выступлению, на этот раз оффлайновому, на SQA days. Нужна ваша помощь, пройдите, пожалуйста, небольшой опрос: https://forms.gle/R9kqTUAyiS7XWTaA7

И еще малюсенький, но очень важный опросик! https://forms.gle/dc5NZVPa7QJvR72L9
Лайк-шер, всем плюсов в карму! 😊

Спасибо всем, кто поучаствовал в опросе! Обобщенные результаты доступны по ссылке

Спасибо всем, кто поучаствовал в опросах! Результаты опроса про техники тест-анализа и тест-дизайна обновлены ☝️
Результаты опроса по локализации багов доступны по ссылке

Данные результаты будут использованы в моём докладе на ближайшей SQA days в Питере, не пропустите 😊

#общее #бесплатное
Вышла статья, в которой я участвовала в качестве эксперта! Получилось, на мой взгляд, интересно и полезно для начинающих!
https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/

Первое выступление на SQA days, да и вообще на оффлайн конференции, считаю, прошло успешно! 🥳
Спасибо всем, кто поддерживал и верил, спасибо всем, кто пришел очно или онлайн, спасибо всем, кто задавал вопросы и подошел поболтать в кулуарах после доклада! 🤗
Когда будет запись, обязательно поделюсь 😊

#общее #рабочийпроцесс
Опыт выступления на SQA days был незабываемый! При подготовке доклада я прошла все стадии принятия, в какой-то момент хотела отказаться, но увидела, что меня уже вписали в программу 😅
И вот она заветная запись моего доклада! Смотрю и умиляюсь, даже самой нравится.
Доклад "Тестируем головой, а не руками!" посвящен мануальным тестировщикам, рассказала о том, что и тестировщики делают в ходе своей работы и почему это не так просто, как кажется со стороны.

Пишите в комментариях ваши впечатления, что понравилось, что нет, какие темы еще хотели бы увидеть на конференциях в моём исполнении 😊
Ну и - подписывайтесь, ставьте лайки, делайте репосты и всё такое 😂
Приходите на следующую SQA days в Москве, тоже очень надеюсь там быть 😊

UPD: выложен ролик-интервью с SQA days про SM Lab: https://www.youtube.com/watch?v=EeIQ0cDPV6E

Поздравляю всех моих подписчиков с наступающим Новым годом! Пусть новый год принесёт нам всем радость и счастье! Лёгких релизов и прод без багов! 🥳🎄🥂🤗

Этот год был в целом довольно хорошим с точки зрения моей профессиональной деятельности и я решила поделиться своими профессиональными итогами года:
1. Устроилась в Спортмастер и это оказалась работа мечты! Те рабочие обязанности, которые я и хотела, отличнейшие люди, много интересных команд и продуктов!
2. Ушла из Я.Практикума по ряду причин и с текущей рабочей загрузкой ни разу об этом не пожалела 🤪
3. Сейчас я курирую QA в 6-ти командах (в новом году будет 7), в этих командах у меня 16 тестировщиков разных профилей (в начале нового года их будет уже 19). Среди моих команд есть, наверное, всё: 1С, десктоп на дельфях с ораклом, веб, мобилки, апишки, кассовый специфический десктоп.
4. Из моих 16 тестировщиков 10 собеседовала и нанимала я (+ 3, которые присоединятся к нам в январе)
5. В числе нанятых есть два джуна, про то, как их искала написала тут
6. Создала внутренний справочник QA и с одобрения руководства (да-да, руководитель у меня тоже очень классный!) расшарила его на всех
7. Была в составе рабочих групп для решения ряда методологических задач для всех наших команд
8. Очень неожиданно приняла участие в интервью с прекрасной Fidelina, поговорили с ней про мануальное тестирование
9. Впервые выступила с докладом в Подлодке с моим любимым ленивым рационализмом
10. Участвовала в организации стендов и активностей СпортмастерЛаб для конференций Heisenbug и SQA Days.
11. Была на Heisenbug в качестве стендиста, это был мой первый опыт стендистом 😊
12. Отдельным пунктом хочу отметить своё первое оффлайн выступление: доклад про мануальное тестирование на SQA Days
13. Участвовала в написании двух статей для блога Я.Практикума в качестве эксперта: "Что такое баг-репорт и как его составить" и вторая статья про таблицу принятия решений, она скоро выйдет, следите за новостями 😉
14. Провела несколько тестовых собеседований с развёрнутой обратной связью, надеюсь, моя помощь пригодилась ☺️

А какие у вас профессиональные итоги года? Был ли этот год, несмотря ни на что, хорошим для вас?

#общее #рабочийпроцесс
Други мои! Поговорим сегодня о процессах обеспечения качества.
Обычно всё начинается с того, что команда осознаёт, что им не хватает тестировщика и чего-то магического, что тестировщик привносит в команду для повышения качества выпускаемого продукта. По следам поста https://t.iss.one/QAJuniorFAQ/15 рассмотрим процессы. Напомню, что в посте рассматривался вариант, когда ты джун без опыта и тебя взяли в команду первым и единственным тестировщиком.
Над чем стоит подумать и что встроить в процесс разработки:
1. Самое первое – понять каков текущий процесс разработки, что туда входит и кто за что отвечает:
a. откуда начинается задача, где она заканчивается
b. кто на каком этапе принимает участие
c. где хранятся задачи
d. где лежит документация
e. занимался ли кто-то тестированием раньше, создавал ли он какие-то артефакты для этого
f. есть ли у разработчиков практика написания юнит-тестов
g. настроен ли инструмент для статического анализа кода
h. есть ли CI/CD или всё делается руками
i. какие есть тестовые стенды (если они есть) и что на каждом из них сейчас делается
2. Непосредственно процесс тестирования, т.е. в жизненном цикле разработки должен появиться этап тестирования после этапа написания кода. Что сюда входит (в идеале):
a. Сборка версии, статический анализ кода, прогон юнит-тестов, деплой сборки на тестовый стенд
b. Анализ требований, написание тестов (чек-листы, тест-кейсы – любые виды документирования тестов). Отмечу, однако, что данный этап необходимо будет потихоньку сдвигать влево, т.е. в идеале анализ требований и написание тестов должны происходить после завершения этапа аналитики и ДО написания кода
c. Проверка ПО на соответствие требованиям по написанным тестам, заведение багов, ретест багов, передача задачи дальше по процессу.
3. Процесс тестирования требований – то, о чем писала выше в пункте 2.b. Это вообще отдельная большая тема, вкратце – здесь надо проверить, что то, что написал аналитик одинаково понятно всем участникам задачи – аналитику, разработчику, тестировщику. В этом процессе тестировщику поможет составление верхнеуровневого, а может даже подробного чек-листа.
4. Процессы работы с багами. Как поступать с багами с прода, с багами с регресса и с багами из новых задач. Что делать, если баг оказался не баг и т.д.
5. Процесс выкладки в прод. Как это происходит? Позадачно? Релизами? Как часто? Насколько автоматизирован этот процесс? Много ли возникает обычно проблем при релизе? А сразу после релиза? Исходя из ответов на эти вопросы можно планировать процесс регрессионного тестирования, если он нужен.
6. Другие процессы для обеспечения качества такие, как:
a. Анализ дефектов
b. Определенные DoR и DoD для задач, эпиков, этапов и т.д. – в зависимости от процесса
c. Процессы обеспечения качества на этапе разработки – статический анализ кода, код ревью, юнит-тесты, правила написания кода для команды (нейминг, декомпозиция, оформление и т.д. – всё то, что обеспечивает читаемость кода и взаимозаменяемость разработчиков)
d. Карта функциональности: для понимания границ продукта, связей, покрытия функциональности тестами
e. Импакт анализ или анализ влияния изменений
f. Автоматизированное тестирование – определение стратегии покрытия, определение пользы и окупаемости автоматизации
g. Проведение нефункциональных видов тестирования по необходимости (юзабилити, нагрузка, безопасность и т.д.)

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

#анонс #мероприятия
Сегодня и завтра на лучшей конференции для руководителей! 😍