2️⃣ Цифровое рабочее пространство

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

📁 Во-первых, я рекомендую использовать отдельный жёсткий диск (например, логический раздел). Это поможет сберечь файлы при переустановке системы и форматировании системного диска. Также отдельный диск вы не будете открывать в нерабочее время и не смешаете личные файлы с рабочими. При увольнении или переходе на другой проект будет достаточно форматировать этот диск.

🖥Во-вторых, для работы нужно использовать отдельный браузер, который вы не используете в свободное время. Например, если используете хром, то можно взять лису (Firefox) для работы. Те, кто тестирует веб и кроссбраузерность, могут зарегистрировать отдельный аккаунт для синхронизации браузера и переключаться между личной учётной записью и рабочей, используя один и тот же браузер (создаётся отдельный инстанс). При этом браузер будет открываться в отдельном окне для каждого аккаунта. Главное преимущество такого подхода — можно «выйти с работы» в один клик. Но также важно то, что в рабочее время вас не будут отвлекать сообщения в соцсетях, личная почта или развлекательные сайты. На скриншоты к дефекту не попадут вкладки с вашей любимой музыкой и панель с личными закладками.

3️⃣ Распорядок дня

⏳Как и работа в офисе, работа из дома требует особого графика, который поможет избежать прокрастинации и, напротив, переработок. Если у вас на проекте гибкое начало дня (как в большинстве IT-компаний), то нужно выбрать оптимальное время начала. Не стремитесь к «раньше начал, раньше ушёл» – если разработчики начинают позже, то это приведёт к постоянным переработкам с вашей стороны или увеличению сроков выполнения ваших задач. Лучше начинать работу в то же время, в которое вы привыкли это делать в офисе.

💪Хорошее утро начинается с зарядки – найдите для себя комплекс упражнений в комфортном для вас ритме и оптимальной длительности. Мне понравилась йога, я делаю утренний комплекс с медленными и несложными асанами общей продолжительностью не более 15 минут. Это помогает “прийти в себя” и сказать миру “доброе утро!”.

🍽Завтрак лучше проводить не у рабочего места, а на кухне, не открывая рабочие чаты. Во время обеда также кушайте не на рабочем месте.

🌳Так как обеденный перерыв помимо еды включает в себя время отдыха, занимайтесь физическими упражнениями или выйдите на короткую прогулку на улицу (достаточно 10-15 минут). Такая смена обстановки поможет разгрузить голову, чтобы после перерыва продуктивно справиться с оставшимися задачами. В любом случае – не проводите перерыв за компьютером.

☕️В течение рабочего дня также не забывайте делать короткие перерывы – заварить кофе или чай.

4️⃣ Еда и кофе

🍱 Благодаря карантину многие заведения, не имевшие ранее опции доставки, подключили себе эту возможность. Если вы привыкли есть на работе в столовой или кафе, то можно заказывать бизнес-ланчи домой. В агрегаторах доставки постоянно проходят акции, особенно в дневное время.

☕️А если вы, как и я, не можете прожить рабочий (и нерабочий) день без кофе, и дома нет кофеварки, то любимый напиток можно заказывать домой из любимых кофеен. Другой вариант – дрип-кофе. Это такие пакетики, которые ставятся на кружку и заливаются кипятком. Получается аналог фильтр-кофе. Для капучино можно взять специальный венчик, который работает от батареек (на любом маркетплейсе стоит около 500 рублей) и отлично взбивает молоко.

5️⃣ Минусы работы из дома

Почти получилось превратить все минусы в плюсы! Но всё же осталось несколько важных нюансов.

