Доклад Сергея Остапенкова на SQA Days-15. 18-19 апреля, 2014, Москва. www.sqadays.com

1. Обеспечение качества:
Практические советы
Сергей Остапенков. Intetics

2. Обеспечение качества в
рамках компании
Quality
Assurance
Processes
Matured Processes
Iterative Testing Cycle
ISO 9001 & 27001
Technologies
E Business
Client/Server
CRM
Infrastructure
Test Management
Test Automation
Requirements
Management
Issue Tracking
Communication
People
Experienced Staff
ISTQB Certified
Automation Experts
Measurements
Code
Development Process
Testing Process
02/21

3. Проблемы
• Много найденных багов
• Нехватка времени
• Сдвиг даты релиза
• Нагрузка в конце итерации
• Низкое качество проекта
• Баги с продакшен-сервера
• Неудовлетворенность заказчика
03/21

4. Пути решения
• Много найденных багов - > Предотвращение типичных багов
• Нехватка времени - > Распараллеливание задач
• Сдвиг даты релиза - > Нахождение проблем на ранних этапах
• Нагрузка в конце итерации - > Мини-регрессии по ходу итерации
• Низкое качество проекта - > Обеспечение качества на всех этапах
• Баги с продакшен-сервера - > Анализ и предотвращение
• Неудовлетворенность заказчика - > Выполнять все пункты выше...
04/21

5. Спецификация
#1. Хранение: Единая точка (Confluence / SVN)
#2. Декомпозиция и именование каждого реквеста: Понятно,
лаконично, с наличием прямой ссылки на каждый реквест
#3. Обратная связь с заказчиком: Открытый доступ для review
#4. Заносятся ВСЕ требования, включая казалось бы мелкие
ПОЛЬЗА:
Требования в одном месте и каждый таск в Jira чётко на них ссылается;
обратная связь снижает риски ошибок в требованиях. ВРЕМЯ!
05/21

6. Планирование итерации
#5. Вдумчивый анализ и составление вопросов
#6. Участвуют ВСЕ
#7. Создание приёмочных тестов (DEV & QA)
#8. Переход к Test Design сразу после планирования итерации
#9. Декомпозиция задач
ПОЛЬЗА: Все в курсе что будет делаться; многосторонняя точка
зрения и разнообразные вопросы; обнаружение проблем на ранних
этапах. Четкое понимание что нужно делать. ВРЕМЯ!
06/21

7. Работа с тест кейсами
#10. Тесты описывают только то, что они должны проверять
ПОЛЬЗА: Исключение избыточности, легкость в поддержке
#11. Создаваемый тест кейс рассчитан на незнающего проект человека
ПОЛЬЗА: Обучение проекту; привлечение специалиста со стороны,
включая программистов на проекте (agile). ВРЕМЯ!
#12. Введение дополнительных параметров тест кейса
ПОЛЬЗА: Удобство при формировании и запуске тест сета. ВРЕМЯ!
#13. Unit-test по запросу
ПОЛЬЗА: Вынос проверки на уровень сборки. РИСКИ!
#14. Проведение рефакторингов тестовых сценариев
07/21

8. Оптимизация тест кейсов
#15. Используем тестовые данные (sample data, полу-автоматизация)
Иструмент: Apache ant (db-load, db-export)
ПОЛЬЗА:
- Единая терминология в рамках команды
- Компактные тест кейсы и баги
- Ускорение запуска тест кейсов и устранение человеческого фактора
08/21

9. Различные виды тестов на
все случаи жизни
#16. Различные виды тестов на все случаи жизни
• Sanity - поверхностные тесты
• Urgent – основной функционал
• Functional – детализированное описание фичи
• Cross – связь между различными функциональностями
• Comprehensive – ключевые функциональности в рамках схожего
поведения (Пример: Email sending - Entry points)
• Bugs list – список багов по функциональности
• Checklists – список ключевых аспектов функциональности
• Must haves – тест кейсы, которые выполняются в каждой итерации
• Автоматические функциональные скрипты
• Автоматические нагрузочные скрипты
• Проверка безопасности
09/21

10. Верификация тасков
#17. Code-review (Tech Lead) РАННЕЕ ОБНАРУЖЕНИЕ!
#18. Доступность билдов и умение работать с ними автономно ВРЕМЯ!
#19. Верификация тасков в параллели
ПОЛЬЗА: Более ранняя загрузка программиста, нахождение критичных
проблем на ранних стадиях. ВРЕМЯ! РИСКИ!
#20. Постоянное общение с программистом после любого фикса
ПОЛЬЗА: Всеобъемлющая проверка на ранней стадии. РИСКИ!
10/21

11. Работа с багами
#21. Заносим всё, что находим (используем контейнеры)
#22. Не полагаемся на память программиста
#23. Создаем покрытие на любой баг
#24. Указываем номер бага в тест кейсе
#25. Анализируем баг глубже
#26. Помечаем баги с продакшен-сервера и анализируем их
11/21

