Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2018/02/how-is-the-testing-going/

Перевод: Ольга Алифанова

Недавно я опубликовал вот такой твит:

"С тестированием все путем". Значит ли это, что продукт в хорошей форме, или что мы добились хорошего покрытия, или нашли много багов? "С тестированием все очень плохо". Продукт хорош? Тестирование заблокировано? Мы ошибочно ставим много багов?

- Майкл Болтон (@michaelbolton), 31 января 2018

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

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

В курсе Rapid Software testing мы делаем упор на важности трехкомпонентной тест-истории, где каждый из компонентов – история сама по себе.

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

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

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

Очень важно рассказать о том, что мы покрыли, тестируя. Куда важнее может быть упоминание того, что мы еще не покрыли, или не будем покрывать вовсе, пока что-либо не изменится. Непокрытые области пространства тестирования могут скрывать куда худшие баги и риски, нежели те, о которых мы уже знаем.

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

Мы должны рассказать историю о том, насколько хорошо наше тестирование. Если вторая линия тест-истории поддерживает первую, то третья поддерживает вторую. Наша задача – описать, почему проведенное тестирование – самое замечательное из того, что мы могли сделать. А если это не так, то нужно объяснить, до какой степени это не так, почему это не так, и что нам нужно (или что мы рекомендуем сделать), чтобы улучшить ситуацию.

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

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

Когда наступит тот печальный миг, когда менеджер спросит "Почему вы не нашли этот баг?", я хочу иметь возможность дать разумное объяснение. Во-первых, что не только я не заметил баг: никто в команде его не заметил. Во-вторых, я хочу быть в состоянии напомнить менеджеру, что во время разработки мы делали что могли, и совместно решали, на что обращать внимание в плане тестирования и тестируемости. Без обсуждений связанных с тестированием проблем в процессе разработки эти решения будут плохо информированными. А если мы пропустили баги, я хочу быть уверен, что мы извлекли из этих ошибок полезный урок. Допущение того, что баги скрылись от нас, может быть такой ошибкой.

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

Менеджеры, если вам нужен отчет от тестировщика, и вы не хотите быть сбитым с пути, спросите о всех трех линиях сюжета. "Как дела с продуктом? Как ты это узнал? Что ты покрыл, и какие важные тесты еще не проводились? Почему мы должны удовлетвориться проведенным тестированием? Есть ли у нас поводы для волнения? Что мешает тебе тестировать наилучшим образом? Как мы можем ускорить тестирование, упростить его, сделать его всеобъемлющим?"

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

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