🗣Первый и самый главный – отсутствие живого общения. На прошлом проекте в команде помимо меня было шесть тестировщиков, но «вживую» мне удалось познакомиться только с двумя, о чём я очень сильно сожалею. Но виртуальные стендапы в Zoom и Google Meet, рабочие чаты в Telegram и Slack полностью справились с тем, чтобы обеспечить рабочую коммуникацию внутри и вне команды. Очень важно поддерживать ежедневное общение с коллегами так, как это было в офисе. Не заключайтесь в себе – команде и особенно тим-лиду по-прежнему нужна обратная связь от каждого. Не забывайте о «неформальном общении» – актуальные новости, смешные мемы и милые котики. Всё то, чем «живет» офис, помимо работы, никуда не исчезло. Кстати, если вы раньше любили задерживаться в офисе по четвергам (или другим дням?) ради настолок, то в домашних условиях такие игры, как Tabletop Simulator, позволят продолжить традицию виртуально.

🏠 Еще один не менее важный нюанс состоит в том, что при работе из дома может появиться ощущение «заключения в четырёх стенах». Для борьбы с ним в условиях, когда путешествия невозможны, можно использовать несколько приёмов: частые прогулки (да, от них сплошные плюсы), ужин «не дома» несколько раз в неделю (любимое кафе/родители/друзья), а также работа из коворкингов или кафе несколько раз в месяц. В выходные дни лучше как можно меньше находиться в той комнате, где вы работаете. Можно выбираться за город или путешествовать по родной стране – всегда есть множество интересных и красивых мест, которые стоит посетить.

✨✨✨✨✨

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

Первая работа тестировщиком.

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

Я хочу поделиться с вами несколькими особенностями поиска работы на начальных этапах.

Внимание: актуально только для первого опыта работы в сфере тестирования.

✅Первая компания

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

✅Уровень заработной платы

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

✅Резюме

Обязательно нужно составить резюме, даже если у вас до этого не было какого-либо опыта работы. В резюме вспомните и опишите:
✅Софт скиллы
✅Технические скиллы
✅Программы, с которыми умеете работать
✅А также обязательно напишите, почему выбрали сферу тестирования.

✅Собеседования

Ходите на максимальное кол-во собеседований, которые только можно уместить в ваш график – временно откажитесь от досуга в их пользу. Каждое собеседование даст огромный опыт, познакомит с требованиями, а тестовые задания дадут полезные знания. И не бойтесь получать отказы – это нормально.

✅Выбор проекта

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

✅Объект тестирования

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

Разбор челленджа: Testing Challenge #1 – web testing, с примерами и ответами.

Наверное, каждый второй тестировщик уже видел этот замечательный челлендж-тренажер!

Он на наглядных примерах демонстрирует отличное покрытие кейсами текстового поля имени пользователя в форме регистрации.

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

Пользователь должен заполнить стандартную форму, чтобы получить доступ к какой-то информации. По условию мы должны проверить только поле First name, максимальная длина которого – 30 символов.

Если Вы ещё не успели попробовать решить его самостоятельно, то скорее переходите по ссылке (только с компьютера).

После того как найдёте максимальное количество кейсов сами, проверьте ответы
⤵️⤵️⤵️1️⃣2️⃣⤵️⤵️⤵️
https://t.me/qatalks_ru/22
https://t.me/qatalks_ru/23

Ответы1️⃣

Базовые кейсы

Кейсы из данного раздела обязательно должны быть проверены при тестировании подобного функционала на вашем проекте.

Обычное значение (Average value)
Какой кейс тестировщик должен проверять в первую очередь?
Правильно: позитивный кейс! Форма должна работать корректно, если пользователь ввёл в него обычное имя, например Kate.

Граничные значения (Minimum value/Maximum values/More than maximum values)
Одной из самых распространённых техник тест-дизайна является анализ граничных значений. В спецификации указано, что максимальное количество символов в поле [30]. Проверим значения на границе (30, 31), а также минимально возможное [1] символ.

Пустое значение (Empty value)
В данной форме поле имени отмечено как обязательное. Первый из негативных тестов, который стоит проверить – это отправка пустого значения.


Кейсы с “небуквами”

