Вопрос #11

Q: Что такое уровни детализации тест-плана?

A: В зависимости от особенностей проекта и методологии работы, бывает достаточным создание одного тест-плана или нескольких наследуемых тест-планов. В случае создания иерархии планов, обобщающий называется Мастер тест-планом, а вложенные — просто тест-планом или детальным тест-планом.

[ Master Test Plan ]

Мастер тест-план создается в двух случаях:
1. Если продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять
2. Если различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа

В Мастер тест-плане содержится следующая информация:
1. Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы
2. Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование
3. Критерии готовности продукта к выпуску, метрики качества
4. Используемые инструменты и техники

[ Test Plan / Level Test PLan ]

Детальный тест-план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта. Его основная цель — кратко и доходчиво отразить задачи тестирования.

В детальном тест-плане содержится следующая информация:
1. Перечень областей тестирования с приоритетами
2. Стратегия тестирования
3. Проектные риски
4. Ресурсы, необходимые для выполнения задач
5. Проектный план (сроки готовности ключевых задач)

Вопрос #12

Q: Как правильно оценить риски по время составления плана тестирования?

A: Риск — это вероятность того, что дефекты в проекте повлекут за собой финансовые проблемы, нанесут урон репутации компании, снизят доверие клиентов, увеличат сроки исполнения проекта и затраты на его реализацию. Стратегия управления рисками — часть планирования тестирования.

Информация о рисках, влияющих на проект, используется при расстановке приоритетов при планировании тестирования. Например, если производительность системы — наиболее рискованная область, тестирование производительности может выполняться как можно раньше.

Определение рисков проекта:
1. Какие функции и атрибуты проекта являются критическим функционалом?
2. Насколько видимой будет проблема в функции/атрибуте для пользователей, заказчика и других заинтересованных лиц?
3. Насколько часто используется функция?

Риски также могут не относиться непосредственно к продукту, но влиять на приоритеты тестирования:
1. Проблемы с квалификацией персонала
2. Нехватка персонала
3. Проблемы с координацией и кооперацией
4. Нехватка инструментов

- - - - - - - - -
Собеседование на тестировщика (Junior QA) / Вопросы на собеседовании QA
- - - - - - - - -

В видео говорится о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное письмо? Именно правильно составленное резюме поможет вам без труда найти работу или как минимум попасть на интервью.

https://www.youtube.com/watch?v=UYZgZ2uYbfw

Вопрос #13

Q: Какие изменения произошли в выборе подходов к тестированию в последние годы?
A: Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:

1. Гибкость в разработке преобладает над четким планированием.
2. Мы больше ориентируемся на мастерство, чем на методы.
3. Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
4. Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
5. Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.

 Вопрос #14

Q: Какие основные виды подходов к тестированию вы знаете?
A: Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).

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

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

Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Скорее всего, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.

Приглашаем обсудить QA в финтехе на онлайн-конференции ЮMoneyDay: https://events.yoomoney.ru/yoomoneyday_2021.

🔍🐞 Сначала узнаем, как устроен наш процесс разработки. Затем тестировщики выступят с докладами:

— К каким выводам мы пришли, собирая метрики тестирования, и что из процессов удалось автоматизировать.

— Когда для полнотекстового поиска можно использовать PostgreSQL.

📍Регистрируйся по ссылке! Начало конференции 13 ноября в 10:00. Секция по тестированию стартует в 15:20.

 Вопрос #15

Q: Выше мы поговорили про Сценарный (Scripted) и Исследовательский (Exploratory) подходы к тестированию. Существуют ли иные варианты?

A: Эти два подхода к тестированию – не единственные. Кроме них существуют и другие, которые находятся где-то между ними:
1. Detailed scripting (Подробное сценарное тестирование)
2. Global scripting (Общее сценарное тестирование)
3. Session based testing (Сессионное тестирование)
4. Bug hunts (Поиск багов)
5. Test tours (Тест туры)
6. Freestyle exploratory testing (Исследовательское тестирование)

Взгляните на схему - почему эти подходы расположены именно в таком порядке? Ответ прост: Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.

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

- - - - - - - - -
QA из Silicon Valley
- - - - - - - - -

В интервью автор постарался детально разобраться в том, как прорваться в Кремниевую Долину и пополнить стройные ряды QA. Необходимые знание и навыки, лайфхаки и дух Долины - всё это в этом выпуске!

https://www.youtube.com/watch?v=V3O0_a4MeUw

Вопрос #16

Q: Чем похожи и чем отличаются следующие виды тестирования: Подробное сценарное и Общее сценарное тестирование (Detailed Scripting & Global scripting) ?

A: Объясняем на примере. Если мы тестируем, скажем, почту, то Подробное сценарное тестирование (Detailed Scripting) может выглядеть так:

1. Перейдите на стартовую страницу
2. Нажмите на кнопку «Новый»
3. В поле «Кому» напишите [email protected]
4. Нажмите на кнопку «Файл»
5. Выберите документ «Тест1»
6. В поле «Тема» напишите «Тестовое вложение <дата>
7. Откройте почтовый ящик [email protected]
8. Проверьте, доставлено ли сообщение и вложение.

Для этого же примера сценарий Общего тестирования (Global scripting) может выглядеть так:

