Lesson 293
Это последний урок последней главы книги Lessons Learned in Software Testing Сэма Канера и его товарищей.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.