Не ASCII символы (Non ASCII)
Форма представлена на английском языке, и она подразумевает ввод имени в английской раскладке. Но что будет, если ввести, например, кириллические символы (Иван/Пётр…)?

Небуквенные символы (Other chars then alphabetic)
В имени может содержаться дефис. Поэтому кейс Masha-Sasha можно считать позитивным. Но также пользователь может попытаться ввести в поле знаки препинания, числовые значения и тому подобные символы.


Кейсы с пробелами

Пробел внутри (Space in the middle)
Имя может быть составным, поэтому нужно проверить, что корректно обрабатывается случай, при котором введено несколько слов через пробел (Ина бин Хатаб).

Тримминг пробелов (обрезание пробелов) (Space values at the end/Space values at the beginning)
Пользователь может скопировать своё имя из документа или другой страницы, и вместе с тем пробелы тоже могут попасть случайно в буфер обмена. Поэтому важна проверка обрезания пробелов перед и после имени.

Пробел (Space)
Что если пользователь будет достаточно ленив, чтобы вводить своё имя, и поставит в поле только пробел? Это тоже важный кейс, потому что пробелы по-разному обрабатываются в БД, и такое значение может повлечь за собой непредвиденные ошибки.


Кейсы тестирования безопасности

Следующие кейсы обычно проверяются при тестировании продукта на безопасность (например, пентестерами) и чаще всего не нужны junior/middle тестировщикам.

Использование HTML тегов внутри поля (You used html tags)
Данный кейс проверяет, можно ли встроить и выполнить свой код через форму ввода. Используйте любой HTML тег. Например, <p> (или <script>, но об этом ниже).

Базовая SQL инъекция (Basic Sql injection)
Используйте завершение SQL выражения с любым последующим запросом, чтобы проверить, экранировано ли поле ввода. (Например: ‘); SELECT * FROM users; )

Базовая XSS инъекция (Basic XSS)
Для проверки возможности запуска сторонних скриптов через поле ввода можно использовать такую базовую XSS-инъекцию, как <script>alert(‘xss’);</script> Или просто <script>

Ответы2️⃣

Кейсы-пасхалки с исходным кодом

Эти кейсы спрятаны немного глубже и позволяют протестировать не только поле ввода имени, но и некоторые особенности страницы. Такие кейсы не так часто встречаются в реальной работе тестировщика, но не менее интересны.

Залезть в куки (You looked at the cookie)
При тестировании веба так или иначе придется периодически “лезть в куки”. Нужно открыть консоль разработчика (клавиша F12) и перейти в cookies:
Chrome/Yandex/Edge: вкладка Application – Cookies
Firefox: вкладка Хранилище – Куки
В списке сайтов выберете сайт челленджа, ну а дальше Вы просто не сможете пройти мимо 🙂

Залезть в исходный код (You looked at the page source)
Редко используется на практике, но я рекомендую всё же проверять, что разработчики убрали все внутренние комментарии и код страницы выглядит аккуратно. Открываем консоль разработчика (см. выше), затем вкладку с ресурсами страницы:
Chrome/Yandex/Edge: вкладка Sourses
Firefox: вкладка Отладчик
В списке нужно найти самый главный файл – index.php Пролистываем файл в конец и читаем комментарий.

Сделать пользователя админом (You made the user admin)
На практике такой кейс может произойти в том случае, когда после тестирования какого-то функционала включение/выключение забыли убрать из “продовской” версии, и теперь фактически любой пользователь сможет функционал активировать.
Нажимаем на поле ввода имени и выбираем “исследовать элемент”. Откроется консоль разработчика и код из index.php Пролистываем код чуть вниз (ниже first name поля) и видим список скрытых input полей. Находим среди них name=”user_right_as_admin” и убираем атрибут hidden. Дальше увидите, что изменится в форме.

