Сообщений в теме: 9

[Lyzzochka]

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

[Mishelka]

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

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

[Romich]

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

[dimasoft]

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

[SALar]

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

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

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

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

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

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

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

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

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

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

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

[SALar]

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

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

[Lyzzochka]

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

[Imbecile]

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

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

[darielle]

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

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

[Mila]

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

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

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