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

Подписаться

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

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

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

.
Встречайте: КОДР
30.10.2024 00:00

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если конкретнее, я читала статью Пола Карвальо, где он упоминал про тест-руководства; эта идея, как мне кажется, схожа с документами, с которыми я постоянно работаю.

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

Кратко о других шаблонах

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


(унаследованный мной образец)

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

Я погуглила другие шаблоны, чтобы выяснить, чем заняты другие тестировщики. По моим ощущениям, тестирование в компании только начинало развиваться, и вкладываться в формальный инструмент тест-менеджмента не было смысла; честно говоря, эти инструменты мне тоже не нравились. К сожалению, оказалось, что все остальные (насколько я могла тогда судить) пользовались Word-документами, похожими на мой, или таблицами Excel. Ретроспективно размышляя, я, возможно, искала не то. Шаблон мне вручили, как «тест-сценарий», и затем я гуглила разницу между кейсами и сценариями, и искала именно такие шаблоны. О сессионном тест-менеджменте я узнала гораздо позже (года через два).

Я решила, что мне надо просто чуть улучшить ситуацию и больше стараться, и вдохновилась найденными в сети шаблонами, создав этот шаблон в Excel.

 

(шаблон тест-кейса в Excel)

Этот формат нравился мне больше, но проблемы никуда не делись.

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

Встречайте КОДР

И так появился КОДР: Как Оно Должно Работать.

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

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

Что, если я столкнусь с чем-то, что выглядит, как баг, но не описано в документации? Мне это игнорировать? «Можно» ли мне свернуть с пути шагов кейса и исследовать вопрос? Это было ужасно!

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

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

 

(шаблон «Как оно должно работать»)

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

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

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

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

Попробуйте и расскажите мне, как оно вам. Шаблон можно найти здесь.

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