Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Использовали Testrail, но т.к. у них нет помесячной оплаты стали искать что-то другое. В итоге наткнулся на qase.io он полностью бесплатный (по крайне мере на данный момент) с платным функционалом, который мало кому понадобится. Багтрекинг весьма не плох, не требует установки на выделенный сервер, легко настраивается. Из плюсов — отлично работает импорт тест кейсов из других трекеров (перенос тестов из testrail занял пару минут и очень прост)
Спасибо!
Существует ли возможность в ней добавить ожидаемый результат для каждого шага кейса? Сейчас смотрю главную страницу сайта, кажется, нет. В настройках или, может быть, платной версии нельзя переключить вид кейса?
UPD: Не совсем понял про плату за TestRail или вы про выделенный сервер? тогда да там написано что сразу за год платить
Существует ли возможность в ней добавить ожидаемый результат для каждого шага кейса? Сейчас смотрю главную страницу сайта, кажется, нет. В настройках или, может быть, платной версии нельзя переключить вид кейса?
UPD: Не совсем понял про плату за TestRail или вы про выделенный сервер? тогда да там написано что сразу за год платить
Можно.
Функционал создания тест кейса:
UPD. Про оплату testrail не особо в курсе т.к. этим занимался наш менеджер проекта, но он сказал, что нужно платить за год. В защиту Testrail могу сказать, что он тоже очень удобен и 30$ в месяц это не дорого (относительно цен на остальные баг-трекеры).
Функционал создания тест кейса:
Начало
Шаги кейса
UPD. Про оплату testrail не особо в курсе т.к. этим занимался наш менеджер проекта, но он сказал, что нужно платить за год. В защиту Testrail могу сказать, что он тоже очень удобен и 30$ в месяц это не дорого (относительно цен на остальные баг-трекеры).
Вторая статья за месяц про выбор системы тестирования в которой нет TFS. Он не популярен?
Если люди про него спрашивают, значит какая-то популярность есть. Я года два назад пробовал в ней кейсы писать. Может сейчас она стала еще круче (надо как-то глянуть). Но это вотчина Microsoft. Не купит ли она завтра другую компанию для этого, а свою систему забросит? GitHub тому пример.
Я как «счастливый» обладатель Windows Phone теперь немного с опаской смотрю на них. Хотя VS Code их конечно шикарен.
Я как «счастливый» обладатель Windows Phone теперь немного с опаской смотрю на них. Хотя VS Code их конечно шикарен.
Работаю QA 8 лет.
В разных компаниях в США.
Видел разные системы.
Мой вывод: если у вас больше 5 тест кейсов, то все эти системы добавляют слишком много оверхеда (лишней головной боли), и без них — лучше, чем с ними.
2 самых эффективных способа держать в порядке тест кейсы и репорты:
1) Excel (или Google Spreadsheets). Да, да. Кто бы что ни говорил, редактировать в Excel гораздо проще, чем во всех этим тулзах, где разные тесты и поля на разных экранах, и что-то надо делать так, а что-то по другому.
2) MD (MarkDown) файлы с тест кэйсами, которые хранятся вместе с основной репой.
Тут процесс такой:
— тест планы хранятся в репе вместе с продуктом, поэтому они всегда правильной версии
— когда нужно что-то тестировать, то репорт сохраняется:
* а) в комментариях к PR, который вы тестируете. И это очень ЛОГИЧНО: это такой ручной критерий именно этого PR. ИЛИ
* б) в JIRA таске (или какой-то другой системе, которую вы используете). Так что вы всегда можете найти этот репорт, потому что эта таска находится в правильном проекте, с правильной версией, назначенной на нужного человека и т.д… Если вы смотрите на статус спринта, то вы видите там задачу «Manual QA», вы можете её открыть, посмотреть, что уже сделано и т.д.
В разных компаниях в США.
Видел разные системы.
Мой вывод: если у вас больше 5 тест кейсов, то все эти системы добавляют слишком много оверхеда (лишней головной боли), и без них — лучше, чем с ними.
2 самых эффективных способа держать в порядке тест кейсы и репорты:
1) Excel (или Google Spreadsheets). Да, да. Кто бы что ни говорил, редактировать в Excel гораздо проще, чем во всех этим тулзах, где разные тесты и поля на разных экранах, и что-то надо делать так, а что-то по другому.
2) MD (MarkDown) файлы с тест кэйсами, которые хранятся вместе с основной репой.
Тут процесс такой:
— тест планы хранятся в репе вместе с продуктом, поэтому они всегда правильной версии
— когда нужно что-то тестировать, то репорт сохраняется:
* а) в комментариях к PR, который вы тестируете. И это очень ЛОГИЧНО: это такой ручной критерий именно этого PR. ИЛИ
* б) в JIRA таске (или какой-то другой системе, которую вы используете). Так что вы всегда можете найти этот репорт, потому что эта таска находится в правильном проекте, с правильной версией, назначенной на нужного человека и т.д… Если вы смотрите на статус спринта, то вы видите там задачу «Manual QA», вы можете её открыть, посмотреть, что уже сделано и т.д.
Интересный подход.
1. Как справляетесь с большой базой кейсов? Как идёт выборка и добавление определенных кейсов для прогона?
2. Как работаете с вложениями (картинками в частности), если в MD еще это представляю как реализуется. А вот в Экселе меня дико бесило, что нельзя картинку вставить (только ссылкой куда-то)
3. Как историю по прогонам отслеживаете? есть отдельный репорт?
1. Как справляетесь с большой базой кейсов? Как идёт выборка и добавление определенных кейсов для прогона?
2. Как работаете с вложениями (картинками в частности), если в MD еще это представляю как реализуется. А вот в Экселе меня дико бесило, что нельзя картинку вставить (только ссылкой куда-то)
3. Как историю по прогонам отслеживаете? есть отдельный репорт?
1.В чём проблема с большой базой кэйсов?
Я работал в медицинской компании, там были десятки тест протоколов и тысячи репортов. Хранили в Excel, Excel хранили в Confluence — там была система документооборота заточенная под требования аудита.
Вместо Confluence можно и другие системы использовать, если там есть версионность и некоторые фишки аудита (типа NextCloud)
2. Очень редко у меня были случаи когда нужно добавлять картинки. Но и в Excel и в Google Spreadsheet картинки вставлять можно.
3. Что такое «история по прогонам»? Мы работаем в контексте версий (вот репорты для этой версии) или в контексте PR (вот репорт для этого PR).
Обычно структура такая:
— есть regression suite (протокол), который обязательно нужно прогнать перед релизом, и может быть посреди цикла, если изменения большие.
— и есть отдельные протоколы на features. Разрабатываем и тестируем feature A, то значит её протокол и создаём (обновляем) и используем.
Я работал в медицинской компании, там были десятки тест протоколов и тысячи репортов. Хранили в Excel, Excel хранили в Confluence — там была система документооборота заточенная под требования аудита.
Вместо Confluence можно и другие системы использовать, если там есть версионность и некоторые фишки аудита (типа NextCloud)
2. Очень редко у меня были случаи когда нужно добавлять картинки. Но и в Excel и в Google Spreadsheet картинки вставлять можно.
3. Что такое «история по прогонам»? Мы работаем в контексте версий (вот репорты для этой версии) или в контексте PR (вот репорт для этого PR).
Обычно структура такая:
— есть regression suite (протокол), который обязательно нужно прогнать перед релизом, и может быть посреди цикла, если изменения большие.
— и есть отдельные протоколы на features. Разрабатываем и тестируем feature A, то значит её протокол и создаём (обновляем) и используем.
1. Выглядит жутко, по мне. Как сейчас помню скролил даже 100 кейсов в одном Эксель файле. А у вас тысячи. Плюс это еще куда-то в систему документооборота уходит. Менеджеры у вас все эти портянки смотрят? или вы им красивые отчеты уже готовите?
2. Счастливый вы человек.
3. Я про отслеживание изменений. Т.е. реально у вас взять один кейс и сразу увидеть в какой версии он упал, а в которой успешно прошёл?
2. Счастливый вы человек.
3. Я про отслеживание изменений. Т.е. реально у вас взять один кейс и сразу увидеть в какой версии он упал, а в которой успешно прошёл?
1. Вот как раз в Excel можно открыть файл с тысячей кэйсов и легко с ними работать, скролить через все, сделать поиск по всем и сразу увидеть. Ни одна из веб-систем и близко не приближается в плане удобства к Excel.
Посмотреть 1000 кэйсов в Excel нетрудно, а вот кликать через пагинацию в веб-приложении — боль.
Смотреть на пироги-репорты — занятие тоже довольно бессмысленное (хотя в Excel это тоже делается легко).
3. нет, такой возможности нет. Но вроде бы не особо и надо. Если что боле-менее серьёзное, то баги есть в JIRA.
Посмотреть 1000 кэйсов в Excel нетрудно, а вот кликать через пагинацию в веб-приложении — боль.
Смотреть на пироги-репорты — занятие тоже довольно бессмысленное (хотя в Excel это тоже делается легко).
3. нет, такой возможности нет. Но вроде бы не особо и надо. Если что боле-менее серьёзное, то баги есть в JIRA.
Спасибо, что поделились своим опытом.
Но удалять статью я пока не буду =) Что-то мне подсказывает, что неспроста их столько на рынке. Еще и новые появляются. Или тоже всё маркетинговые уловки это? и на самом деле нам не нужны все эти «плюшки»?
Но удалять статью я пока не буду =) Что-то мне подсказывает, что неспроста их столько на рынке. Еще и новые появляются. Или тоже всё маркетинговые уловки это? и на самом деле нам не нужны все эти «плюшки»?
Статья на самом деле полезная, удалять не надо. Это очень полезно быть в курсе того, какие инструменты сегодня есть на рынке.
Я нередко наблюдал такую картину:
— в компании есть тестеры, которые тем или иным образом занимаются тестирование
— возникает «проблема». Проблемы, связанных с процессом может быть две:
а) тестеры прохлопали серьёзный баг, которые выкатили в продакшен (отправили клиенту, ...) и теперь начинают разбираться — а чем там тестеры занимались, кто виноват… Ну а тестеры прикрывают себе заднее место, никто не может понять кто и что тестировал. И тогда начальство решает: поставить систему, чтобы всё было видно: кто и что тестировал, и что не тестировали.
б) каждый раз, когда готовиться релиз, тестеры заваливают сроки. От них невозможно получить надёжного ответа на вопрос: что уже сделано и сколько осталось? И тогда начальство требует, чтобы им сделали дэшборды, чтобы там это всё было видно и «прозрачно».
В обоих случаях тестеры получают головную боль, потому что им теперь нужно в той или иной системе заниматься внесением мета-информации (кто, что, когда, какой результат)… Аджайл быстро перестаёт быть аджайлом, процесс формализуется. Со сроками становится ещё хуже, а заднее место прикрывать тестеры всё равно как-нибудь сумеют. На дэшборды никто не смотрит до следующего фэйла, а при фэйле — там ясности не добавляется.
В корне этих проблем: все эти инструменты нагружают тестеров не очень полезной и нудной деятельностью с довольно большим оверхедом.
Тех же целей (разделение ответственности и более прозрачное планирование) можно достичь с намного более меньшим оверхедом использую более простые инструменты: Excel или чеклисты в MarkDown файлах
P.S. В прошлом году, я был на StarEast conference (наверное самая большая конференция тестеров в США), и там один мужик представлял очередную подобную систему. Так он показательно начал свою презентацию с таких слов:
С его слов я понял, что они (продажники таких систем) знают, что большинство тестеров сидит в Excel, и очень не хотят переходить ни на какие «современные инструменты». Потому что уже проходили.
Было бы интересно сделать опрос. Вангую, что больше половины используют Excel / Google Spreadsheet.
Я нередко наблюдал такую картину:
— в компании есть тестеры, которые тем или иным образом занимаются тестирование
— возникает «проблема». Проблемы, связанных с процессом может быть две:
а) тестеры прохлопали серьёзный баг, которые выкатили в продакшен (отправили клиенту, ...) и теперь начинают разбираться — а чем там тестеры занимались, кто виноват… Ну а тестеры прикрывают себе заднее место, никто не может понять кто и что тестировал. И тогда начальство решает: поставить систему, чтобы всё было видно: кто и что тестировал, и что не тестировали.
б) каждый раз, когда готовиться релиз, тестеры заваливают сроки. От них невозможно получить надёжного ответа на вопрос: что уже сделано и сколько осталось? И тогда начальство требует, чтобы им сделали дэшборды, чтобы там это всё было видно и «прозрачно».
В обоих случаях тестеры получают головную боль, потому что им теперь нужно в той или иной системе заниматься внесением мета-информации (кто, что, когда, какой результат)… Аджайл быстро перестаёт быть аджайлом, процесс формализуется. Со сроками становится ещё хуже, а заднее место прикрывать тестеры всё равно как-нибудь сумеют. На дэшборды никто не смотрит до следующего фэйла, а при фэйле — там ясности не добавляется.
В корне этих проблем: все эти инструменты нагружают тестеров не очень полезной и нудной деятельностью с довольно большим оверхедом.
Тех же целей (разделение ответственности и более прозрачное планирование) можно достичь с намного более меньшим оверхедом использую более простые инструменты: Excel или чеклисты в MarkDown файлах
P.S. В прошлом году, я был на StarEast conference (наверное самая большая конференция тестеров в США), и там один мужик представлял очередную подобную систему. Так он показательно начал свою презентацию с таких слов:
Если вы всё ещё используете Excel для хранения тест протоколов и тест репортов, то вы живёте в прошлом веке. Пора уже купить наш супер-современный инструмент, и наступит вам счастье.
С его слов я понял, что они (продажники таких систем) знают, что большинство тестеров сидит в Excel, и очень не хотят переходить ни на какие «современные инструменты». Потому что уже проходили.
Было бы интересно сделать опрос. Вангую, что больше половины используют Excel / Google Spreadsheet.
Так вот как раз эти системы и призваны записывать всю эту мету информацию, не отвлекая от самого тестирования. Разве это не полезно?
А как вы тогда разбираетесь и выявляете слабые места процесса? Или у вас заказчики спокойно относятся к фейлам?
так в том-то и дело, что «не отвлекая от самого тестирования» лучше всего получается у Excel.
Все остальные инструменты отвлекают очень серьёзно.
Например, у вас есть сценарий:
— открыть приложение в браузере
— залогиниться
— сделать 3-4 CRUD операции
— разлогиниться
И вам надо тестировать это в 3-4 браузерах.
Если вы это делаете в Excel — это выделать мышкой регион и нажать Ctrl-V 3-4 раза.
Если вы это делаете в любой системе — вы не можете там сделать Ctrl-V на все шаги. Вы должны каждый шаг: 1) открыть, 2) ввести результат, 3) отправить. После каждого шага надо ждать, пока веб-сервер ответит (даже если это немного — это всё равно складывается).
В результате Excel уделывает любую систему раз в 10 по времени, которое тестеры надо потратить на то, чтобы ввести результаты.
Другой вариант:
допустим у вам в тест-кейсах есть какие-то детали, связанные с окружением: может имя сервера, или ожидаемый текст сообщения в ответе и т.д.
И если это поменялось, и надо изменить больше одного тест-кэйса, то в Excel — это «Find and Replace».
А вот в «полезном инструменте» это превращается в ад, когда надо вручную открыть и исправить стопятьсот кэйсов. Или сделать экспорт в Excel, исправить там, и импортировать обратно ;-) Это если у инструмента есть вменяемый импорт-экспорт
Все остальные инструменты отвлекают очень серьёзно.
Например, у вас есть сценарий:
— открыть приложение в браузере
— залогиниться
— сделать 3-4 CRUD операции
— разлогиниться
И вам надо тестировать это в 3-4 браузерах.
Если вы это делаете в Excel — это выделать мышкой регион и нажать Ctrl-V 3-4 раза.
Если вы это делаете в любой системе — вы не можете там сделать Ctrl-V на все шаги. Вы должны каждый шаг: 1) открыть, 2) ввести результат, 3) отправить. После каждого шага надо ждать, пока веб-сервер ответит (даже если это немного — это всё равно складывается).
В результате Excel уделывает любую систему раз в 10 по времени, которое тестеры надо потратить на то, чтобы ввести результаты.
Другой вариант:
допустим у вам в тест-кейсах есть какие-то детали, связанные с окружением: может имя сервера, или ожидаемый текст сообщения в ответе и т.д.
И если это поменялось, и надо изменить больше одного тест-кэйса, то в Excel — это «Find and Replace».
А вот в «полезном инструменте» это превращается в ад, когда надо вручную открыть и исправить стопятьсот кэйсов. Или сделать экспорт в Excel, исправить там, и импортировать обратно ;-) Это если у инструмента есть вменяемый импорт-экспорт
Опрос я хотел добавить. Но видимо у меня кармы не хватает. Не увидел нигде "добавить опрос" при публикации, а сторонний сервис уже не хотел искать, итак затянул со статьей. И там как раз хотел добавить вариант Эксель и еще "своя разработка"
Коллеги, добавил опрос. Теперь можно проголосовать за один вариант.
Извините, что сразу после модерации не проверил Редактирование статьи. До модерации опрос был не доступен.
Я выбрал TestLink т.к. с ним работал на последнем проекте. Также помимо него в разное время использовали: Табличный документ, Zephyr for Jira, TestRail
Извините, что сразу после модерации не проверил Редактирование статьи. До модерации опрос был не доступен.
Я выбрал TestLink т.к. с ним работал на последнем проекте. Также помимо него в разное время использовали: Табличный документ, Zephyr for Jira, TestRail
Есть еще azure.microsoft.com/en-us/services/devops/test-plans
После первого опыта использования, могу сказать что производит хорошее впечатление. Но пока мы его не внедрили. Так что у меня есть только певое впечатление.
После первого опыта использования, могу сказать что производит хорошее впечатление. Но пока мы его не внедрили. Так что у меня есть только певое впечатление.
Спасибо! Да уже был комментарий выше про TFS, я так понимаю он эволюционировал вот в это.
И что-то мне подсказывает, что-то подобное мы скоро увидим на гитхабе (если уже его там нет).
Кстати, приложения-дополнения в GitHub, GitLab и т.п. для управления тестами это еще одна тема, которую можно осветить (идея для тех у кого есть на это время и желание)
И что-то мне подсказывает, что-то подобное мы скоро увидим на гитхабе (если уже его там нет).
Кстати, приложения-дополнения в GitHub, GitLab и т.п. для управления тестами это еще одна тема, которую можно осветить (идея для тех у кого есть на это время и желание)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выбор системы управления тестированием в 2019