среда, 22 февраля 2012 г.

Lesson 75

С подачи doktorbel .

Философское.

1. Если функционал покрыть тестами, то в нем, скорее всего, не будет баг.
2. Чем дольше в тестируемом функционале нет баг, тем больше вероятность того, что они там появятся.
Вывод:
Баги появляются в функционале, в котором нет тестов.
Второй вывод:
Баги появляются, пока на функционал нет тестов.
Главный вывод:
При дальнейшем повышении автоматизации тестирования единственной задачей станет: БЫТЬ ГОТОВЫМ к неисправности автоматики.
Следствие:
Чем надежнее автоматика, облегчающая работу тестировщика, тем тяжелее быть постоянно готовым к её неисправности. Следовательно, чем более облегчается труд тестировщика, тем тяжелее у них работа.

If You're testing through bug nest keep testing.
(типа того)

Слово Канеру:

Продолжайте тестирование при наличии незначительных, казалось бы, ошибок.

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

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

Мы рекомендуем попробовать три типа дальнейшего тестирования:
Меняйте поведение (изменяйте условия тестирования). Например, воспроизвести ошибку снова и снова. Это накапливающаяся ошибка? Протестируйте объекты связанные с объектом, в котором обнаружен сбой. Например, если программа неожиданно сдвигает экран, когда вы добавляете два числа, протестируйте все что связано с добавлением или с этими числами. Проверьте все, что связано с ошибкой. Если программа сдвигает экран после добавления — сдвиньте экран до добавления самостоятельно. Измените размер экрана. Попробуйте вводить числа быстрее, измените скорость выполнения теста. Конечно, вы можете попробовать широкий спектр других методов поиска ошибок в данном случае. Иногда полезно проводить много несвязанных тестов подряд без перезагрузки или перезапуска программы.

Измените настройки программы (измените условия, изменив программу). Типичная смена условий — использование другой базы данных, изменение констант, изменение настроек использования памяти, что-либо еще, что программа позволяет поменять. В примере со сдвигом экрана, можно изменить размер окна программы, точность отображения чисел, отключение/включение проверки орфографии.

Измените окружение вашего ПО (изменение условий путем изменения ПО, работающего с продуктом). Это конфигурационное тестирование. Вы не проверяете ошибку на стандартной конфигурации, вместо этого вы меняете конфигурацию так, чтобы сделать ошибку более серьезной. Например, если вы считаете, что время — решающий фактор — используйте другую частоту процессора или видеокарты, другой способ передачи данных. Если вы думаете, что это связано с памятью — проверьте продукт на компьютере с меньшим или большим количеством памяти, измените размер свопа.

Вы можете продолжать заниматься тестированием бесконечно. Как долго нужно продолжать? Как минимум несколько минут - любой сбой может быть связан с этой ошибкой.
Для некоторых сбоев, ты можешь продолжать тестирование дольше, может быть, день. Доверяй своему суждению Если ты считаешь, что еще несколько тестов могут дать тебе ценную информацию, проведи их. Если вы считаете, что знаете об ошибке достаточно, и после дополнительного тестирования не узнаете о ней больше — остановите тестирование и сообщите, что вам известно. Доверяйте своим суждениям.

Комментариев нет:

Отправить комментарий