А так ли нужны test cases ?
вторник, июля 21, 2009
А так ли нужны test cases, когда нет времени на регрессионное тестирование вообще?
В небольшой фирме, где я сейчас работаю, времени на тестирование выделяется ровно столько, сколько необходимо на верификацию bugs, проверку новых features и прогонку smoke теста при выпуске нового патча.
Я привык относится к тестированию более систематически — прочитал книги Канера и иже с ним, в подборке куча регулярно читаемых «светил» отрасли и т.д. (здесь умышленно не касаюсь практического опыта) — и считаю, что хорошо построенный процесс тестирования (читай всей разработки) приводит к хорошему результату.
Но совсем недавно, на очередном team meeting, мне подумалось: А зачем писать test cases, если их никто не использует? (Честно говоря, они нужны только нашему заказчику, да и то раз в год...)
Подумал... и сам испугался: неужели я ставлю себя умнее, чем все эти умудренные опытом люди? Но потом мне вспомнилось цитата какого-то умного человека «документ пишется не для документа, а что бы документ использовался» (вольная интерпритация)
И в итоге вывод, который я сделал для себя, гонка за «процессом», «как нужно», «как написано» и т.д. не приводит к результату, если в этом нет необходимости.
Вода течет только туда, где есть место — «правильный» процесс тестирования нужно внедрять там, где без него невозможно жить, а «сопокойные» места (где нет проблем) лучше не трогать.
Умный человек писал:
По сложившейся традиции вся учебная литература мира информационных технологий обучает читателей и студентов разрабатывать объемную и подробную тестовую документацию. Мы позволим себе не согласиться с этой традицией, поскольку наш опыт свидетельствует, что документация не должна быть впечатляющей - она должна быть эффективной.
Сем Канер и др. Тестирование ПО
Собственно, мысль классиков жанра только подтверждает мои мысли.
Но!
Что мы оставим после того как пардон уволимся? Ушла полностью группа тестировщиков - либо необходимо передать на аутсорсинг тестирование и тут документация как никогда нужна. Хотя бы чек листы. Хотя бы названия тестов.
Во-первых, есть Smoke Test - всё-таки один документ мы пишем и держим up2date. Во-вторых, большая часть вины/нагрузки ложится на менеджмент, который поставлен в известность: либо больше времени, либо отсутствие документов и риски с этим связанные.
Ну да конечно. К пуговицам претензий нет ;)). Может стоит иногда думать что кроме менеджмента думать головой нужно и самому тестеру?
ИМХО но планирование и документация - альфа и омега преемственности. А к тому же - "если не не знаешь куда собирался идти - не удивляйся что пришел не туда." Если ты не планируешь выпускать качественный программный продукт то и не стоит его выпускать.
Я же говорю: документы это хорошо. Но если ты поставлен в ситуацию выбора: либо проверишь толково конкретную feature или напишешь test case по ней, то что ты выберешь?
Я выберу сделать то, что от меня ожидает работодатель - обеспечу релиз хорошо проверенного ПО, а не описанного в документах.
Кроме того, работая даже в конторе с CMMI 4 уровня (кажется это так называлось), вся документация (и тест план в том числе) писалась в основном после выпуска продукта и только для Quality Assurance отдела. Ив таком безплановом тестировании выпускались дествительно стоящие вещи.
Думаю, что не все так однозначно даже с приемственностью: всегда можно сделать неделю/месяц на передачу дел... и основы рассказать, а нюансы - приходится чем-то жертвовать...
Ну что сказать... Каждому свое, но все же отказ от тест кейсов это скорее зло, чем добро.
Были в моей практике проекты, на которых я лично писал банальные "чеклисты", а не тест кейсы. Но это уже другая история.
Отказавшись от тест кейсов мы получаем риски, самый явный из них - пропустить в продакшн какую-нить мелкую багу, исправление которой будет стоить уже не так мало. Вы скажете, что и с тест кейсами может так выйти. Я соглашусь - МОЖЕТ, но тогда у вас, по крайней мере, будет известна фамилия того, кто и по какой причине пропустил багу, и Вы сможете предпринять некие действия, для предотвращения повторения подобной ситуации.
Мы пишем кейсы не из головы, а исходя из чего-то в виде спецификаций, требований, юзкейсов и т.д. Эти кейсы - покрывают тестами только описанные части системы. Плюс к ним еще добавляется куча кейсов, которые пишутся исходя из опыта работы тестера.
Набор тест кейсов может быть бесконечно большим, а нужно ли это? Для увеличения покрытия - ДА. Но тут вопрос, какое покрытие тестами нам необходимо? ИМХО, отсюда вывод зная покрытие, мы можем управлять качеством тестирования.
А можете ли вы это делать не имея тест кейсов?
Вывод такой, без тест кейсов мы делаем процедуру тестирования неуправляемой и бесконтрольной.
Вот.
Алексей,
Во-первых, если вы ссылаетесь на тест кейсы. значит у вас есть время на регрессию. В своей же заметке я писал, что у нас просто НЕТ на это время. Единственное, что мы можем сделать - прогнать смок тест (он обновляется и хранится up2date)
На счет пропуска баги и привязки к кейсам: т.е. при начальном тестировании фичи тестер пишет ещё и кейсы, затем через Х времени вылазит мелкая ошибка. И вы, смотря в кейсы, находите того, кто пропустил эту багу и ...
Но для этого есть - баг(issue) трэкер. Он покажет, кто тестил ту или иную функциональность.
С вашим подходом проверка и описание мелочей не попадает в кейсы (мне так показалось, по крайней мере).
А судить о "покрытии" по количеству написанных кейсов - не думаю, что это истина.
Вернее будет судить о покрытии, по количеству рпогнанных кейсов на данном билде (надеюсь у вас именно так)... а вот ТУТ и кроется суть вопроса: у нас НЕТ времени на прогонку полной регрессии. А в смоук мы добавлем самое-самое-самое-...-самое важное
Мое предложение - не попытка вывести что-то новое - это способ жить и работать в тех условиях, что предоставлены заказчиком/работодателем
Начнем по порядку!
"Но для этого есть - баг(issue) трэкер. Он покажет, кто тестил ту или иную функциональность."
Ситуация 1 - нет тест кейсов:
- Вася, ты тестировал форму логина?
- Да
- а почему ты не проверил, вот такую вот фичу?
- Э-э, ну. Забыл...
Ситуация 2 - есть кейсы
- Вася, ты тестировал форму логина?
- Да
Вариант А:
- Ты прошел все тест кейсы назначенные на тебя?
- Да
- Молодец.
Вариант Б:
- а почему ты не проверил, вот такую вот такой тест кейс, который был на тебя назначен?
- Э-э, ну. Забыл...
- Вася, двойка тебе и родителей в школу...
Разница видна? Мне она очевидна - при написанном тест кейсе очень сложно пропустить что-то, если оно задокументировано и ты идешь по описанным шагам...
Дальше:
"С вашим подходом проверка и описание мелочей не попадает в кейсы"
С моим подходом в кейсы попадаёт все, что описано в спецификации, а так же туда попадают случаи появившиеся в процессе тестирования или взятые из БестПрактис (кстати, если такие есть, то их нужно переносить в спеки, т.к. их наличие показывает неполноту описания требований). Вообще мой подход такой: "если все, что должно работать работает как описано в спеке, значит можно поискать что-то, что выходит за ее пределы." Т.к. если приложение будет очень красивым, без видимых багов, но не будет, по некоторым причинам, выполнять свои прямые функции, то оно не нужно заказчику в таком виде...
Максим, я не в коем случае не навязываю свою точку зрения, я лишь говорю, что отсутствие кейсов увеличивает риски и управляемость...
Алексей, да.. существование кейсов только на пользу...
В обоих ваших ситуациях вы рассматриваете процедуру регрессионного тестирования, когда тестировщики "ходят" по написанным кейсам.
Но если взять во внимание ситауцию, описанную мной выше. такого случая не предвидется в ближайшее время.
Риски связанные с этим понятны, ваша к ним аппиляция - тоже. Тут вы правы, но приходится выбирать... и выбор не в пользу кейсов.
Договорились... :)
Кстати, вот попалось на глаза определение:
Тестирование - проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
Сама уже много времени задаю себе тот же вопрос и прихожу примерно к такому же выводу, как автор поста.
Мы в своем проекте сначала писали ТК. Потом перестали. И качество никак не изменилось :).
Как выразился в комментарии Алексей Булат "
Мы пишем кейсы не из головы, а исходя из чего-то в виде спецификаций, требований, юзкейсов и т.д.". Вопрос - Зачем переписивать информацию из одного места в другое? :)
Сейчас мы поступаем так. Из требования заказчика, как водится, составляем документ "Спецификация требований". согласовываем с щаказчиком. И начинаем разработку. Как известно, во время разработки требования неоднократно уточняются :). Все уточнения аккуратно исправляем в спеке.
А если бы мы начали сразу по первому спеку писать ТК - пришлось бы еще править кучу ТК. Двойная работа! Оно нам надо?
Когда программысты отдают нам "готовую" функциональность (тестируем мы по мере разработки, а не вконце, что я тоже считаю очень правильнм подходом). Так вот, при получении новой функциональности для тестирования мы берем спек, распечатываем:) и идеи по нему. Проверил пункт - поставил +. Нашел багу - поставил - и номер баги. Все как в тест менеджмент системе:)
Если тестеров в команде несколько, спек делится поровну между всеми. В следующей итерации можно поменятся.
В таком подходе есть еще один важный плюс. Спек (особенно подробный и ясный, как у нас) очень полезен для программистов. А ТК для программитстов никакой пользы не представляют.
И еще плюс - нам не нужно отдельно тестировать требования. Потому как мы их сами пишем и самы обновляем, ведь это наш основной рабочий документ.
Также, автоматически решается проблема сохранения актуальной! документации для следующих поколений, что будут работать на проекте :)
Уважаемая, emeralda.
Что я могу сказать... Если вы считаете тот процесс, по которому вы работаете, удобным и он дает вашей команде какие-то бенефиты, то это очень даже хорошо. Поздравляю, вы разработали идеальный процесс для Вашей отдельно взятой команды.
Вы пишите, что у вас постоянно меняются требования. Я скажу, что это бардак и избалованность вашего кастомера. (Хотя конечно Вам удобно, он же платит).
Мне кажется, что грамотный бизнес аналитик решил бы процентов 90 всех подобных проблем. Но ведь вы же не видите в этом никаких проблем? ведь так?
Врачи всего мира говорят:
- первый путь на пути к выздоровлению - признать что ты болен!!!
P.S. Эх... А потом на собеседования приходят "гуру" тестеры и говорят, что тест кейсы никогда не писали. Одно только это меня отговорит брать таких спецов к себе в команду.
Алексей,
Не стоит быть таким категоричным. Если вы в своей рабочей практике не сталкивались с заказчиками, которые ведут себя немного не так как большинство - не значит, что такого не может быть.
"Вы пишите, что у вас постоянно меняются требования. Я скажу, что это бардак и избалованность вашего кастомера."
Не всегда. У нас, например, заказчик сам является исполнителем для кого-то там ещё - и вот там творится что-то не всегда ясное. Что нам и туда аналитиков отправлять?
А на счет "гуру" тестеров - тут вы абсолютно правы. ;)
Извиняюсь за категоричность... осень, депрессия, кризис среднего возраста и т.д.
Сам неоднократно сталкивался с проблемой писать их или не писать. На разных проектах получалось по-разному, как всегда. Потом посмотрел тут Стало понятнее :)