Потерявшийся CSS (Missing css)
Не закрывайте консоль разработчика, она всё ещё нужна. Никто не любит неиспользуемые переменные, файлы и прочий мусор. Это действительно засоряет проект и вводит всех в заблуждение. Поэтому в index.php есть подсказка:
Если тут есть потерявшийся файл ресурсов, то добавьте его имя и расширение в поле ввода имени.
Ищем пустой файл. Далее просто копируем его название вместе с “хвостиком” после точки и отправляем форму.

📕 Краткий план обучения тестированию с нуля

Когда хочешь изучить что-то совсем новое, в начале пути легко теряешься. Совершенно не знаешь с чего начать, а гугл только усиливает тревогу. Тем, у кого есть техническое (IT) образование проще, так как примерно понятно, чем предстоит заниматься, какими знаниями обладаешь, а что стоит подучить. Поэтому вопрос «С чего начать изучать тестирование?» я чаще всего слышу от людей, ранее работавших в других (не IT) сферах, или от тех, кто только начал получать высшее образование, но уже видит себя специалистом по тестированию.

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

✅Этот план поможет новичкам в тестировании сориентироваться, с чего начать обучение.

✅Он предназначен для людей без IT-образования, определяя базовые необходимые знания.


Подписывайтесь, чтобы не пропустить ✨

1️⃣ Краткий план обучения тестированию с нуля

Итак, начинаем с теории.

Базовая теория:
1. Что такое тестирование
2. Цель тестирования
3. Этапы разработки ПО
4. Основные виды тестирования
5. Что такое баг
6. Документация (тест-кейсы, чек-листы, тест-планы)
7. Базовые техники тест-дизайна (граничные значения, эквивалентные классы, диаграмма состояний и переходов).

Базовая теория очень хорошо описана в книге Романа Савина “Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах”. Я настоятельно рекомендую прочитать её от начала до конца будущим специалистам по обеспечению качества. Она была написана довольно давно, но основные идеи тестирования по сей день актуальны, в ней они изложены коротко и понятно.

➡️Читать все части статьи: 1 | 2 | 3 | 4⬆️

🐞QAtalks

2️⃣ Краткий план обучения тестированию с нуля

Мы готовы сделать свои первые шаги в практике — теперь можно «потрогать» то, чем занимается тестировщик.

Есть отличный тренажёр на русском языке «Треугольники» (лучше открывать с компьютера). Я рекомендую открыть задачу, прочитать описание и попробовать самостоятельно составить чек-лист того, что будете проверять. Можно сделать это в бумажном блокноте, как вы обычно пишете список покупок или того, что взять с собой в путешествие. И только после этого приступать к решению (осторожно, там есть кейсы для продвинутого уровня — не расстраивайтесь, если не получится решить всё сразу!).

После этого можно потренироваться составлять тест-кейсы. Возьмите самый простой функционал любимой программы или сайта и напишите несколько тест-кейсов.

Где можно писать тест-кейсы? Тут несколько вариантов. В некоторых маленьких компаниях до сих пор ведут тестовую документацию в гугл-доках. Документах. Так почему бы не начать с них?

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

➡️Читать все части статьи: 1 | 2 | 3 | 4⬆️

🐞QAtalks

3️⃣ Краткий план обучения тестированию с нуля

Таск-менеджмент. Небольшой список того, с чем нужно ознакомиться:
1. Багтрекеры/таск-менеджеры
2. Что такое доска (борда)
3. Типы задач
4. Основные атрибуты бага
5. Статусы (задач, багов) в системах управления задачами

✅ На большинстве проектов используются специальные инструменты, похожие на to-do списки, которые мы используем в повседневной жизни. В них заводятся задачи, назначаются исполнители, можно писать комментарии, прикладывать скриншоты и т. д. На одних проектах используются таск-менеджеры (Trello, Asana и подобные), позволяющие менеджерам планировать разработку. Но чаще используются специализированные комплексные инструменты: Jira, YouTrack, Bugzilla и т. д. В них ведётся вся проектная документация, заводятся задачи, планируются релизы, а также в них репортят баги. В этих инструментах нет ничего сложного, у них, как правило, дружелюбный интерфейс.

