Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 24 декабря
Автоматизация функционального тестирования
онлайн, начало 27 ноября
Логи как инструмент тестировщика
онлайн, начало 30 ноября
Тестирование REST API
онлайн, начало 30 ноября
Фотография

Нужен совет по дизайну тестов и организации их хранения


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 10

#1 Once

Once

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 18 февраля 2011 - 20:14

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

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

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

Вобщем, мой вопрос - каким образом проектировать тесты (какова должна быть их детализация) и от чего отталкиваться в первую очередь? От декомпозиции функций программы или от декомпозиции требований? Как связать между собой эти вещи? Какое представление (или какой инструмент) для этого лучше использовать?

Да, еще один ньюанс состоит в том, что четко формализованных и специфицированных требований нету (изначально при работе над проектом работа с требованиями была организована не лучшим образом). Т.е. мне придется как бы «выявлять» требования из уже имеющейся программы + какой-то еще доп.информации (ее источники имеются).

Пока строю свою работу следующим образом – в excel постепенно строю и детализирую дерево функций. Для каждой минимальной, недробимой более функции, делаю тест (пока по 1 штуке – т.н. positive). Далее планирую расширить набор тестов за счет анализа граничных значений и т.д.. и т.п… все по книжке того же Канера.
Тут же в excel – при переходе к тестированию следующей версии программы - копирую целиком имеющееся на текущий момент дерево с привязанными тестами на новый лист, обзываю новый лист номером тестируемой версии, тестирую то, что еще не протестировано, расширяю и детализирую дерево функций на новом листе и т.д. в том же духе.
Как тут лучше прикрутить требования?
Правильно ли я организовал свою работу, чтобы в дальнейшем не возникло каких-либо проблем с анализом информации, полнотой покрытия требований/функционала? Мне с моим небольшим опытом в тестинге пока сложно это оценить…

Буду очень признателен за любую помощь в разъяснении этих вопросов.
  • 0

#2 CVD1

CVD1

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 19 февраля 2011 - 09:55

1) Мне кажется, ваш подход приемлем, но только если трудоемкость не зашкаливает. Скажите, вы оценили сколько времени потребуется на полное тестовое покрытие?
2) Не приходила ли в голову мысль объединить позитивные проверки функций в логически связанные последовательности, в так называемые сценарии использования или сценарии тестирования?
3) Если хватает времени, на каждый позитивный тест необходим и негативный в дополнение.
  • 0

#3 Once

Once

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 20 февраля 2011 - 12:19

Спасибо за комментарий. Отвечу по-порядку:

1) Нет, честно говоря, такую оценку не проводил. Но пока время вроде есть, не поджимает..
Правильно ли я понимаю вашу мысль, что в случае, если дедлайн все-же близок, и чувствуется, что времени на все возможные проверки не хватит, то следует провести проверки только по очевидным сценариям использования, которые возникнут у конченых пользователей?
2) Да, такая мысль приходила. Я так понимаю, такая цепочка из миимальных тестов будет представлять собой "большой" тест-кейс? А все,что в него не войдет - это потом тестировать дополнительно, если останется время? нужно ли отдельно фиксировать этот "большой" тест-кейс в тест-плане? или ограничиваться просто включением его "маленьких" составляющих?
Как лучше (в каком представлении ) вести перечень необходимых тест-сценариев в привязке к дереву функциональности?

3) да, по этому пункту понимание есть, я так и планировал..
  • 0

#4 CVD1

CVD1

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 20 февраля 2011 - 15:04

1) Нет, честно говоря, такую оценку не проводил. Но пока время вроде есть, не поджимает..

На мой взгляд, это ошибка (естественная для новичка). Советовал бы вам записывать статистику - сколько времени вам требуется на описание тест кейсов. Попробуйте так поработать неделю, а потом прикиньте, в какую трудоемкость выльется такой подход. У меня, к примеру, есть такой эксель файл. Очень полезная вещь.

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

Ну зачем же так о них ;-) На пользователя надо молиться;-)
Я бы сказал, что правильнее охватить весь функционал общим взглядом и выделить критически важные проверки - их минимально необходимый объем и трудоемкость прогона. Отталкиваясь от этого фундамента, вы сможете более-менее уверенно делать быстрый и адекватный срез состояния системы. А затем наращивать объем тестов при наличии времени на это. Времени на все возможные проверки на хватает никогда, все возможные проверки описать невозможно (но не говорите об этом заказчику);-).

Да, такая мысль приходила. Я так понимаю, такая цепочка из минимальных тестов будет представлять собой "большой" тест-кейс? А все,что в него не войдет - это потом тестировать дополнительно, если останется время? нужно ли отдельно фиксировать этот "большой" тест-кейс в тест-плане? или ограничиваться просто включением его "маленьких" составляющих?
Как лучше (в каком представлении ) вести перечень необходимых тест-сценариев в привязке к дереву функциональности?

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

#5 Drag

