3. Тестировщик:
• Хороший тестер — это въедливая, дотошная тварь, которая срет прогерам в душу санитар леса. Ну, на самом деле, для этого, надо иметь структурное мышление само по себе. Надо уметь с толком доебаться до всего. И не просто добеаться, а объяснить четко, ясно и понятливо, по пунктам: как, почему и кто может, как решить. А еще, анончик, учти, что это очень регламентированная работа с кучей отчетиков, охуенного количества документации, милоты, лютых дедлайнов, ненавизди и веселья.
• стоит обратить внимание на: https://toster.ru/q/5522
• О, Савина вспомнили! Чудесная книжка, без дураков, и далеко не только для тех, кто хочет стать тестировщиком. В первой половине быстро, четко и без соплей нормальным языком разжевывают (Роман Савин – Тестирование Дот Ком; в 2021 уже считается устаревшей)
Чем бы вы заменили этого самого Савина?
• вместо Савина можно полистать книгу с епамовских курсов, имхо: http://svyatoslav.biz/software_testing_book/
в ней инфа поактуальней, автор взял из istqb и других источников много всего по теории тестирования (те самые виды тестирования, как кейсы писать и все такое), плюс она на русском. подходит в первую очередь для желающих вкатиться через епамовские курсы, но и в целом для понимания, че как тестят, подходит
• «Paul Jorgensen. Software testing: a craftsman's approach» и «cem kaner: testing computer software». вот последней вроде есть перевод на русский.
• Борис Бейзер «Тестирование черного ящика»
• Перспективную нынче (2012 год) автоматизацию тестирования можно делать на python'e.
• для тестирования веба есть прекрасный Selenium WebDriver, его тоже можно освоить дома. Тестируйте холиварку, например)
• Из тестера ТС успешно переполз в аналитику, и сидит днями-ночами за работой
• а вот эти курсы? https://qa-academy.ru/vopros-otvet/ ... то курсы норм, в Беларуси сильные тестировщики (и вообще айти-сектор).
• Английский + теория тестирования + SDLC.
• Java - подойдет как для изучения ООП вообще, так и на задел под автоматизацию, в частности.
• Тестировщики ведь бывают и мануальные, которым ЯП не нужны. Глянь багтрекинговые системы (Redmine, Jira) и системы для управления тест-кейсами (Testlink). Это пригодится везде
• можно погуглить тестовые задания (хорошие комментарии на тему - https://habrahabr.ru/post/193902/#comment_6733754, https://habrahabr.ru/post/193902/#comment_6734006) либо берешь дайрики любое приложение и пробуешь протестировать согласно всему тобой прочитанному в книгах со всеми сопутствующими артефактами (тз что будешь тестить, как, что нашел, шаги. отчеты)
• на Степике "Тестирование ПО" от ISTQB и "Введение в тестирование" от Women in Tech
• Можешь посмотреть отзывы о разных курсах (и холивары) в чатике по теме — https://t.me/qa_courses
Ещё у курса по тестированию на Яндекс.Практикуме бесплатная вводная часть.
===========================================================
Мне нужен какой-то бесплатный курс (курсера, степик, открытое образование) с каким-либо базовым инструментом тестирования, который я могу посмотреть сам и понять, достоин ли я, сколько усилий мне нужно будет приложить, чтоб понять материал и пойму ли я его вообще.
• Под запрос больше всего подходит это https://www.learnqa.ru/stageone
===========================================================
• Набор навыков тестировщика по версии анона (2020-й год):
1. Теория тестирования (виды, тест-дизайн и все такое)
2. Автоматизация(ЯП + всякие фреймфорки и либы, самые популярные Selenium, Appium, TestNG, jUnit, Rest Assured)
3. REST API ( виды запросов, коды состояний + Postman, ну и cURL понимать, что он есть)
4. SQL
5. Снифферы (Fiddler, Charles).
6. DevTools браузеров (как правило, хром) на очень хорошем уровне.
7. Для мобилок - adb маст хэв плюс эмуляторы.
8. Неплохо иметь представление, что есть Jmeter и тестирование производительности в целом.
9. Базовые знания о сетевых протоколах.
• Ну это только хардскилы. Я бы пожертвовал, при найме джуна многим из этого, автоматизацией точно.
Оставив: теорию, АПИ, самые основы SQL(Заполнить базу, вытащить данные таблицы), понимать, что есть пенетрейшн, безопасность и нагрузка.
Снифферы... лишним не будет, но на регулярной основе даже не знаю, зачем могут понадобиться, перекрестные апи проверять на проброс левых запросов или перехватывать и подменять для тестов безопасности. Но этим разработчик должен заниматься, иначе, что он отдает на тесты? АПИху на угад?
А вот софт-скиллы которые я с трудом нашел в свое время в одном человеке:
1) Дотошность, придирчивость, разумный уровень перфекционизма.
2) Грамотная речь. Плюсом умение проводить презентации, как для команды, так и для конечного заказчика.
3) Умение составить техническое описание, багрепорты и задания так, чтоб не возникало разночтений и лишних вопросов
3) Добиваться решения задач, т.е. не бояться идти к ПМу, ПО, да даже тех. диру и сообщить, что такую то задачу не решают, а надо! естественно, если это в зоне ответственности QAteam.
4) Подмечать возможные баги на стадии составления ФО, ТЗ и прочего, да, это работа аналитика, но протестировать ТЗ, тоже надо уметь. Мега ценный навык, уметь найти вероятные ошибки до того, как появились первые версии продукта.
5) Понимать UX. Т.е. не только найти эти самые баги, но и предложить улучшения. Юзабилити, новые фичи, в общем все, что может помочь конечным пользователям и естественно, что можно продать заказчику.
Коктейль из аналитика, ПМ и пользователя системы, ну и шобы был приятным человеком. Но я никогда не нанимал тестеров в крупные QA-команды, и это только касаемо ручников, т.е. тез, кто, в итоге, предприемочное проводит.
===========================================================
• Посмотри, что у тебя в багаже из инструментов всё-таки есть, и что чаще упоминается в интересных тебе вакансиях.
Если у тебя практический опыт в багаже есть, то советую начать с хотя бы пролистывания книги Куликова (лично мне помогло собрать в кучу теоретические знания и осознать свой опыт перед началом активного поиска новой работы).
Если у тебя только фронт и не хватает бэка, то — да, поковыряй инфо про API и Postman. Можно начать с бесплатных источников и официальной документации Postman, а там уже станет понятно — точно ли тебе надо ещё и платные курсы.
Про Postman — https://t.me/postman_by/5713
SQL можно поковырять тут — https://stepik.org/course/63054/info (классный и бесплатный курс). Другое дело, что далеко не везде SQL по факту нужен вообще или на серьёзном уровне.
Если хочешь перекатываться в автотесты, то ЯП понадобится.
Я.Практикум и Пойнт — могу ошибаться, но вроде оно всё же рассчитано на тех, у кого опыта ещё совсем нет? Можешь потыкать бесплатную часть Практикума и подумать, а надо ли оно тебе.
Возможно, тебе имеет смысл добирать куски теории уже более адресно. Например, https://software-testing.ru/edu/3-online/46-test-design, https://software-testing.ru/edu/3-onlin … t-analysis или подобное) Или вообще подумать о своих пробелах и почитать статьи/книжки для начала. :-)
===========================================================
• Базовый концепт тестирования по версии International Software Testing Qualifications Board
Версия 2018: https://www.rstqb.org/ru/istqb-download … 018-RU.pdf
• Обзорно рассказывают про тест-дизайн и подходы к тестированию - http://33testers.blogspot.ru/2013/07/bl … 0.html?m=1
===========================================================
• Ты думаешь, ручное тестирование - это, я не знаю, кликать от балды, надеясь попасть на баг? Одна из целей тестирования, хоть автоматического, хоть ручного, - своевременно предоставить команде и менеджменту информацию о том, насколько продукт соответствует требованиям и ожиданиям. И для того, чтобы ответить на этот вопрос, в любом случае надо это тестирование планировать, проанализировать требования, проанализировать риски, написать тесткейсы, руководствуясь классами эквивалентности (выделить группы тестов, где протестировав один ты трестируешь все, и тестировать только один тест из группы) и граничными значениями, чтобы их одновременно было достаточно для тестового покрытия, но не избыточно, расписать негативные сценарии, потому что в требованиях о них обычно забывают, проанализировать, как новая фича повлияла на старый функционал и добавить в план какое-то количество старых кейсов. И вот когда у тебя есть план тестирования, можно начинать кликать. И это - все ещё ручное функциональное тестирование.
===========================================================
• При ручном тестировании чёрным ящиком и не надо разбираться в коде, куда важнее, какие она пишет тест-кейсы: покрыты ли тестами все требования, позитивные и негативные сценарии, классы эквивалентности и граничные значения, вот это все. Ну и эксплоративное тестировании ещё, но оно идёт дополнительно. В общем-то потыкать мышкой по сценарию может кто угодно, подготовить хороший план тестирования с хорошими тестовыми сценариями сложнее. .... Ну, знаешь, посматривать в инспектор и в консоль браузера не помешает. Чтобы хотя бы знать, на чьей стороне проблема. Например, данные с формы не сохраняются. Мне, верстальщику, ставят баг с такой формулировкой. Я иду и проверяю, что запрос на бек ушел, почему он там дальше неправильно обработался - не мои проблемы. Так нафига баг стоит на мне? Мне кажется, это вполне может определить тестировщик. И такого дофига.
===========================================================
• В тестировании почитай теорию. К нам идут ребята на автотестинг и мы спрашиваем вопросы типа «протестируй калькулятор с кнопками цифр, кнопкой плюс и кнопкой равно». И удивительно, как часто бывает, что тестовое задание по автоматизации окнорм, а в такой задачке человек упирается в редкие граничные случаи и даже после намеков и подсказок не может придумать ни одного позитивного кейса, типа: все кнопки работают, самый частый случай, для которого используется функция сложения в калькуляторе, работает, устройство вывода работает, и тд. Все равно берём, но приходится учить писать тест кейсы и обеспечивать покрытие.
То есть, я хочу сказать, попробуй понять для себя, для чего вообще происходит тестирование и как бы ты тестировал приложение. И почитай книжку Савина «Тестирование дот ком», она очень простая
===========================================================
• У меня знакомый без опыта по паре часов в день фрилансил тестером в https://www.utest.com/ , потом устроился тестером на работу в фирму. Там сдельно платят за найденные дефекты и вроде бы за пройденные сценарии. Врать не буду, сама не пользовалась, но может быть новичку можно поискать в инете гайды по этой платформе или аналогичной и попробовать.
===========================================================
Системы для тест-кейсов и чек-листов:
• https://holywarsoo.net/viewtopic.php?pi … 2#p2944812
===========================================================
Анончики-тестировщики, порекомендуйте плс что почитать, посмотреть, поизучать для написания автотестов. Анон работает в веб-проекте, и всё у нас тестится ручками. Но хотелось бы освоить автотесты. Есть навыки программирования на нескольких языках. Как понимаю для web-a это selenium, или есть что-то ещё?
• Для веба селениум считай стандарт, но если у вас тот же ангуляр - то лучше брать всякие селениды, а не пытаться писать на чистом селениуме.
По селениуму отличные курсы у Баранцева на software-testing, но они платные, попробуй выпросить у работы.
• С одной стороны, чистые мануальщики уже не нужны особо. С другой, чистых автоматизаторов не так много, вечно хотят чтоб и автоматизировал, и кейсы писал, и прод настраивал, и ишью от клиентов разбирал, и фичи новые проверить не забыть, и скрипты для разворачивания в облаке сделать, и все это один человек на проект.
• Я привык, что термином "тестовый сценарий" переводят "test case", то есть описание начального состояния, действий, данных, ожидаемого результата. То, что на ЯП это уже "реализация сценария" или "автотест". Возможно, придет кто-то, кто в теме, и объяснит, что имеется в виду. Если нет, я бы на твоем месте вместо подтверждения "получил-делаю", написал что-то типа "я правильно понимаю, что должен составить список кейсов для таких-то компонентов и реализовать их на одном из перечисленных языков для выполнения в selenium webdriver?" Обычно для тестировщика способность доебаться до деталей и терминов считается плюсом, так что не стесняйся писать "поясните, пожалуйста, что вы подразумеваете под сценарием для тестирования? Вы имеете в виду test case (тут можно определение со ссылкой на что-нибудь авторитетное) или соответствующий автотест?" В общем, покажи умение работать с документацией:)
===========================================================
Аноны, а есть какие-то ресурсы где ( пусть за разумную плату) качественно отфидбэчат резюме/сопроводиловки/собесы?
• В QA sisters часто такое организуют, если ты тестер. Сейчас есть даже пробные собесы с фидбеком (от куа лидок). https://sites.google.com/view/qasisters
Бесплатно совершенно.
===========================================================
Гуглодоки с полезностями:
Раз: Полезные ссылки QA https://docs.google.com/spreadsheets/d/ … edit#gid=0
Два: QA Sisters Shared Knowledge
https://docs.google.com/spreadsheets/d/ … edit#gid=0
Ещё одна версия, QA Sisters Public Shared Knowledge:
https://docs.google.com/spreadsheets/d/ … edit#gid=0
===========================================================
• Аноны, подскажите, с каких языков сейчас лучше изучать тестирование? Не модные сейчас, а, скорее, полезные.
- С силлабуса ISTQB для начала. Прежде чем в автоматизацию соваться.
===========================================================
• По моему опыту исследование 10 методами отнимает много ресурсов, а в результате обнаруживаются обычно баги, фикс которых можно и до следующего релиза отложить. Т.е. это попросту нецелесообразно, если ты не тестишь ПО, от которого зависят жизни людей или многомиллионные обороты банка.
В среднестатистической компании будет именно что "наш алгоритм не захватил мир? Ах, захватил, но приказал убить только половину человеков? Срочно деплоим"
===========================================================
• если возникла такая ситуация, что ты прогнал основные проверки и время таки осталось, то тратится оно в зависимости от приоритетов. Иногда приоритет продолжить тестирование и применить хотя бы 2 метода из оставшихся 10 (а то и все), иногда багов найдет миллион, после фиксов все равно будет регресс, так что лучше переключиться на другие таски.
===========================================================
• Есть один очень популярный анекдот, который часто рассказывают тестировщики и который я ненавижу:
Заходит однажды тестировщик в бар. Заказывает
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qwertyuip кружек пива.
И к нему есть дополнение, которое делает этот анекдот моим любимым:
Заходит первый посетитель в бар. Спрашивает: "Где здесь туалет?" Бар взрывается.
Любой тестировщик может придумать миллионы тест-кейсов типа "ящерица в стакане". И, если он работает не на АЭС и не на производстве авионики, то всех этих "ящериц в стакане" никто никогда не проверит (да и не будет проверять). Наша задача - проверить кейсы "где здесь туалет", "еще одну", "я угощаю", "то же, что у того парня", "вызови мне такси" и т.д. Иметь четкий список кейсов с приоритетами, осознавать, где в этом списке находятся границы
- продукт говно, но не взрывается
- с пивом потянет
- готов к выпуску
- вылизан и красив
- и вот мы начали доебываться до незначащих мелочей.
И в зависимости от ситуации доводить продукт до той или иной стадии. А то, что бар взорвется, если кто-нибудь закажет малиновую сурикату с зелеными пятнышками в бокале для мартини со взбитыми сливками сверху в первую среду февраля, если это нечетное число, а скорость ветра за окном выше 30 м/с - ну и хер с ним, с этим баром, пусть взрывается.
===========================================================
• меня учили, что круто использовать метод полумер - лучше применить больше разных подходов более поверхностно, а не один или два очень глубоко.
при тестировании фичи или релиза нормально проверять гуи, юзать функциональные и нефункциональные проверки, проверять итеграцию компонентов, ранать позитивные и негативные тесты. я, конечно, в кучу все накидала, но думаю, понятно. ни один тестировщик не будет тестить только с помощью строго одного подхода, например, пограничных значений. вот и получается если не 10, то как минимум штук 5 разных методов или подходов.
===========================================================
Аноны, чего ожидать от собеседования на джуна-тестировщика?
• Методики тестирования (smoke, регрессионное, нагрузочное) спросить могут.
Попросить написать тест-кейс на сайт или на карандаш тоже.
Технологии в которых разбираешься и с чем просто имел дело.
Ньюансы зависят от того, куда ты собираешься идти. Мобайл тестинг, Сайтостроительство или Интерпрайз. Разные нужны будут базовые навыки
• Мы проверяем на: селениум, джава, сценарии/чеклисты, понимание своей роли в разработке и зачем все это вообще нужно, умение расставлять приоритеты и ориентация на пользователя (грубо говоря, удостовериться, что работает базовый сценарий важнее, чем найти баг, который проявляется только при полной луне или пользователю может быть интереснее сразу получить минимальный функционал, чем с рюшечками, но через пару месяцев), сможет ли вписаться в имеющуюся команду, опционально аджайл.
• Вопросы из серии "протестируйте что-нибудь" дают как правило джунам без опыта или с минимальным опытом до полугода, дальше уже имеет смысл конкретику спрашивать, в т.ч. и по теории, например, техники тест-дизайна почти везде спрашивают.
===========================================================
С какой стороны лучше подступиться к автоматизации, если у меня полная свобода выбора?
• Во-первых, определись, что именно собираешься автоматизировать. Фронт, бэк, мобильную приложуху, десктопную приложуху?
Во-вторых, подбирай инструмент исходя из пункта один.
Как язык я бы рекомендовал джаву потому что к питону у меня личная неприязнь. А так погугли такие интересные слова, как Selenium (который не иде, а сама библиотека), TestNG либо JUnit, Appium (если тестить на мобилах), REST Assured.
Не торопись хвататься это все изучать! Просто погугли и уясни, что такие штуки есть и о чём они вообще.
В-третьих, постарайся поискать мануалы и курсы именно по автотестированию, а не просто кодингу на языке. Там есть разница в том, какая структура проекта понадобится, а хорошая структура проекта это +100 к реюзабельности кода. С учётом пляшущего интерфейса и перспектив править автотесты под это дело - реюзабельность твоё всё.
И ещё. Если документация там никому не нужна, не трать время на то, чтобы именно подробно-формально-по правилам её писать (тебе и без того будет чем заняться), но! Не забивай на неё болт вообще. Заведи себе блокнот, гуглодок или что-то ещё в таком духе, и там храни инфу. Тестовые данные, формулки, воркфлоу, вот это все, в максимально кратком виде, но так, чтобы ты сам потом вспомнил, что ты там хотел сказать.
К вопросу о людях, которых что-то держит. Анон, не ведись на эту хуйню. Держать человека на проекте может что угодно, и зачастую товарищей, которые пять лет сидят и кодят без малейшей документации, да ещё и объяснить не в силах и не хотят, держит там вавка в голове, а не то, что так работать хорошо и нормально.
===========================================================
• https://www.rstqb.org/ru/istqb-downloads.html
Это материалы международной борды тестеров для самоподготовки к их сертификации, самое начало- глоссарий и базовый уровень (есть на русском). Формат зануден, но теоретические основы закрывает, смотри на выпуск 2018 года только.
===========================================================
• https://geteasyqa.com/qa/best-test-case … -examples/
===========================================================
• Организация работы тестировщика:
https://holywarsoo.net/viewtopic.php?pi … 7#p5713837
===========================================================
• Портфолио тестировщика
https://holywarsoo.net/viewtopic.php?pi … 4#p5832134
===========================================================
Чож это за архитектура такая у автотестов? Серьезно спрашиваю, если чо, стало интересно.
• Гугли autotests architecture и autotests framework.
===========================================================
Анон-тестировщик сейчас решил походить по собеседованиям и впал в какое-то состояние полного уныния. Такое ощущение, что помимо знаний всего, что надо для тестирования необходимо еще быть девопсом, сисадмином и администратором баз данных. Я прямо чувствую себя дерьмом из-за того, что не могу рассказать про отличие БД, с которой я работаю, от другой, не могу самостоятельно собрать весь pipeline для проекта, знаю в только в общих чертах про dns и серверы.
Может, есть какой-то список всего, что должен знать хороший тестировщик? Даже вот вроде бы мне кажется, что я нормально знаю REST API или Java Core, а потом мне задают какой-то каверзный вопрос (типа где кроме урла и боди можно передавать параметры запроса или какие реализации был у ArrayList) и я теряюсь с ответом.
• Вообще, имхо, теряться на собеседованиях нормально. Ну, они выясняют твои границы знаний. Тут знаешь, тут не знаешь, зато они теперь в курсе, насколько именно ты знаешь ту же жаву и что они тебе могут предложить.
Но если ты уверен что именно эти неотвеченные вопросы привели к тому, что тебя не взяли, то от тебя как-то слишком дохуя хотят и я б к такому работодателю не пошел бы, я тестировать хочу, а не работать за пятерых включая девопса и разраба
• Тебя скорее всего тестировали на должности от джуна до сениора. В принципе, лично я думаю, тебя и так немного прокачают в тот же девопс, если у них CI/CD (у нас, например, в простых задачах девопс только консультируют и помогают, а свои джобы строим и поддерживаем мы сами), но если ты уже знаешь, это плюс.
• ТС: В целом, я пока на трех собеседованиях был (прокачал на текущем месте скилы, хочу уйти в автоматизацию полностью), везде спрашивали:
- Теория тестирования.
- Базы данных и SQL (чаще всего, что-нибудь хитровывернутое).
- REST API, HTTP-запросы (опять же от просто типа, чем GET отличается от POST, переключаются на нюансы типа передачи произвольных параметров в хэдерах и 300-ые коды).
- Java (в основном всех интересуют интерфейсы, конструкторы и коллекции).
- Сервера и их характеристики.
- Сетевые протоколы (я относительно адекватно могу рассказать только про http и https + немного про веб-сокеты).
- CI/CD.
- Linux (в котором я вообще толком не шарю, но, говорю, что готов погуглить и быстро научиться (вряд ли это сильно сложнее работы с консолью винды)).
- Тестирование производительности и Jmeter (после того, как меня спросили про написание заглушки, я честно выпал в осадок, т.к. не думал, что в нагрузочное тестирование такое входит)
• На всех собеседованиях прям весь набор? Многовато тогда.
А testNG какой-нибудь не спрашивали? Или фреймворки на базе селениума?А testNG какой-нибудь не спрашивали? Или фреймворки на базе селениума?
• ТС: Нет, хотя я testNG как раз пользуюсь. И про Selenium WebDriver ни одного вопроса (Appium и Selenoid не знаю, но я и не писал, что знаю).
И это я подавался на вакансии с требованиями типа опыт в автоматизации тестирования фронтэнда и бэкенда от 1 года, знание JUnut/TestNG, Allure.
• В общем, на миддла-сениора у нас норм можно попасть с Java, Selenium, Jenkins, testNG, maven, rest api, тест дизайн/теория тестирования, понимание agile/scrum, понимание CI/CD, базовое понимание архитектуры клиент-серверных приложений, английский, опционально js. Вроде все основное. Так что продолжай ходить))
===========================================================
где вообще пишутся эти баг репорты, в каком формате, как увидеть результат работы тестера? Я могу пройти по жизненному циклу чего угодно, могу сделать запрос, но есть ли шаблоны, по которым это описывается?
• Прям строгого шаблона нет, но: в хорошем баг-репорте должно быть краткое и чёткое название, отражающее самую суть проблемы, описание проблемы и подробные шаги воспроизведения (в идеале - со скринами, если уместно). Остальное действительно нюансы фирменных гайдлайнов.
Ещё можешь зачесть вот это - пособие по подготовке к базовому уровню ISTQB. Там едва сто страничек с учетом оглавлений и прочего, но базовая теория, которую любят спрашивать, вся есть.
https://www.rstqb.org/ru/istqb-download … 018-RU.pdf
• В ещё большем идеале - с конкретными реквестами, объектами на разных стадиях флоу и с логами ошибок.
===========================================================
• От чистого ручника я бы ждала прям очень-очень хорошего тест дизайна, софт скиллов и понимания процессов, это роль QA Analyst в идеале. Или бездумно кликать по чужим сценариям, такое сейчас тоже где-то осталось.
===========================================================
• Бизнес-логика может быть реализована и на бэке, и на фронте в зависимости от архитектуры приложения. Твои все 10 перечисленных событий могут вообще не обменяться ни одним реквестом с бэком.
• Интерфейс - это не только отступы и цвета кнопочек, посмотри определение. Кстати, вот навыки тестирования пользовательского интерфейса очень ценятся, но это не про количество пикселей вообще.
• Я имела ввиду, что ты тестируешь прежде всего продукт. У тебя есть ТЗ, знание предметной области и умение поставить себя на место пользователя, исходя из этого ты формируешь тестовые сценарии (в резюме это может называться тест дизайн), потом тестируешь фичу (навыки функционального и эксплоративного тестирования, и вот тут тебя тоже пригодится понимание, что ты тестируешь продукт, а не строчки в ТЗ), потом перед релизом или когда тебя надо формируешь план тестирования, отбирая по приоритету/рискованности/затронутым изменениями областям уровень проверок, которые нужны в данной ситуации (это навыки планирования тестирования), потом ты проверяешь, что релиз готов к проду и ничего не сломалось (это навыки регрессивного тестирования). Процессы могут отличаться.
• И отдельно уже пишешь, что знаешь REST, базовый html/css, используешь в работе браузерные инструменты разработчика, и тд
• И тестирование, блин, это не поиск багов. Это получение информации о качестве продукта.
• Вообще, подтяни теорию по тестированию, тут даже дело не в резюме, а в том, что на собеседовании будет сложно.
===========================================================
Какой язык в средним по больнице самый простой для быстрого (ключевое слово быстрого) осваивания написания автотестов с Селениумом
• Если разрабы норм, и с ними можно советоваться - то язык приложения.
Если советоваться не выйдет, то Пайтон.
===========================================================
• у нас в городе достаточно вакансий мануальных куа, посмотрел сейчас бегло верхние - нужны люди, которые способны изъясняться по-английски, писать норм багрепорты, искать баги, бм знать такие штуки, как девтулз и скл запросы (даже про апишку не везде пишут), не пугаться слова “аджайл”. по сути QC это и есть, где-то требования повыше, где-то пониже. а когда я вкатывался, джунам в нашей конторе вообще обычно давали в зубы пачку тесткейсов от коллег и говорили “иди ебош по ним приложение, репортай баги или обновляй тесты”. так что имхо вкатиться с
«смотреть в результаты анализов и кричать эксплуатации замените масло! "поправьте тут"»
вполне можно
===========================================================
• Те времена, когда в тестирование джуном было вкатиться проще, чем в дев, прошли, кмк. Лет пять назад ещё можно было прийти с улицы (я так в тестирование и пришел), а сейчас надо как минимум безупречное понимание теории (всё что касается баг-репортов, составления тест-кейсов, плана и модели тестирования) + хотя бы что-то из технических навыков (sql почти всегда маст хэв, понимать что творится в консоли браузера, что такое api). Много тестирования мобильных приложух, там вообще свои особенности (специфика андроида, айоси).
И джуновым джуном с такими знаниями, но без реального опыта ты все равно будешь первое время работать за еду (30-40к).
• В общим, резюмируя: работодателя интересуют не распечатанные на принтере "корочки" с курсов. А реальный опыт тестирования от полугода. Хоть стажировкой, хоть волонтерством, хоть на биржах. С подтверждаемым портфолио правдивостью сказанного в резюме )))) Очень мало кто в 2020 году готов взять голого теоретика, пусть и с горящими глазами. А теорию можно нагуглить, ее море.
===========================================================
REST API + Postman
• https://www.youtube.com/watch?v=7D7AMmgxt_I
Вот тут неплохо. с 29 по 31 урок. 32 про фидлер будет.
===========================================================
в тестирование свитчятся вполне успешно и люди постарше, так что возраст сам по себе в нашем эйджистком обществе дело несколько усложняет, но не критично.
По тестированию в сети много бесплатных материалов. Советую посмотреть видео (если правильно помню, то канал Артёма Русау на ютубе довольно неплох), полистать того же Романа Савина (подустарел, но вроде в плане текста для совсем уж начинающих он попроще Куликова) и статьи (у той же Ольги Назиной довольно много интересного в открытом доступе лежит) и так далее, и так далее.
+ бесплатная часть Яндекс.Практикума — мило, с юмором, но по делу.
Если поймёшь, что всё-таки это выглядит интересно и как то, чем можешь заниматься, то вгрызайся дальше — тут уже и курсы можно посмотреть.
Всякие технические навыки — это надстройки, которые прилагаются к пониманию теории и что именно нужно сделать, чтобы протестировать приложение (в самом широком смысле этого слова).
Но лёгких денег тут всяко не будет, к сожалению. Сейчас чуть ли не из каждого утюга тестирование рекламируют как лёгкую работу за много деняк и лёгкий путь в айти, но это, мягко говоря, творческое преувеличение.
Как говорят, порог входа в профессию заметно повысился и теперь, если нет дополнительных каких-то специфичных и полезных навыков, прочитать того же Савина не будет достаточно.
Раз умеешь в английский, то можно ещё и сюда нос сунуть — https://www.utest.com/academy Говорят, есть полезные штуки)
И, да, тестировщикам нужно уметь и коммуницировать с людьми тоже, если что, пусть и внутри команды.
===========================================================
То есть что считается интересным и показательным для примеров автоматизации?
• Я отвечу для Java + Selenium и как бы я оценивала.
PageObject, опционально с блоками (как минимум, инициализация драйвера не в каждом тесте, вообще, структура тестов: проверки в одном месте, общение со страницей в другой, нет чрезмерного дублирования), грамотные локаторы (а то нам присылали с автоматически сгенерированными простынями и их мало того, что невозможно поддерживать, так они еще ломаются при каждом изменении на странице), testng и умение настроить через него запуск тестов. Сценарии могут быть самые простые: взяли любой сайт, окрыли дропдаун, проверили значения, нажали, проверили список, ввели что-то в поле ввода, отфильтровали, проверили. Важно: даже если ты не будешь делать никакой структуры, умной отчетности и тд, сделай вывод человекочитаемых результатов хотя бы в консоль: результат теста - самое главное, ты должен помнить, зачем вообще все это пишешь.
Для АПИ я бы взяла проверки на тело респонса (парс в джава объект, проверка параметров), проверки на сам респонс: статус код, задержка ответа.
Ну и аккуратность, код стайл, читаемость кода, информационные аннотации для тестов. Это кажется глупостью, код же и так работает, но на проекте может работать десяток людей и им надо будет быстро и удобно читать и поддерживать твой код.
===========================================================
• Автотесты для души, может, и странно, а пет-проекты и чисто всратые эксперименты много где есть, пример сходу:
https://www.reddit.com/r/linux/comments … wish_more/
===========================================================
А, и главная и самая встречающаяся ошибка тестов, которые нам присылают: проект не билдится и/или тесты не запускаются.
===========================================================
• А тебе (или твоей команде в целом) надо тестить веб, мобилки, десктоп, микс?
Ты женского пола (или кто-нибудь из твоих коллег)? В чате QA sisters есть? Там регулярно обсуждаются такие штуки + можно задать собственный вопрос с учётом именно твоего контекста.
В контексте Питона можно и бесплатно на Степике погрызть гранит науки (там есть цепочка из бесплатных курсов по самому Питону (и платный за какие-то смешные деньги — в названии что-то про лапки от https://t.me/python_in_depth) + тестирование UI, у последнего точно есть платный вариант с менторами).
И опять же про Питон — https://sites.google.com/view/python-automation/main
В ГикБ не стоит идти точно)
Скиллбокс лично мне не внушает доверия с учётом того, как они рекламируются, но именно инсайдов сходу не припомню.
Питон на ЯндексП в этом треде обсуждали, помнится — приходил анончик, который там сейчас учится, емнип. У меня отложилось, что нагрузка довольно серьёзная.
Кстати, а на https://software-testing.ru/ курсы смотрели? Навскидку вижу https://software-testing.ru/edu/3-onlin … automation от Баранцева и https://software-testing.ru/edu/3-online/233-python (от него же).
Личного опыта в отношении этих курсов у меня нет, но у товарища хорошая репутация :-)
Нетология может быть норм, но в общем курсе по тестированию там вроде Java, а есть ли отдельно про автотесты на других языках я навскидку не помню)
На всякий случай. Если вдруг начнёте смотреть в сторону Java, то я вот про эту штуку https://qa.guru/ видела неплохие отзывы.
Если с английским нормально, то можно ещё и сюда посматривать в качестве дополнительного источника — https://testautomationu.applitools.com/ (не уверена насчёт корочек и вот этого всего, но)
===========================================================
• https://sites.google.com/view/python-automation/main
• Кстати, ещё у https://www.jetbrains.com/academy/ есть Питон, но это платный трек, так что его не исследовала вообще.
===========================================================
Пока, вроде, полет нормальный, ттт. 
Мысленно седею, лид QA уже ушел домой, люди, которые могут пересабмит залить тоже, если бага не в lua скриптах - короче у нас праздник не как у людей начнется явно, начинаю смотреть что за жопа, первое что смущает, что кейс от макака, и он толковостью не отличается, лезу в базу, смотрю транзакцию на которой стало плохо - бать мать, команду заглючило, в json в одном из полей был список покупаемых за донат валюту вещей, причем по логике там вещи самые разные, поэтому их просто через запятую перечисляли, не группируя, условно "124556,124556,98980,664443" и тут в этом поле больше 14 тысяч повторений одного ID и это старая механика, которая по всей игре работает. Сервер к обработки таких команд жизнь не готовила, поэтому он не смог прочитать поле и отправил ноду в ребут. То есть в любой момент у юзера, который решил что-то докупить за донат, может так же сглючить, нода в ребут, 10-20 тысяч игроков имеют разрыв сессии — пиздец. Хуже всего, что если начала глючить эта команда, значит сломали что-то в глубинах движка и можно не беспокоиться что выложить обновление некому, найти где за 2 месяца мы сотворили подобную гадость, если нет четкого кейса, это не час и не два, а вообще как повезет. Молюсь ктулху чтобы кейс был, бегу к макаку, спрашиваю как сделал, воспроизводится? Макак собой оооочень доволен, он нашел блокер, который не нашел никто и в мечтах уже head of QA как минимум, начинает неспешно рассказывать - я дошел до такого-то квеста, там есть кнопка докупить, я понимаю ЖОПА этот квест в санити тестируют и у нас плавающий баг, макак продолжает: и я 15 тысяч раз нажал на кнопку "+1" Что? Там кнопка, которую даже зажать нельзя, как он ее 15 000 раз нажал? Спрашиваю - ты что кликер в нашу игру поставил? Макак - не, сам нажимал, за 4 часа 
Мысленно считаю до 5, напоминаю что срок дадут как за человека, иду к ПМ-у и объясняю, что задонатив в игру 400 000$ и нажав кнопку 15 000 раз можно ресетнуть 1/32 нашего сервера, что с "блокером" делать будем? ПМ сказал, что за 400к баксов он может сам ресет всего сервера сделать, кнопку не надо, можно прям его телефон выдавать, с продюсерами он договорится 
Злой-злой QA лид погнал этого непризнанного гения изучать как автоматизирвать нажатие на нужный пиксель, макак очень страдал от несправедливости и тяжкой судьбы, пока за него нормальный коллега не сделал, чем окончательно и доказал свою макакиевость.