Кривая спецификация
#1
Отправлено 16 августа 2006 - 12:19
На нашем проекте только два тестировщика с опытом работы по полтора месяца, я среди нас, так сказать, тим лид, за неимением более знающего человека. Только-только сдан бета-релиз. Мы его тестировали следующим образом - написаные тесткейсы(ужасные - по причине отвратительной спецификации) мы использовали для smoke теста, а тестировали уже без каких-либо тесткейсов интуитивно. Сейчас начинает разрабатываться новая часть проекта, только что мне дали требования и я не знаю что с ними делать Проект менеджер вообще не общался с нами по проекту, изредка через письма, а сейчас вообще укатил в отпуск. Требования опять ужасные: с ошибками, неполные, двусмысленные. Я вот думаю, то ли исправить спецификацию, написать список вопросов и отправить заказчику, а потом уже писать тесткейсы; то ли написать кейсы для этого кривого документа, а менеджер проекта пусть сам со всем разбирается, если руки дойдут? А еще, является ли необходимым тестировать только по тесткейсам, если проект не очень большой?
#2
Отправлено 17 августа 2006 - 06:24
Отсюда вытекает, что QA обязан анализировать требования и добиваться их корректной интерпретации. То есть, если у вас возникают вопросы/комментарии к спецификации, необходимо комментировать спеку (просто в режиме правок) или выписывать вопросы и потом с этим списком говорить с PM или бизнес-аналитиком (кто там спеки писал) или со всеми - быстрее истина выяснится. В результате, кое-где спека будет подправлена, некоторые вопросы будут заданы клиенту. И тестировать уже будете корректные и понятные требования. Вообще, QA должен стремиться к тому, чтобы клиент-разработчик-QA трактовали требования одинаково.
Во-вторых, я считаю, что в проектах для заказчика из СНГ, например, не дается достаточно времени для написания тест кейсов, покрывающих все требования. Часто получается, что достаточно хотя бы чек-лист сделать исчерпывающий, чтоб он хоть одержал все моменты, которые надо тестировать. До тест кейсов вы вряд ли дойдете. Или напишете самые критичные. И это нормально. Без интуитивного тестирования - никуда. Могут быть проекты, в которые бессмысленно писать тест-кейсы (и проект не сложный, и времени нет). Если QA вменяем - результат будет хороший. Если спека суперского качества, хорошие коммуникации с остальными членами команды (PM, разработчики) - и без тест кейсов можно обойтись, если времени не выделено на это.
Просто во многих конторах начинают писать тест кейсы (что хорошо, в принципе), НО не все остается охваченным, в требованиях нормально не копаются....В результате результаты качество продукта - ужасающе:( Время и ресурсы нужн отратить оптимально! Выбирайте - в какой форме делать тест дизайн, как глубоко и т.п.
#3
Отправлено 17 августа 2006 - 06:54
Короче проведите пару циклов тестирования (тестить надо одну версию в течении одного цикла): за три недели до релиза (цифра может бфть своя) и потом, когда все эти баги исправят - за неделю до релиза.
Описанная в вашем проэкте ситуация - самая стандартная для быстрых проэктов...
#4
Отправлено 19 августа 2006 - 05:27
Дмитрий Мугтасимов.
#5
Отправлено 20 августа 2006 - 14:36
Выглядит немного странно. Может быть, лучше написать нормальные тесткейсы для smoke теста? Эти сценарии выволняются чаще всего и они должны быть хорошими. То что, они не будут базироваться на спецификации - это проблема спецификации.Мы его тестировали следующим образом - написаные тесткейсы(ужасные - по причине отвратительной спецификации) мы использовали для smoke теста, а
Такое управление дурно пахнет. Обычно такая ситуация имеет место в двух случаях: плохой управленец [1] или организация желает завалить проект [2].Сейчас начинает разрабатываться новая часть проекта, только что мне дали требования и я не знаю что с ними делать Проект менеджер вообще не общался с нами по проекту, изредка через письма, а сейчас вообще укатил в отпуск. Требования опять ужасные: с ошибками, неполные, двусмысленные.
Исправлять спецификацию - не ваша задача.Я вот думаю, то ли исправить спецификацию, написать список вопросов и отправить заказчику, а потом уже писать тесткейсы; то ли написать кейсы для этого кривого документа, а менеджер проекта пусть сам со всем разбирается, если руки дойдут? А еще, является ли необходимым тестировать только по тесткейсам, если проект не очень большой?
Отправлять заказчику - тем более. Не прыгайте через голову.
И что вы будете в этом случае тестировать? Погоду на луне?то ли написать кейсы для этого кривого документа, а менеджер проекта пусть сам со всем разбирается, если руки дойдут?
Тесткейсы необязательны. И тестирование необязательно. В некоторых методологиях.А еще, является ли необходимым тестировать только по тесткейсам, если проект не очень большой?
-----------------------------------
[1] "Управленец" - обобщенный термин включающий в себя все роли, связанные с управлением людьми. Термин взят из "Основ методологии" Анисимова. Подобные же обобщеные термины используются в ТРИЗе.
В данном контексте именно "Управленец", а не, скажем, "ПМ".
[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 20 августа 2006 - 15:06
1. Пожелания клиента можно формализовать.
2. По формализованным пожеланиям можно составить спецификацию.
3. По спецификации можно создать продукт.
4. По спецификации можно провести аудит продукта.
5. Если результат аудита продукта положителен, то продукт соответствует ожиданиям клиента.
Так вот, эти предположения не всегда выполняются. А если не выполняется хотя бы одно предположение, то следование этой метологии ведет в тупик.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
Отправлено 21 августа 2006 - 13:05
#8
Отправлено 21 августа 2006 - 14:53
Кстати, основыаясь на собственном опыте, часто бывает удобней, в случае переписывания спецификаций, оформлять их в виде Use Cases. Тогда в конечном счёте, тестирование, а точнее написание Test Cases, сведётся к тому, с какой точки зрения оценивать качество системы. Покрытие всех возможных вариантов тестов, будет обеспеченно тем, что Use Cases покрывают функционал. Таким образом, например, чтобы оценить функционал, берём Use Case, создаём Test Case, который показывает, что делается то что надо, создаём ещё один (два, пять, десть, в зависимости от случая), который покажет, что то что не должно делаться - не делается. Те же самые Use Cases используем для проверки производительности - замеряем время отклика и т.д.Всем спасибо за советы и полезную инфу. Мы взялись править спеку, несмотря на то, что инициатива наказуема.
#9
Отправлено 22 августа 2006 - 10:25
[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.
А зачем такое делается ваапче?
#10
Отправлено 22 августа 2006 - 11:19
[2] Довольно частая ситуация. Заваливать собственные проекты вынужден даже Микрософт. В этом случае создается режим "наибольшего благоприятствования" для завала. Силами отдельных энтузиастов спасти проект невозможно.
А зачем такое делается ваапче?
Например, интеграция с конкурентными системами... :)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных