Тестировщики не должны писать тест-кейсы

Автор: | 31.07.2012

Безусловно, не должны.

Тестировщики должны тестировать приложения с помощью всех возможных и мыслимых приспособлений.

Среди этих приспособлений числятся и тест кейсы.

В целях борьбы с вредителями риса, Министерство сельского хозяйства Китая объявило, что за каждую сданную саранчу крестьяне будут получать по одному юаню.

Китайские крестьяне стали разводить саранчу на своих подворьях. ©

Было бы смешно (желторотые, дескать, китайцы), но действительно — как задачу поставишь, так белая обезъяна её и выполнит.

И это правило работает даже в случае “сам себе задачу поставлю…

Дашь задачу “написать тест-кейсы” — тебе их напишут пять сотен, задача будет блестяще выполнена.

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

«И попробуйте возразить» ©

2)

Test case = тестовая ситуация.

Абсолютно все люди, которые сталкиваются с тестированием лбами и прочими мягкими местами, должны НЕМЕДЛЕННО прекратить переводить термин ‘test case‘ как ‘тестовый случай‘.

Тест-кейс — это “тестовая ситуация“, а не как мы привыкли…

Уму тестировщика должно быть однозначно вообразимо, что слово ‘case’ неимоверно емкое и неоднозначное. Оно вот это всё:

  1. автоматизированное проектирование систем
  2. аккумуляторный ящик
  3. аргументация по делу
  4. больной
  5. версия
  6. витрина
  7. гильза
  8. деликтный иск по конкретным обстоятельствам дела
  9. дело
  10. доводы
  11. доказательства
  12. заболевание
  13. застекленный стенд
  14. изложение требований
  15. изложение фактических обстоятельств
  16. история болезни
  17. казус
  18. кассета
  19. клиент
  20. кожух
  21. контейнер
  22. коробка
  23. корпус
  24. корпус компьютера
  25. крышка
  26. ларец
  27. материалы дела
  28. меморандум по делу
  29. место
  30. наборная касса
  31. наружная покрышка
  32. находящийся под наблюдением
  33. обвинение
  34. обстоятельство
  35. обшивка
  36. оператор выбора
  37. остов
  38. падеж
  39. пациент
  40. покрышка
  41. покрышка шины
  42. положение
  43. прецедент
  44. раненый
  45. регистр клавиатуры
  46. случай
  47. случай в судебной практике
  48. спорный вопрос в суде
  49. станина
  50. судебная практика
  51. судебное дело
  52. судебное решение по делу
  53. судебный прецедент
  54. сумка
  55. фактические обстоятельства
  56. факты
  57. футляр
  58. чемодан
  59. чехол
  60. чудак
  61. ящик

Отличненько, ага?

Дык вот, ‘case‘ в контексте ‘случай‘ распознается следующими синонимами:

  • case,
  • event,
  • incident,
  • occasion,
  • instance,
  • chance

А собственно ‘test case‘ переводится как “прецедент“:

  • precedent,
  • case,
  • example,
  • test case,
  • authority.

На, убедись: translate.google.com

А вот что означает ПРЕЦЕДЕНТ:

“Поведение в определенной ситуации, которое рассматривается как образец при аналогичных обстоятельствах” ©

Вместо умного и сложного для наших сознаний слова “прецедент” надо использовать слово “ситуация“.

Дело в том, что слово ‘precedent‘ с румынского переводится как ‘предыдущий‘, что привносит много интересных ‘lost in translation’ моментов…

Дело еще в том, что слово ‘case’ в термине ‘test case’ мало кто понимает даже в густо заселенной тестировщиками Индии (коих там больше, чем самих индусов).

А еще дело в том, что…

3)

Тестовая ситуация всегда создается ИСКУССТВЕННЫМ образом.

Перечень шагов в тест-кейсе необходим вовсе НЕ для того, чтобы посредством их прохождения убеждаться в том, что функционал работает ‘as expected’…

Шаги эти рассказывают о том, как привести software в состояние, которое необходимо для проведения теста.

  1. Do blah-blah,
  2. Do blah-blah, blah-blah,
  3. And check that blah-blah… (и софт приведен в необходимое состояние)
  4. (и вот тут – одно-единственное тестовое действие) Click!!!
  5. Expected result: blah-blah и blah.