12. Детализация багов
#27. Детализируем заносимые баги
Keywords:
- Воспроизводимость
- Cсылка на требования
- Точная версия билда (старый баг?)
- Точный список окружения / компонент в приложении
- Минимизация шагов / лаконичный скриншот
- Log-файл с ошибкой
- Приоритет / итерация для фикса / исполнитель по-умолчанию
- Дополнительная информация: проблемный коммит / workaround /
покрытие / возможный фикс / места невоспроизводимости
ПОЛЬЗА: Предотвращение занесения невоспроизводимых багов;
экономия времени программиста; понятное, наглядное и
локализованное обнаружение проблемы. ВРЕМЯ!
12/21

13. Формирование тест сетов
• Features verification
#28. Выполнение теста по частям; обязательная финализация фичи
• Bug-fixing / verification
#29. Проведение мини-регрессий
• Release candidate testing
#30. Детальный и вдумчивый анализ всех изменений итерации
#31. Знание о доступном времени
#32. Привлечение PM’a к составлению тест сета
#33. Балансирование между КОЛИЧЕСТВО - ВРЕМЯ - КАЧЕСТВО
• Sanity check на продакшен-сервере
#34. Проверка сервер-ориентированных и новых функциональностей
13/21

14. Артефакты тестирования
#35. Наличие собственного тестового сервера (аналог продакшена)
#36. Создание словаря терминов, опросников, диаграмм зависимостей,
различная документация по настройке и автономной работе с проектом
Примеры:
- Single feature опросник - “New format”
- Connection and deploy on the test server
- Setting up test PC for Automation
14/21

15. Обеспечение качества
процесса
#37. Слежение за выполнением регламентированных процессов:
Milestones (Features Complete, Code Freeze), Commit программиста,
Закрытие сущности в Jira
#38. Создание и постоянный апдейт таких документов как Test Plan,
Known Issues, Main functionality and features list, Releases and hot-fixes
#39. Анализ unresolved сущностей в баг-трекинг системе
Keywords: актуальность; новые детали; соответствие приоритету
#40. Периодический анализ логов на продакшен сервере
#41. Своевременное “бранчевание”
#42. Распределение браузеров между командой
#43. Инициирование своевременных demo для заказчика
#44. Создание “Cписка улучшений” для review заказчику
15/21

16. Автоматизация
#45. Автоматизируем только важные и стабильные фичи
#46. Создаем кросс-функциональные скрипты на основе
Regions.Compare (TestComplete 7)
#47. Создаем скрипты для тестирования Web Services (soapUI)
#48. Включаем всю автоматизацию в Continuous Integration процесс с
ежедневным отчетом
ПОЛЬЗА: Нахождение проблем на ранних этапах; уменьшение
времени на регрессию; уменьшение времени на update.
#49. Используем вспомогательные приложения: SnagIT, AutoIT,
BCompare, Araxis Merge, SeleniumIDE
ПОЛЬЗА: Простой уровень вхождения; требуют мало времени на
освоение, но дают хороший эффект на выходе
16/21

17. Производительность
#50. Создание скриптов, позволяющих создать нагрузку (LoadRunner,
JMeter) / поиск нагружаемых функциональностей в проекте (Search)
#51. Проверка возможной просадки производительности перед
релизом на идентичных продакшен-серверу мощностях (load / no load)
#52. Периодический анализ sqlslow лога на продакшен-сервере
17/21

18. Безопасность
#53. Написание и выполнение инструкции по SQL injections
#54. Создание Must have тест кейса по авторизации пользователя и
проверке доступа к данным
#55. Периодический анализ используемых 3'd party компонентов
(exim4, proftpd, etc) на предмет актуальности версии, проблем с
безопасностью, инициирование апгрейда в случае нахождения
потенциальных угроз (http://www.cvedetails.com)
18/21

19. Сохранность данных и
поддержка
#56. Инкрементальный бекап (binlogs)
#57. Репликация данных (резервный сервер базы данных)
#58. Маскирование данных в продакшен-дампах, используемых
локально (email address, passwords, skype, phones, etc)
#59. Настройка уведомлений команде в случае непредвиденных
ошибок с детальным логом ошибки (email, sms)
#60. Pingability – слежение за доступностью сервера из разных мест
#61. Анализ данных из Google Analytics (используемые браузеры,
время наибольшей активности, нагрузки)
19/21

20. Активности после релиза
#62. Ретроспектива
• Приведение статистики по состоявщемуся релизу проекта
• Озвучивание новых или старых проблем; поиск путей решения
• Улучшения в процессе: выработка лучшего решения
• Cоздание и занесение протокола в Confluence
#63. Дополнительные активности после релиза
• Хранение релизного билда и всей отчетности по релизу
• Добавление новых функциональностей в опросники
• Обновление приемочных тестов
• Анализ невыполненных QA-тасков
• Поиск потенциальных целей для автоматизации
20/21

21. Обеспечение качества
РЕЗЮМЕ
21/21
Email: sergey.ostapenkov@gmail.com
Skype: sergey.ostapenkov