✅Доска — это визуализация списка задач в виде карточек на доске с несколькими столбцами. Тестировщик может отслеживать задачи, которые разработка уже передала в тестирование, задачи, «зависнувшие» в статусах, или те, которые находятся на этапе планирования. Обычно карточки-задачи перемещаются слева направо, но иногда (например, если в задаче обнаружен баг и она требует доработки) — и в обратном порядке.

✅Задачи в трекерах обычно делятся на несколько типов:
➖epic — крупная задача, новая большая «фича». Обычно разбивается на задачи;
➖задача — то, что нужно сделать;
➖подзадача — дочерняя задача, используется для удобства разработки и оценки времени;
➖баг — ошибка или проблема. Может существовать отдельно или как подзадача;
➖user story — требование, сформулированное с точки зрения пользователя. Например, «как пользователь, я хочу иметь возможность регистрироваться в системе».

✅Баг-репорт — это документ, в котором есть обязательные и дополнительные поля. Дополнительные могут отличаться в зависимости от проекта, а обязательные везде неизменны:
⚫️Название — кратко и ёмко описывает, что сломалось. Не содержит побудительный глагол (починить/исправить и т.д)! Пример: «Кнопка "Профиль" не отображается в Safari».
⚫️Шаги воспроизведения — что нужно сделать, чтобы воспроизвести ошибку (пошагово: «1. Открыть сайт. 2. Нажать…»).
⚫️Ожидаемый и фактический результаты — что должно происходить vs. что происходит в данный момент.
⚫️Серьёзность (Severity) — насколько баг критичен (блокирующий пользование функционалом, важный, обычный, незначительный).
⚫️Приоритет (Priority) — насколько срочно нужно починить (High, Medium, Low).

✅Статусы показывают, на каком этапе находится задача или баг:
🔳Open/New — задача только что создана.
🔳In Progress — разработчик начал исправлять.
🔳Fixed — баг исправлен (можно и нужно проверить).
🔳Reopened — тестировщик проверил, но баг остался, поэтому задача возвращается разработчику.
🔳Closed — баг устранён, всё работает, задача в проде.
🔳Duplicate — такой баг уже есть в системе.
На досках эти статусы отображаются в виде колонок для карточек задач.

Попробуй потренироваться — зарегистрируйся в Trello, создай тестовую доску с колонками «New», «In progress», «Review», «Testing», «Done». Добавь тестовые задачи и баги, переводи их в разные статусы и оставляй комментарии. Так ты сможешь понять, как это работает.

Также, в качестве практики, можно пройти тренажёр с параллельным разбором в моём блоге и завести несколько багов и задач в любом бесплатном баг-трекере.

➡️Читать все части статьи: 1 | 2 | 3 | 4⬆️

🐞QAtalks

🌟 Практика🌟

Сегодня практикуемся в основных техниках тест-дизайна: граничные значения и эквивалентные классы.

Возьмём вымышленный сайт кружка рисования, на нём есть форма записи ребёнка в группу. Кружок рассчитан на возраст 7–12 лет.

Что тестируем: поле «Возраст».
Составляем список проверок на листочке/в заметках телефона/в блокноте компьютера.

Ответы будут на следующий день, а если не хотите ждать, спрашивайте Deepseek 😁

Подписывайтесь на QAtalks

🟠Ответы для практического задания 29.05🟠

Граничные значения для поля [7-12]:
✅минимум: 7
✅ниже минимума: 6
✅максимум: 12
✅выше максимума: 13

Эквивалентные классы:
Валидные значения✅
✅нижняя граница: 7
✅промежуточные значения: 8-11
✅верхняя граница: 12

