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

[Doveangel]

Подскажите грин, с чего вы взяли что мы из одного города??)
Вы из Москвы, а я из Минска
Или в вашем инфо неверные данные)

[Green]

Анжелика,

Это линк на одну небольшую, но очень полезную статью:
12 тестов Джоэла.

Если вы сможете со временем ответить на все вопросы "Да", то станете равными среди равных.

Что касается требований...
то тут у вас кроется проблема масштаба вашей компании. Если с этим разберетесь, то и время высвободите, и процесс улучшите, и радостнее будете.
:rolleyes:

[Green]

Вы из Москвы, а я из Минска

Я только пол года как москвич - засланец.
B)

До этого жил и работал в Минске, в компании ЕПАМ.
:D

[barancev]

Уважаемая Анжелика!

С чего Вы вообще взяли, что вам нужна какая-то документация по тестированию? ЗАЧЕМ ОНА ВАМ???

От Вас начальство требует, чтобы Вы её писали? Судя по всему нет.
Вы ощущаете в ней насущную потребность, Вам не хватает какой-то информации? Тоже вроде бы нет. Вот требования понадобились -- и Вы их написали.

А зачем тогда Вам ещё какая-то документация? Как Вы собираетесь её использовать?
Вот научит Вас многоопытный Сергей aka Green, какую документацию нужно иметь (всю, как Вы вероятно помните :)), напишите Вы её -- И ЧТО? Что Вы будете с ней делать? В шкаф положите?

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

Зачем же, в самом деле, писать документацию, и какую? Ответ очень прост и лежит на поверхности, хотя может быть "конкретные" советы Сергея покажутся Вам более полезными.

Пишите только ту документацию, которая Вам нужна, а всю остальную не пишите! Потому что она Вам не нужна. Это относится не только к тестированию и не только к документации. Не делайте лишнюю работу.

Ну хорошо, а как же определить, какая нужна? А вот это вообще говоря не Ваша работа, как тестировщика, а руководителя проекта. Нет, это не "спихивание" ответственности на другого, спихивать ответственность на начальство -- себе дороже. Впрочем, сначала я расскажу, как руководитель проекта определяет, что делать, а что не делать, а потом объясню, почему у Вас вряд ли получится сделать это за него, даже если вы руководствуетесь самыми благими намерениями.

Сейчас я открою Вам маленький менеджерский секрет -- как заменить почти любую работу, в том числе написание той или иной документации, одной единственной строчкой в одном единственном документе. Угадайте, в каком? Правильно, описание и оценка рисков проекта. Можно не делать любую работу, главное -- представлять последствия и знать способ борьбы с ними.

Предположим, у Вас нет документа о замысле проекта (Vision). И что? Будем писать? Нет, вместо этого вносим в документ с описанием рисков строчку "Неясно определённая цель проекта может привести к тому, что мы сделаем не то, что нужно заказчику"; оцениваем вероятность (скажем, процентов 20%, потому что два похожих проекта уже делали и все знают, что делать, и заказчик ни разу ещё не жаловался, но в этот раз появились некоторые новые аспекты, и т.п., короче, 20%); прогнозируем последствия (удвоение бюджета и сроков) -- и дело в шляпе. Теперь можно документ о замысле проекта не писать.

Предположим, Вы не написали тесты на какое-то требование. И что? Может быть этой частью функциональности никто не будет никогда пользоваться. Или будет, но при определённых ограничениях. Например, Вы не протестировали, что генерируемые отчёты корректно показываются в браузере Netscape 4.0. Попробуйте оценить риски -- вероятность того, что кто-то пользуется им вблизи нуля, а если пользуется и у него всё сломается -- вряд ли он будет жаловаться, потому что у него и так половина сайтов не показывается и он уже привык. Поэтому можно этим риском пренебречь, ЕСЛИ ЕСТЬ БОЛЕЕ СЕРЬЁЗНЫЕ.

Предположим, Вы не написали полноценные описания тестов, но написали сами тесты. Нет, сначала давайте предположим, что Вы не написали тесты, но зато написали красивые описания. Ага, тут всё понятно, так делать нельзя. Значит, если не хватает ресурсов на то и на другое, тестами пренебречь нельзя. Вывод очевиден.

