Поставте мне правильно голову!
#1
Отправлено 17 апреля 2013 - 08:01
В должности тестировщика я недавно и у меня есть большая проблема (проблема ли?) - я не пишу тест-кейсы!
Опишу ситацию.
Тестер в компании один - я. До этого тестеров не было, и до этого я никогда тестером не работал. Тестирую один единственный сайт - сайт компании (интернет-магазин). Различные нововведения, акции и фишки на сайте появляются с завидной регулярностью. Процесс разработки (и тестирования) поставлен плохо, по сути, никак не поставлен. Собственно, тестер понадобился после многочисленных крэшей и фейлов при релизах на продакшен, когда руководство, с огорчением, на пополам с пользователями занималось отловом багов.
Так вот... Я пытался писать тест-кейсы и суиты, но все заканчивалось тем, что потом просто в них не заглядывал потому что:
1) Некоторые из них (примерно половина) доходила до автоматизма и я просто уставал каждый раз открывать и читать одно и тоже, чтобы выполнить то, что я и так уже знаю, как выполнять и чего ожидать
2) Некоторые (другая половина :) ) теряли свою актуальность из-за постоянных меняющихся требований и функционала сайта. При этом желания поддерживать состояние таких кейсов совсем не возникает.
В общем, весь опыт работы по созданию тест-кейсов - негативный, связанный с бюракратией и ни разу не эффективный.
Все это, как я понимаю, создавалось для регрессионного тестирования. Единственная альтернатива от меня этим тест-кейсам это создание автоматизированных тест-кейсов на selenium'e. Собственно, эти сделанные мною автокейсы и есть мои тест-кейсы, тупо код, без нормального, обычного документирования (как положено).
Вопрос первый: нормальна ли такая ситуация, когда тест-кейсы оформлены только в виде C# кода?
Про приемочные и интеграционные тесты.
Процесс внедрения чего-то нового у нас такой. Кто-то что придумывает (обычно руководство). Это витает в виде идеи на слуху и оформляется дай бог 5 строчками с такс менеджере. Потом основываясь на пояснении проджект менеджера программисты начинают работу (ругаясь на отсутствие ТЗ), потом часто что-то в процессе разработки меняется и программисты матерясь переделывают уже почти созданный функционал. Так может быть несколько раз. Потом когда уже все сделано говорят мне, что это нужно протестировать. Т.е. что это такое вообще, я обычно узнаю уже в конце. По хорошему, как я понимаю, я должен "готовится" к тестированию, т.е. придумывать тест-кейсы и писать тест-план в то время, когда разработчики программируют, но я этого не делаю, и начинаю тестировать просто основываясь на здравой логике, каких-то спеках (если есть), и множества вопросов к программистам и проджект менеджеру. Такой подход нисколько не внушает уверенности, что я чего-то не упустил, и в этом случае, как стало уже понятно, я тоже не пишу никаких тест-кейсов.
Вопрос второй: как быть? :)
PS: что-то много написал, надеюсь кто-нибудь поделится советом)
PS2: менять что-то в процессе разработки я уже пытался, но меня не слышат (или не хотят).
#2
Отправлено 17 апреля 2013 - 09:22
Вопрос второй: как быть? :)
Попробуйте сформулировать для себя, для чего Вам нужны тест кейсы.
Примеры формулировок:
* Чтобы не забыть выполнить все тесты
* Чтобы новым тестерам было легче работать с приложением
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать
* Чтобы произвести впечатление на руководство
* ...
После этого можно адаптировать тест кейсы, чтобы они помогали добиваться целей.
Может получиться так, что тест кейсы Вам на самом деле не нужны.
#3
Отправлено 17 апреля 2013 - 10:02
Вопрос второй: как быть? :)
Попробуйте сформулировать для себя, для чего Вам нужны тест кейсы.
Примеры формулировок:
* Чтобы не забыть выполнить все тесты
* Чтобы новым тестерам было легче работать с приложением
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать
* Чтобы произвести впечатление на руководство
* ...
После этого можно адаптировать тест кейсы, чтобы они помогали добиваться целей.
Может получиться так, что тест кейсы Вам на самом деле не нужны.
Спасибо! Если подумать, для меня тест-кейсы нужны, главным образом, как объективная оценка качества моей работы :) Ну и вроде как главное для тестировщика - тест-кейсы и еще раз тест-кейсы.
Судя по всему, для этой цели они не сильно подходят.
По пунктам:
* Чтобы не забыть выполнить все тесты - использую чек листы
* Чтобы новым тестерам было легче работать с приложением - думаю, новых пока не предвидится
* Чтобы знать, сколько еще тестов нужно написать / выполнить / автоматизировать - чек-листы и код
* Чтобы произвести впечатление на руководство - им пофиг, лишь бы багов не было
#4
Отправлено 17 апреля 2013 - 11:29
Хотя, конечно, возможно, что с ними процесс тестирования был бы на уровень качественнее - тут ничего утверждать не могу. Но пока что не вижу причин считать тест-кейсы чем-то обязательным для любого случая.
#5
Отправлено 17 апреля 2013 - 11:40
Ну и вроде как главное для тестировщика - тест-кейсы и еще раз тест-кейсы.
Думайте о тест кейсах как об инструменте.
Вот, например, для плотника главное - молоток, но если плотнику нужно бревно распилить или шкаф спроектировать - то молоток ему решать эти задачи не поможет:)
#6
Отправлено 17 апреля 2013 - 12:36
Если у вас всё работает и без тест-кейсов - забейте на них. Судя по описанию здесь неплохо было-бы наладить процесс создания новых фич. Если старый напрягает... вообще-то говоря :-)
Тест-кейсы.... если...
Понадобятся менеджеру, чтобы узнать о том, как биллинг протестирован, скажите - "а нету их" .
Понадобится новичку для вникания в проект, скажите - "а нету их".
Захочется узнать о том, что новый инженер протестировал... полезете в тесты -- "а нету их".
Понадобятся для маркетинга или заказчика, скажите - "а нету их".
Понадобится вспомнить через несолько месяцев\лет, что же за фича, и есть только "спека". А тесты... - "а нету их".
Понадобится Вам в отпуск, а проверить, что релиз выкатывать попросят программиста Викториуса. Он спросит, а что проверять? И вроде-бы тесты ему дать хочется... - "а нету их".
Я могу быть уверен "* Чтобы произвести впечатление на руководство - им пофиг, лишь бы багов не было", что багов нет? Посмотрю по тестам, как они прошли, что покрыл-что нет, может в другой стороне копнуть надо... -"а нету их".
...
#7
Отправлено 19 апреля 2013 - 04:34
* не забыть что-то проверить
* наглядно увидеть, что мы проверили, что нет
* наглядно увидеть, что работает, что нет
Для этого абсолютно бессмысленно писать длинные тесты, такие нужны только для передачи знаний (другим сотрудникам или "себе из будущего"). А если всё делается на автоматизме - зачем? Вполне достаточно перечислить в виде таблички список того, что надо проверить, и помечать результаты тестирования плюсами или минусами. Тогда и не забудете, и оценку тестированию и продукту получите, и не будете тратить лишнее время на расписывание кучи буковок, которые всё равно бессмысленны в Вашем случае.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#8
Отправлено 19 апреля 2013 - 05:54
Тестовая документация, на мой взгляд, чаще всего нужна для того, чтобы:
* не забыть что-то проверить
* наглядно увидеть, что мы проверили, что нет
* наглядно увидеть, что работает, что нет
Для этого абсолютно бессмысленно писать длинные тесты, такие нужны только для передачи знаний (другим сотрудникам или "себе из будущего"). А если всё делается на автоматизме - зачем? Вполне достаточно перечислить в виде таблички список того, что надо проверить, и помечать результаты тестирования плюсами или минусами. Тогда и не забудете, и оценку тестированию и продукту получите, и не будете тратить лишнее время на расписывание кучи буковок, которые всё равно бессмысленны в Вашем случае.
Это случаем не чек лист?
#9
Отправлено 19 апреля 2013 - 13:35
Тестовая документация, на мой взгляд, чаще всего нужна для того, чтобы:
* не забыть что-то проверить
* наглядно увидеть, что мы проверили, что нет
* наглядно увидеть, что работает, что нет
Для этого абсолютно бессмысленно писать длинные тесты, такие нужны только для передачи знаний (другим сотрудникам или "себе из будущего"). А если всё делается на автоматизме - зачем? Вполне достаточно перечислить в виде таблички список того, что надо проверить, и помечать результаты тестирования плюсами или минусами. Тогда и не забудете, и оценку тестированию и продукту получите, и не будете тратить лишнее время на расписывание кучи буковок, которые всё равно бессмысленны в Вашем случае.
Это случаем не чек лист? />
Тоже так кажется, чек-листы у меня есть) Спасибо всем в любом случае, для себя сделал выводы :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных