Еще пара цитат из книги.
Цитата раз:
... мы создали поэтапный процесс, в котором можно легко откатить изменение, в котором слишком много багов. тестирование определяет насколько хорошо мы предотвращаем ошибки
Цель инженера по тестированию (Test Engineer TE) не искать ошибки в приложении, чтоб исправить их - этим занимаются разработчики, но искать ошибки, чтоб выявить их причину и помочь разработчику самостоятельно или с помощью разработчика в тестировании (Software Engineer in Test SET) - устранить эти помехи.
Я так понял, баги как таковые тестера вообще не очень интересуют, они являются инструментом выявления проблем, их признаком. Как-то так.
Цитата два:
Simon Stewart: Я пользовался процессом DDD (Defect-Driven-Development). Я объявлял WebDriver бездефектным, а когда пользователь находил баг я его исправлял и снова объявлял продукт бездефектным. так я исправлял по-настоящему значимые для людей баги. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.
пошла и заказала себе тоже эту книгу...
ОтветитьУдалитьцитаты просто шик!
Особо радует демократичность цены.
ОтветитьУдалитьда! это тоже оказалось приятной находкой
ОтветитьУдалитьвторой тезис очень спорный. а как же "баг найденный на продашкене обходится компании намного дороже"? здесь важен баланс. всё очень сильно зависит от проекта. если мы, например, пропустим серьёзный баг, то человек может пойти на маркет-площадку, оставить гневный ревью с одной звездой, рейтинг модуля упадёт, возрастёт веростность того, что другие потенциальные клиенты выберут продукт конкурентов. а ведь еще есть баги юзабилити - такие баги редко репортятся кастомерами, однако приносят им достаточно много неудобств.
ОтветитьУдалитьАргумент.
ОтветитьУдалитьНо у примера есть смягчающий фактор: "доработки существующего продукта" - продукт в поддержке, критикалов нет, есть набор автотестов, а значит новые доработки не натворят ничего страшного.