Практика Flashcards
Написать чек-лист для функционала корзины в интернет-магазине.
Позитивные:
- Товар добавляется
- Количество товара увеличивается
- Количество товара уменьшается
- Товар удаляется
- Разные товары добавляются
- Максимальное значение для одного товара
- Максимальное количество товаров в корзине
- Очистка корзины
- Добавление товара после очистки корзины
Негативные:
Написать тестовые наборы данных для поля ввода даты, которое отсеивает пользователей в возрасте до 18 лет.
Написать чек-лист тестирования формы ввода данных платежной карты.
Валидация
- expiry date не в прошлом
- Номер карты проходит валидацию по Luhn (https://ru.wikipedia.org/wiki/Алгоритм_Луна)
Пропускаются короткие имена/фамилии (1-2 буквы) и составные фамилии (содержат дефис)
Поведение
- Номер карты можно скопировать и вставить в форму. Более того, форма должна быть дружественна к приложениям, сохраняющим и заполняющим данные карты (1password, iCloud keychain и т. д.)
- Цифры в номере карты форматируются по группам
- Между полями можно переходить по табуляции. Последовательность перехода соответствует визуальному расположению полей на форме.
- Вбиваемая кириллица приводится к латинице. Все буквы приводятся к верхнему регистру
Протестировать «предмет» для различных видов тестирования
- лифт
- карандаш
- калькулятор
- Какие требования?
1.1 Если нет требований, то спросить - как предмет вообще произвели и для каких задач? - Если нет требований - узнать есть ли ранее подготовленные чек-листы\кейсы?
- Если нет, то попросить создать требования через user-story
- Говорим, что будем тестировать из своих соображений и здравого смысла
Карандаш
Калькулятор
В нашем калькуляторе один класс, но есть два граничных значения – 1 и 9. Значит, нам потребуется 3 проверки:
- По классу эквивалентности: любые 2 числа, например: 2+5=7
- По первому граничному значению: 1+ любое другое число, например, 1+6=7
- По второму граничному значению: любая цифра + 9, например, 3+9=12
Дополнительные проверки:
- Можно ли сложить не 2, а 3 числа;
- Что будет, если ввести сразу 2 числа (без знака «+»);
- Будет ли нехватка ресурса, если сложить 9 и 9;
- Что будет, если сначала нажать «+», а потом цифры?
- Что будет, если нажать «С» в разных местах вычисления?
- Что будет, если наживать «+», «=» и «С» в разных комбинациях?
- Может ли калькулятор совершать 1 миллион операций в секунду;
- Если это ПО – можно ли запустить одновременно 1 миллион копий этой программы;
- Если это физический калькулятор – выдержит ли он падение на пол со стола.
Лифт
- Functional testing.
1.1. Проверить, что вызывается с первого этажа.
1.2. Проверить, что вызванный лифт приедет на первый этаж.
1.3. Проверить, что на вызванном лифте можно подняться на последний 10-ый этаж.
1.4. Проверить, что на вызванном лифте можно спуститься 10-го на 1-ый этаж.
1.5. Проверить, что на вызванном лифте с 1-го этажа можно подняться на 5-ый этаж.
1.6. Проверить, что вызванный лифт приедет на 5-ый этаж.
1.7. Проверить, что с 5-го этажа возможно спуститься на первый этаж.
1.8. Проверить, что с 5-го этажа можно подняться на 10-ый этаж.
1.9. Проверить, что в лифте работает кнопка “СТОП” при выполнении движения.
1.10. Проверить, что в лифте работает кнопка “Экстренный вызов\Связь”
1.11. Проверить, что вызванный лифт который выполняет задание прибудет на вызванный этаж, только после выполнения задания.
1.12 Проверить, что при загрузке кабины лифта весом 801кг кабина лифта не закроется, произойдет уведомление о перегрузке.
1.13Проверить, что при попытке отправки лифта без груза, лифт останется на этаже. - GUI testing
2.1. Проверить, что рядом с лифтом находиться табличка с номером этажа на котором находиться пользователь.
2.2. Проверить, что при нажатии на кнопку “Вызов”, кнопка подсвечивается. Уведомляя, что команда принята.
2.3. Проверить, что при нажатии на кнопку “Вызов”, циферблат над дверью отображает местоположении лифта в здании.
2.4. Проверить, что в кабине лифта присутствуют кнопки управления.
2.5. Проверить, что в кабине лифта присутствует циферблат с отображением местоположения лифта в здани. - Stress testing
3.1. Проверить, что при одновременном вызове лифта с разных этажей лифт направиться к одному из этажей.
3.2. Проверить, что про одновременной отправки лифта на разные этажи лифт выберет один вариант - System testing
4.1. Проверить, что лифт вызывается.
4.2. Проверить, что после приезда на этаж двери лифта открываются.
4.3. Проверить, что после отправки лифта дверь лифта закрывается. - Usability testing
5.1. Проверить, что кнопка вызова лифта имеет достаточные размеры для нажатия.
5.2. Проверить, что кнопка вызова лифта подсвечивается после нажатия.
5.3. Проверить, что в лифт может свободно поместиться 8-мь среднестатистических человека.
5.4. Проверить, что высота дверей лифта больше среднестатистического человека.
5.5. Проверить, что ширина дверей лифта больше среднестатистического человека.
Имеется Input поле, принимающее целые значения от 18 до 99 включительно.
Следует протестировать с помощью техники тест-дизайна Boundary Values Analysis и Equivalence Partitioning.
Позитивные:
18
99
Негативные:
17
100
string, bool
Проверка валидации на API
Есть веб-страница с полями: e-mail, password и кнопкой submit.Необходимо привести примеры отрицательных тест-кейсов, по которым можно проверить эту страницу.
- Пустые оба поля
- Пустой email
- Пустой пароль
- Максимум символов
- Невалидные email
- Верный email и неверный пароль
- unicode
- SQL-инъекции
Привести примеры тест-кейсов для функционала, находящегося на нескольких страницах проекта (например, поле поиска).
Как протестировать процесс оплаты в интернет-магазине?
Примеры:
- Платежный поток (Payment flow) должен работать для всех различных вариантов оплаты;
- Сохраненный способ оплаты должен быть доступен в процессе оформления заказа;
- Варианты оплаты, такие как Visa, Mastercard, Paypal, UPI, должны быть видны с их логотипом;
- Применяемые дополнительные предложения или коды скидок должны снизить цену покупки;
- Конфиденциальные данные, такие как пароли, CVV, OTP и т. д., не должны сохраняться после завершения покупки;
- Выполнение тестов безопасности является обязательным при хранении данных кредитных карт клиентов или любой другой личной информации;
- При оформлении заказа в качестве гостя процесс покупки должен проходить гладко и позволить гостю зарегистрироваться после оплаты;
- Должны происходить безопасные транзакции, и после оплаты клиенту должно быть предложено вернуться в приложение/сайт электронной коммерции;
- Идентификатор транзакции и детали, связанные с платежом, должны быть сохранены вместе с деталями заказа;
- Выполните тестовый платеж, используя каждый способ оплаты;
- Убедитесь, что платеж обрабатывается правильно, используя все виды способов оплаты, таких как дебетовая карта, кредитная карта, интернет-банкинг, PayPal и т. д.;
- Подтвердить недействительный платеж;
- Подтвердить отмену заказа.
Как протестировать сломанный тостер?
- Зачем нам тестировать сломанный тостер?
- Какие требования?
Как вы провели smoke-testing для приложения типа Telegram?
Есть таблица books с полями: name, price, page_count.Нужно выбрать все имена книг, в которых price более 10 единиц и количество страниц от 20 до 100.
SELECT name FROM books WHERE price > 10 AND page_count BETWEEN 20 AND 100
Что делать, если разработчик не соглашается, что заведенный баг действительно является багом?А если в требованиях использована неоднозначная формулировка?Если бизнес-аналитик, PM и представитель клиента сейчас недоступны, чтобы подсказать?Как можно предотвратить такую ситуацию?
- Обращаемся к требованиям в документации
- Обращаемся к аналитику, PM\PO или представителю клиента для уточнения формулировки
- Обращаемся к тим-лиду QA или разработки или к своему руководителю
Вводим тестирование требований и ревью требований. Тестирование должны проводить сами аналитики
Для предотвращения подобных ситуаций:
- Четкое определение критериев бага: С участием команды определите четкие критерии, по которым проблема может быть классифицирована как баг. Это поможет избежать неоднозначных ситуаций в будущем.
- Установление процедур урегулирования споров: Убедитесь, что с командой установлены четкие процедуры разрешения спорных ситуаций, включая коммуникацию с другими членами команды или руководством, если требуется дополнительное утверждение.
- Регулярное обучение и обмен опытом: Регулярное обучение и обмен опытом с членами команды помогут укрепить понимание общих критериев багов и улучшат коммуникацию в команде.
- Понимание целей продукта: Понимание целей и потребностей пользователей продукта поможет определить, какие проблемы действительно важны и должны быть рассмотрены как баги.
- Регулярное обсуждение и принятие обратной связи: Регулярное обсуждение в команде и принятие обратной связи от всех участников процесса разработки поможет улучшить взаимопонимание и избежать недопониманий или конфликтов в процессе выявления и исправления багов.
Сложилась ситуация, когда команда тестирования не успевает закончить свою работу в дедлайн.Как правильно поступать в этом случае?А если релиз передвинуть нельзя?А если никакие фичи из релиза убрать нельзя?
- Передвигается релиз
- Из релиза исключатся непротестированные фичи
- Выбираются самые критичные тест-кейсы и проверяются только они
Что делать, если проект уже начался, а QA-инженер там начал работать только когда начали разрабатываться бизнес-фичи?
Какие этапы тестирования теперь нужно наверстать и нужно ли это?
Как это сделать максимально грамотно без ущерба для загрузки по тестированию новых фич?
Какие риски имеет позднее вовлечение QA-инженера в разработку?
- Анализ требований
- Планирование тестирования
- Написание тест-кейсов
Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают.Как проверить, что информация отправлена в базу данных?
