4. Скопление дефектов. Так называемый принцип 80% на 20% (принцип Парето). 80% дефектов находится в в 20% функционала продукта, и наоборот. Необходимо предусмотреть каким функционалом будет пользоваться конечный пользователь, и уделить ему особое внимание. Например, которые требуют ввода данных в поля , и где есть логика зависимости заполнения полей. 5. Парадокс пестицида. Если каждый раз использовать один и тот же сценарий снова и снова, то со временем, этот набор тестов перестанет выявлять новые баги. Ведь после каждого нахождения багов, разработчики будут их исправлять, и при след тестирован. скорее всего уже не будут обнаружены. Поэтому важно каждый раз менять тестовые сценарии. 6. Тестирование зависит от контента. Например, банковский софт,в котором критически важна безопасность тестируется иначе чем новостной портал и портал прогноза погоды. 7. Заблуждение об отсутсвие ошибок. Отсутсвие дефектов не всегда означает готовность продукта к релизу. Продукт должен быть удобен и удовлетворять ожидания и потребности пользователя.

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

Поговорим о Классификация багов, и какие бывают приоритеты в баг-репортах
Баги — очень разные. Их различают по степени влияния на систему — серьёзности (severity):
Блокирующий (Blocker), на жаргоне — «блокер». Ни один элемент системы не работает: никто не может ей пользоваться.
На сайте интернет-магазина нельзя сделать покупку. Продукт не выполняет свою задачу.
Критический (Critical). Важная часть системы не работает: пользоваться можно, но вероятность сбоя — высокая.
В интернет-магазине не работает кнопка «Купить» после авторизации в личном кабинете. Без авторизации всё работает — магазин ещё может принимать заказы.
Высокий (Major). Система работает, но не так, как нужно. Пользоваться можно, элементы активны, но выполняют не то, что задумано.
В интернет-магазине по кнопке «Купить» выдают скидку 3% на покупку. Приятно, но это не то, что планировали маркетологи. Кнопка работает неправильно.
Низкий (Minor). С системой всё в порядке, но работать неудобно. Например, дефект в дизайне.
В интернет-магазине в разделе «Товары» не работает вертикальная сортировка. Это не мешает пользователям делать заказ — ошибка не такая серьёзная.
Незначительный / Тривиальный (Trivial). Баг, который не влияет на работу программы. Например, ошибка в тексте.
На сайте интернет-магазина раздел «Чайники» назван «Чайник». Исправить ошибку совсем легко.

Шпаргалка по составлению баг-репорта

Обязательные элементы баг-репорта — окружение и версия приложения. Окружение — это среда, в которой произошла ошибка: информация об операционной системе, браузере и типе устройства. А версия приложения — «номер партии» продукта. Тестировщик описывает окружение при заведении баг-репорта. Порядок описания такой:
Версия приложения — укажи версию продукта.
Браузер — укажи версию и название браузера, в котором тестировалось веб-приложение.
ОС — укажи версию операционной системы: Windows, macOS, Linux, Android, iOS. Если ты тестируешь приложение на компьютере или ноутбуке, то устройство указывать не нужно. Если ты тестируешь на мобильном устройстве, нужно дополнительно указать:
тип устройства, на котором обнаружена проблема. Например: смартфон, планшет или электронные часы;
ПРИМЕР: На MacBook Pro с операционной системой MacOS 10.14.6 установили браузер Google Chrome версии v. 77.0.3865.75. Тебе нужно проверить тестовую версию приложения Яндекс.Еда с номером 222.32.1. Будет выглядить след образом:

Версия приложения: 222.32.1, браузер: Google Chrome v. 77.0.3865.75, ОС: macOS 10.14.6

Друзья, есть гугл-таблица, по ментором и менти, можно найти своего наставника,подготовиться к собесу, получить опыт, разобрать свои знания с наставникам по полочкам https://docs.google.com/spreadsheets/d/1Ql4F7iIEa4_PdlJbpShHdV3W9We4kZQjN6Uv9AFsYyA/htmlview#gid=1009536141

Шпаргалка-окружение

Замечательная книга! Учебный и теоретический материал подан настолько легко, что запомнить и понять не составит особого труда. Савин полностью показывает профессию тесетровщика со всех сторон, и самое главное ты начинаешь нырять во всё это.
Да, какие-то методы устарели, однако в целом книга очень познавательна и актуально по сей день. Много от кого слышала о ней, а сегодня делюсь ею с вами 😊Приятного прочтения .

