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

1. Тестирование ПО.
По другую сторону баррикад:
взгляд разработчика
Андрей Дмитриев
Oracle Development SPb

2. Соотношение времени
разработки и тестирования

3. Соотношение времени
отладки и исправления

4. Тестирование ПО.
По другую сторону баррикад:
взгляд разработчика
Андрей Дмитриев
Oracle Development SPb.

5. Предыстория(1/2)
 Проект с объемом пространства >100Мб
 10+ разработчиков
 Группа SQE (до четырех человек)
 Группы, зависящие от проекта

6. Предыстория(2/2)
 Интеграции каждую неделю
 Ночные сборки
 Предварительное тестирование
 Тестовые наборы

7. Мотивация к докладу?
 Почему считается, что тестировщик
«соперничает» с разработчиком?
 Что ожидается от разработчика?
 Что ожидается от тестировщика?

8. Программа
 Ваши продукты
 Отчёты об ошибках
 Постановка процесса
 Менеджмент общих
целей

9. Ваши продукты

10. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты

11. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты

12. Ваши продукты
 Максимальное покрытие тестами
 Покрытие критической часть программы
 Покрытие спецификации
 Шаблон «Всё равно надо будет»
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты
Взгляд разработчика

13. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты

14. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Внедрение этих инструментов
 Наборы тестов, которые я боюсь запускать
 Своевременное информирование о результатах
 Предусмотреть время на исправление
 Удобные отчёты
Взгляд разработчика

15. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты

16. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Предусмотреть время на исправление
 Почему этот баг возрастом два года стал Critical?
 Удобные отчёты
Взгляд разработчика

17. Ваши продукты
 Максимальное покрытие тестами
 Хорошие инструменты для тестирования и
анализа результатов тестов
 Своевременное информирование о результатах
 Удобные отчёты

18. Наши продукты

19. Наши продукты
 ПО, работающее по спецификации
 Быстрая реакция на ошибки и запросы
 «Поменьше ошибок в коде»
 Участие в обсуждениях и консультациях
 ???

20. Что такое хороший отчёт?
 Краткий
 С тестом, картинкой экрана, видео, звуком
 С описанием того, что должно быть и что на
самом деле наблюдается
 Как настроить систему
 Разбиение на части, фокус на важном
 И т.д.

21. Что такое хороший отчёт?
 По прочтении понятно, что нужно исправить
 Или к какому компоненту относится
 Нейтральная формулировка
 Баг, где просили уволить всех разработчиков
 Что будет, если баг увидит кто-то другой?
 Результаты тестирования производительности,
попавшие в отчет
 Приведены все нужные ссылки
 Да, я не знаю, где лежит тестовый набор!
 Отсутствие опечаток
 Просьба переформулировать
Взгляд разработчика

22. Постановка процесса
 Контроль за работой над дефектом
 Периодичность и своевременность
 Прозрачность того, что делает тестировщик
 Рассылки о статусе тестирования, взят/не взят в цикл
 Советоваться с разработчиком перед тем как делать
что-то неоднозначное
 Создание репутации ответственного
тестировщика
 Толковый, делает дело до конца и сотрудничает
 Когда привлекать тяжёлую артиллерию?

23. Постановка процесса
 Нужно знать, какие компоненты проверяются
 Тег <SQE> в дефектах
 Ошибки должны быть легко доступны
 Извещения – по почте
 Нужно знать, когда начинается цикл
тестирования
 Хочу успеть положить фикс
Взгляд разработчика

24. Общие цели
 Качество продукта
 Соблюдение сроков
 Благополучие команды

25. Общие цели
 Качество продукта – Что ты делаешь?
 Соблюдение сроков – Для кого делаешь?
 Благополучие команды – С кем делаешь?

26. Общие цели
 Качество продукта – Что ты делаешь?
 Соблюдение сроков – Для кого делаешь?
 Благополучие команды – С кем делаешь?
 Тестировщик – первый пользователь
 Возможность точнее видеть ожидаемый результат

27. Общие цели
 Разработчик отдалён от конечного продукта
 Я не использую свой продукт в работе
 Инициатива приветствуется
 Образование в предметной области
 Образование в ИТ в целом
Взгляд разработчика

28. Выработка общей цели
Взгляд разработчика
 Выйти из ситуации
 Сформулировать свою цель
 Оставить пути к отступлению
 Рассмотреть альтернативы

29. Выводы
 Разработчик выполняет ключевую
часть задачи
 Но не обладает видением
ситуации в целом
 Разработчику имеет смысл
прислушиваться к доводам
тестировщика
 Совместное планирование
 Доносите мысли и находите
общее
 Мы мыслим по-разному
 У разработчика и тестировщика
есть общая цель

30. Ссылки
 Crucial Conversations,
VitalSmarts
 Джоэл Спольски о
программировании
 Стив Макконнелл
«Профессиональная
разработка»
 Google: defect good report

31. Спасибо!
andrei-dmitriev@yandex.ru
http://improve-it.org

32. Вопросы?