Невалидные значения❎
✅числа меньше 7
✅числа больше 12
✅дробные числа
✅отрицательные числа
✅нечисловые значения


Подписывайтесь на QAtalks

🌳 Системы контроля версий

Чаще всего на проектах ты столкнёшься с git-подобными системами. Реже, но всё ещё можно встретить и svn. На текущем этапе знать разницу необязательно. В статье для удобства используется git.


✅Как работает контроль версий?
Классический пример - написание дипломной работы. При добавлении новой главы или исправлении ошибок в предыдущих главах мы обычно сохраняем новую версию диплома под названием что-то вроде "Дипломный_проект_1.docx", "Дипломный_проект_final.docx",  "Дипломный_проект_final._final.docx" и т.д.  Чтобы не запутаться с версиями файла, удобнее использовать контроль версий.


✅В чём разница и зачем оно нам?
Продолжу объяснять на примере дипломной работы.
Репозиторий - это папка, в которой у тебя лежит дипломный проект. Внося изменения, ты не нажимаешь "сохранить как...", а делаешь коммит. К коммиту можно оставить комментарий, например, "Добавил главу 4".

В отличие от диплома, над проектом, как правило, работает сразу несколько человек. Это ещё одна причина, почему без систем контроля версий никуда. Перед началом работы над задачей создаётся ответвление - оно так и называется - ветка. В ней один человек вносит свои изменения, например, добавляет новый код.

Продолжая пример с дипломом, можно создать новую ветку "chapter5", написать в ней главу 5, а потом сделать коммит. На следующий день взглянули на это свежим взглядом, увидели несколько ошибок, исправили их, снова сделали коммит (то есть нажали "сохранить как...").

После того как всё, что хотели сделать в ветке, сделали, можно влить изменения в основной файл диплома - смержить ветку с основным файлом. Так, как если бы мы удалили файл "диплом_4главы.docx" и оставили только "диплом_5глав.docx". Но с системой контроля версий возможность откатить изменения остаётся!

Таким образом с ветвлением стало возможно работать над одним проектом нескольким людям почти независимо, внося свой код в единый проект. А если затронуть один и тот же участок кода, то произойдёт конфликт, но ничего не "перетрётся".

✅Про основные команды git можно почитать тут: https://git-scm.com/book/ru/v2/Ветвление-в-Git-О-ветвлении-в-двух-словах

🐞QAtalks

🖥 Трёхзвенная клиент-серверная архитектура.

Веб-приложения можно представить в виде совокупности трёх основных элементов. Давай я объясню на простом примере.

1. Клиент (frontend) - это то, что видит пользователь, и с чем он взаимодействует.
2. Сервер (backend) - обрабатывает запросы.
3. База данных - хранит данные.

Итак, ты хочешь зайти в любимую соцсеть за свой аккаунт.

1. Клиент: Ты заходишь в браузер и вводишь логин и пароль, жмёшь «Войти». Браузер отправляет эти данные серверу.
2. Сервер: Получает твой логин и пароль. Говорит: "Так, нужно проверить, есть ли такой пользователь". Он обращается к базе данных.
3. База данных: Ищет в своих таблицах запись с твоим логином, проверяет пароль и сообщает серверу: "Да, всё верно, вот данные этого пользователя".
4. Сервер: Получает ответ от базы, понимает, что вход успешный, и отправляет браузеру команду: "Покажи главную страницу".
5. Клиент: Браузер получает команду и данные из базы данных (новости, фото друзей) и красиво отображает их тебе.

🐞 QAtalks

🌟 Практика🌟

Сегодня практикуемся в составлении тест-кейсов.

Давай возьмём какой-то интернет-магазин, например, ювелирных украшений. Проверим кнопку "Добавить в корзину". Напиши 5 простых тест-кейсов, содержащих не более 5 шагов.

Можно записать кейсы на листочке/в заметках телефона/в экселе на компьютере. Пример ответов будет на следующий день, а если не хочешь ждать, спрашивай Deepseek 😁

