Что мы имеем. (Rex Black)

Некоторое время думал, каким образом лучше описывать главы из книги Managing the testing Process. Решил, надо как обычно - читаю и выделяю ключевые и интересные с моей точки зрения мысли и идеи.


Название поста - это мой вольный перевод названия главы. Ну а в скобках автор сего классического труда. 


1. Перед началом организации всего процесса тестирования нужно определить: 
а) Что мы можем протестировать
б) Что мы должны протестировать
в) И в конце концов, что мы сможем протестировать


2. Проект тестирования нужно продать своему менеджменту для получения необходимых ресурсов и времени.


3. Проверять систему при усреднённой нагрузке как единственная техника тестирования - серьёзная ошибка, которая часто совершается тестовыми командами.


4. Программы, написанные на С и С++ часто имеют серьёзные security bugs, связанные с переполнением буфера.


5. Beta тестирование часто проводится как ad hoc ( случайное, что является худшим вариантом тестирования) или как exploratory (исследовательское, что является лучшим вариантом).


REM: По поводу exploratory testing мне норавилась публикация James Bach Exploratory Testing Explained .


6. Часто прожект план по тестированию игнорирует или недооценивает важность интеграционного тестирования, что приводит к нехватке ресурсов в тот момент, когда возникает в нём необходимость.


7. Acceptance testing включает в себя настоящие данные, натоящее окружение и типичные сценарии пользователей. Поэтому маркетинговый отдел, отдел продаж, техническая поддержка, и даже управленческие кадры компании - лучшие кандидаты для такого тестирования.


8. Для того, чтобы понять что тестировать, нужно определиться: что означает качество применительно к предмету тестирования, и какие риски качества (quality risks) существуют.


9. То, что пользователь чаще всего намеривается или использует в системе, является областью наиболее критичиской с точки зрения рисков.


10. Существует понятие - project risk. Когда первичный эффект от какой-либо проблемы влияет на успех и выполнение всего проекта- это project risk.


11. Для успеха в тестирование нужно расставить все тесты по приоритету и начинать тестирование всегда с самого важного. При недостатке времени всегда можно будет убрать из плана менее важные тесты.


12. Самые важные функциональности или аспекты тестируемого софта должны быть покрыты самым большим разнобразием тестов. И усилися при тестировании прилагаться соответсвующим образом.


13. Предварительный анализ всех усилий по тестированию обычно базируется на некорректных предположениях и недостаточной информации.


14. Лучший способ определения рисков качества - проведения многосторонних встреч с техническими и бизнес специалистами в компании.


15. Сhecklist всех аспектов, входящих в понятие качества продукта, достаточно большой.
Вот некоторые из аспектов:
- Functionality
- Performance
- Error/disaster handling and recovery
- Data flow coverage
- User Interface
- Installation setup and initial configuration
- Documentation and packaging
...


16. Ключевой фактор оценки рисков - правильный выбор  участников многосторонних встреч для их оценки. Всякий, кто может понять, что может пойти не так с системой, хороший кандидат со стороны технических специалистов (stakeholder).  Команда обязательно должна включать в себя менеджера проекта и менеджера разработки.


17. Слишком сильная детализация рисков приведёт к сложностям в упралении ими, низкакя детализация вызовёт тркдности в установке приоритетов тестов.


18. При невозможности придти к согласию по степени рисков эту степень должен выставить тот, кто в конечном счёте ответственен за качество поставляемого продукта.


19. "Schedule, cost and quality - pick two" Что означает, выбираешь и устанавливаешь 2 аспекта и они уже определяют третий. 
NB: VERY IMPORTANT 


20. Структура тест - цикла ( Confirmation Tests --> Scheduled Tests --> Exploratory Tests)


21. Если опыта работы с командой проекта нет, то нужно примерно угадать с количеством циклов. По своему стандарту, отработанному на многих проектах, Rex использовал шесть недельных циклов.


22. Хороший продакт менеджмент предполагает постоянный анализ существующего плана и его изменение согласно менеющимся обстоятельствам.


23. Предварительное планирование предполагает участие в обсуждение плана всех лиц, участвующих в проекте. Однако согласно исследованиям первичные оценки изменяются проектов изменяются на 50, а то и на 200%


24. Оценку тестирования сложно сделать идеальной, но не ужасно сложно сделать хорошо.
Составить план требует нетривиальных способностей, поэтому в начале старайтесь делать более простые планы.  В сложных планах можно и запутаться.


25. Единственное табу в составлении планов - согласиться потом всё сделать за меньшее время или меньшими ресурсами. Если уж менеджмент настаивает, пусть он берёт на себя все риски.


Итоги:  Примерно разобрался в первоначальных задачах, что нужно решать при начале проекта.  Не всё можно применить в таком виде, что описано в книге, но оно и понятно, условия у всех разные.