1. Создайте и отправьте письмо с вложением одному получателю
2. Проверьте, доставлено ли сообщение и вложение

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

- - - - - - - - -
Полезные статьи. Часть 1. Виды тестирования.
- - - - - - - - -

1. Классификация видов тестирования: https://habr.com/ru/company/npo-comp/blog/223833/
2. Классификация тестирования. Схема: https://svyatoslav.biz/wp-pics/software_testing_classification_ru.png
3. Уровни тестирования (на английском): https://tryqa.com/what-are-software-testing-levels/

Ищем QA-инженера (ручное тестирование веб- и мобильных приложений):)

Компания: Digital Agro
З/п до 170 000 net + квартальная премия 30% по итогу KPI
Формат работы: гибрид, офис (Москва)
Оформление по ТК РФ;

Компания "Digital Agro" предоставляет фермерам AgTech инструменты и сервисы, которые позволяют принимать решения на основе больших данных, повышать эффективность и обеспечивать устойчивость бизнеса.

Обязанности:

Проведение ручного функционального тестирования различных продуктов (Web, iOS, Android) в области цифровизации сельского хозяйства
Проведение конфигурационного, регрессионного, интеграционного тестирования
Анализ обнаруженных дефектов и документирование их в Jira
Формирование, поддержка и развитие модели регрессионного тестирования в системе Allure TestOps
Выделение и подготовка тестовых сценариев для последующей автоматизации

Требования:

Опыт в тестировании ПО от полутора лет
Глубокое понимание SDLC, принципов работы по SCRUM
Владение основными техниками тест-дизайна
Опыт в формировании регрессионной тестовой модели в любой TMS, понимание её ценности
Опыт тестирования REST API и Web-приложений обязателен
Опыт работы с Postman, DevTools
Знание SQL на уровне простых JOIN операций
Понимание механизмов взаимодействия компонентов в клиент-серверных приложениях на основе микросервисной архитектуры
Работа строго в офисе в Москве

Будет плюсом:

Опыт тестирования мобильных приложений для iOS и Android
Опыт автоматизации тестирования Web-приложений (Java + Selenium + REST Assured)
Опыт работы с Linux, Docker, Jenkins, Allure TestOps, PostgreSQL

Условия:

Новый MacBook Pro 16
Шикарный офис в Москва-Сити
Квартальные премии по результатам работы
Работа по Agile
Возможность развиваться в автоматизации тестирования на Java

Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).

Компания «Construction Solutions» на данный момент в поисках QA-инженера

Заработная плата до 180 000 руб до вычета НДФЛ
Формат работы: удаленная работа, но изредка нужно приезжать в офис (Москва)
Оформление по ТК

Construction Solutions разрабатывает сервис Live Commerce, помогающий ритейлерам и брендам продавать свои товары эффективнее. В качестве решения наш партнер получает себе мобильное приложение и web-виджет.

Требования:

- Опыт ручного и функционального тестирования Android и iOS-приложений от 2 лет;
- Понимание клиент-серверной архитектуры;
- Опыт тестирования API;
- Понимание жизненного цикла разработки;
- Понимание методологий тестирования;
- Опыт создания тестовой документации (тест-кейсы, чек-листы);
- Хорошие коммуникативные навыки, умение работать в команде.

Команда

Product Manager
Backend разработчики (Java)
iOS разработчики (Swift)
Android разработчики (Kotlin)
QA инженеры
Дизайнеры (Figma)

Преимущества работы у нас:

😎 Команда топ-менеджмента - ex-(Rambler, Связной, Утконос, Burberry)
💰 Хорошее финансирование
👨‍💻 Разработка продукта с нуля, отсутствие легаси
🌎 Продукт ориентирован на международный рынок
🪜 Возможность карьерного роста
🏃‍♂ Отсутствие бюрократии, не медлим в принятии решений
🌃 Есть возможность работать в современном офисе в Москва Сити
☕️ Бесплатный кофе, чай

Если вам интересно обсудить подробности вакансии, напишите рекрутеру Александре (TG: @AlexandraAndrianova (https://vk.com/id256314985), телефон: +79185243149, линкедин: https://www.linkedin.cn/in/александра-андрианова/ ).

Андрей Квапил (@kvaps (https://vk.com/id342039346) на Хабре) создает платформы для автоматического управления инфраструктурой, участвует в open-source-сообществе, пишет статьи и выступает на конференциях.

В интервью Андрей рассказал, как прошел путь от эникейщика до Cloud-архитектора, почему для работы с Kubernetes нужно перестроить свой мозг и почему комментарии на Хабре иногда полезнее статей.
https://vk.cc/c8vTY3

- - - - - - - - -
Из тестировщика в разработчики. Почему так делать не стоит?
- - - - - - - - -

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

https://www.youtube.com/watch?v=PPbVK9B_CVY&list=WL&index=10

 Вопрос #17

Q: Расскажите про основные особенности следующих видов тестирования: Cессионное тестирование и Поиск багов (Session Based Testing & Bug Hunts)

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

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

Сессионное тестирование предусматривает наличие:
1. Сессий тестирования
2. Миссии и точки тестирования / идей для тестирования
3. Заметок во время сессии
4. Отчета после сессии (что мы обнаружили, каково качество системы и пр.)

Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.

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