Являются крайне основательными все уточнения о том, что под тест-кейсом подразумевается ситуация, созданная искусственным образом, как овечка Долли.

Репост очень! Перестаньте уже вызывать страдания в среде тестировщиков! Мимими и няняня!!! Твои потуги огорчают нас, %username%!

Впрочем, ладно…

Подвигом будет осознание хотя бы первого пункта.

Для размягчения сознания — притча:

Однажды к Учителю пришёл любопытный паломник.

~ Учитель! – сказал он, – а вы можете лежать на гвоздях?

~ Ну, могу, в принципе… – ответил Учитель.

~ Ой, а покажите! – взмолился паломник.

Учитель пожал плечами, высыпал на пол два ящика гвоздей, постелил сверху матрас и аккуратно улёгся.

~ Нет, это неправильно, – с упрёком сказал паломник. – Гвозди надо вбить в доску, остриями вверх! И вот на этом лежать!

~ Мужик, ты что, дурак? – вежливо спросил Учитель.

И попробуйте возразить! ©

Тестировщики не должны писать тест-кейсы: 35 комментариев

  1. Илья

    Классно написано 🙂
    Пытаюсь разобраться, чем мне поможет то, что теперь я начну воспринимать Test case как “тестовую ситуацию”, а не как тестовый случай? И то, что в описании дефекты мы приводим систему в необходимое состояние перед воспроизведением проблемы?
    Или это просто для уточнения терминов давались объяснения?
    Мне действительно интересна цель сего поста 😉
    P.S: Если тестировщик напишет 500 классненьких тест-кейсов, он узнает ещё кучу возможностей как можно продиагностировать аппликацию.. я тАк думаю 😉

  2. Sergey

    Хорошая цепочка. Попробуй ментальную карту нарисовать, а я тебе побочных веток подкину.
    Например:
    1. Тестировщики не должны писать тест-кейсы, потому что тест-кейсы должны писать аналитики. Потому что тест-кейсы я вляются одной из важнейших и неотемлемых частей спецификации требований.
    2. Нужно писать тест-кейсы, потому что это помогает выявить дефекты до проведения действий. Анализ записанных тест-кейсов позволяет выявлять дефекты в конечном продукте до написания кода и выявлять дефекты тестирования до работы с программой.

  3. Алексей Лупан

    Случай = случайность.
    Тестовая ситуация != случайность. Это целенаправленное создание ситуации.
    Чем поможет – будете писать шаги тест-кейса более осмысленно и лаконично.
    500 кейсов: тут дело более глубокое и двотрочетвероякое. Во-первых, “если ты знаешь себя и знаешь врага, то тебе не страшны пять сотен битв” 🙂
    Во-вторых, написать 500 тест-кейсов – это долго и больно. Если они дописаны, и возникает какое-то изменение (или прямо запрошенное, или просто соображение), то изменить их будет опять же долго, больно и сложно.
    И я очень сомневаюсь, что посредством написания тест-кейсов тестировщик будет “знать много возможностей”. Тест-кейсы надо писать не глядя на приложение, обычно – когда его еще нет.
    И в четвертых – я еще не видел человеков, которые написали бы 500 классных тест-кейсов. Мусора и лишнего шума при таких объемах неимоверно много. А все оттого, что задача поставлена как “напишите тест-кейсы”, а не “протестируйте”.

  4. Алексей Лупан

    Аналитиков я тут не рассматривал, тестировщики живут и умирают в одиночку 🙂
    Но “Нужно писать тест-кейсы, потому что это помогает выявить дефекты до проведения действий” – это мудро, да.

  5. DJ ZX

    тестировщики могут писать тесткейсы, могут не писать, что такое тесткей – этому даже целый раздел у Канера посвящён. Вопрос в том, кто же ДОЛЖЕН писать тесткейсы? И должен ли вообще?

  6. Алексей Лупан

    Давайте читать не только заголовки 🙂
    Нет такого вопроса – кто должен. Все должны.
    Вопрос следующий – как их писать.
    Писать тест-кейсы надо грамотно.
    В чем секрет – я уже сообщил.

  7. Diesel

    Писать кейсы необходимо, но делать это должен аналитик.
    Тот кто анализирует требования, уточняет детели разрабатываемой функциональности, составляет план тестирования и т.п. (конкретный набор действий зависит от конкретной компании).
    Смысл данного высказывания в том что “тестировщик” – это человек который выполняет действия по проверке качества разрабатываемого ПО. Как он проверяет (по готовым кейсем, ad-hoc, exploratory и т.п.) – опять же зависит от конкретной компании и сутуации.
    Если обощить, то в команде QA (что представляет более широкое понятие чем “тестировщики”) должны быть люди которые занимаются анализом требований… вот они и пишут всякие умные “бумажки” типа кейсов, планов и прочего добра.
    А задача именно тестировщика – тестировать! а не заниматься “paperwork”.

  8. Алексей Лупан

    Да прям 🙂
    Если жестко ограничиваться “я только тестировщик, я только тестирую, кейсы вы сами должны писать”, то на моей морде брезгливость будет проступать еще более ярко.
    Грамотные тестировщики именно потому и становятся грамотными, что не куклятся в определенной роли в определенных рамках. Для этого нужны смелость и определенные обстоятельства, но все-таки.
    Грамотный тестировщик обязан уметь выполнять тест-кейсы, модифицировать их, создавать, и вообще принимать нестандартные решения в нестандартных ситуациях, и что там еще требуется от бойца стройбат-спецназа.
    “Какой тестировщик не мечтает спать с генералом”, или как там говорят в армии программистов…

  9. Diesel

    В моей команде никто не гнушается никакой работой, ни аналитикой, ни функциональным тестированием, ни нудным регрешеном. Вопрос в том что в рамках конкретного проекта, релиза, спринта нужно распределить роли (аналитика, тестировщика и т.п.) и выполнять их. Если на человека вешать сразу анализ нескольких беклогов, писать кейсы, тут же тестировать это и проводить регрешен… то
    1 – “одна голова – хорошо, а две – некрасиво”. В данном случае конечно же надо несколько голов, которые под разными углами посмотрят на тестируемое приложение и добавят своих идей. Поэтоу зачастую аналитики и те кто выполняет тест – разные люди (80% случаев)
    2 – когда на человеке столько различных задач сразу – то его мозг начинает плавится от всего этого, что надо делать и первое и второе и десятое и ещё там чего из старого релиза выползно и надо перепроверить или требования старые найти.
    Понятно что новичков, которые работают всего несколько месяцев в команде я не посажу на анализ и написание кейсев. И наоборот людей которые работают уже годами – не буду мучать скучным регрешенном тех частей которые ещё не успели автомтизировать… но по большей части человек может выполнять почти любую роль в зависимости от необходимости.
    Поэтому возвращаясь к теме топика – пусть пишут кейсы и проходят их разные люди. Больше шансов покрыть различные варианты и сценарии… ну и просто больше хороших идей.

  10. Екатерина

    Алексей, вы.. вы просто молодец!
    Дать название, которое прямо-таки провоцирует холивар…
    Записывать-то тест-кейзы (в любом понятном другому тестеру виде) просто необходимо.
    Нет, оставим холивар, начну сначала..
    Еще никто не сказал волшебное слово “Traceability matrix”? Я буду первая!
    А кстати, как грамотно будет по-русски “Traceability matrix”? Слышала вариант – “матрица соответствия”. По смыслу верно, а звучит коряво.. Или вам так не кажется?
    Действительно, вот есть же довольно адекватная метрика.
    Другое дело, что требования бывают такие общие, что каждый пункт таких требований надо расписать на 5-10 действительно четких требований (вида
    – приложение должно “а”
    – приложение должно “б”
    – приложение должно “а” и “б” одновременно
    – ..)
    Ну, еще.. Говорить о том, что 500 тест-кейзов – это много, не говоря о размере фичи – это, мягко говоря, некорректно (мысль ясна, но мы же тестировщики и хотим быть максимально точными).
    А то “белые обезъяны” будут изобретать тест (типа “тест-кейс”) в котором проверять рАзом по 10 “кейзов”, только “чтобы было 50 тест-кейзов, а не 500”..
    500 классных тестов – действительно редкость, но 500 _необходимых_ тестов для более-менее сложной фичи – совсем не много, (скорее мало). Ну да, действительно интересных кейзов, после которых себя похвалишь “такой кейс придумал(а)!” (и побежишь выяснять, а каков, собственно expected result, поскольку никто этого не предусмотрел) будет мало, штук 10 от силы, но рутину-то тоже проверить надо.
    Даже если обратиться к голой математике:
    1) 500 = 2^9 (грубо), т.е. сочетания 9 параметров с 2 значениями каждый. Много?
    2) 1) 500 тестов на 5 мин каждый = неделя тестирования. Много? Мало? Для меня скорее второе – “моя” последняя фича была суммарно 15 дней (3 недели) тестирования.
    P.S. Простите за “много букв”, это наверно, от зависти 🙂 : мне скорее приходится минимизировать число тестов из-за отраниченного времени на тестирование.

  11. Сирожа

    А чем, простите, тест кейсы помогают выявить дефекты до действий? И чем они в этом плане лучше любой другой формы структурированной записи информации? И зачем тест-кейсы в спецификации, когда они по сути являются дублирующим документом?

  12. Сирожа

    Есть альтернативная версия – никто не должен.
    Bing, например, так и тестируется – формализуются только модели (множество моделей, что характерно), а после этого наличие и количество тест кейсов значения вообще не имеет. Ровно как и холивары на тему что считать тест кейсом

  13. DJ ZX

    и что, бинг чем-то примечателен? 😉

  14. DJ ZX

    не, ну я прочитал конечно всю статью, но всё таки “правильность” написания тесткейсов очень сильно зависит от типа продукта и процесса, который используется в разработке
    и нередко кейсы должны реально быть проверками в лоб без вариантов шагов влево или вправо

  15. Сирожа

    “И чо” это классный вопрос. Даже теряюсь что на это ответить. Ну стоит сильно дороже чем вся IT отрасль Украины. Но тут ничего примечательного.
    Чем он должен быть примечателен?

  16. Алексей Лупан

    Самый близкий перевод “Traceability matrix” – матрица покрытия требований тест-кейсами.
    Другое дело, что два слова переводятся пятью – дело вкуса.
    Мало или много 500 тестов – если их надо будет всего лишь прочитать и осознать, то это будет много 🙂

  17. DJ ZX

    ну честно – Бинг провальный и бажный проект и стоимость не имеет значения (я не про США, я про ворлдвайд, честно – рашкинский Яндекс работает лучше, да и сервисы там не менее вкусные), с другой стороны – пример просто сам по себе непонятен, тестекейсы действительно могут быть не нужны, но не всегда так можно. Сколько раз нас спасал трекинг результатов по кейсам на год-два назад (или даже больше).

  18. Сирожа

    Провальность и бажность Bing’а мне лично недоступна. Почти 30% поискового рынка в штатах сложно назвать провалом. Я знаю пару национальных поисковиков, которые за такое душу продали бы без вопросов.
    В мировых масштабах мало, но все еще в два раза больше того же Яндекса, а если сидящий на движке Bing’а Yahoo! посчитать в кучу, то даже в мировых масштабах неплохая цифра получается.
    Мне лично Bing интересен в первую очередь процессами и тем, что там за главного по тестированию некий Harry Robinson (копать отсюда и далее: http://model-based-testing.info/2012/03/12/interview-with-harry-robinson/ ).
    С примером все просто – тест-кейсы это детализация модели приложения без формального ее описания. Зачастую даже не одной модели без четкого описания. Т.е. тест-кейсы это довольно неудобная форма хранения и описания модели. При этом для того же ретроспективного анализа вообще не имеет значения что трекать – главное чтобы была информация, а формат уже вторичен.

  19. Тимур

    >>Тест-кейсы надо писать не глядя на приложение, обычно – когда его еще нет.
    Чуть ранее
    >>Я думал, что попал в логово неадеквата.Я думал, что надо бежать.
    Я в подобной ситуации как раз нахожусь.
    Аналитик выдал мне пачку юз-кейсов, незаконченных, на которые я должен написать пачку тест-кейсов. Да пожирнее чтоб. Продукта как такового ещё нет, по сути.
    Дали в зубы книги Баха, Канера и ткнули пальцем какие блоги читать.
    Слова про логово неадеквата очень в тему.
    Опыта ноль.
    Роды тестера проходят тяжеловато, но идут. Теоретически я понимаю, что самый хардкорный путь – самый быстрый.
    Но как, черт возьми, иногда трудно.

  20. Алексей Лупан

    В подклассе объясняю технологию их “придумывания”. Но иногда лучше сделать это самостоятельно, через хардкор и “завоевание целины”.

  21. Ivan

    Грандиозно)

  22. none

    Дизайнер -тестов пришет тест-кейсы, а дизайнером тестов может быть любой грамотныч специалист.

  23. DJ ZX

    начну с бажности – насколько более точно и качественно ищет гугл – просто не сравнить, и это при всей рекламе и накрутках. бинг даже по сайту майкрософта ищет хуже, чем гугл.
    по провальности: 30% рынка в штатах – это ноль, 70% юзеров не меняют настройки системы, которые не предлагается менять (и даже больше), ИЕ с 8-й версии предлагает ставить бинг по дефолту. То есть можно сказать (я не гуглю статистику, пишу просто на основании своих оценок) – более половины даже американских юзеров тупо отказываются от бинга. Какой движок юзает Яху – не имеет значения для конечного юзера, если они юзают Яху, то значит не хотят бинг.
    Формат конечно вторичен, само собой, но и продукты бывают разные. Для нашего продукта количество ТестСюит (наборов тесткейсов) по отдельным функционалам стремится к 200 и это практическая необходимость. Некоторые тестсюиты составлены очень точно, потому что там должно работать всё 1 в 1, некоторые содержат общие описания поведения и стимулируют всегда делать исследовательское тестирование. Подходы могут быть разные даже в пределах одного продукта. Другое дело, что есть продукты, для которых реально нужны структурированные модели.
    Кстати, в спецификациях не должно быть тесткейсов, только юзкейсы. Если в спеке кто-то прописал тесткейс – удалите и не читайте.

  24. silver price

    Тоже самое можно сказать и о тест-кейсах. Смыслом написания/выполнения тест-кейсов является проверка того, насколько тестируемое приложение удовлетворяет предъявляемому к нему требованию. Результатом выполнения тест-кейса должны стать его прохождение или провал, что подтвердит соответствие реализации требованию или нет (кстати, для тестировщика любой исход является положительным, правда, в случае провала тест-кейса — более приятным :)).

  25. Andrew

    1. Статья тянет на пост в Википедию о различиях в терминологии, но никак не на технически обоснованую статью…
    Крикливое и радикальное название размывается комментариями аля:
    “Но “Нужно писать тест-кейсы, потому что это помогает выявить дефекты до проведения действий” – это мудро, да.”
    Алексей Лупан on 31.07.2012 at 11:09
    2. Чем Вам тестеры схожи с крестьянами из Китая? Неужели то что Саранча = Насекомое = Bug есть основанием для сравнения?
    Весь раздел разлитой воды под названием “Безусловно, не должны.” можно было бы заменить предложением о том что ленивым и халатным тестерам не разрешать ничего делать, и все – не нужно заставлять читателя писать лишнее, а то Ваша статья похожа на 500 вымученых тест-кейсов, написанные крестьянами из преднебесной )

  26. Алексей Лупан

    Википедия такие вольности не приемлет. Отпадает.
    Объяснять “про крестьян” тоже отпадает. Прояснение вам только забьет баки.

  27. Andrew

    Хотя да, Ваша статья – Ваша песочница…
    Cпасибо за аргументированные ответы 😉
    PS: Про “мои баки” (и других читателей) нужно было беспокоится до написания статьи…

  28. Алексей Лупан

    Всегда велком 🙂
    Вам же не будет удивительно узнать, что про читателей в момент написания этого текста никто не думал?!

  29. Alex

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

  30. voorhis

    Это самая бесполезная статья за всю историю) Автор молодец. Верни мои 5 минут жизни

  31. Уведомление: «Мелочь пузатая или Объем тест кейса против его содержательности» © Алексей Лупан | ЛітоЛєна

  32. Tolik

    Тестировщиком я б стал, пусть меня научат:)
    Прочёл текст и понял, что он писался поздно..))

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.