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



https://github.com/allure-framework



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



• Пример

https://github.com/yandex-qatools/htmlelements-examples/blob/master/htmlelements-junit-example/src/test/java/my/company/web/SearchingByRequestTest.java














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




– Выполнение самого Java кода

– Получение браузера




– Выполнение самого Java кода

– Получение браузера

• Так и происходит :)



• Другой пример - тестирование serverside

• Есть маленькая копия продакшн – тестовый стенд

• Тесты на нем можно гонять в один поток

• Где здесь применить облако?



• Другой пример - тестирование serverside

• Есть маленькая копия продакшн – тестовый стенд

• Тесты на нем можно гонять в один поток

• Где здесь применить облако?

• Правильно!

– Делать новые стенды по мере надобности

– Удалять ненужные



• Что еще можно сделать с помощью облака?

• Наладить автозапуск тестов:

– Jenkins-хук по сборке релиза

– Разворачивание тестового стенда

– Запуск теста

– Отчет приходит в почту

• Нам остается только пить кофе :)


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


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

• Экспертная оценка – Руководитель сервиса – Менеджер – Senior – Руководитель группы тестирования

• Статистика – Найденных багов – Пропущенных багов – Критичности тех и других

• Скорость тестирования • Измерение code coverage


Обязанности и ответственность тестировщика

• Тестирование :) • Анализ задачи

– Обнаружить нестыковки – Какие нужны доступы, ресурсы

• Заведение багов • Отчет о тестировании

– «можно катить» – Ссылка на отчет автотестов, с кратким резюме – ок/не ок

• Root cause analysis – По пропущенным багам

• Ведение документации по тестированию


Technology

Software testing in practice