Разделы портала

Онлайн-тренинги

.
Ценность пессимизма в тестировании
20.12.2022 00:00

Автор: Барри Эйгиатор (Barry Ehigiator)
Оригинал статьи
Перевод: Ольга Алифанова

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

Определение защитного пессимизма

Защитный пессимизм – это стратегия для использования сомнений и волнений в качестве мотивации для лучшей производительности. Наиболее важный аспект защитного пессимизма, как отмечают Норем и Кантор в своей прорывной работе (1986) включает, помимо прочего, установку низких ожиданий от результата определенной ситуации. Это может помочь предотвратить рискованные ситуации и улучшить производительность, если такая ситуация возникает. К примеру, вы ожидаете, что ваше любимое устройство не будет работать, как надо, в определенных условиях, а затем воображаете факторы, которые могут вызвать эти условия. Эта практика помогает предотвратить этот отказ работы. Тестирование – безусловно, та область, где защитный пессимизм будет полезен.

Образ мыслей защитного пессимиста в тестировании

Образ мыслей – это та внутренняя линза, при помощи которой мы смотрим на жизнь и идем по ней (Рид и Штольц, 2011). Он влияет на наше отношение – способ, которым мы понимаем, что происходит, и как на это реагировать. Образ мыслей очень важен – он помогает нам видеть возможности, но он же может загнать нас в ловушку пораженческих настроений.

В тестировании практика защитного пессимизма поможет вам получить критично важные знания о вашем продукте, внести свой вклад в улучшение качества в ходе разработки, и, в конце концов, стать полезным заказчикам. К примеру, пессимистичное отношение к качеству продукта заставляет вас подвергать сомнению все аспекты разработки (от концепции до поставки), выпущенного продукта и способа, которым его используют заказчики. К тому же оно заставляет вас усердно искать таящиеся в приложении проблемы. Затем вы можете бороться за то, чтобы эти проблемы были исправлены как можно раньше в ходе разработки. Более того, пессимистичное отношение к качеству продукта, как широко описано Кейнером и др. (2002) в "Lessons Learned In Software Testing, помогает убедиться, что вы как тестировщик практикуете следующие важные уроки:

Подвергайте сомнению все на свете, но необязательно вслух (Урок 7)

Чтобы тестирование было полезным и эффективным, нужно научиться подвергать сомнению допущения. Конечно, вы можете тестировать, не сомневаясь в допущениях: выполняя задокументированные заранее тест-кейсы, запуская автоматизированные регрессионные тесты, тестируя специфические позитивные сценарии, и т. д. Однако в этих случаях вы тестируете, почти не задействуя когнитивные, интерактивные и интеллектуальные аспекты тестирования. Полностью понять свой продукт, логику его функциональности, интеграцию с другими системами, его использование пользователями, граничные сценарии использования трудно без достаточной когнитивной вовлеченности в продукт. Следовательно, бесспорно то, что хорошо тестировать таким образом невозможно.

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

Концентрируйтесь на неудачах, чтобы клиенты смогли концентрироваться на успехах (Урок 8)

Запуск нового продукта в любой отрасли сложен, потому что многое может пойти не так. Самый частый пример: отказы ПО – когда продукт не способен выполнить свои целевые функции в пределах требований, или подвергает пользователя определенным уязвимостям безопасности.

Список таких случаев бесконечен, даже если брать только недавнюю историю. Отказы ПО вносили сумятицу в работу банков, авиакомпаний, и множества технологических гигантов. Эти отказы обычно возникают, когда дефект, который должны были поймать в ходе разработки, попадает к конечному пользователю. Развитие мышления, которое концентрируется на неудачах в ходе разработки продукта, обычно повышает ваши шансы как тестировщика на нахождение ожидаемого или связанного с ним отказа в продукте.

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

Признайте, что вы не найдете абсолютно все баги (Уроки 9 и 10)

Многие современные приложения похожи на живые организмы. Когда они созданы, они становятся самоорганизующимися системами, имеющими все необходимые характеристики живого существа, включая собственную внутреннюю логику, или, можно сказать, клеточную структуру. Все подобные системы имеют явные и неявные уязвимости, часть которых может внедриться в ходе разработки. Другие уязвимости могут возникнуть в ходе специфических сценариев, в ходе которых происходит обмен информацией или ввод данных. Вне зависимости от того, сколько усилий вы прилагаете, вы никогда не узнаете всего, что может пойти не так в ПО.

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

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

Поймите, что "оно работает" на самом деле значит "оно вроде бы до какой-то степени соответствует какому-то требованию" (Урок 34)

Сообщая о "статусе качества" приложения, тестировщик часто говорит "Я это тестировал, оно работает". Это может разнообразными способами ввести вашу команду или заинтересованных лиц в заблуждение, потому что "оно работает" – само по себе расплывчатое утверждение. К примеру, вы можете подразумевать, что приложение работает, как задумано. Но это не сообщает вашей аудитории об условиях, при которых приложение работает. Это также не означает, что оно будет хорошо работать в руках ваших пользователей.

Напротив, пессимистичный склад ума может заставить вас задуматься, что на самом деле значит "оно работает". Это может сподвигнуть вас задать вопросы вроде "Что именно работает? Какая часть продукта наблюдалась? Какая функциональность или тип тестирования выполнялись? Насколько успешен и до какой степени был тест? При каких условиях или обстоятельствах приложение работает", и т. д., а также попытаться найти на них ответы. Эти ответы помогут вам перевести выражение "оно работает" в "оно вроде бы до какой-то степени соответствует определенному требованию".

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

Помните – вас сложнее обмануть, если вы помните, что вы дурак (Урок 40)

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

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

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

Тестировщик как защищающийся пессимист

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

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

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

И, наконец, пессимизм или пессимистичное отношение к качеству – необязательно негативная черта. Это также не должно считаться отрицательной характеристикой, особенно в тестировании. Однако вы можете выводить из себя множество разработчиков и заинтересованных лиц, если всегда приходите с плохими новостями о воспринимаемом качестве продукта – как, так сказать, "пессимист". Несмотря на это, значение имеет только то, что вы делаете со своим пессимизмом, и как вы сообщаете о результатах пессимистичного подхода вашей команде. Ценность знания о проблемах продукта, их своевременного исправления до релиза невозможно переоценить.

Предупреждение: эту статью нельзя никаким образом воспринимать как попытку дать полноценный анализ затронутой темы или упомянутых концепций – она просто дает обзор способов, которыми защитный пессимизм может помочь тестировщикам улучшить тестирование. Хорошее тестирование, безусловно, требующий напряжения интеллектуальный процесс, сложный и многогранный. Следовательно, важно отметить, что "ценность любой тест-практики или концепции, в том числе упомянутых в статье, зависит от их контекста". Контекст имеет значение: ценность вашего пессимизма будет определяться только его контекстом.

Дополнительная литература