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

Фотография

Кривая спецификация


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

#1 Lyzzochka

Lyzzochka

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

  • Members
  • Pip
  • 12 сообщений
  • Город:Минск

Отправлено 16 августа 2006 - 12:19

Для начала попытаюсь описать ситуацию:
На нашем проекте только два тестировщика с опытом работы по полтора месяца, я среди нас, так сказать, тим лид, за неимением более знающего человека. Только-только сдан бета-релиз. Мы его тестировали следующим образом - написаные тесткейсы(ужасные - по причине отвратительной спецификации) мы использовали для smoke теста, а тестировали уже без каких-либо тесткейсов интуитивно. Сейчас начинает разрабатываться новая часть проекта, только что мне дали требования и я не знаю что с ними делать :victory: Проект менеджер вообще не общался с нами по проекту, изредка через письма, а сейчас вообще укатил в отпуск. Требования опять ужасные: с ошибками, неполные, двусмысленные. Я вот думаю, то ли исправить спецификацию, написать список вопросов и отправить заказчику, а потом уже писать тесткейсы; то ли написать кейсы для этого кривого документа, а менеджер проекта пусть сам со всем разбирается, если руки дойдут? А еще, является ли необходимым тестировать только по тесткейсам, если проект не очень большой?
  • 0

#2 Mishelka

Mishelka

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

  • Members
  • Pip
  • 19 сообщений
  • Город:Киев

Отправлено 17 августа 2006 - 06:24

Цель тестирования - гарантировать, что все требования клиента реализованы и реализованы корректно.
Отсюда вытекает, что QA обязан анализировать требования и добиваться их корректной интерпретации. То есть, если у вас возникают вопросы/комментарии к спецификации, необходимо комментировать спеку (просто в режиме правок) или выписывать вопросы и потом с этим списком говорить с PM или бизнес-аналитиком (кто там спеки писал) или со всеми - быстрее истина выяснится. В результате, кое-где спека будет подправлена, некоторые вопросы будут заданы клиенту. И тестировать уже будете корректные и понятные требования. Вообще, QA должен стремиться к тому, чтобы клиент-разработчик-QA трактовали требования одинаково.