Как правило, когда вас спрашивают на собеседовании о видах тестирования, собеседующий имеет в виду классификацию по уровню функционального тестирования, а это : Функциональное тестирование - отвечает на вопрос, что должен делать наш продукт? Задача проверить, что все функции приложения работают как положено и отвечают требованием заказчика.
Например: кнопочка «login» должна быть желтого цвета. Проверяем, она желтая? Она нажимается? Выполняет ли свою функцию и можем ли мы залогиниться? Выполняет ПО, свою основную функцию или не выполняет. Вот это ключевое что мы проверяем.

И разберем какие бывают виды виды функционального тестирования: -Дымовое тестирование (smoke test)- проводится после появления нового билда (некая промежуточная версия ПО). Отвечает на вопрос: готово ли приложения для выполнения своих основных функций? Например: можем ли мы залогиниться, отправить товар в корзину, провести оплату;- максимально всё поверхностное без детализации.Часто автоматизируется.

Тестирование критического пути. - направлено для проверки функциональности, тестируем типичные функции пользователя,его типичные задачи . Плюс ко всему позволяет выявить самые быстро находимые дефекты и исправить приложение в более сжатые сроки. Например: Заходим на сайт aliexpress, можем ли мы залогиниться; вбить интересующий товар в поисковик; добавить в корзину; в избранное СМОЖЕМ ЛИ К ПРОЦЕССУ ПОДКЛЮЧИТЬ ФИЛЬТР, по определенному параметру данного товара. / хотим отправить письмо по мail , меняем штрифт, жирность, размер, цвет. и т.д. Здесь мы проверяем основную массу требований к продукту,все ли с ним ок. Часто используется для вэб-проектов.

Расширенное тестирование (extended) Проверяем нестандартное использование приложение. Например: вводить некорректные логин / пароль в поле, или оставить их пустыми и нажать - авторизация. Подгрузка файлов недопустимых размеров или форматов. На собеседование за основу можно взять три основных вида : smoke test; критического пути; расширенное тестирование.

Какие бывают виды нефункционального тестирования: 1. Тестирование производительности (performance testing) 2. Инсталляционное тестирование (installation testing) 3. Проверка удобства (Usability) 4. Тестирование безопасности (security testing) 5.Тестирование локализации ( L10N) и интернационализации(L18N) 6. Тестирование доступности (accessibility

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

1. Тестирование производительности (performance testing) комплекс видов тестирования, целью которого является проверка работоспособности, стабильности. Cтабильность и работоспособность нашего продукта – это очень важный показатель, ведь если наше приложение будет виснуть, то пользователь перестанет им пользоваться.

Подвиды тестирование производительности : а. Нагрузочное (load testing) - Целью его проведения выступает проверка производительности программы на предмет способности справиться с большим количеством запросов и обращений со стороны потенциальных клиентов. Например, наш порог пользователей 1000 пользователей на сайте (то есть наша норма), в идеале конечно установить это значение именно при 1000 пользователях. б. Стресс-тестирование. Например: система рассчитана на 1000 пользователей, как система будет себя вести если будет работать максимально на грани, что с ней будет происходить. Вспоминаем "Черную пятницу" .

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

г. Объёмное тестирование. Это когда например все 1000 пользователей будут одновременно отправляют сообщения или загружают файлы , как себя система будет себя вести при этом? Jmeter( программа помощник в данном контексте)

2. Инсталляционное тестирование (installation testing). Этот вид тестирование направлен на проверку успешной установки и настройки; обновления или удаления приложения. Например: Устанавливается / удаляется ли наше приложение с телефона, компьютера. Можно ли его скачать с playMarket или App Store. Проверяем обновление нашего приложение; можно ли откатить к предыдущей версии.

3. Проверка удобства (Usability) Проверка на удобства. На сколько удобен функционал, комфортен ли дизайн, цветовое решение ; На сколько наш продукт удобен конечному пользователю, захочет ли он пользоваться им снова и снова.

4. Тестирование безопасности (security testing) Используется для проверки безопасности системы, анализа рисков связанные с обеспечение защиты приложения ( вирусы, атака хакеров , несанкционированный доступ к конфиденциальным данным) .

5. Тестирование локализации( L10N) Как система отображает нужный нам язык. Например мы тестируем для русской/ английской аудитории , все ли корректно отображаются слова.Как на кнопке login отображается язык на месте или съехал.Находится ли все на русском или что-то из текста меню не перевелось.( это будет баг)Если мы тестируем локализацию на русском языке, то всё должно быть чисто на русском без примеси других языков.

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