Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Не встречала ни одного тестера, который бы был слишком велеречив в составлении описаний. Наоборот — обычно описание состоит из «неправильный параметр X», а нюансы типа «для какой записи», «при каких действиях до того», «а какой правильный и откуда берется» и т.д. — приходится вытягивать клещами в личной беседе.
Хорошо структурированный код с понятным именованием методов и переменных в 90% случаев заменяет комментарии, даже если это код тестов. «Ужимание» в вашей терминологии — есть по сути рефакторинг кода теста с целью улучшения его читабельности.
Рефакторинг рулит, однозначно. Хотя, конечно, лучше сразу писать код понятно и компактно :)
Однако у описаний тестов (не автоматизированных) есть существенное отличие от кода — они интерпретируются человеком, который невероятно крут по своим возможностям — он может интерпретировать идеи, а не только инструкции!
Однако у описаний тестов (не автоматизированных) есть существенное отличие от кода — они интерпретируются человеком, который невероятно крут по своим возможностям — он может интерпретировать идеи, а не только инструкции!
Хотя, конечно, лучше сразу писать код понятно и компактно :)
Нет предела совершенству ) А если серьезно код всегда будет видоизменяться в той или иной степени, если проект живой.
он может интерпретировать идеи
В целях сокращения описаний и текста у нас часто используются скриншоты или видео, иллюстрирующие проблему или как воспроизвести тест ;) Картинки идеи доносят лучше чем текст.
Вы описываете тесты в видео-формате? Это большая редкость, я в своей практике встречался с таким лишь единожды. Да и то в оригинале это были не совсем тесты, а «обучающее видео», но его приспособили для обучения новых тестировщиков, приходящих в проект — в тесте было написано «выполнить такой-то сценарий, см. видео».
Но вообще-то видео ещё хуже, чем текст — чтобы понять идею, заложенную в текст, его можно прочитать быстро по диагонали, а видео придётся смотреть от начала и до конца.
А вот картинки, действительно, могут работать весьма хорошо. Причём не только скриншоты, но и диаграммы, схемы, майнд-мапы.
Но вообще-то видео ещё хуже, чем текст — чтобы понять идею, заложенную в текст, его можно прочитать быстро по диагонали, а видео придётся смотреть от начала и до конца.
А вот картинки, действительно, могут работать весьма хорошо. Причём не только скриншоты, но и диаграммы, схемы, майнд-мапы.
Нет конечно, я говорю об идее, как ее можно донести без утомительного описания в тексте. Короткое видео (буквально несколько секунд), показывающее цель или проблему порой гораздо информативнее для донесения идеи.
Вы правы, но даже это далеко не всегда помогает програмистам понять, где в коде и что нужно фиксить. Тогда они приходят к тестировщикам, которые на процент больше могут знать функциональность (да, это частое явление) и задают наводящие вопросы.
Тоже единожды встречал видео как указатель. Короткий ролик полезен, но применяется не очень часто, поскольку может быть достаточно текстовых стэпов и скриншота с логом. Тем более что не всегда заказчики любят большие вложения =)
Тоже единожды встречал видео как указатель. Короткий ролик полезен, но применяется не очень часто, поскольку может быть достаточно текстовых стэпов и скриншота с логом. Тем более что не всегда заказчики любят большие вложения =)
Походу тут все путают описание теста и проблемы.
Сам удивляюсь…
Не сочтите меня за КО, но раз непонятки возникают, считаю нужным написать нижеследующее.
Пояснение для нетестировщиков: описание теста и описание дефекта — это два разных типа артефактов :)
Тестировщик сначала придумывает, какой тест он будет делать, потом его выполняет, в процессе выполнения находит дефект и пишет описание дефекта. Подробно пишет — что конкретно вводил, в какой конкретно последовательности, куда при этом ещё нажимал. Логи прикладывает, скриншоты, видео.
А описание теста — это описание того, что он в самом начале придумал: «проверить, как файл сохраняется в защищенную от записи папку», «проверить, нет ли SQL-инъекции в модуле просмотра заказов», «проверить, запоминает ли визард данные, введённые на предыдущих шагах, если вернуться назад» и т.д. Хорошему тестировщику конкретика не нужна, ему нужны идеи, а детали он сам в процессе выполнения теста придумает.
Не сочтите меня за КО, но раз непонятки возникают, считаю нужным написать нижеследующее.
Пояснение для нетестировщиков: описание теста и описание дефекта — это два разных типа артефактов :)
Тестировщик сначала придумывает, какой тест он будет делать, потом его выполняет, в процессе выполнения находит дефект и пишет описание дефекта. Подробно пишет — что конкретно вводил, в какой конкретно последовательности, куда при этом ещё нажимал. Логи прикладывает, скриншоты, видео.
А описание теста — это описание того, что он в самом начале придумал: «проверить, как файл сохраняется в защищенную от записи папку», «проверить, нет ли SQL-инъекции в модуле просмотра заказов», «проверить, запоминает ли визард данные, введённые на предыдущих шагах, если вернуться назад» и т.д. Хорошему тестировщику конкретика не нужна, ему нужны идеи, а детали он сам в процессе выполнения теста придумает.
«Если тестировщики игнорируют какие-то предложения, или идеи, или шаги, или целые тесты — просто выбросьте их.»
Поддерживаю (в пределах разумного). Я бы дополнил — а если тестировщики, как роботы, слепо следуют пошаговой инструкции, ни на шаг не отступая, то выбросите таких тестировщиков.
Мы строим тесты в основном на основе требований ПО, чтобы максимально покрыть тестами все возможные ситуации + некоторые спец тесты для покрытия кода. Беда в том, что коллектив не очень большой и писать сценарии тестов приходится самим программистам, и не всё можно автоматизировать. Вот, допустим, где-то пользователь должен сохранить данные в файл. Я предпочёл бы написать просто: «проверить сохранение в файл там-то». Хороший думающий тестировщик проверит при этом: как ведёт себя программа при отмене диалога, при записи файла с тем же именем, при записи на защищённый от записи или заполненный диск, и т.д. и т.п. Он достроит самостоятельно все возможные ситуации. От такого тестировщика и баг-репорты — сплошное удовольствие: сделал то-то и то-то, получил то-то, а ожидалось вот что. Однако встречаются тестировщики, которые работают как «роботы». Им просто необходимо разжёвывать тесты до каждого щелчка мыши, иначе ничего оттестировано не будет. Как правило после таких тестов отловленных багов — кот наплакал при меньшем покрытии кода (при том, что дорогостоящий программист убил неделю на Mercury, а тестировщик за полдня нащёлкал все тесты и бодро отчитался о проделанной работе короткими Pass/Fail безо всяких деталей).
Поддерживаю (в пределах разумного). Я бы дополнил — а если тестировщики, как роботы, слепо следуют пошаговой инструкции, ни на шаг не отступая, то выбросите таких тестировщиков.
Мы строим тесты в основном на основе требований ПО, чтобы максимально покрыть тестами все возможные ситуации + некоторые спец тесты для покрытия кода. Беда в том, что коллектив не очень большой и писать сценарии тестов приходится самим программистам, и не всё можно автоматизировать. Вот, допустим, где-то пользователь должен сохранить данные в файл. Я предпочёл бы написать просто: «проверить сохранение в файл там-то». Хороший думающий тестировщик проверит при этом: как ведёт себя программа при отмене диалога, при записи файла с тем же именем, при записи на защищённый от записи или заполненный диск, и т.д. и т.п. Он достроит самостоятельно все возможные ситуации. От такого тестировщика и баг-репорты — сплошное удовольствие: сделал то-то и то-то, получил то-то, а ожидалось вот что. Однако встречаются тестировщики, которые работают как «роботы». Им просто необходимо разжёвывать тесты до каждого щелчка мыши, иначе ничего оттестировано не будет. Как правило после таких тестов отловленных багов — кот наплакал при меньшем покрытии кода (при том, что дорогостоящий программист убил неделю на Mercury, а тестировщик за полдня нащёлкал все тесты и бодро отчитался о проделанной работе короткими Pass/Fail безо всяких деталей).
Есть нюанс — это может не работать с новыми сотрудниками, т.к. сжатые мысли понимаются зачастую достаточно фривольно и ведут к достаточно низкому уровню покрытия тестами фичей. А в клинических случаях — «написано мало, значит можно забить».
И ещё может встать проблема — определить грамотные границы «ужимания». В последнее время очень часто вместо каких-то предложений и описания юзкейсов начинаются писать отдельные слова, вроде «докачка» или «иконки». Ты-то помнишь о том, что это такое, и какие-то сценарии держишь в голове. Но что достанется тем, кто придет после нас? :)
И ещё может встать проблема — определить грамотные границы «ужимания». В последнее время очень часто вместо каких-то предложений и описания юзкейсов начинаются писать отдельные слова, вроде «докачка» или «иконки». Ты-то помнишь о том, что это такое, и какие-то сценарии держишь в голове. Но что достанется тем, кто придет после нас? :)
Людям свойственно придумывать символические системы и общаться, используя их. Этакие надстройки над языком (который тоже символическая система, разумеется, но достаточно общая, хотя и на этом уровне возникают проблемы взаимонепонимания).
«Докачка» — элемент символической системы, которая является частью культуры отдельно взятой организации. В другом месте слово «докачка» может пониматься иначе, они говорят на своём диалекте русского языка.
Когда человек приходит в организацию, можно либо дать ему словарь, где описан ваш диалект (интересно, существуют ли у кого-нибудь такие словари?), либо он выучит диалект, общаясь с живыми носителями. Они объяснят ему, что такое «докачка». А он потом объяснит тем, кто придёт после него.
Альтернатива — не использовать надстройку, говорить и писать только на «базовом языке». Увы, это замедляет коммуникацию.
Так что не волнуйтесь, это нормально. Главное не утратить преемственности носителей культуры, чтобы всегда был кто-то, кто может объяснить, что значит «докачка».
«Докачка» — элемент символической системы, которая является частью культуры отдельно взятой организации. В другом месте слово «докачка» может пониматься иначе, они говорят на своём диалекте русского языка.
Когда человек приходит в организацию, можно либо дать ему словарь, где описан ваш диалект (интересно, существуют ли у кого-нибудь такие словари?), либо он выучит диалект, общаясь с живыми носителями. Они объяснят ему, что такое «докачка». А он потом объяснит тем, кто придёт после него.
Альтернатива — не использовать надстройку, говорить и писать только на «базовом языке». Увы, это замедляет коммуникацию.
Так что не волнуйтесь, это нормально. Главное не утратить преемственности носителей культуры, чтобы всегда был кто-то, кто может объяснить, что значит «докачка».
За перевод, конечно, плюс. Однако…
Моя практика общения с тестерами (и даже немного координации их работы, да) говорит, что степень подробности тестов прямо пропорциональна количеству тестеров, которые потенциально будут гонять тесты.
Поясню.
Есть команда инженеров — 100 человек, из которых 40 девелоперов, 40 тестеров, и 20 других спецов — все разной квалификации — от студентов до старых прошаренных бойцов.
Из 20 тестеров, например, 5 — пишут тесты и все 20 потом прогоняют их. Прогон тестов может быть отдан любому. Соответственно, во избежание разночтений, тесты пишутся подробно — на случай если гонять будут новички. Конечно, потом и новички будут гонять их, даже не читая описания. Однако — лучше перебдеть, чем недобдеть.
Противоположный пример — команда 6 человек, 2 из которых — тестеры. Оба друг друга знают, оба тесты и пишут, и гоняют. Оба — профи. Понятно, что описывать тест подробно смысла нет, важен посыл и направление тестирования, качество тестирования всё равно будет отличным. И здесь — да, краткость только приветствуется.
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Моя практика общения с тестерами (и даже немного координации их работы, да) говорит, что степень подробности тестов прямо пропорциональна количеству тестеров, которые потенциально будут гонять тесты.
Поясню.
Есть команда инженеров — 100 человек, из которых 40 девелоперов, 40 тестеров, и 20 других спецов — все разной квалификации — от студентов до старых прошаренных бойцов.
Из 20 тестеров, например, 5 — пишут тесты и все 20 потом прогоняют их. Прогон тестов может быть отдан любому. Соответственно, во избежание разночтений, тесты пишутся подробно — на случай если гонять будут новички. Конечно, потом и новички будут гонять их, даже не читая описания. Однако — лучше перебдеть, чем недобдеть.
Противоположный пример — команда 6 человек, 2 из которых — тестеры. Оба друг друга знают, оба тесты и пишут, и гоняют. Оба — профи. Понятно, что описывать тест подробно смысла нет, важен посыл и направление тестирования, качество тестирования всё равно будет отличным. И здесь — да, краткость только приветствуется.
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Моя практика общения с тестерами (и даже немного координации их работы, да) говорит, что степень подробности тестов прямо пропорциональна количеству тестеров, которые потенциально будут гонять тесты.
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Эти два утверждения не очень связаны между собой.
Что будет, если у нас те же 40 тестировщиков, но высококвалифицированные? Согласно второму тезису можно писать мало, а согласно первому — много.
А что, если у нас всего 2 низкоквалифицированных тестировщика?
Может быть, Вы хотели сказать своим комментарием, что чем больше тестировщиков, тем выше вероятность того, что среди них будут низкоквалифицированные?
Или хотя бы разрыв в квалификации будет достаточно большим?
Второе, скорее всего, верно. НО! Написание инструкций квалифицированными тестировщиками и исполнение их неквалифицированными не способствует росту квалификации последних. Поэтому я считаю такой подход пагубным, он консервирует существующее неблагоприятное положение дел, не решая проблему низкой квалификации части сотрудников.
В общем, итог — количество слов в описании теста обратно пропорционально потенциальной квалификации тестера.
Эти два утверждения не очень связаны между собой.
Что будет, если у нас те же 40 тестировщиков, но высококвалифицированные? Согласно второму тезису можно писать мало, а согласно первому — много.
А что, если у нас всего 2 низкоквалифицированных тестировщика?
Может быть, Вы хотели сказать своим комментарием, что чем больше тестировщиков, тем выше вероятность того, что среди них будут низкоквалифицированные?
Или хотя бы разрыв в квалификации будет достаточно большим?
Второе, скорее всего, верно. НО! Написание инструкций квалифицированными тестировщиками и исполнение их неквалифицированными не способствует росту квалификации последних. Поэтому я считаю такой подход пагубным, он консервирует существующее неблагоприятное положение дел, не решая проблему низкой квалификации части сотрудников.
> Может быть, Вы хотели сказать своим комментарием, что чем больше тестировщиков, тем выше вероятность того, что среди них будут низкоквалифицированные?
Перечитав оба коммента, получилось сформулировать:
Чем больше тестеров, тем больше вероятность появлявления разночтения одних и тех же тестов. Соответственно, при одном и том же количестве тестеров, больше подробностей — меньше разночтений, меньше подробностей — и тут остается только уповать на взаимопонимание и высокую квалификацию исполнителей.
Если команда большая, но исполнители — с хорошей квалификацией, то проблем с уменьшением детализации не вижу, согласен.
Перечитав оба коммента, получилось сформулировать:
Чем больше тестеров, тем больше вероятность появлявления разночтения одних и тех же тестов. Соответственно, при одном и том же количестве тестеров, больше подробностей — меньше разночтений, меньше подробностей — и тут остается только уповать на взаимопонимание и высокую квалификацию исполнителей.
Если команда большая, но исполнители — с хорошей квалификацией, то проблем с уменьшением детализации не вижу, согласен.
Меня всегда удивлял такой подход. Сначала сказать «Я приверженец Context-based тестирования», а через пару минут добавить: «Exploratory лучше всего, чем меньше кейсы тем лучше» и т.д.
Очень похоже на реализацию аджайла в российских компаниях, когда на стендап-митинги собирают как на линейку, участники стоят на вытяжку, а биг-босс шествует как на параде, раздаёт задачи и говорит «У нас аджайл!».
Так и в этой заметке.
Какие у нас тестировщики?
Какой у нас продукт?
Насколько он критичен, это игра или софт, управляющий ядерным боеголовком?
Какая методология разработки?
Какая распределённость команд?
Нужны ли нам тест-кейсы и как много в них нужно писать, зависит от этого и ещё минимум от 10-ка параметров. Не бывает best practices, которые можно переиспользовать в разных командах и проектах. Не бывает «хороших тестов».
Попробуйте, примените советы из статьи, когда вы разрабатываете софт для ВВС США, а команда по тактическим соображениям распределена по трём континентам (пример из личного опыта).
Иногда я организовывала процесс exploratory, потому что это однозначно лучший выбор. Иногда у меня был мега-структурный script-based, и по-другому точно было нельзя. Есть шкала, по которой в рамках контекстной школы мы определяем оптимальный подход. Если диапазон узкий, и мы ограничиваемся какими-то предпочтениями (типа того что «исследовательское тестирование — это хорошо»), то мы НЕ МОЖЕМ выбирать оптимальные подходы.
Надо расширять границы, диапазоны, вариативность используемых техник. Только тогда можно говорить про контекстность.
Очень похоже на реализацию аджайла в российских компаниях, когда на стендап-митинги собирают как на линейку, участники стоят на вытяжку, а биг-босс шествует как на параде, раздаёт задачи и говорит «У нас аджайл!».
Так и в этой заметке.
Какие у нас тестировщики?
Какой у нас продукт?
Насколько он критичен, это игра или софт, управляющий ядерным боеголовком?
Какая методология разработки?
Какая распределённость команд?
Нужны ли нам тест-кейсы и как много в них нужно писать, зависит от этого и ещё минимум от 10-ка параметров. Не бывает best practices, которые можно переиспользовать в разных командах и проектах. Не бывает «хороших тестов».
Попробуйте, примените советы из статьи, когда вы разрабатываете софт для ВВС США, а команда по тактическим соображениям распределена по трём континентам (пример из личного опыта).
Иногда я организовывала процесс exploratory, потому что это однозначно лучший выбор. Иногда у меня был мега-структурный script-based, и по-другому точно было нельзя. Есть шкала, по которой в рамках контекстной школы мы определяем оптимальный подход. Если диапазон узкий, и мы ограничиваемся какими-то предпочтениями (типа того что «исследовательское тестирование — это хорошо»), то мы НЕ МОЖЕМ выбирать оптимальные подходы.
Надо расширять границы, диапазоны, вариативность используемых техник. Только тогда можно говорить про контекстность.
Наташа, ты возражаешь против моего «радикального совета», про который я написал во введении, или против основного тезиса автора переведённой заметки — «избавляйтесь в описаниях тестов от избыточного текста, несущественных подробностей, очевидных вещей, словесного мусора и прочих игнорируемых элементов»?
Где в заметке упоминается слово «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. Что не мешает, конечно, иметь документы, содержащие описания тестов, причём иногда достаточно подробные. Настолько подробные, насколько это необходимо, но не более того.
Где в заметке упоминается слово «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. Что не мешает, конечно, иметь документы, содержащие описания тестов, причём иногда достаточно подробные. Настолько подробные, насколько это необходимо, но не более того.
Автору спасибище огромное за статью! Полностью совпадает с моим видением процесса. Все четко и по полочкам! По-больше бы таких статей на хабре!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Меньше слов — больше смысла