Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Разговоры о тестировании повсеместно и довольно давно идут наперекосяк. Как любил подчеркивать Джерри Вайнберг, слово «тестирование» перегружено смыслами и сваливает в одну кучу множество идей и видов деятельности. Это слово применяется к различным действиям, выполняемым разными людьми, работающими в разных контекстах, выполняющими разные задачи с различными приоритетами, в разные моменты процесса разработки. Неудивительно, что люди из настолько разных парадигм говорят, не слыша друг друга.

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

О чем пойдет речь

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

• Говоря «продукт», я подразумеваю некий продукт или сервис. «Продукт» применяется не только к выпущенному, рабочему ПО, но и к чему угодно, производимому или предоставляемому кем-либо в ходе разработки. Это могут быть:
  • Фича
  • Спецификация
  • Функция
  • Плановая документация
  • Диаграмма на доске
  • Автоматизированная проверка
  • Документация требований
  • Анализ рисков
  • Тест-дизайн
  • Однострочное изменение в коде
  • Идея
  • …
  • Когда я говорю «мы», то в целом я подразумеваю группу разработки или проектное сообщество – тестировщиков, разработчиков, менеджеров, ответственных за документацию, DevOps-инженеров и службу сопровождения, службу поддержки пользователей, и любые другие роли.
  • Все мы работаем в какой-либо организации, а иногда наша организация обслуживает какие-либо другие. Не все организации – бизнес, но я буду называть «бизнесом» и наших прямых клиентов, и их пользователей. В ситуациях, когда это важно, я буду явно их разделять.
  • Говоря о тестировании, я использую определение тестирования из словаря Rapid Software Testing. Тестирование – это процесс оценки продукта путем его изучения через получение опыта, исследование и эксперименты, что в какой-то степени включает постановку вопросов, ознакомление, моделирование, наблюдение, вмешательство, и т. п. Помните, что «продукт» подразумевает любой продукт, как я указал выше. Проводимые эксперименты могут быть «тестами» в общепринятом смысле – конфигурацией, взаимодействием, наблюдением и оценкой работающего программного продукта – или же, в случае идей или артефактов дизайна, «эксперименты» принимают форму мысленных экспериментов при анализе или ревью.
  • Проверка результатов работы продукта – это неотъемлемая часть тестирования. Проверки (согласно словарю Rapid Software Testing) – это процесс взаимодействия, сбора наблюдений о взаимодействии, применение правил принятия решений к этим наблюдениям, а затем – отчетность о результатах работы этих правил; все это алгоритмически. То есть проверку можно превратить в закодированный процесс, и его может выполнить как человек, так и машина. Проверки можно автоматизировать – тестирование автоматизировать нельзя. Разработка проверок (включающая процесс проектирования и кодирования) может проводиться при помощи инструментов, но тоже не автоматизируется. Схожим образом инструменты могут помочь в интерпретации результатов проверок, но оценка того, о чем проверки нам сообщают (о баге в продукте? О баге в проверке? О какой-то другой проблеме?) – это фундаментально человеческая задача.
  • Кто угодно в проекте может побывать в роли тестировщика, выполнять задачи тестирования или проводить тесты. У некоторых людей тестирование – их основная задача. В словаре Rapid Software Testing мы обычно называем таких людей просто «тестировщиками». Иногда мы хотим разграничить тестировщиков и людей из других ролей, выполняющих задачи тестирования, хотя тестирование – не их основная обязанность. Иногда мы называем их вспомогательными тестировщиками, и говорим про ответственных тестировщиков, подразумевая первую группу. Я буду разделять эти группы, когда это различие важно.

Чего хочет бизнес?

Мы – люди ПО. Мы предоставляем услуги какой-либо организации или бизнесу. Мы называем это «бизнесом», даже если организация некоммерческая, и мы говорим о «деньгах» и «прибыли», обозначающих ценность, наличные деньги или какой-либо социальный рейтинг.

Итак, чего хочет бизнес?

Бизнес хочет делать деньги, предоставляя значимые для людей продукты или услуги (назовем это пока просто «продуктом»). Это может включать продукты, помогающие людям успешнее или экономичнее выполнять рутинные задачи; продукты, делающие возможным невозможное ранее; обучающие и развлекательные продукты. Бизнес может вывести на рынок и продать продукт высокой ценности, принося назад эту желанную, чудесную прибыль.

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

В то же самое время бизнес не хочет, чтобы чересчур много средств вытекало – в смысле зарплат, расходников, издержек на поддержку и ликвидацию последствий, когда что-то идет не так. Чтобы быть жизнеспособным, бизнесу нужно поддерживать издержки разработки, поддержки и обслуживания на относительно низком уровне.

Теперь, чтобы бизнес получил то, чего он хочет, должно произойти как минимум следующее: нам нужно создать продукт.

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

Пока все в порядке. Но…могут возникнуть проблемы (продолжение следует).

Обсудить в форуме