А так ли нужны test cases ?


А так ли нужны test cases, когда нет времени на регрессионное тестирование вообще?

В небольшой фирме, где я сейчас работаю, времени на тестирование выделяется ровно столько, сколько необходимо на верификацию bugs, проверку новых features и прогонку smoke теста при выпуске нового патча.

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

Но совсем недавно, на очередном team meeting, мне подумалось: А зачем писать test cases, если их никто не использует? (Честно говоря, они нужны только нашему заказчику, да и то раз в год...)

Подумал... и сам испугался: неужели я ставлю себя умнее, чем все эти умудренные опытом люди? Но потом мне вспомнилось цитата какого-то умного человека «документ пишется не для документа, а что бы документ использовался» (вольная интерпритация)

И в итоге вывод, который я сделал для себя, гонка за «процессом», «как нужно», «как написано» и т.д. не приводит к результату, если в этом нет необходимости.
Вода течет только туда, где есть место — «правильный» процесс тестирования нужно внедрять там, где без него невозможно жить, а «сопокойные» места (где нет проблем) лучше не трогать.

Нашли ошибку в тексте? Выделите её мышкой и нажмите Ctrl + Enter.

Ещё по данной теме:


16 ответов, оставьте свой...:

  1. Александр Селяев отметил:

    Умный человек писал:

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

    Сем Канер и др. Тестирование ПО

  2. Maksim Grinevich отметил:

    Собственно, мысль классиков жанра только подтверждает мои мысли.

  3. Александр Селяев отметил:

    Но!
    Что мы оставим после того как пардон уволимся? Ушла полностью группа тестировщиков - либо необходимо передать на аутсорсинг тестирование и тут документация как никогда нужна. Хотя бы чек листы. Хотя бы названия тестов.

  4. Maksim Grinevich отметил:

    Во-первых, есть Smoke Test - всё-таки один документ мы пишем и держим up2date. Во-вторых, большая часть вины/нагрузки ложится на менеджмент, который поставлен в известность: либо больше времени, либо отсутствие документов и риски с этим связанные.

  5. Александр Селяев отметил:

    Ну да конечно. К пуговицам претензий нет ;)). Может стоит иногда думать что кроме менеджмента думать головой нужно и самому тестеру?
    ИМХО но планирование и документация - альфа и омега преемственности. А к тому же - "если не не знаешь куда собирался идти - не удивляйся что пришел не туда." Если ты не планируешь выпускать качественный программный продукт то и не стоит его выпускать.

  6. Maksim Grinevich отметил:

    Я же говорю: документы это хорошо. Но если ты поставлен в ситуацию выбора: либо проверишь толково конкретную feature или напишешь test case по ней, то что ты выберешь?

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

    Кроме того, работая даже в конторе с CMMI 4 уровня (кажется это так называлось), вся документация (и тест план в том числе) писалась в основном после выпуска продукта и только для Quality Assurance отдела. Ив таком безплановом тестировании выпускались дествительно стоящие вещи.

    Думаю, что не все так однозначно даже с приемственностью: всегда можно сделать неделю/месяц на передачу дел... и основы рассказать, а нюансы - приходится чем-то жертвовать...

  7. А.Б. отметил:

    Ну что сказать... Каждому свое, но все же отказ от тест кейсов это скорее зло, чем добро.
    Были в моей практике проекты, на которых я лично писал банальные "чеклисты", а не тест кейсы. Но это уже другая история.
    Отказавшись от тест кейсов мы получаем риски, самый явный из них - пропустить в продакшн какую-нить мелкую багу, исправление которой будет стоить уже не так мало. Вы скажете, что и с тест кейсами может так выйти. Я соглашусь - МОЖЕТ, но тогда у вас, по крайней мере, будет известна фамилия того, кто и по какой причине пропустил багу, и Вы сможете предпринять некие действия, для предотвращения повторения подобной ситуации.

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

    А можете ли вы это делать не имея тест кейсов?

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

    Вот.

  8. Maksim Grinevich отметил:

    Алексей,

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

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

    С вашим подходом проверка и описание мелочей не попадает в кейсы (мне так показалось, по крайней мере).

    А судить о "покрытии" по количеству написанных кейсов - не думаю, что это истина.
    Вернее будет судить о покрытии, по количеству рпогнанных кейсов на данном билде (надеюсь у вас именно так)... а вот ТУТ и кроется суть вопроса: у нас НЕТ времени на прогонку полной регрессии. А в смоук мы добавлем самое-самое-самое-...-самое важное

    Мое предложение - не попытка вывести что-то новое - это способ жить и работать в тех условиях, что предоставлены заказчиком/работодателем

  9. А.Б. отметил:

    Начнем по порядку!
    "Но для этого есть - баг(issue) трэкер. Он покажет, кто тестил ту или иную функциональность."
    Ситуация 1 - нет тест кейсов:
    - Вася, ты тестировал форму логина?
    - Да
    - а почему ты не проверил, вот такую вот фичу?
    - Э-э, ну. Забыл...

    Ситуация 2 - есть кейсы
    - Вася, ты тестировал форму логина?
    - Да
    Вариант А:
    - Ты прошел все тест кейсы назначенные на тебя?
    - Да
    - Молодец.
    Вариант Б:
    - а почему ты не проверил, вот такую вот такой тест кейс, который был на тебя назначен?
    - Э-э, ну. Забыл...
    - Вася, двойка тебе и родителей в школу...

    Разница видна? Мне она очевидна - при написанном тест кейсе очень сложно пропустить что-то, если оно задокументировано и ты идешь по описанным шагам...

    Дальше:
    "С вашим подходом проверка и описание мелочей не попадает в кейсы"
    С моим подходом в кейсы попадаёт все, что описано в спецификации, а так же туда попадают случаи появившиеся в процессе тестирования или взятые из БестПрактис (кстати, если такие есть, то их нужно переносить в спеки, т.к. их наличие показывает неполноту описания требований). Вообще мой подход такой: "если все, что должно работать работает как описано в спеке, значит можно поискать что-то, что выходит за ее пределы." Т.к. если приложение будет очень красивым, без видимых багов, но не будет, по некоторым причинам, выполнять свои прямые функции, то оно не нужно заказчику в таком виде...


    Максим, я не в коем случае не навязываю свою точку зрения, я лишь говорю, что отсутствие кейсов увеличивает риски и управляемость...

  10. Maksim Grinevich отметил:

    Алексей, да.. существование кейсов только на пользу...

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

    Риски связанные с этим понятны, ваша к ним аппиляция - тоже. Тут вы правы, но приходится выбирать... и выбор не в пользу кейсов.

  11. А.Б. отметил:

    Договорились... :)

    Кстати, вот попалось на глаза определение:
    Тестирование - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

  12. emeralda отметил:

    Сама уже много времени задаю себе тот же вопрос и прихожу примерно к такому же выводу, как автор поста.

    Мы в своем проекте сначала писали ТК. Потом перестали. И качество никак не изменилось :).

    Как выразился в комментарии Алексей Булат "
    Мы пишем кейсы не из головы, а исходя из чего-то в виде спецификаций, требований, юзкейсов и т.д.". Вопрос - Зачем переписивать информацию из одного места в другое? :)

    Сейчас мы поступаем так. Из требования заказчика, как водится, составляем документ "Спецификация требований". согласовываем с щаказчиком. И начинаем разработку. Как известно, во время разработки требования неоднократно уточняются :). Все уточнения аккуратно исправляем в спеке.
    А если бы мы начали сразу по первому спеку писать ТК - пришлось бы еще править кучу ТК. Двойная работа! Оно нам надо?
    Когда программысты отдают нам "готовую" функциональность (тестируем мы по мере разработки, а не вконце, что я тоже считаю очень правильнм подходом). Так вот, при получении новой функциональности для тестирования мы берем спек, распечатываем:) и идеи по нему. Проверил пункт - поставил +. Нашел багу - поставил - и номер баги. Все как в тест менеджмент системе:)
    Если тестеров в команде несколько, спек делится поровну между всеми. В следующей итерации можно поменятся.
    В таком подходе есть еще один важный плюс. Спек (особенно подробный и ясный, как у нас) очень полезен для программистов. А ТК для программитстов никакой пользы не представляют.
    И еще плюс - нам не нужно отдельно тестировать требования. Потому как мы их сами пишем и самы обновляем, ведь это наш основной рабочий документ.
    Также, автоматически решается проблема сохранения актуальной! документации для следующих поколений, что будут работать на проекте :)

  13. А.Б. отметил:

    Уважаемая, emeralda.

    Что я могу сказать... Если вы считаете тот процесс, по которому вы работаете, удобным и он дает вашей команде какие-то бенефиты, то это очень даже хорошо. Поздравляю, вы разработали идеальный процесс для Вашей отдельно взятой команды.

    Вы пишите, что у вас постоянно меняются требования. Я скажу, что это бардак и избалованность вашего кастомера. (Хотя конечно Вам удобно, он же платит).

    Мне кажется, что грамотный бизнес аналитик решил бы процентов 90 всех подобных проблем. Но ведь вы же не видите в этом никаких проблем? ведь так?

    Врачи всего мира говорят:
    - первый путь на пути к выздоровлению - признать что ты болен!!!

    P.S. Эх... А потом на собеседования приходят "гуру" тестеры и говорят, что тест кейсы никогда не писали. Одно только это меня отговорит брать таких спецов к себе в команду.

  14. Maksim Grinevich отметил:

    Алексей,

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

    "Вы пишите, что у вас постоянно меняются требования. Я скажу, что это бардак и избалованность вашего кастомера."
    Не всегда. У нас, например, заказчик сам является исполнителем для кого-то там ещё - и вот там творится что-то не всегда ясное. Что нам и туда аналитиков отправлять?

    А на счет "гуру" тестеров - тут вы абсолютно правы. ;)

  15. А.Б. отметил:

    Извиняюсь за категоричность... осень, депрессия, кризис среднего возраста и т.д.

  16. Unknown отметил:

    Сам неоднократно сталкивался с проблемой писать их или не писать. На разных проектах получалось по-разному, как всегда. Потом посмотрел тут Стало понятнее :)