Но всё таки, предположим, что Вы тесты всё же написали, а их полноценные описания таки нет. И что? Будем писать? А кто их будет читать? Предположим, что Вы знаете заранее, что систему передадут Вам на сопровождение и на разработку следущей версии, но при этом известно, что примерно половина требований изменится так, что тесты придётся переделывать заново. Но половина-то останется! Предположим также, что в следующем проекте тестированием будут заниматься не все те же люди, часть отдела тестирования поменяется на новичков, которых нужно будет вводить в курс дела. Оцениваем, насколько наличие документации в дополнение к тестам снизит затраты на сопровождение, на переработку тестов, на обучение. Если ожидаемое снижение затрат не превосходит планируемых затрат на разработку документов -- не нужно их делать. Тем более, что реально снижение окажется как всегда меньше ожидаемого, а затраты на разработку больше, чем планировалось. Ну может и не больше, но в документ с описанием рисков опять записываем, что может быть и больше.

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

Короче, ещё раз вернусь к тому, что сказал в самом начале -- пишите только ту документацию, которая Вам ДЕЙСТВИТЕЛЬНО НУЖНА, без которой Вы не можете обойтись, а всю остальную не пишите. Это и есть минимум.

[Viktor]

Например:
Требование: при нажатии на кнопку Х запись с созданным договором должна отображаться в таком-то гриде такого-то окна.

Тест-кейс: 1. Активируйте такое-то окно
2. Нажмите на кнопку Х
3. Проверьте что запись отобразилась в гриде текущего окна
4. Проверьте корректность отображённых данных

В Вашем примере слишком детализированное требование и тест-кейс.
Такого требования достаточно, чтобы не иметь ни архитектурной спецификации, ни тест-кейсов, да и программа лишняя :)

Здесь Алексей и Сергей правы: зачем? Есть время? Обучение и воспроизводимость, которые могут никогда не случиться - это не аргумент.

[Натали]

Читаю и думаю - как повезло Анжелике - у них в компании 4-5 тестировщиков и они позволяют себе думать о документации. :)
В нашей компании - я одна.
И в принципе уже сейчас пришла к выводу, что пишу только то, что мне действительно необходимо.

Хм, а как же вы тогда догадываетесь, правильно программисты её сделали или нет? Получается, что если "не падает", то всё по-определению правильно. Или тестировщики тоже ездят в банк-заказчик, независимо от разработчиков?

У нас нет требований, кроме ТЗ или обследования компании.
А правильно то, что не "падает", "по определению" или нет, узнается путем вопросов программерам и изучением предметной области. А про что не спросили - то осталось непроверенным.

[van]

Ребята!

Много чего написали, еще больше полезного, но все это по большей части теория чистой воды (поправьте меня, если я ошибаюсь)!

Если есть возможность, киньте пожалуйста ссылки (или вышлите по мылу) на конкретные примеры тестовой документации - тест кейсы, матрицы покрытий, матрицы контрольных точек и т.д.

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

Всем заранее огромное спасибо!

[Doveangel]

Спасибо всем, кто принимает участие в данной теме!

Отдельно хотела бы посочувствовать Натали((( Я одна бы не справилась! Требуйте соответствующую зарплату (за 4-х) ;)

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

Здесь все отталкиваются от установленных правил (опять же признаю, что эти правила проверены временем) - ведь мы с вами живём в прекрасной стране (и Россия и Беларусь) - и не в этой стране разработаны общепринятые правила ведения документации!! Почему бы нам не придумать и ввести новый тип описания!

Заранее хочу сказать, что это ОЧЕНЬ творческая работа и не всем она по зубам! Здесь надо не просто знать, здесь надо думать!

Теперь мне кажется мало кто ответит после этого сообщения :( ... потому как это намного сложнее, чем штудировать хорошие умные книги

Просьба никому не обижаться))) Я сама попытаюсь разработать схему)

[barancev]

Ребята!

Много чего написали, еще больше полезного, но все это по большей части теория чистой воды (поправьте меня, если я ошибаюсь)!

Если есть возможность, киньте пожалуйста ссылки (или вышлите по мылу) на конкретные примеры тестовой документации - тест кейсы, матрицы покрытий, матрицы контрольных точек и т.д.

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

Всем заранее огромное спасибо!

Так что может быть проще -- возьмите, скажем, RUP, там есть и описания тестов, и матрицы покрытий, и ещё много такого, о чём и не задумываешься в повседневной жизни. И с примерами, и с рекомендациями, и с перекрёстними связями, и с инструментальной поддержкой от IBM Rational. Чего ещё желать? Почему Вы думаете, что там -- теория, а вот участники форума дадут Вам некие секретные материалы, про которые ни в каких книгах не написано, но вот они-то и приведут к озарению и поднимут профессионализм до невиданных высот? Нет, как сказал уже Сергей -- всё, про что написано в книгах -- правда! Вам только нужно из этой правды выбрать необходимый именно Вам кусочек. И это никто сделать за Вас не сможет, как бы ни хотелось в это верить.

