понедельник, 17 октября 2011 г.

То, что важно

Есть такая штука, называется Risk-Based Testing. Если коротко, то это очередное средство борьбы с извечной проблемой тестирования - как получить хорошую выборку из бесконечного количества тестов?

RBT предлагает понятный для бизнеса, да и вообще для всего вариант - тестировать то что важно (для тех кто решает) и то что имеет большую вероятность сломаться. Тем самым мы себя сильно ограничиваем в плане компонент которые тестировать. Нам не нужно убиваться тестируя  уголки приложения куда пользователи ходят совсем редко, нам легко оправдать себя, когда время поджимает и надо урезать активности. Тем более мы избавляемся от откровенно идиотических случаев, типа ударов кувалдой по монитору и трипл-кликов с комбами из десяти пальцев на клавиатуре (да-да, такие тестировщики еще встречаются).
То что у нас будут уголки, где будет треш угар и содомия решается тем, что всякие не особо важные части мы тестируем довольно поверхностно и откровенный трешак мы там скорее всего обнаружим и его починят.

В целом очень классная методика очищения своих бесконечных "тестпланов всего" от бесполезной ерунды.

Но есть другая сторона. А все ли важные вещи мы учли? Ведь иногда бизнес/клиент два пишет, а три держит в уме. Или почему бы нам не повыявлять всякие вещи которые легко починить и легко обнаружить?

В итоге очень хочется переформулировать это "важные тесты это те, что проверяют места, где больше риски для бизнеса и/или больше шансов на поломку" на "важные тесты это те, которые, по нашему мнению, могут выявить информацию, которая стоит затраченного времени вне зависимости от требований/рисков/подходов/взоров гневных...".

5 комментариев:

  1. зырь ещё FMEA. тоже кое-какие мудрости есть в подходе.

    http://ru.wikipedia.org/wiki/FMEA

    ОтветитьУдалить
  2. Оно скорее про багхантинг, а не про выборки

    ОтветитьУдалить
  3. А что если не пытаться предсказать, что для пользователя важно, а дать пользователям приложение пораньше, собрать статистику и по результатам определить, что чаще в использовании?

    ОтветитьУдалить
  4. Пойти и спросить это отличный вариант. Только есть ньюансы.

    Первый - получение качественного фидбэка не всегда простая задача. К тому же, если речь о пользователях, то фидбэк от них часто поверхностный и без технических деталей (т.е. придется допиливать). 'If I'd asked customers what they wanted, they would have said "a faster horse"' (c) H.Ford.

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

    ОтветитьУдалить
  5. Ну и как бонус - сбор статистики от пользователей не везде и не всегда легко реализуем. К тому же в предложенном варианте он предполагает что что-то уже работает и реализовано. Это уже само по себе создает приоритеты. Без всяких пользователей.

    ОтветитьУдалить