Форум Сообщества Аналитиков

×


Test Case & Test Analyst (Прочитано 56629 раз)
Re: Test Case & Test Analyst Ответ #45 : 08 Декабря 2008, 17:15:07
Вот и наметилась основа для семинара "Нафига нужны тесткейсы". :) Осталось только под шаблон подогнать.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Test Case & Test Analyst Ответ #46 : 08 Декабря 2008, 17:35:37
Первая жизненно важная функция тест кейсов - документирование нашего знания о желаемом поведении продукта. Тест кейс - это ведь не только что мы хотим сделать руками. Это и что мы ожидаем, и как мы конкретно удостоверимся в получении правильного результата.

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

Третье - документирование того что будет проверяться/проверялось во время тестирования.

Четвертое - Тест кейсы совершенно незаменимы там, где пишутся автоматизированные тесты. Как бы хорошо Вы ни знали Силк или ВинРаннер, надо знать что с этим тулом делать в конкретной ситуации. Автоматизация тестирования без наличия добротных тест кейсов превращается в профанацию и только дискредитирует идею автоматического тестирования как таковую.
Рад что наши мнения совпадают.
А вот руководитель мой считает иначе. :-(



Re: Test Case & Test Analyst Ответ #47 : 08 Декабря 2008, 17:49:54
Вот и наметилась основа для семинара "Нафига нужны тесткейсы". :) Осталось только под шаблон подогнать.
Ага, будет хорошим продолжением семинара в Спб. Наши коллеги из другого лагеря (Саша и Сергей) не хотят провести такой семинар?? ;)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Test Case & Test Analyst Ответ #48 : 08 Декабря 2008, 18:18:02
Можно я тоже выскажусь.

Сейчас в компании, в которой я работаю, я как раз отвечаю за это самое тестирование.

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

Такой процесс не дает никакой реальной пользы. Почему?
1. выявить все ошибки не возможно
2. человек даже самый аккуратный не в силах методично и систематически проверять систему (тем более без всякого плана)
3. просто физически аналитик не в состоянии прогнать даже все тесты, которые у него сидять в голове, а следовательно его выводам мало доверия

Простой пример: у меня сейчас сделано не так много тестов, но некоторые направления более или менее покрыты. Например нужно посмотреть работает биллинг или нет. Как обычно поступает аналитик(он же по совместительству тестер). Запускает билинг, выбирает каких-то двух трех клиентов и смотри - о все окей.
Как я поступил - во-первых я выбрал 50 разных клиентов (т.е. с разными начальными условиями). Я написал ОДНУ процедуру проверки и запустил ВСЕХ 50 клиентов на проверку. Из них 10 клиентов не прошли.Причем как выяснилось проблема не в алгоритме биллинга, а некоторых предварительных действиях. Вот этих 10 клиентов при старом подходе мы бы пропустили, а так удалось найти ошибки совершенно другого характера.

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

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

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

Не знаю как в других системах, но в TestComplete есть так называемые сценарии ручного тестирования, которые можно просто понимать как мастера освоения работы с системой :)




Re: Test Case & Test Analyst Ответ #49 : 09 Декабря 2008, 11:23:08
А есть утилитки которые могут помочь в генерации Test Case?



Re: Test Case & Test Analyst Ответ #50 : 09 Декабря 2008, 18:29:12
А есть утилитки которые могут помочь в генерации Test Case?
Андрей, что значит утилитки? И что значет помочь в генерации?

Тестовый случай разрабатываете вы сами. Опять же на каком уровне. На уровне тестирования классов, функций или процедур - тут одно и средства такие есть насколько мне известно.

