ПО для ведения тест документации, процесса тестирования.

инструменты
, , , , , ,
#1

И так, выпросив вымолив на новый проект минимальную доку, стал вопрос какой инструмент задействовать для оборота тест документации (test plan,test suite, fast-check-list, composite test suite).
Ренее не приходилось иметь какого либо отдельного инструмента - юзали redmine, для этих целей. Посему какие то знания/впечатления стремятся к нулю, но есть пожелания:

  • функциональная разбивка доки/теговость/ возможность пользовательских тегов и группировки по ним
  • мягкие тест сьюты/планы (дока обновилась, тест сьют будет иметь не завершенные поля, либо версионированные поля)
  • дискретные асертменты (есть форма логин пас, пишу сьюты проверить поле емейал на асертмент такой то, а пароль на такой то)
  • версионированные fast-check-list (ану ка быстро пробегись по это вот функциональности, надо глянуть не сломалось ли там что то, создал тест чеки из набора сьютов, прогнал, галочки поставил, отдал манагреу)
  • локальные (кастомные) атрибуты проверки для пользовательских асертов (возьми вон тот сьют и примени его по отношению к такому вот набору браузеров, либо к такому вот типу юзеров)

Заранее прошу прощения, если “хотелки” являются базвордом (не правильные определения), буду раз услышать правильные версии.

По требованиям к ПО. Это может быть standalone приложение для target тестера, либо серверное (с множественным доступом), желательно не само в себе, с какими нить минимальными отчетами (тот же fast-check-list типа сделал распечатал, или отправил в редмайн к таску, или там заспечатал кастомный сьют, и отдал мануальщику отдельному пусть проверяет.)
Короче предполагаю инструментов таких не много, посему пишите.
Усугубляется это тем, что доку с тест планами сьютами прийдется отдать заказчику, для другой команды тестеров. Не охота упасть в грязь лицом, и не охота переделывать (если будет не гибко, не удобно)…там только доков 1000+ страниц.
Заранее спасибо.

02
02859×482 33 KB

QA weekly #26: требования, Книга как вылавливать баги, selene, развитие, онлайн-курсы, GitHub, тест документация.
#2

TestRail

#3

ИМХО для таких задач важен не столько инструмент, сколько правильная (более-менее адекватная) организация документации. На эту тему есть англоязычный ресурс, на котором про это разжевано так, что только глотать успевай. Правда, на текущий момент недоступный :frowning_face:. Тем не менее, если ресурс оживет:
Alistair Cockburn
Или вот статья, например, про организацию юз кейса:
How to Write a Use Case
Русскоязычный учебник о тестировании со скачиваемыми шаблонами тест-документов:
Про Тестинг: тесты, тестирование и тестировщики программного обеспечения..

Ну а что до инструментов, черные маги разработки используют Emacs + org-mode :smiling_imp:

#4

Платненько, но триалку погляжу, как админ виртуалку выделит.

Для того что бы адекватно развернуть документацию, нужно знать (или заранее определить) возможности инструмента.

можно и дебагать принтами…
В целом Вы видимо не понимаете что есть объектом вопроса с топике)

#5

Честно сказать, действительно понять трудно:

#6
  • функциональная разбивка доки/теговость.
    Есть дока пункты, подпункты. Каждому пункту подпункту я могу присвоить тег, и этот тег, далее привязывается к тест-сьютам по этой доке, дальше я такой говорю:
    А покажи ка нам все тест сьюты, которые есть в функциональность такой то, и тег такой то -> а теперь для этого дай мне тест-ран-доку, для того что бы я сел и начал тестить.
  • мягкие тест сьюты/планы
    Каждая дока покрывается тест сьютами/описывается планами/типа энвайромента. Но продукт не стоит на месте, чуваки напили новую функциональность (расширили) старую. Менеджер (тест-дизайнер/док-врайтер) открыл ПО дописал еще один пункт (теперь можно грабить корованы), дал ему метку, версию. Тест менеджер получил уведомление, что функциональность А не полностью покрыта тестами/сьютами. и нужно их сделать.
  • дискретные асертменты
    У меня страницы на 40% состоят из форм, и я офигею для каждой формы писать тест кейзы проверки полей ( да есть и другие вещи которые явно и косвенно повторяются). Хочется иметь некую базу паттернов, и применять их к вводам на страницах ( и не только).
    Тест покупки:
    заполни поле 1 (примени асерты Х с такими вот данными)
    заполни поле 2 (примени асерты Y с такими вот данными)
    Покупка есть в корзине/нету.
    Получается сам факт покупки является объектом тестирования в данном случае, а не валидатор, который есть только способом ввода данных. И такой валидатор есть на куче других страниц.
    Похожие вещи даже можно организовывать для описания енвайромента: для прогона тест кейза А иди выполни тирАп А и проверь на асерты А (иди создай юзера, но проверь есть ли юзер в данной группе). Но фишка в том, что во многих других тестах, нужно знать “если ли юзер в данной группе”.
  • версионированные fast-check-list (тест-раны как я понял)
    есть некий созданный тест ран, но я хочу что бы я мог его по нужде расширять, не изменяя оригинал и привязывать его к версии тегам и прочему (потестить покупку в магазине с оплатой, и без нее). Основной тест-ран один, а вот наследуемые - другие.
  • локальные (кастомные) атрибуты.
    Ассерты, о которых мы говорили выше, должны поддерживать data-driven условия и данные.
    Есть у меня ресурс, доступ к которому имеют все, но для каждого он выглядит по своему (форум - админ/суперадмин/модератор/пользователь)
    Тест: проверить что сообщение в теме создалось
    Тест кейз одни, но асерты разные ( админ не видит сообщение, но видит циферку, модер видит как непромодерированное сообщение, пользователь видит надпись что сообщение ожидает премодерацию)…сумбурный пример вышел, но как то так.
    Как и писал, можно ассерты юзать исходя из других требований( если страница открыта через IE, то на месте этой формы показать юзеру кулак и ссылку на Яндекс-браузер…господи прости.:grimacing:)
