🧪 Теория тестирования: как "правильно" должно быть

В прошлом посте я делился, как у нас в компании тестирование происходит "по-простому" - вручную и по чек-листам. Теперь разберёмся, а как по теории всё это должно выглядеть 👇 Зачем вообще нужно тестирование? Не чтобы "найти баги", а чтобы оценить риск того, что продукт подведет пользователя в самый ответственный момент. Это страховка для бизнеса. 🔹 Виды тестирования • Функциональное - проверяем, что ПО делает то, что написано в требованиях. • Нефункциональное - скорость, надёжность, удобство, безопасность. • Модульное (Unit) - проверяем отдельные "кирпичики" (модули) - функции, классы. Делают разработчики. • Интеграционное - как модули и сервисы работают вместе (часто - тестировщики + разработчики). • Системное (E2E) - проверка всей системы целиком, как это слелал бы пользователь (проверяют тестировщики). • Приёмочное (UAT) - готов ли продукт к сдаче заказчику (проверяет заказчик или его представитель). Нужно, чтобы подтвердить: "Да, это то, что мы хотели". • По принципу работы: ○ Позитивное - проверка, что система работает как должна на корректных данных. ○ Негативное - проверка, как система обрабатывает ошибки (неверный пароль, битый файл). ○ Дымовое (Smoke / Sanity) - быстрая проверка "заводится ли вообще" после обновления, работает ли сборка, стоит ли её дальше гонять. ○ Регрессионное - проверка, что новое обновление не сломало старое. ○ Нагрузочное - проверка, как система поведет себя под нагрузкой. 🔹 Manual vs Automated • Ручное тестирование - глазами и руками: удобно для UX, интерфейса и нестандартных процессов. Минус - долго и можно упустить баг. • Автоматизированное - скрипты и инструменты гоняют тесты сами. Удобно для регрессии, API и повторяющихся задач. Минус - дорого внедрять и поддерживать. На практике чаще всего сочетают оба подхода. 🔹 Подходы • Тестирование на основе риска - сначала проверяем то, что "сломается" с наибольшими последствиями. • Чёрный / белый / серый ящик - разный уровень знаний о системе и коде: ■ Белым ящиком (White Box): Тестируем, зная внутреннее устройство системы. Нужно знать код. ▪︎Черным ящиком (Black Box): Тестируем только внешнее поведение, не зная, что внутри. Как делает пользователь. □ Серым ящиком (Gray Box): Что-то знаем о внутренностях, но тестируем снаружи. • Эквивалентные классы и граничные значения - тестируем самые важные и крайние случаи, чтобы не перегружать проверку. • Исследовательское тестирование (Exploratory) - выделяешь время и "играешь" с системой, чтобы найти неожиданные баги, идёшь не по чек-листу, а ищешь баги опытом и интуицией. 🔹 Как выглядит процесс • Анализ требований и сценариев. • Определяем виды тестов. • Составляем чек-листы / тест-кейсы. • Готовим тестовые данные и среду. • Проводим тестирование. • Логируем ошибки, отправляем на исправление. • Повторная проверка (регрессия). • Приёмка и выпуск. • Сбор обратной связи после релиза. 🔹 На что обратить внимание аналитику • Проверяй и UI, и "под капотом" (БД, логи). • Составляй чек-листы и тест-кейсы с неочевидными случаями. • Замечай, чего нет в требованиях. • Работай в связке с тестировщиками и разработчиками: это даёт очень сильный эффект. Почему так сложно? В идеальном мире каждый этап формализован. Но на практике, как и в моём случае, часто всё сводится к ручному тестированию по чек-листам. И это нормально, если проект небольшой и риски низкие. Главное - понимать, к чему стоит стремиться. В следующем посте разберу, какие артефакты тестирования можно использовать (чек-листы, тест-кейсы, баг-репорты и др.). А как у вас устроено тестирование? Делитесь опытом 👇 #теория_са #системный_аналитик #системный_анализ