[van]

Так что может быть проще -- возьмите, скажем, RUP, там есть и описания тестов, и матрицы покрытий, и ещё много такого, о чём и не задумываешься в повседневной жизни. И с примерами, и с рекомендациями, и с перекрёстними связями, и с инструментальной поддержкой от IBM Rational. Чего ещё желать?

Спасибо за совет!

У Вас есть в электрическом виде какое - нибудь достаточно полное описание RUP. Если есть, то буду очень признателен, если Вы им со всеми нами поделитесь :)

[barancev]

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

Здесь все отталкиваются от установленных правил (опять же признаю, что эти правила проверены временем) - ведь мы с вами живём в прекрасной стране (и Россия и Беларусь) - и не в этой стране разработаны общепринятые правила ведения документации!! Почему бы нам не придумать и ввести новый тип описания!

Заранее хочу сказать, что это ОЧЕНЬ творческая работа и не всем она по зубам! Здесь надо не просто знать, здесь надо думать!

Теперь мне кажется мало кто ответит после этого сообщения :( ... потому как это намного сложнее, чем штудировать хорошие умные книги

Просьба никому не обижаться))) Я сама попытаюсь разработать схему)

Ну, я всё-таки не удержусь опять спросить -- ЗАЧЕМ?

Вас что-то не устраивает в существующих предлагаемых схемах? Их много. Возьмите для начала любую. Например, опять же, извините за банальность, RUP. Чем плохи предлагаемые там шаблоны документов? Ну так давайте это и обсудим. Вот и будет конкретика, а не теоретические измышления.

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

[Viktor]

Здесь все отталкиваются от установленных правил (опять же признаю, что эти правила проверены временем) - ведь мы с вами живём в прекрасной стране (и Россия и Беларусь) - и не в этой стране разработаны общепринятые правила ведения документации!! Почему бы нам не придумать и ввести новый тип описания!

Думаете, любовь к Родине - достаточный аргумент, чтобы набрать "format c:"?

[Doveangel]

Так что может быть проще -- возьмите, скажем, RUP, там есть и описания тестов, и матрицы покрытий, и ещё много такого, о чём и не задумываешься в повседневной жизни. И с примерами, и с рекомендациями, и с перекрёстними связями, и с инструментальной поддержкой от IBM Rational. Чего ещё желать?

Спасибо за совет!

У Вас есть в электрическом виде какое - нибудь достаточно полное описание RUP. Если есть, то буду очень признателен, если Вы им со всеми нами поделитесь :)

У Вас есть в электрическом виде

[barancev]

Так что может быть проще -- возьмите, скажем, RUP, там есть и описания тестов, и матрицы покрытий, и ещё много такого, о чём и не задумываешься в повседневной жизни. И с примерами, и с рекомендациями, и с перекрёстними связями, и с инструментальной поддержкой от IBM Rational. Чего ещё желать?

Спасибо за совет!

У Вас есть в электрическом виде какое - нибудь достаточно полное описание RUP. Если есть, то буду очень признателен, если Вы им со всеми нами поделитесь :)

Есть-то конечно есть, но это же коммерческий продукт, не думаю, что IBM Rational будет в восторге, если я его опубликую :)

Вам нужно не описание RUP, а он сам, в виде продукта. Потому что в описании опять будет так называемая "теория".

Пробную версию можно скачать с сайта IBM: http://www14.softwar...104AH W42&S_CMP или попросить у локального дилера IBM Rational.

[Green]

Полностью согласен с Алексеем (barancev).
:)

Любой специалист будет использовать только тот инструмент, в необходимости и полезности которого он ЛИЧНО уверен. Все остальное будет игнорироваться или использоваться из под палки, а значит не эффективно.

Анжелика,
Давайте проанализируем, какую именно информацию Вам необходимо иметь для выполнения работы.
1. Что тестировать.
2. С какими значениями тестировать.
3. В какой последовательности тестировать.
4. Что уже протестировано (что бы не повторяться).

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

Инструмент - Excel.

Оформление.
1. Составте список всех окон приложения.
* Согласен, что иногда это сделать очень сложно, т.к. одно и тоже окно может показываться по разному в зависимости от исходных условий. С таком случае выбирете одно из них за основное, а другие назовите его модификациями. Важно, что бы у Вас был полный список окон.

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

