2. Отдел тестирования 1. Формирование и развитие профессионального центра компетенции по тестированию. 2. Более гибкое управление группами тестировщиков по проектам или продуктам.
3. Что было 3-4 проекта ― 1 тестировщик: Страдает качество; Страдает проект; Нужно довольно много времени, чтобы перестраиваться с одного проекта на другой; Страдает планирование работы тестировщика;
4. Как будет Четкое планирование работы тестировщика на проекте по времени. Например, 1 проект несложный, кратковременный, а второй только в стадии планирования, разработки, когда тестировщику приходится тратить немного времени на написание тест-кейсов, на тестирование каких-либо небольших разрозненных функциональностей. Погружение в работу Осведомленность о мелочах проекта Возможность приглашения тестировщика с другого проекта для помощи или освежения взгляда на продукт
5. Обучение Непрекращающееся обучение: самообучение, чтение книг/статей; участие в конференциях; проведение тренингов внутри отдела; делиться полученными знаниями/опытом с коллегами; «Прочитал статью/книгу, дай ссылку коллеге, сделай доклад/презентацию» Участие в online-конференциях всем отделом ― просмотр докладов через проектор. Повышение компетенции в областях разрабатываемых продуктов (мобильные приложения, трейдинговые приложения).
6. Анализ проблем Постоянный анализ проблем, возникающих при работе (ошибки, непонимание и т. д.); Изучение фидбека от заказчика, пользователей (в зависимости от проекта).
7. Bug tracking system Введение шаблонов описания ошибок: поиск; исключение дублирования. Введение обязательных полей для заполнения. Изменение приоритета/важности/статуса только с обоснованием. И т.д.
11. Метрики Цель контроля - обратная связь и визуализация процесса тестирования. Вручную и автоматически. Оценка: покрытия (например, покрытие требований или кода тестами) критериев выхода (например, критерии окончания тестирования) прогресса выполнения запланированных работ Примеры метрик : Метрики по тестовым случаям (Test Cases) Метрики по багам Метрики по задачам
12. Метрики По багам: Open/Closed Bugs - отношение количества открытых багов к закрытым (исправленным и перепроверенным) Feedback/Closed Bugs -отношение количества возвращеных багов к закрытым (исправленным и перепроверенным) Метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" визуализируют степень приближения продукта к достижению критериев качества по багам. Метрики "Feedback/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования. Пример: Количество переоткрываемых после починки багов не уменьшается или даже растет. Это сигнал к тому, что необходимо провести анализ причин, т.к. подобная ситуация может показать, что: Требования к функции можно трактовать по разному Тестировщик не точно описал проблему Некачественное поверхностное решение проблемы (фикс бага)
13. Версионность, формализация На тестирование принимается замороженая версия продукта. Формализация (Функционал: проверка задач/тестирование функционала -> исправление ошибок -> проверка исправлений -> ... -> конфигурационнное тестирование/интеграционанное тестирование и т. д. … -> регресс) VS «Разработчик сказал посмотреть здесь, я посмотрел и сказал, что все хорошо» и забыли. Регистрация всех найденых багов в баг-трекере, даже если используется гибкая методология разработки.
14. Тестовый сервер Отдельный тестовый сервер: проведение ночных автотестов конфигурационное тестирование (разные ОС, браузеры, эмуляторы) оценка возможности и рентабельности введения.
