RBT предлагает понятный для бизнеса, да и вообще для всего вариант - тестировать то что важно (для тех кто решает) и то что имеет большую вероятность сломаться. Тем самым мы себя сильно ограничиваем в плане компонент которые тестировать. Нам не нужно убиваться тестируя уголки приложения куда пользователи ходят совсем редко, нам легко оправдать себя, когда время поджимает и надо урезать активности. Тем более мы избавляемся от откровенно идиотических случаев, типа ударов кувалдой по монитору и трипл-кликов с комбами из десяти пальцев на клавиатуре (да-да, такие тестировщики еще встречаются).
То что у нас будут уголки, где будет треш угар и содомия решается тем, что всякие не особо важные части мы тестируем довольно поверхностно и откровенный трешак мы там скорее всего обнаружим и его починят.
В целом очень классная методика очищения своих бесконечных "тестпланов всего" от бесполезной ерунды.
Но есть другая сторона. А все ли важные вещи мы учли? Ведь иногда бизнес/клиент два пишет, а три держит в уме. Или почему бы нам не повыявлять всякие вещи которые легко починить и легко обнаружить?
В итоге очень хочется переформулировать это "важные тесты это те, что проверяют места, где больше риски для бизнеса и/или больше шансов на поломку" на "важные тесты это те, которые, по нашему мнению, могут выявить информацию, которая стоит затраченного времени вне зависимости от требований/рисков/подходов/взоров гневных...".
зырь ещё FMEA. тоже кое-какие мудрости есть в подходе.
ОтветитьУдалитьhttp://ru.wikipedia.org/wiki/FMEA
Оно скорее про багхантинг, а не про выборки
ОтветитьУдалитьА что если не пытаться предсказать, что для пользователя важно, а дать пользователям приложение пораньше, собрать статистику и по результатам определить, что чаще в использовании?
ОтветитьУдалитьПойти и спросить это отличный вариант. Только есть ньюансы.
ОтветитьУдалитьПервый - получение качественного фидбэка не всегда простая задача. К тому же, если речь о пользователях, то фидбэк от них часто поверхностный и без технических деталей (т.е. придется допиливать). 'If I'd asked customers what they wanted, they would have said "a faster horse"' (c) H.Ford.
Второй - пользователи это не единственные лица, от которых зависит то что нам важно. Это может быть еще и команда, менеджмент, маркетологи и т.п. Хороший пример - реклама у гугля или яндекса. Конечному пользователю поиска она никуда не впилась, а даже наоборот. Но бизнес именно от нее получает деньги. И я верю, что они вполне могут решить что какими-то фичами можно пожертвовать, если они будут сильно мешать или противоречить маркетингу (выпил "+" у гугля тому пример)
Ну и как бонус - сбор статистики от пользователей не везде и не всегда легко реализуем. К тому же в предложенном варианте он предполагает что что-то уже работает и реализовано. Это уже само по себе создает приоритеты. Без всяких пользователей.
ОтветитьУдалить