Обеспечение качества: Практические советы

Сергей Остапенков. Intetics

Обеспечение качества в рамках компании

QualityAssuranc

e

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

MeasurementsCode

Development Process

Testing Process

02/21

Проблемы

• Много найденных багов

• Нехватка времени

• Сдвиг даты релиза

• Нагрузка в конце итерации

• Низкое качество проекта

• Баги с продакшен-сервера

• Неудовлетворенность заказчика

03/21

Пути решения

• Много найденных багов - > Предотвращение типичных багов

• Нехватка времени - > Распараллеливание задач

• Сдвиг даты релиза - > Нахождение проблем на ранних этапах

• Нагрузка в конце итерации - > Мини-регрессии по ходу итерации

• Низкое качество проекта - > Обеспечение качества на всех этапах

• Баги с продакшен-сервера - > Анализ и предотвращение

• Неудовлетворенность заказчика - > Выполнять все пункты выше...

04/21

Спецификация

#1. Хранение: Единая точка (Confluence / SVN)

#2. Декомпозиция и именование каждого реквеста: Понятно, лаконично, с наличием прямой ссылки на каждый реквест

#3. Обратная связь с заказчиком: Открытый доступ для review

#4. Заносятся ВСЕ требования, включая казалось бы мелкие

ПОЛЬЗА:

Требования в одном месте и каждый таск в Jira чётко на них ссылается; обратная связь снижает риски ошибок в требованиях. ВРЕМЯ!

05/21

Планирование итерации

#5. Вдумчивый анализ и составление вопросов

#6. Участвуют ВСЕ

#7. Создание приёмочных тестов (DEV & QA)

#8. Переход к Test Design сразу после планирования итерации

#9. Декомпозиция задач

ПОЛЬЗА: Все в курсе что будет делаться; многосторонняя точка зрения и разнообразные вопросы; обнаружение проблем на ранних этапах. Четкое понимание что нужно делать. ВРЕМЯ!

06/21

Работа с тест кейсами

#10. Тесты описывают только то, что они должны проверять

ПОЛЬЗА: Исключение избыточности, легкость в поддержке

#11. Создаваемый тест кейс рассчитан на незнающего проект человека ПОЛЬЗА: Обучение проекту; привлечение специалиста со стороны, включая программистов на проекте (agile). ВРЕМЯ!

#12. Введение дополнительных параметров тест кейса

ПОЛЬЗА: Удобство при формировании и запуске тест сета. ВРЕМЯ!

#13. Unit-test по запросу

ПОЛЬЗА: Вынос проверки на уровень сборки. РИСКИ!

#14. Проведение рефакторингов тестовых сценариев

07/21

Оптимизация тест кейсов

#15. Используем тестовые данные (sample data, полу-автоматизация)

Иструмент: Apache ant (db-load, db-export)

ПОЛЬЗА:

- Единая терминология в рамках команды

- Компактные тест кейсы и баги

- Ускорение запуска тест кейсов и устранение человеческого фактора

08/21

Различные виды тестов на все случаи жизни

#16. Различные виды тестов на все случаи жизни

• Sanity - поверхностные тесты• Urgent – основной функционал• Functional – детализированное описание фичи• Cross – связь между различными функциональностями• Comprehensive – ключевые функциональности в рамках схожего

поведения (Пример: Email sending - Entry points)• Bugs list – список багов по функциональности• Checklists – список ключевых аспектов функциональности • Must haves – тест кейсы, которые выполняются в каждой итерации• Автоматические функциональные скрипты• Автоматические нагрузочные скрипты• Проверка безопасности

09/21

Верификация тасков

#17. Code-review (Tech Lead) РАННЕЕ ОБНАРУЖЕНИЕ!

#18. Доступность билдов и умение работать с ними автономно ВРЕМЯ!

#19. Верификация тасков в параллели

ПОЛЬЗА: Более ранняя загрузка программиста, нахождение критичных проблем на ранних стадиях. ВРЕМЯ! РИСКИ!

#20. Постоянное общение с программистом после любого фикса ПОЛЬЗА: Всеобъемлющая проверка на ранней стадии. РИСКИ!

10/21

Работа с багами

#21. Заносим всё, что находим (используем контейнеры)

#22. Не полагаемся на память программиста

