О том как описывать баги, сказано уже очень много. О правилах поведения при встрече с багами на пальцах показал Cartoon Tester Andy Clover. О том, как баги искать, не менее убедительно расскажет любой человек, который их когда либо искал ;).
Моя следующая книга для метро "Дзен и искусство ухода за мотоциклом" заставила задуматься о формализации процесса поиска багов. Конечно же книга не о багах, как таковых, но меня тронуло то, что форма решения задач у ученого и тестировщика в чем то схожа:
Об ученых:
(1) постановка проблемы,
(2) гипотеза, касающаяся причины проблемы,
(З) эксперименты, предназначенные для испытания каждой гипотезы,
(4) предсказанные результаты экспериментов,
(5) наблюдаемые результаты экспериментов,
(6) заключения из результатов экспериментов.
О тестировщиках:
Баг - по сути - это проблема.
Мы выдвигаем гипотезы, о том как воспроизвести баг.
Как только мы сталкиваемся с неправильным поведением приложения, вполне очевидно мы должны его попытаться воспроизвести и найти кратчайший путь: мы ставим эксперименты.
Предсказанные результаты -> наблюдаемые результаты -> заключение в виде описанного бага в багтрекинг системе.
Оказывается любой тестировщик это ученый, поскольку:
Человек, проводящий сенсационный научный показ с применением франкенштейновского оборудования стоимостью пятьдесят тысяч долларов, не совершает ничего научного, если знает заранее, какими будут результаты его усилий. Напротив, мотомеханик, нажимающий на клаксон, проверить, работает ли аккумулятор, неформально проводит настоящий научный эксперимент
Занятная мысль: каждый день мы ставим научные эксперименты! - еще один камень на нашу чашу весов в выборе профессии ж).
Именно с такими мыслями чуть больше года назад я оставил за спиной профессию разработчика (:
ОтветитьУдалитьС той лишь разницей, что у мира нет правильного поведения.
ОтветитьУдалить