Drag

    Активный участник

  • Members
  • PipPip
  • 123 сообщений


Отправлено 21 февраля 2011 - 01:58

Я бы посоветовала исходить из нескольких правил:
1. Чтобы было удобно пользоваться вам,
2. Чтобы кто-то сторонний мог тоже в этом разобраться,
3. Чтобы доки были в сохранности (а то неудачное нажатие кнопки и все накрывается тазом),
4. Чтобы через несколько недель посмотрев на доки вы не пугались и не думали "что это такое",
5. Для начала продумайте какие документы вам понадобятся, затем как вы их будете различать между собой (система нумерации например), затем мелочи типа стандарта оформления.

Что касается вопроса "что есть тест кейс" на это сложновато дать конкретный ответ, т.к. многие пользуются простейшими чек листами (список что надо проверить) и не расписывают их в конкретные кейсы. И ничего страшного в этом нет - все зависит от времени выделенного на оформление документации.
  • 0

#6 Tuchka_84

Tuchka_84

    Активный участник

  • Members
  • PipPip
  • 105 сообщений
  • ФИО:Маша

Отправлено 21 февраля 2011 - 10:03

Здравствуйте,
Возможно для объединения всей структуры Вам подойдет бесплатная программа TestLink.
Вместо копирования эксель документов, там можно просто создать новую версию продукта и новую версию теста. Тест прямо там можно дополнять( например, у Вас в программе расширился функционал пару пунктов добавляете). Еще там удобно спецификации(требования ТЗ) привязывать к тестам.
Мне удобно этой штукой пользоваться.
  • 0

#7 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 27 февраля 2011 - 09:18

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

На собственном опыте могу Вам сказать, что в один прекрасный день Вы заметите, что катастрофически не успеваете ;)
Это сейчас времени вагон. Как я поняла, Вы проводите сейчас только pozitiv testing?
Я воспользуюсь советом, который мне дали, и скажу вам так - возьмите весь функционал, напишите чек-лист, разбейте на категории,проведите pozitiv testing всех компонентов.
Следующим пунктом будете по мере критичности и необходимости тестировать все более детально, постепенно превращая данный раздел в чек -листе в качественный и подробный тест-кейс.

Таким образом у вас будет статистика выполненной работы, время на это затраченное и "черновик" будущего тест-кейса одновременно.

Еще один совет - не углубляйтесь сейчас в "дизайн" особо. :acute: Когда у Вас будет практически все готово - тогда приведете свой труд в более приятный для взгляда вид.
Все что Вам сейчас необходимо - информация.

Есть у меня один знакомый тестировщик, который очень любит красивые таблички exel(кто ж их не любит), так вот, он каждый раз Х времени тратил на "разукрашку" тест-кейса.
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.

#8 CVD1

CVD1

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 27 февраля 2011 - 13:56

И постепенно чек-лист превратится в полноценный тест-план. :good:
  • 0

#9 ivayi

ivayi

    Новый участник

  • Members
  • Pip
  • 7 сообщений
  • ФИО:Ironia

Отправлено 27 февраля 2011 - 19:26

+1 к тем кто советовал чек листы.
От себя хочу добавить, пока кейсов мало их легко проходит для каждого билда/ релиза. Когда на прохождение кейсов тратиться больше времени чем требуется для выхода нового билда, то требуются приоритеты. Да и нет большой пользы проверять каждую неделю например одну и ту же валидацию в одной и той же форме. Гораздо интереснее/ труднее / а зачастую и важнее для продукта проверять бизнес логику
Расставлять приоритеты лучше сразу, их проще потом в 2 -5 местах исправить чем сидеть и проставлять для 1000 кейсов
  • 0

#10 Nemora

Nemora

    Новый участник

  • Members
  • Pip
  • 8 сообщений

Отправлено 04 марта 2011 - 12:59

За последнюю неделю 2 раза обжегся на том, что не посмотрел в 2-х проектах на самую простую вещь, искал падение или что-то страшное, а как оказалось надо было посмотреть самое простое, так как разработчики умудрились сломать то, что работало идеально уже кучу билдов подряд.
Вывод: смотреть на элементарное, очень часто разработчики не проверяют самые элементарный вещи.
  • 0

#11 Zhu

Zhu

    Опытный участник

  • Members
  • PipPipPipPip
  • 288 сообщений
  • ФИО:Рина Ужевко
  • Город:Москва


Отправлено 04 марта 2011 - 14:31

Вывод: смотреть на элементарное, очень часто разработчики не проверяют самые элементарный вещи.



как по мне, не совсем верный вывод)
смотреть нужно на все и всегда! =)

У разработчиков ВСЕГДА ВСЁ работает, они ВСЕ проверили и т.д.
На практике же, как минимум один баг, но найду)

Вобще, сложилось ощущение, что Вы регрессивное тестирование не проводите)
  • 0
Bugs@Feature
Не бывает совершенных программ, бывают недотестированные.


Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале