4. Как будем считать
•Учет ограничений бюджета или
сроков.
•Аналогия с предыдущими проектами.
•Экспертная оценка.
•Декомпозиция работ.
•Эмпирические оценки.
4
5. Что будем учитывать, чтобы не промахнуться
• Неполноту требований.
• Непредусмотренные проблемы,
связанные с изменением оборудования.
• Непредусмотренные проблемы,
связанные с использованием 3rd party.
• Условное время выполнения задачи.
• Время на интеграцию.
• Время на подготовку персонала.
5
8. Two test or not too test
Тестируем только то, что необходимо
Тестер: «Я нашел баг, самолет
не умеет летать задом на
перед»
PM: «А с чего ты взял, что он
должен это делать?»
8
9. О пользе и вреде Unit-тестов
Польза Вред
•Unit-тест показал, •Unit-тест показал,
что код работает. что код работает
•Unit-тест – верный именно там, где его
путь к выполнили;
автоматизации. поэтому...
9
10. Трассировка всего на все
Трассируем:
• код на требования,
• код на железо,
• код на тесты,
• тесты на железо,
• софт на железо,
• софт на код,
и т.д.
10
13. Чистота – залог успеха - 2
Перепроверяем сразу после
исправления, иначе:
• сложнее искать,
• сложнее перепроверить,
• «а был ли мальчик?» (с)
13
14. Готово = сделано + протестированно
То, что сделано, но не
проверено:
• портит статистику,
• вводит в заблуждение,
• это неправда .
14
15. Как же быть?
В-третьих,
«повторение – мать учения»
15
16. Автоматизация всего, что можно
автоматизировать
Обширное ручное тестирование для
встраиваемых проектов достаточно
сложно, если вообще возможно, поэтому:
•ручное тестирование только для того,
чтобы потом его автоматизировать;
•ручное тестирование только там, где нет
возможности его автоматизировать.
16
20. В результате-1
•Тратим время, чтобы оценить
заранее и не тратить время потом.
•Следим за «чистотой».
•Думаем и тщательно выбираем,
перед тем, как броситься нажимать
кнопки.
20
21. В результате-2
• Трассируем все на все.
• Пробуем построить атоматизированный
стенд.
• Накапливаем и расширяем автотесты.
• Если удалось автоматизировать -95+% -
очень хорошо.
• Гоняем автотесты в двух режимах.
21