Software testing in practice

Промышленное тестирование
Николай Васильев
IITU Software Testing, 2014 1

Для чего мы тестируем?

Для чего мы тестируем?
• Для самопроверки
– Разработчик, чтобы быть уверенным в качестве
проделанной работы
• Для сохранения имиджа
– Не показывать пользователям ерунду
– Давать пользователям то, что работает, не
обманывает ожиданий
• Предотвратить потери в деньгах
• Предотвратить вред жизни или здоровью

Почему мы тестируем?
• Люди ошибаются
• Даже самая мелкая ошибка может стоить
дорого
• Разработчики не всегда проверяют свой код
– А уж тем более, не всегда делают это
эффективно

Задача тестирования
• Проверить, что полезные фичи
реализованы как надо
• Проверить, что нет вредных эффектов
• Сделать это все эффективно

Роли в проекте

• Что такое проект?
– Ограничение по времени
– Есть определенная цель
– Есть методы ее достижения
– Есть метрики оценки успешности (KPI)
• Проекты могут быть маленькие (месяцы)
• Могут быть большие
• Могут быть бессрочные
– Состоят из подпроектов
– Мы называем их «сервисы»

• Руководитель сервиса (тимлид)
• Менеджер проектов
• Разработчики
• Тестирование
• Админы (devops)

Роли в проекте:
тимлид
• Руководит направлением, сервисом
• Отвечает за все проекты в направлении
• Решает межпроектные споры
• Решает внутрипроектные споры
– Если договориться с менеджером не
получилось

менеджер проекта
• Координирует проект
– Или несколько небольших
• Согласует работу участников проекта
• Согласует сроки всех задач
• Согласует приоритеты задач

разработчик
• Каждый разработчик – реализует полезные бизнес-функции
• Senior, Старший разработчик
– Знает всю техническую систему (подсистему), которая затронута
проектом
– Сам делает как правило только самые важные и ответственные
задачи
– Несет ответственность за младших разработчиков
• Разработчик
– То же самое, но знает только часть нужной системы
– Несет ответственность за свои задачи
• Junior, младший разработчик; Intern, стажер
– Не знает систему, или знает недостаточно
– Все знания получает в процессе работы
– Ответственность за его задачи несет senior

разработчик
• Рост разработчика
– Увеличение знания системы (экспертиза)
– Ответственность за свои задачи (от 0 до 100%)
– Ответственность за задачи в подсистеме,
системе (от 0 до 100%)

системный администратор
• Выкладывает готовый софт в продакшн
– Production – софт, который сейчас обслуживает
пользователей
• Следит за работоспособностью продакшна
• То же самое для тестовой среды
– С меньшим приоритетом

тестирование!

руководитель группы тестирования
• Знает всю техническую систему, которая
затронута проектом (см. Senior)
• Знает как тестировать каждый узел системы
• Оценивает риски и приоритеты
тестирования
• Согласует объем и приоритет задач на
тестирование
• Несет ответственность за качество

тестировщик
• Знает часть сервиса и как ее тестировать
– Как правило, лучше всех в проекте (эксперт)
• Создает план на тестирование компонентов
– если нужно
• Проводит тесты
• Фиксирует дефекты, документирует
• Создает тестовую документацию (как тестируем),
если нужно
– Тест-кейсы
– Чеклисты – списки кейсов
• Дает добро (или блокирует) выкладку релиза

автоматизатор тестирования
• Тестировщик-программист
• Пишет программы, которые делают тесты
автоматически
• Когда?
– Когда вручную невозможно
– Когда вручную не эффективно

нагрузочное тестирование
• Отдельная каста
• Имитируют высокую нагрузку на сервис на
специализированной среде
• Измеряют показатели скорости и качества
ответа
– Скорость ответа приемлема
– Нет отказов

Тимлид
НагрузочникРазработчик
Менеджер Тестировщик
Автоматизатор
Технический
писатель

Процесс разработки и тестирования
• Разработка ведется по фичам (задачам)
• Фича, Feature – законченный элемент
системы, отдельная полезная функция

Процесс разработки и тестирования
• Создается задача
– Task, issue, change request, фича, таска…
• Реализуется разработчиком
• Коммит в бранч
• Сборка, юнит-тесты (если есть)
• Код ревью
• Тестирование в бранче
• Мерж в мастер
• Сборка релиза по мастеру

Процесс тестирования релиза
• Создается специальный issue
– Какие пакеты и как надо выкатить (для админов)
– Какие задачи вошли в релиз и какие есть подводные камни
(для тестирования)
• Тестирование регрессии
– Вручную при каждой сборке; один раз на релиз вручную;
каждый раз при сборке – автоматически; выборочно;
• Тестирование новых фич
– Получить спецификацию на фичу, дополнить, убрать все
неясности
• Заведение багов
• Проверка resolved – исправленных багов
• Решение о выкладке в продакшн

Методы тестирования
• Тестирование по спецификации
– В явном виде может и не быть
• Исследовательское тестирование
• Бета-тестирование
• Сравнение с эталоном

Технологии и средства тестирования
• Дизайн и обсуждение дизайна тестов
– Блокнот, ручка, маркер, доска
• Коммуникации
– Почта, джаббер, телефон, личные и видео
встречи
• Организация работы
– Issue-трекер, вики

• Инструменты тестирования
– Браузер
– Командная строка (bash, ssh, diff)
– Текстовые редакторы
– СКВ – git, svn
– Языки программирования, среды разработки
(для автотестов)

• Кастомные инструменты
– https://github.com/yandex-qatools/htmlelements
– https://github.com/allure-framework
– Различные дифферы
– Фреймворки…
• Jenkins, teamcity
• WebDriver (Selenium)

Облачные технологии в
тестировании

• Пример
https://github.com/yandex-
qatools/htmlelements-
examples/blob/master/htmlelements-junit-
example/src/test/java/my/company/web/Searc
hingByRequestTest.java

• Что из этого можно делать удаленно (в
облаке)?

облаке)?
– Выполнение самого Java кода
– Получение браузера

облаке)?
– Выполнение самого Java кода
– Получение браузера
• Так и происходит :)

• Другой пример - тестирование serverside
• Есть маленькая копия продакшн – тестовый
стенд
• Тесты на нем можно гонять в один поток
• Где здесь применить облако?

• Другой пример - тестирование serverside
• Есть маленькая копия продакшн – тестовый
стенд
• Тесты на нем можно гонять в один поток
• Где здесь применить облако?
• Правильно!
– Делать новые стенды по мере надобности
– Удалять ненужные

• Что еще можно сделать с помощью облака?
• Наладить автозапуск тестов:
– Jenkins-хук по сборке релиза
– Разворачивание тестового стенда
– Запуск теста
– Отчет приходит в почту
• Нам остается только пить кофе :)

Методы оценки качества

Методы оценки качества
• Экспертная оценка
– Руководитель сервиса
– Менеджер
– Senior
– Руководитель группы тестирования
• Статистика
– Найденных багов
– Пропущенных багов
– Критичности тех и других
• Скорость тестирования
• Измерение code coverage

Обязанности и ответственность
тестировщика
• Тестирование :)
• Анализ задачи
– Обнаружить нестыковки
– Какие нужны доступы, ресурсы
• Заведение багов
• Отчет о тестировании
– «можно катить»
– Ссылка на отчет автотестов, с кратким резюме – ок/не ок
• Root cause analysis
– По пропущенным багам
• Ведение документации по тестированию

Software testing in practice

More Related Content

What's hot (18)

Viewers also liked (18)

Similar to Software testing in practice (20)

Software testing in practice