Что пишут в блогах

Подписаться

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

Конференции

Что пишут в блогах (EN)

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

Про инструменты

Лучшие вакансии

.
Как дела с тестированием?
04.10.2018 12:40

Автор: Майкл Болтон (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. Эти ярлыки не особенно важны, если люди осознают, что проблемы могут мешать тестированию, и довод