Интересная беседа получается. Давайте напишем статью на тему позитивных и негативных сценариев тестирования.
Введение в том, что жизнь — череда выборов, как правило, выбор падает на позитивный сценарий тестирования, а негативные включаются в работу, если начать копать ошибку в позитивном, или по остаточному принципу. Как правило, но не всегда.
Содержательная часть из примеров, ситуаций, позитивных и негативных сценариев, видов тестирования, размеров аудитории продукта.
Вывод, что негативные сценарии сложно проектировать. Тут считаю, что ещё более сложно выполнять негативные сценарии, технически сложные негативные сценарии (имя файла на 2000 символов, картинка на 500 МБайт, особый набор входных параметров для проверки экранирования вывода, ...). И они важны.
Касаемо неоригинальности мысли. Алексей Баранцев, проводя выступление про тестирование по вариантам использования, предложил обсудить эту тему с аналитиками. Так и поступил. Обсудил тему с коллегой аналитиком (Стасом), который не был на выступлении. Выше изложены мысли из нашей с ним беседы, скорее, мысли Стаса, чем мои. И при изложении, видимо, изложил мысли словами Алексея Баранцева. Алексей произвёл впечатление, хорошее было выступление, рад, что вы там были.
Касаемо студентов. На практике не закрепил с ними проектирование тестов. Тесты проектировали, были обсуждения, рассказы, примеры. Не было вовлечения в процесс, когда студент осознанно проектирует, и лишь консультируешь и направляешь. Вовлечение есть, когда студент приходит на производственную практику. От того, думаю, студенты не запомнили тему проектирования. В частности, не осознали роль негативных сценариев при проектировании, которую мы сейчас обсуждаем. Когда студенты придут в вашу компанию, придётся их обучать проектированию тестов. Вклад преподавания в том, что студент сможет сделать осознанный выбор в пользу тестирования и будет ориентироваться в предметной области.
Вероятно, у вас есть некие сомнения по озвученному вопросу. Подкреплю их собственными наблюдениями и наблюдениями коллег.
Пользователь не замечает ошибок программы, пока программа выполняет основной сценарий работы (почти всегда — позитивный) в соответствии с ожиданиями пользователя.
Как только основной сценарий расходится с ожиданиями, внимательность и осторожность пользователя повышаются многократно. И уже становится очень важным, чтобы на негативных сценариях программа вела себя достойно.
Программа не выполняющая основные позитивные сценарии, чаще всего, не нужна пользователю.
Тут уместно задать почти философский вопрос: «А какая же программа нужна пользователю?»
Отвечая на него можно придти к мысли, что если у программы лишь десяток пользователей, основной сценарий работы которых хорошо известен и их ожидания выполняются. То приоритет негативных сценариев снижается. Пользователи даже сами могут сказать разработчику не усложнять и не мудрить, так как их всё устраивает.
Если же у программы сотни и тысячи пользователей, и программа недостаточно проста, чтобы соответствовать ожиданием всех. То просто необходимо уделять внимание негативным сценариям.
Могу привести рассуждение отталкиваясь от тестирования защищённости, стрессового тестирования и их важности.
По роду деятельности отвечаю преимущественно за негативные сценарии, а мои коллеги за позитивные. Если вы занимаетесь промышленной разработкой, то знаете как ищутся более оптимальные способы планирования, организации и выполнения работ по тестированию, чтобы убедиться в выполнении основных сценариев. Основными сценариями занимается большая часть команды, большую часть времени. На негативные сценарии и специализированные виды тестирования выделяют отдельных людей.
Спасибо за хорошую идею. В следующий раз выскажу именно ту мысль, что вы изначально поняли. И посмотрю, поставит ли кто-нибудь её под сомнение.
Поспорю с завершающим слайдом. Совет по повторному использованию кода функциональных тестов не универсален.
Представьте, подготовка БД завершена, контекст настроен, в системе есть контакт с ИД 42.
Функциональный тест: открыть карточку контакта с ИД 42, проверить, что в поле Статус значение Действующий, и что значение можно сменить, убедиться, что в логах не появилось ошибок и предупреждений.
Если распараллелить такой тест на 100 пользователей, то проверим эффективную работу с кешем. А если работа с кешем эффективна, то нагрузка не будет создана. Для того, чтобы кеш испытал шок и рассыпался в пыль, придётся подключить 50 000 пользователей, а имеющееся оборудование может не позволить этого, или бизнесу может быть не интерсна поддержка такого количества, или, вообще, схватим deadlock при разборе логов уже на 10-м потоке.
Если переписать функциональный тест так: открыть карточку произвольного контакта, проверить, что значение в поле Статус можно сменить на случайное и код ответа сервиса — 200 (OK).
То тест становится более подходящим для нагрузки.
Но когда бизнес спросит: «Действующие контакты в новом билде по-прежнему действуют, при открытии карточки в логах нет предупреждений?», — дать положительный ответ, на основе функционально-нагрузочного теста не получится.
Благодарю. Постараюсь учесть выявленные недостатки. Абсолютно согласен с неинформативностью «полуавтоматизированного» тестирования. Все тестирование в IT как минимум такое, и приставка «полу» постоянно смущала. Спасибо, что нашли нужные слова.
Конечно, могу отбиваться. Что смоуки и санити они во входном тесте где-то. И так как, часто люди специализируются. То для автоматизаторов смоуку соотвествует входной тест (на дым) для автоматических тестов. А специалист по ручному функциональному тестированию под входным тестом будет понимать, то что вы понимаете под санити. И оба этих специалиста найдут общий язык, великий и могучий.
Замечу, что зубрить не надо. Цель в том, чтобы обяснить отличия и общности, расставить приоритеты. Например, легко объяснить отличие негативного теста от позитивного. Но важно заметить, что тот же санити будет, почти всегда, позитивным. И если у вас 1000 тестов, и надо оставить только 200 из них, то скорее всего, сокращение вы начнёте с негативных. Потому-то потому-то…
На конкретном месте работы пусть, вообще, не будет применяться понятие негативного теста. Но объяснить, чем такой тест будет отличаться от позитивного, стоит.
Отбиваться можно долго. И в конечном итоге, мы поймём друг друга. Как говорит мой друг: хороший биолог объяснит физику-ядерщику атомное устройство вселенной на тычинках и пестиках. Так и мы увяжем санити с входным тестом.
Чтобы избежать разночтения отмечу, под физикой имел в виду физическую подготовку. Занятия спортом делают человека спокойным, уверенным и упрямым.
Также знаю девушку, которая «прямо растекается по стулу», когда читает байки из «Физики шутят», «Математики тоже шутят»,…
— Как измерить силушку богатырскую?
— Нужно умножить массушку на ускореньице!
Чувство юмора можно привнести в преподавание, начиная рассказ с хорошей байки. Байки в преподавании очень важны. К счастью, их не всегда надо выдумывать. Ведь уже случилось столько курьёзных историй из-за багов. Некоторые байки считаю выдуманными, особенно по части защищённости и информационной войны; когда ищешь первоисточник, выясняется, что история записана со слов отставного генерала, которую он услышал от своего приятеля. И, вроде, можно рассказать об упавшей ракете или лопнувшем нефтепроводе, но с тем же успехом можно начать рассказ так: «Итак. Представьте ...», — и дальше понеслась фантазия.
От лица тестировщиков, считающих себя хорошими — спасибо.
Есть мнение, что одно из главных качеств тестировщика — это чувство юмора. Подробнее можно прочитать в интервью с моей коллегой Асиёй: День тестировщика 2014: поздравления от Ижайти.
И чтобы быть энергичным, ищущим неизведанное, надо наравне с психологией подтягивать и физику. Зайдите в такой отдел тестирования, который считаете хорошим. Наверняка, увидите крепких ребят и очаровательных девушек. Круг их спортивных интересов различный. Нужные качества прививаются естественным образом.
Да. Тестирование защищённости почти всегда исследовательское или специализированное (на моей практике). Это будет тестирование защищённости, автоматизированное, негативное. А дальше по ситуации.
Если ваш уровень знаний превышает возможности фаззера, и это инструмент который удобно лежит в руке, а не чёрный ящик, то тестирование будет исследовательским. Особенно, если вы дописываете фаззер под конкретную задачу, тут все признаки исследования. Если же тестирование выполнять, как запуск фаззера на определённом наборе правил, то оно скорее будет специализированным, ведь момент исследования уже пропадает.
Для тестирования защищённости по тестам только-только приспособил ASVS и Testing Guide, рекомендую.
Спасибо за замечание. Есть объективные ограничения — количество часов лекционных и практических занятий. Несогласованность — код, написанный на дисциплине, связанной с разработкой не тестируется на дисциплине связанной с тестированием и отладкой. И субъективные ограничения — да, надо сеять доброе вечное, регулярно давать домашние задания, обсуждать со студентами результаты. Преподавание — это дополнительная работа, которую попросили сделать на основной работе. Преподаванию уделял не столь много времени и сил, сколько было бы нужно для большего эффекта.
Зверя в студентах не будил. Сам учился на примерах.
Наиболее сильные примеры — публикации хакеров. Замечание описано в три предложения. Поначалу каждое слово незнакомо. И надо понять ход мысли человека, который нашел этот дефект. Если научиться так мыслить, то на тестируемую систему уже смотришь иначе.
Красивая визуализация процесса есть в сериале про Да Винчи. Тут ведь также получается. Смотришь на сайт, уже телепатишь какие технологии в нём используются, что на стороне сервера, на стыках каких модулей есть ошибки.
Также пересмотр замечаний на работе. Использую «тематический» пересмотр. Просматриваю замечания и пожелания, в поисках замечаний по защищённости, например, или по удобству использования. Просмотр, указание тегов или категорий, поиск дублей. Вроде бы, это рутина, но это помогает. Пересмотр можно делать и без тематики. Посмотреть замечания за последние несколько месяцев, расширить представление о качестве продукта и почерпнуть изобретательные способы. Наиболее простые и красивые из изобретательных способов поиска замечаний (хаки), видно сразу.
Пожалуйста.
Да, приёмочное тестирование скатилось вниз, поправлю, можно сделать так:
Комплексное
Приёмочное, с ним же входное тестирование (на дым)
Основное
Повторное
Регрессионное
Тут надо объяснить студентам, что хотя регрессионное и в одной группе с повторным, и группа называется «По хронологии выполнения». Нельзя сказать, что регрессионное всегда до, после или во время повторного. Можно рассказать как было когда-то в реальной жизни, отметив, что приёмочное было до основного и почему. А в практике студентов приёмочного может и не быть.
Курс по тестированию вёл один раз (студентам). И рассказываю коллегам частями.
Файл локализации, про который написал в комментарии выше:
http://pastebin.com/DeqXckUv — файл «custom_strings.1.9.5.txt», с переведёнными строками локализации для testlink 1.9.5, 198 КБайт;
http://pastebin.com/aUGETs7B — файл "\testlink\locale\ru_RU\custom_strings.txt", это файл «custom_strings.1.9.5.txt» после обработки стандартным скриптом testlink дополняющим список модифицированных строк до полного списка из "\testlink\locale\en_GB\", 204 КБайт.
Тоже есть файлик локализации testlink 1.9.5. При подготовке я и мои коллеги старались. Составил глоссарий и переводил строки согласовано. С радостью предоставлю любым удобным способом. Файл достаточно полный, на момент версии 1.9, для более новых версий потребуется расширение.
Когда-то начинал перенос уже переведённого файла в проект translatedby. Закончил перенос на 18%.
Постараюсь не забыть опубликовать файл локализации.
Буду рад ответить на вопросы по локализации, изменению внешнего вида, интеграции testlink с системами учёта замечаний, администрированию, способам загрузки тестовых сценариев из внешних источников, организации процесса согласования проектов тестов, предоставлении удобного анонимного доступа к отчётам и показателям тестирования.
Об организации тестирования в команде, сделавшей отличный продукт.
Инженеры по тестированию — часть команды разработки, где также есть системный аналитик, системный инженер и два инженера технической поддержки. Сначала соотношение было 0 к 1-му, потом 2 к 7-ми, сейчас 3 человека занимаются тестированим и 11 разработкой. Большой кабинет, общий митинг. Требования уточняются у системного аналитика и группы аналитики.
Важнейший вид тестирования — функциональное тестирование, автотесты на основные сценарии. Тестирование по требованиям и исследовательское. Тесты пишутся для сценариев, проверенных сейчас и которые стоит проверять в будущем. Из нефункциональных видов: нагрузочное, защищённости, конфигурационное.
Группа разработки — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие различными знаниями, навыками. Обмен знаниями повсечастный.
Введение в том, что жизнь — череда выборов, как правило, выбор падает на позитивный сценарий тестирования, а негативные включаются в работу, если начать копать ошибку в позитивном, или по остаточному принципу. Как правило, но не всегда.
Содержательная часть из примеров, ситуаций, позитивных и негативных сценариев, видов тестирования, размеров аудитории продукта.
Вывод, что негативные сценарии сложно проектировать. Тут считаю, что ещё более сложно выполнять негативные сценарии, технически сложные негативные сценарии (имя файла на 2000 символов, картинка на 500 МБайт, особый набор входных параметров для проверки экранирования вывода, ...). И они важны.
Касаемо неоригинальности мысли. Алексей Баранцев, проводя выступление про тестирование по вариантам использования, предложил обсудить эту тему с аналитиками. Так и поступил. Обсудил тему с коллегой аналитиком (Стасом), который не был на выступлении. Выше изложены мысли из нашей с ним беседы, скорее, мысли Стаса, чем мои. И при изложении, видимо, изложил мысли словами Алексея Баранцева. Алексей произвёл впечатление, хорошее было выступление, рад, что вы там были.
Касаемо студентов. На практике не закрепил с ними проектирование тестов. Тесты проектировали, были обсуждения, рассказы, примеры. Не было вовлечения в процесс, когда студент осознанно проектирует, и лишь консультируешь и направляешь. Вовлечение есть, когда студент приходит на производственную практику. От того, думаю, студенты не запомнили тему проектирования. В частности, не осознали роль негативных сценариев при проектировании, которую мы сейчас обсуждаем. Когда студенты придут в вашу компанию, придётся их обучать проектированию тестов. Вклад преподавания в том, что студент сможет сделать осознанный выбор в пользу тестирования и будет ориентироваться в предметной области.
Пользователь не замечает ошибок программы, пока программа выполняет основной сценарий работы (почти всегда — позитивный) в соответствии с ожиданиями пользователя.
Как только основной сценарий расходится с ожиданиями, внимательность и осторожность пользователя повышаются многократно. И уже становится очень важным, чтобы на негативных сценариях программа вела себя достойно.
Программа не выполняющая основные позитивные сценарии, чаще всего, не нужна пользователю.
Тут уместно задать почти философский вопрос: «А какая же программа нужна пользователю?»
Отвечая на него можно придти к мысли, что если у программы лишь десяток пользователей, основной сценарий работы которых хорошо известен и их ожидания выполняются. То приоритет негативных сценариев снижается. Пользователи даже сами могут сказать разработчику не усложнять и не мудрить, так как их всё устраивает.
Если же у программы сотни и тысячи пользователей, и программа недостаточно проста, чтобы соответствовать ожиданием всех. То просто необходимо уделять внимание негативным сценариям.
Могу привести рассуждение отталкиваясь от тестирования защищённости, стрессового тестирования и их важности.
По роду деятельности отвечаю преимущественно за негативные сценарии, а мои коллеги за позитивные. Если вы занимаетесь промышленной разработкой, то знаете как ищутся более оптимальные способы планирования, организации и выполнения работ по тестированию, чтобы убедиться в выполнении основных сценариев. Основными сценариями занимается большая часть команды, большую часть времени. На негативные сценарии и специализированные виды тестирования выделяют отдельных людей.
Спасибо за хорошую идею. В следующий раз выскажу именно ту мысль, что вы изначально поняли. И посмотрю, поставит ли кто-нибудь её под сомнение.
Примерное описание на русском языке можно прочитать в статье http://licenseit.ru/wiki/index.php/Creative_Commons_Licenses.
Представьте, подготовка БД завершена, контекст настроен, в системе есть контакт с ИД 42.
Функциональный тест: открыть карточку контакта с ИД 42, проверить, что в поле Статус значение Действующий, и что значение можно сменить, убедиться, что в логах не появилось ошибок и предупреждений.
Если распараллелить такой тест на 100 пользователей, то проверим эффективную работу с кешем. А если работа с кешем эффективна, то нагрузка не будет создана. Для того, чтобы кеш испытал шок и рассыпался в пыль, придётся подключить 50 000 пользователей, а имеющееся оборудование может не позволить этого, или бизнесу может быть не интерсна поддержка такого количества, или, вообще, схватим deadlock при разборе логов уже на 10-м потоке.
Если переписать функциональный тест так: открыть карточку произвольного контакта, проверить, что значение в поле Статус можно сменить на случайное и код ответа сервиса — 200 (OK).
То тест становится более подходящим для нагрузки.
Но когда бизнес спросит: «Действующие контакты в новом билде по-прежнему действуют, при открытии карточки в логах нет предупреждений?», — дать положительный ответ, на основе функционально-нагрузочного теста не получится.
Для подстройки размера карты под размер окна браузера поменял расчёт ширины и высоты:
И расчёт масштабирования (scale):
И тег h1 убрал, чтобы он не сокращал полезную площадь document.body (при наличии тега и текущем способе расчёта ширины/высоты появлялся скролинг).
Замечу, что зубрить не надо. Цель в том, чтобы обяснить отличия и общности, расставить приоритеты. Например, легко объяснить отличие негативного теста от позитивного. Но важно заметить, что тот же санити будет, почти всегда, позитивным. И если у вас 1000 тестов, и надо оставить только 200 из них, то скорее всего, сокращение вы начнёте с негативных. Потому-то потому-то…
На конкретном месте работы пусть, вообще, не будет применяться понятие негативного теста. Но объяснить, чем такой тест будет отличаться от позитивного, стоит.
Отбиваться можно долго. И в конечном итоге, мы поймём друг друга. Как говорит мой друг: хороший биолог объяснит физику-ядерщику атомное устройство вселенной на тычинках и пестиках. Так и мы увяжем санити с входным тестом.
Также знаю девушку, которая «прямо растекается по стулу», когда читает байки из «Физики шутят», «Математики тоже шутят»,…
Чувство юмора можно привнести в преподавание, начиная рассказ с хорошей байки. Байки в преподавании очень важны. К счастью, их не всегда надо выдумывать. Ведь уже случилось столько курьёзных историй из-за багов. Некоторые байки считаю выдуманными, особенно по части защищённости и информационной войны; когда ищешь первоисточник, выясняется, что история записана со слов отставного генерала, которую он услышал от своего приятеля. И, вроде, можно рассказать об упавшей ракете или лопнувшем нефтепроводе, но с тем же успехом можно начать рассказ так: «Итак. Представьте ...», — и дальше понеслась фантазия.
Есть мнение, что одно из главных качеств тестировщика — это чувство юмора. Подробнее можно прочитать в интервью с моей коллегой Асиёй: День тестировщика 2014: поздравления от Ижайти.
И чтобы быть энергичным, ищущим неизведанное, надо наравне с психологией подтягивать и физику. Зайдите в такой отдел тестирования, который считаете хорошим. Наверняка, увидите крепких ребят и очаровательных девушек. Круг их спортивных интересов различный. Нужные качества прививаются естественным образом.
Если ваш уровень знаний превышает возможности фаззера, и это инструмент который удобно лежит в руке, а не чёрный ящик, то тестирование будет исследовательским. Особенно, если вы дописываете фаззер под конкретную задачу, тут все признаки исследования. Если же тестирование выполнять, как запуск фаззера на определённом наборе правил, то оно скорее будет специализированным, ведь момент исследования уже пропадает.
Для тестирования защищённости по тестам только-только приспособил ASVS и Testing Guide, рекомендую.
Наиболее сильные примеры — публикации хакеров. Замечание описано в три предложения. Поначалу каждое слово незнакомо. И надо понять ход мысли человека, который нашел этот дефект. Если научиться так мыслить, то на тестируемую систему уже смотришь иначе.
Красивая визуализация процесса есть в сериале про Да Винчи. Тут ведь также получается. Смотришь на сайт, уже телепатишь какие технологии в нём используются, что на стороне сервера, на стыках каких модулей есть ошибки.
Также пересмотр замечаний на работе. Использую «тематический» пересмотр. Просматриваю замечания и пожелания, в поисках замечаний по защищённости, например, или по удобству использования. Просмотр, указание тегов или категорий, поиск дублей. Вроде бы, это рутина, но это помогает. Пересмотр можно делать и без тематики. Посмотреть замечания за последние несколько месяцев, расширить представление о качестве продукта и почерпнуть изобретательные способы. Наиболее простые и красивые из изобретательных способов поиска замечаний (хаки), видно сразу.
Да, приёмочное тестирование скатилось вниз, поправлю, можно сделать так:
Тут надо объяснить студентам, что хотя регрессионное и в одной группе с повторным, и группа называется «По хронологии выполнения». Нельзя сказать, что регрессионное всегда до, после или во время повторного. Можно рассказать как было когда-то в реальной жизни, отметив, что приёмочное было до основного и почему. А в практике студентов приёмочного может и не быть.
Курс по тестированию вёл один раз (студентам). И рассказываю коллегам частями.
Когда-то начинал перенос уже переведённого файла в проект translatedby. Закончил перенос на 18%.
Постараюсь не забыть опубликовать файл локализации.
Буду рад ответить на вопросы по локализации, изменению внешнего вида, интеграции testlink с системами учёта замечаний, администрированию, способам загрузки тестовых сценариев из внешних источников, организации процесса согласования проектов тестов, предоставлении удобного анонимного доступа к отчётам и показателям тестирования.
Инженеры по тестированию — часть команды разработки, где также есть системный аналитик, системный инженер и два инженера технической поддержки. Сначала соотношение было 0 к 1-му, потом 2 к 7-ми, сейчас 3 человека занимаются тестированим и 11 разработкой. Большой кабинет, общий митинг. Требования уточняются у системного аналитика и группы аналитики.
Важнейший вид тестирования — функциональное тестирование, автотесты на основные сценарии. Тестирование по требованиям и исследовательское. Тесты пишутся для сценариев, проверенных сейчас и которые стоит проверять в будущем. Из нефункциональных видов: нагрузочное, защищённости, конфигурационное.
Группа разработки — сработавшиеся люди, знающие друг друга, доверяющие друг другу, обладающие различными знаниями, навыками. Обмен знаниями повсечастный.