Во-вторых, я считаю, что в проектах для заказчика из СНГ, например, не дается достаточно времени для написания тест кейсов, покрывающих все требования. Часто получается, что достаточно хотя бы чек-лист сделать исчерпывающий, чтоб он хоть одержал все моменты, которые надо тестировать. До тест кейсов вы вряд ли дойдете. Или напишете самые критичные. И это нормально. Без интуитивного тестирования - никуда. Могут быть проекты, в которые бессмысленно писать тест-кейсы (и проект не сложный, и времени нет). Если QA вменяем - результат будет хороший. Если спека суперского качества, хорошие коммуникации с остальными членами команды (PM, разработчики) - и без тест кейсов можно обойтись, если времени не выделено на это.
Просто во многих конторах начинают писать тест кейсы (что хорошо, в принципе), НО не все остается охваченным, в требованиях нормально не копаются....В результате результаты качество продукта - ужасающе:( Время и ресурсы нужн отратить оптимально! Выбирайте - в какой форме делать тест дизайн, как глубоко и т.п.
  • 0

#3 Romich

Romich

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

  • Members
  • Pip
  • 27 сообщений
  • ФИО:Статкевич Роман Борисович
  • Город:г. Днепропетровск, Украина

Отправлено 17 августа 2006 - 06:54

Я тоже считаю, что писать тест-кейсы можно только когда есть хорошая и прозрачная спецификация. Написание толковых тест-кейсов занимает по времени 50% всего тестирования (по крайней мере у нас). Обычно их просто просят заказчики и мы с учетом всех найденных перед этим багов пишем тест-кейсы, которые покрывают общие вещи и углубляются только в тех местах, где были баги.
Короче проведите пару циклов тестирования (тестить надо одну версию в течении одного цикла): за три недели до релиза (цифра может бфть своя) и потом, когда все эти баги исправят - за неделю до релиза.
Описанная в вашем проэкте ситуация - самая стандартная для быстрых проэктов...
  • 0

#4 dimasoft

dimasoft

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

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Мугтасимов Дмитрий Азатович
  • Город:Москва

Отправлено 19 августа 2006 - 05:27

Нужно делать первое, т.е. путем вопросов получить хорошу спецификацию, по крайней мере в свои тестовых требованиях.
  • 0
С уважением,
Дмитрий Мугтасимов.

#5 SALar

SALar

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

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 20 августа 2006 - 14:36

Мы его тестировали следующим образом - написаные тесткейсы(ужасные - по причине отвратительной спецификации) мы использовали для smoke теста, а

Просмотр сообщения

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

Сейчас начинает разрабатываться новая часть проекта, только что мне дали требования и я не знаю что с ними делать   :acute:  Проект менеджер вообще не общался с нами по проекту, изредка через письма, а сейчас вообще укатил в отпуск.  Требования опять ужасные: с ошибками, неполные, двусмысленные.

Просмотр сообщения

Такое управление дурно пахнет. Обычно такая ситуация имеет место в двух случаях: плохой управленец [1] или организация желает завалить проект [2].

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

Просмотр сообщения

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

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

Просмотр сообщения

И что вы будете в этом случае тестировать? Погоду на луне?

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

Просмотр сообщения

Тесткейсы необязательны. И тестирование необязательно. В некоторых методологиях.
-----------------------------------
[1] "Управленец" - обобщенный термин включающий в себя все роли, связанные с управлением людьми. Термин взят из "Основ методологии" Анисимова. Подобные же обобщеные термины используются в ТРИЗе.
В данном контексте именно "Управленец", а не, скажем, "ПМ".

[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#6 SALar

SALar

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

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 20 августа 2006 - 15:06

Некоторые современные методологии (особенно тяжелые) базируются на нескольких предположениях.
1. Пожелания клиента можно формализовать.
2. По формализованным пожеланиям можно составить спецификацию.
3. По спецификации можно создать продукт.
4. По спецификации можно провести аудит продукта.
5. Если результат аудита продукта положителен, то продукт соответствует ожиданиям клиента.

Так вот, эти предположения не всегда выполняются. А если не выполняется хотя бы одно предположение, то следование этой метологии ведет в тупик.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#7 Lyzzochka

Lyzzochka

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

  • Members
  • Pip
  • 12 сообщений
  • Город:Минск

Отправлено 21 августа 2006 - 13:05

Всем спасибо за советы и полезную инфу. Мы взялись править спеку, несмотря на то, что инициатива наказуема. :acute:
  • 0

#8 Imbecile

Imbecile

    Постоянный участник

  • Members
  • PipPipPip
  • 156 сообщений

Отправлено 21 августа 2006 - 14:53

Всем спасибо за советы и полезную инфу. Мы взялись править спеку, несмотря на то, что инициатива наказуема.  :acute:

Просмотр сообщения

Кстати, основыаясь на собственном опыте, часто бывает удобней, в случае переписывания спецификаций, оформлять их в виде Use Cases. Тогда в конечном счёте, тестирование, а точнее написание Test Cases, сведётся к тому, с какой точки зрения оценивать качество системы. Покрытие всех возможных вариантов тестов, будет обеспеченно тем, что Use Cases покрывают функционал. Таким образом, например, чтобы оценить функционал, берём Use Case, создаём Test Case, который показывает, что делается то что надо, создаём ещё один (два, пять, десть, в зависимости от случая), который покажет, что то что не должно делаться - не делается. Те же самые Use Cases используем для проверки производительности - замеряем время отклика и т.д.
  • 0
In Test we trust.

#9 darielle

darielle

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

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Дарья

Отправлено 22 августа 2006 - 10:25

[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.


А зачем такое делается ваапче?
  • 0

#10 Mila

Mila

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • Город:Санкт-Петербург

Отправлено 22 августа 2006 - 11:19


[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.


А зачем такое делается ваапче?

Просмотр сообщения


Например, интеграция с конкурентными системами... :)
  • 0


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

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