Вопрос #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. Отчета после сессии (что мы обнаружили, каково качество системы и пр.)

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

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

- - - - - - - - -
Полезные статьи. Часть 2. Smoke-тестирование.
- - - - - - - - -

1. О понятии "Smoke-тестирование": https://en.wikipedia.org/wiki/Smoke_testing_(electrical)
2. Различия Smoke-тестирования и Sanity-тестирования: https://www.guru99.com/smoke-sanity-testing.html
3. Smoke-тестирование и Sanity-тестирование. Различия с примерами: https://www.softwaretestinghelp.com/smoke-testing-and-sanity-testing-difference/

Впорос №18

Q: Расскажите про основные особенности следующих видов тестирования: Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

A: При проведении исследовательского тестирования акцент делается на личной свободе и ответственности тестировщика. Оно предполагает постоянный поиск ответов на вопросы: «как сделать лучше?», «какие тесты сейчас наиболее важны?». Вы не просто делаете то, что написано в сценарии, вы постоянно думаете. Кроме этого, все этапы тестирования (проектирование, выполнение, интерпретация результатов и пр.) проходят не последовательно, а параллельно на протяжении всего проекта.

При проведении исследовательского тестирования иногда бывать сложно сфокусироваться на чем-то конкретном. И в этом случае помогают исследовательские туры. Туры отражают основные цели и задачи, которые ставятся при проведении тестирования.

Цитируем Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».

В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

1. Тур по функциям – протестировать все функциональные возможности приложения.
2. Тур по требованиям – протестировать на предмет того, соблюдены ли коммерческие требования.
3. Тур по данным – протестировать обработку данных.
4. Тур по вычислениям – протестировать все вычисления.
5. Тур по процессам – протестировать поддержку рабочих процессов приложением.
6. Тур по экранам – протестировать все экраны.
7. Тур по компонентам с плохой репутацией – протестировать те части приложения, которые ранее имели много ошибок.
8. Тур по интерфейсам – протестировать все интерфейсы.
9. Асоциальный тур – протестировать некорректное использование.
10. Тур грабителя – протестировать на предмет того, можно ли получить неавторизованный доступ.

Вопрос №19

Q: Мы поговорили об основных видах тестирования с точки зрения подхода к его планированию. Перечислите основные характеристики этих подходов.

A:
Сценарное тестирование:
1. Сфокусировано на подготовке
2. Сфокусировано на планировании
3. Опирается на методы
4. Подчиняется процессу
5. Сфокусировано на документации

Исследовательское тестирование
1. Сфокусировано на действии
2. Гибкое
3. Прагматичное
4. Ставит в центр внимания тестировщика
5. Сфокусировано на выполнении тестов

Может возникнуть ощущение, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.

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

Вопрос №20

Q: На основании каких критериев можно считать тестирование завершенным?

A: Выходные критерии – это совокупность условий, которые должны быть выполнены, чтобы фаза тестирования была успешно закрыта.

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

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

Выходные критерии устанавливаются заранее, при планировании тестирования.