Продолжая описывать элементарные вещи, которым учила меня работа, хочется сейчас вспомнить вот какую: когда-то я поняла, как полезно понимать смысл того, что ты тестируешь. Кажется, что это естественно и само собой разумеется, но я не перестаю удивляться, как часто люди понятия не имеют, над чем же по сути они работают, или что означают те алгоритмы, которые они разрабатывают или проверяют - поэтому позволю себе немного поразглагольствовать на эту простую тему :)
Часто доступная документация к проекту является чем-то техническим - описанием элементов графического интерфейса, их соответствиями полям базы данных, зависимостями между данными, алгоритмами расчётов и т.п. То же, что стоит за всем этим, каким обычным процессам нормальной человеческой жизни всё это соответствует - если и описывается, то часто в разработку и тестирование даже не предоставляется. Вроде как - а и зачем? Ведь для разработки и тестирования вполне достаточно знать, что если поле-1 принимает значение "А", то поле-2 должно принять значение "Б". И многие так и работают, не задумываясь о том, что вообще значат эти поля, эти значения, и почему между ними должна быть именно такая зависимость. А на самом деле задуматься может быть весьма полезно.
Больше всего подобная проблема проявляется, когда работа идёт с НЕ русскоязычными проектами. Тогда за непонятными словами часто видятся просто какие-то объекты, которые принимают какие-то статусы, реагируя на какие-то события.
Но стоит только хотя бы перевести названия кнопок, статусов и объектов на русский язык и немного подумать - как "картинка оживает": мы перестаём видеть перед собой просто формочку с объектом, кнопочками и отображаемыми статусами, но видим уже историю - например, человека, которого могут пригласить на какое-то собрание, и который может значиться в системе как приглашённый или не приглашённый, или чьё приглашение должно быть изменено.
И это как минимум помогает сделать тестирование легче, ведь чем отслеживать изменение статусов по алгоритму, гораздо проще видеть за этим осмысленные сценарии и следовать им при проверке. Мы не просто запоминаем, что вместе с изменением статуса объекта-1 должен измениться статус объекта-2, но понимаем, что если отменилось собрание, то должно отмениться и приглашение на это собрание. Мы не просто проверяем, как статус "А" переходит в статус "Б", а мы уже моделируем историю, как человека пригласили, но потом выяснили, что ошиблись, и изменили приглашение на другое время - и лучше понимаем, на что подобные изменения могут повлиять. Тестирование может стать и более осмысленным, и более реалистичным, и более полезным.
Более того - когда мы понимаем, какие реальные процессы стоят за алгоритмами, мы ещё и в алгоритме можем найти ошибку. Ведь мы же уже не просто видим, как меняются признаки каких-то объектов, но замечаем, что при изменении времени собрания не учтено изменение времени в приглашениях на это собрание.
Так что попытки увидеть реальную жизнь за тестируемым приложением и лучше понять предметную область - могут быть весьма полезными в тестировании. Забавно, но даже самой себе иногда приходится об этом напоминать :)
Собственно, для этого и придумали Use Cases. Не надо переводить с английского на русский. Надо понимать что это значит для пользователя и как он с этим работает или может работать. И UML-ные UseCase диаграммы поэтому и считаются одними из самых полезных.
ОтветитьУдалитьРазумеется, Use cases - это то, что сразу приходит на ум, если говорить о "физическом смысле" приложения. Вот только, во-первых, они далеко не всегда доступны. А во-вторых, даже наличие юскейсов не гарантирует понимание, например, потому, что предметная область может быть очень малознакомой.
ОтветитьУдалитьА переводить - тоже всё-таки стоит О-) Наверное, с англоязычными проектами всё проще, т.к. большинство людей в нашей сфере его понимает. Но, допустим, работая с немецким проектом, можно годами использовать какие-то термины, знать, как объекты, скрывающиеся за ними, проживают в проекте полный свой жизненный цикл и взаимодействуют с другими объектами с таким же непонятным названиями - и не представлять, что же это всё-таки значит. Например, какой-либо Verteilungstermin - это не просто длинное слово и объект, необходимый для регистрации каких-то расчётов, а это судебное заседание, посвящённое распределению средств, вырученных от продажи имущества на аукционе :)
В XP есть такая хорошая штука как пользовательские истории (user stories), мне кажется, они как раз более близки к тому, о чем Вы говорите, нежели use cases. На самом деле я практически не встречала их использования, а очень жаль. Особенно это и, правда, полезно для тестировщиков. Мы часто тестируем РАЗНЫЕ приложения, используя практически одни и те же методы, совершенно не задумываясь, что "целевая аудитория" у этих приложений может быть совершенно различная. Даже одно приложение может быть протестировано с точки зрения разного рода пользователей. Мы пробовали применить эту практику к играм. Обычно у такого рода приложений очень широкий спектр пользователей от мала до велика, от опытных до не очень, и еще с кучей возможных различий. Исходя из этого можно разрабатывать сценарии, ориентированные на работу конкретного типа пользователей, а не некоего абстрактного, коему зачастую большинство из нас уподобляется.
ОтветитьУдалитьАнонимный (или скорее Анонимная :) ), спасибо за комментарий.
ОтветитьУдалитьТо, о чём вы говорите - наверное, немножко не то, о чём я в своей заметке писала, однако это, пожалуй, логичное продолжение.
Т.е. как минимум тестеру стоит подняться выше уровня "проверяю по алгоритму, и мне неважно, о чём реально идёт речь". А дальше - чем лучше понимаешь приложение и то, что оно должно делать - тем лучше и для работы. И понять, кто будут реальные пользователи и как они будут использовать приложение - безусловно полезно.
А про user stories надо мне будет почитать поподробнее, спасибо за наводку :)