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

Фотография

Как вовремя остановиться?


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

#1 nadezhda_potaenko

nadezhda_potaenko

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Потаенко Надежда Вячеславовна


Отправлено 30 марта 2016 - 15:09

Уважаемые гуру тест - дизайна, нужна помощь.

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

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

Сначала я подумала: "Чего проще?" - но чем дольше думала, тем больше путалась. Наверное, я слишком привыкла к знанию всех важных для анализа моментов. А теперь у  меня вызывает бурю сомнений такая вещь: текстовое поле для ввода e-mail. Сначала я кинулась составлять кучу кейсов, с содержанием в имени типографских символов и с нестандартно - длинными доменными частями и т.п. Но потом задумалась.... В реальности, как часто я в жизни сталкиваюсь с тем, что при регистрации в форуме автомобилистов проверяется мой e-mail на корректность так дотошно? Ну, не получу письмо со ссылкой о подтверждении регистрации - сама себе сделаю хуже... И вот с точки зрения здравой логики, мне не кажутся нужными эти 30 проверок несчастного e-mail...
Да, я знаю, правило, что раз ящик черный, то проверять надо все. Но где границы этого "все"?

Как бы вы подошли к такому ящику, чтобы не скатываться до абсурда? 


  • 0

#2 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 30 марта 2016 - 15:34

Проверять вообще все не надо :)
Вы правильно думаете, что проверять надо только наиболее приоритетное.

Надо определить ограничение и исходить из него.
Это могут быть:
1. Время
2. Пройденные бизнес-сценарии, юз-кейсы, тест-сценарии, тест-кейсы итд.
3. Требования к качеству продукта
4. Стоимость обнаружения ошибки (которая выше потенциальных убытков от ее необнаружения)
и пр.

Один из возможных вариантов действий:
1. Определяем наши ограничения по времени
2. Определяем наиболее критичные сценарии
3. Составляем по ним тесты, прогоняем.
4. Находим менее приоритетные сценарии
5. Составляем тесты прогоняем.
6. Повторяем пункты 4-5, пока не закончится время.

В ходе выполнения тестирования вы можете и не упереться в нехватку времени, если вдруг поймете, что все основные сценарии пройдены, и дальше тестировать будет уже неэффективно - мы придумаем еще 30 тестов, выполним, и вдруг выяснится, что нельзя зарегаться с иероглифами в email на портале lada-kalina-sport2.spb.ru :) Результат этого теста нам как-то не особо важен.
  • 0

#3 nadezhda_potaenko

nadezhda_potaenko

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

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Потаенко Надежда Вячеславовна


Отправлено 30 марта 2016 - 15:45

Проверять вообще все не надо :)
Вы правильно думаете, что проверять надо только наиболее приоритетное.

Надо определить ограничение и исходить из него.
Это могут быть:
1. Время
2. Пройденные бизнес-сценарии, юз-кейсы, тест-сценарии, тест-кейсы итд.
3. Требования к качеству продукта
4. Стоимость обнаружения ошибки (которая выше потенциальных убытков от ее необнаружения)
и пр.

Один из возможных вариантов действий:
1. Определяем наши ограничения по времени
2. Определяем наиболее критичные сценарии
3. Составляем по ним тесты, прогоняем.
4. Находим менее приоритетные сценарии
5. Составляем тесты прогоняем.
6. Повторяем пункты 4-5, пока не закончится время.

В ходе выполнения тестирования вы можете и не упереться в нехватку времени, если вдруг поймете, что все основные сценарии пройдены, и дальше тестировать будет уже неэффективно - мы придумаем еще 30 тестов, выполним, и вдруг выяснится, что нельзя зарегаться с иероглифами в email на портале lada-kalina-sport2.spb.ru :) Результат этого теста нам как-то не особо важен.

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


  • 0

#4 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 527 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 31 марта 2016 - 09:01

 

 

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

 

 

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


  • 0

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



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

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