Наташа, ты возражаешь против моего «радикального совета», про который я написал во введении, или против основного тезиса автора переведённой заметки — «избавляйтесь в описаниях тестов от избыточного текста, несущественных подробностей, очевидных вещей, словесного мусора и прочих игнорируемых элементов»?
Где в заметке упоминается слово «exploratory» (кроме моего введения) или «лучшая практика»? :)
Но раз пошёл об этом разговор, думаю, следует уточнить контекст спора, то есть пояснить, что я подразумеваю под тестированием методом свободного поиска (aka explotatory testing), чтобы дискуссия не напоминала известную поговорку про дядьку в Киеве и бузину в огороде.
Тестирование методом свободного поиска — вещь иного порядка, нежели вопрос о том, писать тесты или не писать. Взгляни на «официальное» определение, сформулированное Кемом Канером — там нет никаких упоминаний про конкретные техники. Это своего рода манифест:
“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”
Отличие scripted от exploratory по своей сути заключается не в использовании (или неиспользовании) тех или иных техник, приёмов, инструментов, а в следовании инструкциям (как завещали наши отцы и деды).
Так вот, оптимизация тестов (ужимание, выкидывание ненужных, рефакторинг) — это характерные признаки наличия элементов exporatory. Что не мешает, конечно, иметь документы, содержащие описания тестов, причём иногда достаточно подробные. Настолько подробные, насколько это необходимо, но не более того.
Людям свойственно придумывать символические системы и общаться, используя их. Этакие надстройки над языком (который тоже символическая система, разумеется, но достаточно общая, хотя и на этом уровне возникают проблемы взаимонепонимания).
«Докачка» — элемент символической системы, которая является частью культуры отдельно взятой организации. В другом месте слово «докачка» может пониматься иначе, они говорят на своём диалекте русского языка.
Когда человек приходит в организацию, можно либо дать ему словарь, где описан ваш диалект (интересно, существуют ли у кого-нибудь такие словари?), либо он выучит диалект, общаясь с живыми носителями. Они объяснят ему, что такое «докачка». А он потом объяснит тем, кто придёт после него.
Альтернатива — не использовать надстройку, говорить и писать только на «базовом языке». Увы, это замедляет коммуникацию.
Так что не волнуйтесь, это нормально. Главное не утратить преемственности носителей культуры, чтобы всегда был кто-то, кто может объяснить, что значит «докачка».
Не сочтите меня за КО, но раз непонятки возникают, считаю нужным написать нижеследующее.
Пояснение для нетестировщиков: описание теста и описание дефекта — это два разных типа артефактов :)
Тестировщик сначала придумывает, какой тест он будет делать, потом его выполняет, в процессе выполнения находит дефект и пишет описание дефекта. Подробно пишет — что конкретно вводил, в какой конкретно последовательности, куда при этом ещё нажимал. Логи прикладывает, скриншоты, видео.
А описание теста — это описание того, что он в самом начале придумал: «проверить, как файл сохраняется в защищенную от записи папку», «проверить, нет ли SQL-инъекции в модуле просмотра заказов», «проверить, запоминает ли визард данные, введённые на предыдущих шагах, если вернуться назад» и т.д. Хорошему тестировщику конкретика не нужна, ему нужны идеи, а детали он сам в процессе выполнения теста придумает.
Вы описываете тесты в видео-формате? Это большая редкость, я в своей практике встречался с таким лишь единожды. Да и то в оригинале это были не совсем тесты, а «обучающее видео», но его приспособили для обучения новых тестировщиков, приходящих в проект — в тесте было написано «выполнить такой-то сценарий, см. видео».
Но вообще-то видео ещё хуже, чем текст — чтобы понять идею, заложенную в текст, его можно прочитать быстро по диагонали, а видео придётся смотреть от начала и до конца.
А вот картинки, действительно, могут работать весьма хорошо. Причём не только скриншоты, но и диаграммы, схемы, майнд-мапы.
Рефакторинг рулит, однозначно. Хотя, конечно, лучше сразу писать код понятно и компактно :)
Однако у описаний тестов (не автоматизированных) есть существенное отличие от кода — они интерпретируются человеком, который невероятно крут по своим возможностям — он может интерпретировать идеи, а не только инструкции!
Это Вы говорите про описания дефектов, а заметка — про описания тестов.
Да, при описании дефекта нужно больше деталей, потому что это описание конкретного события.
В отличие от описания теста, которое конкретикой обрастает только в момент выполнения.
Вы, видимо не тестировщик? :)
Заметки отличаются не только названием, но и содержанием.
В начале этой заметки написано, что она является продолжением той.
Они предложили такое объяснение:
Портной, пришивая карман, совершил ошибку, чуть-чуть не доведя шов до конца, в результате карман имеет дефект в виде дырки в углу, и «у пользователя периодически случаются сбои в работе кармана» — в дырку что-нибудь вываливается :)
Вы верите в то, что менеджерами рождаются, что ими становятся только избранные, что у них встроенный зуб мудрости? Или Вы думаете, что они при посвящении в менеджеры проходят специальную инициацию, у них открывается третий глаз и они начинают понимать?
Большинство ИТ-менеджеров — бывшие программисты или аналитики или тестировщики. Редко встречаются такие, кто попробовал много разных профессий. Даже менеджерами они становятся не всегда в результате личного стремления, порой это случается просто в силу обстоятельств (кто-то должен был взять на себя ответственность за проект, выискался самый инициативный или совестливый — он и стал менеджером, вуаля!)
Менеджер тоже порой «закруживается», причём иногда больше, чем программисты и тестировщики.
Поэтому ожидать от менеджера, что он сам всё поймёт, потому что он «должен» — по меньшей мере нечестно.
Несколько раз прочитал коммент, но суть не уловил. Попробую уточнить.
Вы имеете в виду, что предложенные советы звучат красиво, но на практике неприменимы?
Ага, я когда весной у него на тренинге побывал — моему ЧСВ тоже пришлось серьёзно потесниться. Вроде у меня и опыта за плечами немало, и сам уже тренинги провожу, но слушал с раскрытым ртом. Например, тестирование методом чёрного ящика он демонстрирует при помощи показа фокусов — предлагает разгадать устройство реквизита. Блин, тоже хочу научиться!
По поводу блондинок вспомнилось. На одном из тренингов я давал задание придумать объяснение на понятном примере разницы между тремя понятиями — ошибка, дефект и сбой. Так вот, там была группка из трёх замечательных барышень, которые после непродолжительного обсуждения заявили, что они им сложно объяснить это на примере софта, зато они легко могут это объяснить на примере пришивания кармана на платье :)
Документация есть средство поддержания коммуникации, позволяющее передавать некоторую информацию без искажений а) без искажений во времени, б) с возможностью многократного воспроизведения (это важно как для одного человека — можно перечитывать многократно, так и для большого количества людей — передача информации таким образом масштабируется).
1) Есть и другие способы передачи информации, которые тоже обладают указанными двумя характеристиками.
2) Документация всегда неполна, поэтому аберрации сознания просто переходят в область интерпретации текста.
Можно, чтоб не писать. В фразе «для этого еще и проектная документация должна быть нормальной» вместо слова «документация» следует читать «коммуникация».
Где в заметке упоминается слово «exploratory» (кроме моего введения) или «лучшая практика»? :)
Но раз пошёл об этом разговор, думаю, следует уточнить контекст спора, то есть пояснить, что я подразумеваю под тестированием методом свободного поиска (aka explotatory testing), чтобы дискуссия не напоминала известную поговорку про дядьку в Киеве и бузину в огороде.
Тестирование методом свободного поиска — вещь иного порядка, нежели вопрос о том, писать тесты или не писать. Взгляни на «официальное» определение, сформулированное Кемом Канером — там нет никаких упоминаний про конкретные техники. Это своего рода манифест:
“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”
Отличие scripted от exploratory по своей сути заключается не в использовании (или неиспользовании) тех или иных техник, приёмов, инструментов, а в следовании инструкциям (как завещали наши отцы и деды).
Так вот, оптимизация тестов (ужимание, выкидывание ненужных, рефакторинг) — это характерные признаки наличия элементов exporatory. Что не мешает, конечно, иметь документы, содержащие описания тестов, причём иногда достаточно подробные. Настолько подробные, насколько это необходимо, но не более того.
«Докачка» — элемент символической системы, которая является частью культуры отдельно взятой организации. В другом месте слово «докачка» может пониматься иначе, они говорят на своём диалекте русского языка.
Когда человек приходит в организацию, можно либо дать ему словарь, где описан ваш диалект (интересно, существуют ли у кого-нибудь такие словари?), либо он выучит диалект, общаясь с живыми носителями. Они объяснят ему, что такое «докачка». А он потом объяснит тем, кто придёт после него.
Альтернатива — не использовать надстройку, говорить и писать только на «базовом языке». Увы, это замедляет коммуникацию.
Так что не волнуйтесь, это нормально. Главное не утратить преемственности носителей культуры, чтобы всегда был кто-то, кто может объяснить, что значит «докачка».
Не сочтите меня за КО, но раз непонятки возникают, считаю нужным написать нижеследующее.
Пояснение для нетестировщиков: описание теста и описание дефекта — это два разных типа артефактов :)
Тестировщик сначала придумывает, какой тест он будет делать, потом его выполняет, в процессе выполнения находит дефект и пишет описание дефекта. Подробно пишет — что конкретно вводил, в какой конкретно последовательности, куда при этом ещё нажимал. Логи прикладывает, скриншоты, видео.
А описание теста — это описание того, что он в самом начале придумал: «проверить, как файл сохраняется в защищенную от записи папку», «проверить, нет ли SQL-инъекции в модуле просмотра заказов», «проверить, запоминает ли визард данные, введённые на предыдущих шагах, если вернуться назад» и т.д. Хорошему тестировщику конкретика не нужна, ему нужны идеи, а детали он сам в процессе выполнения теста придумает.
Но вообще-то видео ещё хуже, чем текст — чтобы понять идею, заложенную в текст, его можно прочитать быстро по диагонали, а видео придётся смотреть от начала и до конца.
А вот картинки, действительно, могут работать весьма хорошо. Причём не только скриншоты, но и диаграммы, схемы, майнд-мапы.
Однако у описаний тестов (не автоматизированных) есть существенное отличие от кода — они интерпретируются человеком, который невероятно крут по своим возможностям — он может интерпретировать идеи, а не только инструкции!
Да, при описании дефекта нужно больше деталей, потому что это описание конкретного события.
В отличие от описания теста, которое конкретикой обрастает только в момент выполнения.
Заметки отличаются не только названием, но и содержанием.
В начале этой заметки написано, что она является продолжением той.
Портной, пришивая карман, совершил ошибку, чуть-чуть не доведя шов до конца, в результате карман имеет дефект в виде дырки в углу, и «у пользователя периодически случаются сбои в работе кармана» — в дырку что-нибудь вываливается :)
Большинство ИТ-менеджеров — бывшие программисты или аналитики или тестировщики. Редко встречаются такие, кто попробовал много разных профессий. Даже менеджерами они становятся не всегда в результате личного стремления, порой это случается просто в силу обстоятельств (кто-то должен был взять на себя ответственность за проект, выискался самый инициативный или совестливый — он и стал менеджером, вуаля!)
Менеджер тоже порой «закруживается», причём иногда больше, чем программисты и тестировщики.
Поэтому ожидать от менеджера, что он сам всё поймёт, потому что он «должен» — по меньшей мере нечестно.
Вы имеете в виду, что предложенные советы звучат красиво, но на практике неприменимы?
1) Есть и другие способы передачи информации, которые тоже обладают указанными двумя характеристиками.
2) Документация всегда неполна, поэтому аберрации сознания просто переходят в область интерпретации текста.