3. Каждой функции поставьте в соответствие контрольное значение. Конечно же, если данная функциональность способна принимать входные значения. Если - нет, то набор операций.
* Все входные значения необходимо разделить на четыре класса:
- ближайшее минимальное не корректное значение;
- минимальное корректное значение;
- максимальное корректное значение;
- ближайшее максимальное не корректное значение.
В итоге у Вас должна получиться матрица в которой в первом столбце идет список всех окон и для каждого окна перечислены все функции, а в строке, соответствующей каждой функции перечислены допустимые и не допустимые значения.

Использование.
Этот пункт мне кажется очевидным.
Каждый раз проходя ту или иную ветвь, соответствующую конкретному бизнес процессу, Вы постепенно будете заполнять эту матрицу результатами. Если конкретная функциональность с конкретным значением сработала корректно, то в соседней ячейке ставим - Pass, если нет, то Fail и заносим соответствующий дефект в баг трекинговую систему.
С течением проекта и заполнением матрицы Вы будете иметь полную картину того, что уже протестировано, а что еще требует проверки. В первую очередь проверяется критичная функциональность, дальше - основная и второстепенная.
Модули с "замороженной" функциональностью могут помечаться другим цветом и постепенно исключаться из повседневных задач.

Update.
При получении на тестирование нового билда от разработчиков необходимо так же получать исчерпывающий список всех изменений в приложении. Иначе вся работа не имеет смысла. Сила данного подхода именно в актуальности данных, включенных в матрицу.
Кстати, думаю, что в этом случае Вы можете отказаться от написания требований к системе, т.к. это действительно не продуктивная работа, если ее выполняют тестировщики.

Немного фантазии... и можно представить, что данный подход принят не только тестировщиками, но и разработчиками. Какая жизнь тогда начнется!
Поступает к Вам на тестирование новый билд. Вы открываете матрицу, а там уже все окна, в которых были внесены изменения, помечены другим цветом, так же отмечены все новые и измененные функции и проставлены тестовые данные.
Ну, не красота?!

B)

Надеюсь, это поможет.

******
The main thing is to keep the main thing as the main thing.

[Натали]

Спасибо, Green. :)
Матрица описана более чем исчерпывающе.
Но у меня вопрос о неповторении.

4. Что уже протестировано (что бы не повторяться).

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

[Doveangel]

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

Я так понимаю, что под всевозможными окнами лучше (а может это вы и имели ввиду) описывать поля окон. Т.е.
--наименование окна 1
--поле 1 (наименование)
--поле 2
--...
--...

Насчёт RUP-технологий: у нас в организации утановлен продукт Rational, но нет RUP. Я уже подняла вопрос о приобретении и установке RUP. Т.е. всё достаточно оперативно - и ваши все труды не проходят даром :)

Втечение нескольких ближайших недель несколько наших тестировщиков (и я в том числе) будут посещать курсы на AltWolf по технологии тестирования ПО с использованием Ратионал. После этого возможно полное использование продукта в процессе тастирования. Т.е. всё ещё впереди. Сказать по правде мне очень помогли все вышеизложенные советы: на самом деле-зачем изобретать велосипед?? Достаточно модифицировать уже существующие правила))

[Green]

Я так понимаю, что под всевозможными окнами лучше (а может это вы и имели ввиду) описывать поля окон. Т.е.
--наименование окна 1
--поле 1 (наименование)
--поле 2
--...
--...

Совершенно верно.

Только не стоит ограничиваться полями, так как может существовать функциональность не связанная с конкретной кнопочкой.

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

[barancev]

Для любителей Excel -- советую посмотреть вот на это: http://www.qadownloads.com/Templates/ (брать второй элемент в списке).

[Green]

Спасибо, Green. :)
Матрица описана более чем исчерпывающе.
Но у меня вопрос о неповторении.

4. Что уже протестировано (что бы не повторяться).

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

Здась возможны два варианта.

1. Что-то все-таки изменилось с прошлого раза - внешнее воздействие.
Возможно программисты втихаря добавили или изменили что-то в функциональности, или изменилось тестовое окружение.

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

Как поступать в этом случае.
Необходимо полностью исключить внешнее влияние на тестовую среду и тестируемое приложение.
- тестировать на тестовом сервере;
- закрыть доступ разработчикам на тестовый сервер;
- один проект - один сервер.

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

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

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