Если на уровне тестирования интерфейса, функционального тестирования черного ящика, то есть множестов систем захвата и воспроизводства. В частности Test Complete (http://automatedqa.com).
Он помогает записывать ваши действия с тестируемым приложением. Обычно потребуется некоторая правка полученного макроса.
В TestComplete входят типа утилит программы рекодеры, но только в профессиональной редакции.



Re: Test Case & Test Analyst Ответ #51 : 10 Декабря 2008, 20:05:08
Хорошая статья "TOP 13 ошибок тестировщиков".
Первая часть как раз, главным образом, о тест-кейсах (и немного о требованиях).

http://www.software-testing.ru/library/5-testing/66-top-13----i----

greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Test Case & Test Analyst Ответ #52 : 10 Декабря 2008, 20:09:21
Для тех, кого заинтересовала статья, продолжение здесь (в первой части я не нашёл ссылки на продолжение):

http://www.software-testing.ru/library/testing/bug-tracking/65-top-13-ii-
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Test Case & Test Analyst Ответ #53 : 11 Декабря 2008, 16:11:50
Спасибо за ссылки статей. Довольно интересно



Re: Test Case & Test Analyst Ответ #54 : 12 Декабря 2008, 10:16:45
Спасибо за статью.Хорошо описан пример.Увидел что часть документации у нас написано с ошибками.
Примерно так:

Шаги:
1. Действие 1
2. Действие 2
3. Действие 3
4. Действие 4

Ожидаемые результаты:
1. Результат 1
2. Результат 2
3. Результат 3
4. Результат 4

А для чего нужны Test Plan(тестовые планы)?
Покажите примерчик плиз
« Последнее редактирование: 12 Декабря 2008, 13:20:31 от Бобылёв Андрей »



Re: Test Case & Test Analyst Ответ #55 : 12 Декабря 2008, 12:53:58
Вопрос по Test Case
Какой вариант более правильнее в написании.Вернее сказать более распространен.
Вариант 1
Название теста
1 Шаг №
2 Описание действий
3 Описание ожидаемого результата
4 Результат

Вариант 2 (См вложение)
Название теста
1 Шаг №
2 Описание действий
3 Скриншот ожидаемого действия
4 Результат



Re: Test Case & Test Analyst Ответ #56 : 12 Декабря 2008, 13:10:31
Вопрос по Test Case
Какой вариант более правильнее в написании.Вернее сказать более распространен.
Вариант 1
3 Описание ожидаемого результата

Вариант 2 (См вложение)
3 Скриншот ожидаемого действия
4 Результат
Более правильный тот вариант, который удобней и понятней в использовании в конкретной задаче конкретным людям. Если результатом должен быть вывод какой-то визуальной информации, то обычно удобней скриншот, если какие-то изменения в данных, еще где-то или скриншота еще физически не существует, то описание.
Это не догма, здесь все подбирается под конкретную задачу. Если некий вариант решает задачу, поставленную перед ним, значит, он и есть правильный.



Re: Test Case & Test Analyst Ответ #57 : 12 Декабря 2008, 13:22:18
А какова в среднеем время изготовления одного Test Case?
И каково в среднем их колличество(10 , 50,100 шт)?
« Последнее редактирование: 12 Декабря 2008, 13:27:29 от Бобылёв Андрей »



Re: Test Case & Test Analyst Ответ #58 : 12 Декабря 2008, 15:28:40
А какова в среднеем время изготовления одного Test Case?
И каково в среднем их колличество(10 , 50,100 шт)?
Ну как можно ответить на эти вопросы, не зная конкретики системы и квалификации писателя?!



Re: Test Case & Test Analyst Ответ #59 : 12 Декабря 2008, 17:42:08
Андрей, описание тестовго случая должно быть конкретным до мелочей. Будете ли Вы иметь такое описание в виде текста или возможно у Вас будет сразу тестовый скрипт, зависит от того, как организована работа у Вас.

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

Подробное описание тестового случая само по себе очень полезно. Имея его, при отсутствии автоматизированного теста, всегда можно поручить поверить тест практически любому человеку. Более того, эти описания можно дать тем же заказчикам для приемочного тестирования. Да и как говорил Александр Лобач - эти описания могут быть положены в основу обучения пользователей работе с программой.

Вы задаете вопрос лучше описание результата или скриншот: сильно зависит от ситуации. Однако представьте что вы выкладываете скриншот печатной формы документа. Проверять все? Тяжелая работа да иногда и не очень корректная.

Я стараюсь разбивать тестовые случая на мелкие элементы, но никто не запрещает объединять их в тестовые процедуру.

Количество тестов в минимуме должно соотвествовать количеству требований к системе. Но это недостижимый идеал. Причем ведь надо еще подумать как о положительном тесте, так и отрицательным.

Потому нужно определится со стратегией: как что когда зачем.

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

Время затрат на разработку теста весьма различно. Простой тест - если описание разработать можно очень быстро. Даже если писать скрипт, то тоже не слишком долго, пр определенном навыке. Больше времени уходит на объединение, оптимизацию и интеграцию. Но в среднем удается сделать 4 теста, или меньше (правда я беру только 4-5 часов)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19