#7

Хочешь, не хочешь, - это разные тесты. Лучшее, что можно сделать в этом случае - выделить общий код в отдельную функцию (или метод). Если кто знает решение лучше, буду рад узнать тоже.

Полный сумбур. Что в данном случае значит “версионирование”? Контроль версий типа Git? Или что-то другое?

Что такое fast-check-list?

Определение с сайта ПроТестинг:
Тесты для запуска ( Test Run ) - это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).

В чем проблема-то? Бери да расширяй. Дописывай новые тест-скрипты, будет расширенный тест ран.

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

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

Что это?

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

Может на эту роль подходит какая-нибудь система класса Continuous Integration?

#8

Прочтите еще раз название топика, а то создается впечатление что мы говорим о разных вещах.
Мне нужен инструмент, для ведения тестовой документации (тест-кейзов и прочего), а не какой то там CI или test-framework. Еще нет никаких тестов, и не написано ни строчки кода, есть лишь трехтомник документов, описывающий что и как должна делал система.
Эту доку, нужно транспонировать в наборы тест случаев/сьютов и тому подобное, что бы в дальнейшем используя его, можно было вести ручное/авто тестирование.
И в своих тезисах, я перечислил какие функции я бы хотел видеть в этом инструменте.

#9

Testlink forever

1 лайк
#10

Начинает звучать, как заказ на разработку такого инструмента. В таком случае тебе следует построить свои требования более четко и с использованием более вразумительной пунктуации. И поменьше жаргона, видимо, только тебе понятного.

Если нет, то тебе сначала надо не сюда, а в поиск гугл.

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

Короче, вот тебе список. Надеюсь, по-аглицки вразумляешь:

1 лайк
#11

Hiptest попробуй, там и теги и интеграции с досками. Есть бесплатный пакет на 3 пользователей.

1 лайк
#12

Jira-Zephyr тесты и степы
ту да же по апи валяться результаты прогонов тестов

не элегантно но!

  • бесплатно (90% энтерпрайз кастомеров юзают жиру)
  • тестовая документация пишется 1 раз для автомейшен 1мануал Куа, разработчиков и ПО
  • легко проверять покрыты ли акцептанс критерии для залинкованой фичи
1 лайк
#13

Да уж совсем не бесплатно. Он идет как отдельный плагин. И платить за него надо тоже независимо от Jira. Причем, нельзя просто взять и купить лицензию на 10 пользователей для масштаба тысячной организации. Платить придется по полной программе.

#14

Хм не знал - просто везде где была жира - был зефир в нагрузку и кастомер ничего больше не хотел)

думал что платная версия это
https://www.getzephyr.com/products/enterprise-test-management/how-to-buy

#15

Тема я так понимаю заглохла, но корневой вопрос до сих пор актуален, где же господа Senior QA Testers хронят документацию с удобной навигацией по ней (схемами архитектуры проекта, тестпланы, чеклисты и.т.д.) неужели нет удобного (бесплатного/почти бесплатного софта) для тестеров всех скилл уровней.

#16

testrail, первый же ответ

3 лайка
#17

Плюс его API и возможность связать прогоны тестов с TestRail Run - то что надо. А про плагин pytest-testrail вообще молчу, лучше не придумаешь.

2 лайка
#18

TestRail для тест кейсов, интегрируется легко и после прогона автотестов видим сразу результаты. Для чеклистов обходились Гугл таблицами.

#19

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

#20

Хмм, расскажите это создателям Gitlab’а…ребята весьма грамотно продумали прайсинг, да и почему бы и нет, команде из 1-3 человека не нужен мега-корп софт за 100500 долларов в месяц