🐞QAtalks

🟠Ответы для практического задания 10.10🟠

Кейс 1: Позитивный без доп атрибутов.
Шаг 1. Открыть список товаров.
Шаг 2. Перейти на карточку товара без атрибутов (размера, цвета итд).
Шаг 3. Нажать на кнопку "Добавить в корзину".
Шаг 4. Открыть корзину.
Ожидаемый результат: товар добавлен в корзину.

Кейс 2: Позитивный c доп атрибутами.
Шаг 1. Открыть список товаров.
Шаг 2. Перейти на карточку товара с атрибутом (например, выбор цвета).
Шаг 3. Выбрать атрибут товара.
Шаг 4. Нажать на кнопку "Добавить в корзину".
Шаг 5. Открыть корзину.
Ожидаемый результат: товар с выбранным атрибутом добавлен в корзину.

Кейс 3: Добавление товара из списка товаров.
Шаг 1. Открыть список товаров.
Шаг 2. Навести курсор на товар.
Шаг 3. Нажать на кнопку "Добавить в корзину".
Шаг 4. Открыть корзину.
Ожидаемый результат: товар добавлен в корзину.

Кейс 4: Добавление в корзину нескольких единиц товара.
Шаг 1. Открыть список товаров.
Шаг 2. Перейти на карточку товара.
Шаг 3: Ввести кол-во, не превышающее доступный остаток.
Шаг 4. Нажать на кнопку "Добавить в корзину".
Шаг 5. Открыть корзину.
Ожидаемый результат: В корзину добавлено корректное количество товара.

Кейс 5: Добавление в корзину количество товара, превышающее доступный остаток.
Шаг 1. Открыть список товаров.
Шаг 2. Найти товар, остаток которого на складе ограничен.
Шаг 3. Перейти на карточку товара.
Шаг 4: Ввести кол-во, превышающее доступный остаток.
Шаг 5. Нажать на кнопку "Добавить в корзину".
Ожидаемый результат: Ошибка.

Тест-кейсы могут отличаться, это один из примеров правильного ответа на задание. Если понравилось - поделись с друзьями❤️

🐞QAtalks

4️⃣ Краткий план обучения тестированию с нуля

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

✅Основы SQL (самые-самые основы)
Так как работая с вебом нужно быть готовым искать данные в базах данных, то одним из необходимых навыков является написание базовых запросов. Нужно уметь искать значения в таблицах, изменять записи, создавать новые и удалять их.
Где изучать: достаточно этой главы
Где практиковаться: sql ex

✅Системы контроля версий.
Можно прочитать подробнее тут

✅Командная строка/терминал - очень полезный инструмент, позволяющий быстро и однозначно выполнить какое-либо действие в системе. Чаще всего тестировщику в терминале (командной строке) предстоит устанавливать ПО, необходимое для работы, а также "прописывать" определённые настройки ОС. Хотела дать ссылку на какое-нибудь готовое руководство для новичков, но мне ничего не понравилось, напишу попозже сама. Если не хочешь ждать: тебе нужно понять, что это такое, для чего используется, и, конечно, запомнить несколько самых основных команд.

✅Консоль разработчика в браузерах (Devtools)
Так как многие вакансии связаны с веб-тестированием, то основы работы с консолью в браузере точно тебе пригодятся. В telegram формат не очень подходит для множества скриншотов, а в сети много хороших статей на эту тему. Вот, например:
Статья от джуна тестирования, тем не менее, тут есть прям самые основы основ, и написано понятным языком с иллюстрациями.
Классная статья про основные вкладки devtoolов.
Для практики нашла классный тренажер для тестировщиков.

✅Основы клиент-серверной трехзвенной архитектуры
Можно прочитать тут, а тут про двухзвенную и трёхзвенную.

➡️Читать все части статьи: 1 | 2 | 3 | 4⬆️

🐞QAtalks