#23. Создаем покрытие на любой баг

#24. Указываем номер бага в тест кейсе

#25. Анализируем баг глубже

#26. Помечаем баги с продакшен-сервера и анализируем их

11/21

Детализация багов

#27. Детализируем заносимые баги

Keywords:

- Воспроизводимость

- Cсылка на требования

- Точная версия билда (старый баг?)

- Точный список окружения / компонент в приложении

- Минимизация шагов / лаконичный скриншот

- Log-файл с ошибкой

- Приоритет / итерация для фикса / исполнитель по-умолчанию

- Дополнительная информация: проблемный коммит / workaround / покрытие / возможный фикс / места невоспроизводимости

ПОЛЬЗА: Предотвращение занесения невоспроизводимых багов; экономия времени программиста; понятное, наглядное и локализованное обнаружение проблемы. ВРЕМЯ!

12/21

Формирование тест сетов

• Features verification

#28. Выполнение теста по частям; обязательная финализация фичи

• Bug-fixing / verification

#29. Проведение мини-регрессий

• Release candidate testing

#30. Детальный и вдумчивый анализ всех изменений итерации

#31. Знание о доступном времени

#32. Привлечение PM’a к составлению тест сета

#33. Балансирование между КОЛИЧЕСТВО - ВРЕМЯ - КАЧЕСТВО

• Sanity check на продакшен-сервере

#34. Проверка сервер-ориентированных и новых функциональностей

13/21

Артефакты тестирования

#35. Наличие собственного тестового сервера (аналог продакшена)

#36. Создание словаря терминов, опросников, диаграмм зависимостей, различная документация по настройке и автономной работе с проектом

Примеры:

- Single feature опросник - “New format”

- Connection and deploy on the test server

- Setting up test PC for Automation

14/21

Обеспечение качества процесса

#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

Автоматизация

#45. Автоматизируем только важные и стабильные фичи

#46. Создаем кросс-функциональные скрипты на основе Regions.Compare (TestComplete 7)

#47. Создаем скрипты для тестирования Web Services (soapUI)

#48. Включаем всю автоматизацию в Continuous Integration процесс с ежедневным отчетом

ПОЛЬЗА: Нахождение проблем на ранних этапах; уменьшение времени на регрессию; уменьшение времени на update.

#49. Используем вспомогательные приложения: SnagIT, AutoIT, BCompare, Araxis Merge, SeleniumIDE

ПОЛЬЗА: Простой уровень вхождения; требуют мало времени на освоение, но дают хороший эффект на выходе

16/21

Производительность

#50. Создание скриптов, позволяющих создать нагрузку (LoadRunner, JMeter) / поиск нагружаемых функциональностей в проекте (Search)

#51. Проверка возможной просадки производительности перед релизом на идентичных продакшен-серверу мощностях (load / no load)

#52. Периодический анализ sqlslow лога на продакшен-сервере

17/21

Безопасность

#53. Написание и выполнение инструкции по SQL injections

#54. Создание Must have тест кейса по авторизации пользователя и проверке доступа к данным

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

18/21

Сохранность данных и поддержка

#56. Инкрементальный бекап (binlogs)

#57. Репликация данных (резервный сервер базы данных)

#58. Маскирование данных в продакшен-дампах, используемых локально (email address, passwords, skype, phones, etc)

#59. Настройка уведомлений команде в случае непредвиденных ошибок с детальным логом ошибки (email, sms)

#60. Pingability – слежение за доступностью сервера из разных мест

#61. Анализ данных из Google Analytics (используемые браузеры, время наибольшей активности, нагрузки)

19/21

Активности после релиза

#62. Ретроспектива• Приведение статистики по состоявщемуся релизу проекта• Озвучивание новых или старых проблем; поиск путей решения• Улучшения в процессе: выработка лучшего решения• Cоздание и занесение протокола в Confluence

#63. Дополнительные активности после релиза• Хранение релизного билда и всей отчетности по релизу• Добавление новых функциональностей в опросники• Обновление приемочных тестов• Анализ невыполненных QA-тасков• Поиск потенциальных целей для автоматизации

20/21

Обеспечение качестваРЕЗЮМЕ

21/21

Email: sergey.ostapenkov@gmail.comSkype: sergey.ostapenkov