что такое ран в тестировании

Пол года в тестировании или взгляд с колоколенки

Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе «хочу ли я быть тестировщиком?».В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.

Войти в Ай-Ти или хлопоты «входа»

Немного цифр. После окончания универа по профилю «Энергетика» я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.

Испытательный срок или оклад за обучение

Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:

PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);

Консольку Linux для просмотра логов, кода на тестовых стендах, правки «на горячую», всякие curl и прочие мелочи;

Различные техники тест-дизайна;

Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);

Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);

Ну и всякие мелочи из разряда «деплоить ветку на тестовый стенд», «проверить наличие задач в ветке».

Вывод и скромный совет

Задавай свои вопросы в комментарии и я с удовольствием отвечу на них.

Источник

Тест раны

«Ран» это от английского Run, а не от русского рана.

В плане обычно написано что и как нужно делать, каких результатов ожидать.

Обычно тест план не содержит детальных инструкций с точностью до каждой величины.

Поэтому у тестировщика есть определённая свобода. Можно задать немного разные значения, выбрать другие элементы меню, дать чуть большую нагрузку.

План один и тот же, а фактические тесты разные. Каждый такой тест это и есть Test Run.

Если во время одного рана тест фейлится а другого нет, есть смысл задуматься о внесении изменений в план, но это ни в коем случае не аксиома.

Пример

Рассмотрим мой тест ран из статьи «Интеграционное тестирование»

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

Итак, перейдём к примеру:

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

Как будет выглядеть ваш тест в упрощённом виде:

Теперь разберём действия пошагово.

Нужно зайти на сайт Aviasales и выбрать какой-то маршрут.

Изображение с сайта Aviasales

Переход на новую страницу осуществлён, но вы по-прежнему на том же сайте.

Нужно нажать кнопку «Найти отели»

Изображение с сайта Aviasales

Изображение с сайта Booking.com

Изображение с сайта Booking.com

После того как вы выполнили все действия и написали отчёт можно сказать, что тест ран завершён.

Надеюсь Вам стало чуть понятней, что такое тест ран

Источник

Как помочь мануальному тестировщику. Автоматизаторы спешат на помощь

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

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

Немножко структурных данных

В нашей компании существует отдел ручного тестирования и автоматизаторы. Как система для организации тестов используется довольно популярный инструмент — TestRail. С моей точки зрения удобный и довольно функциональный.
Автоматизация построена тоже на довольно стандартном наборе Ruby + Cucumber + Watir/Selenium (можно упомянуть паттерн Page Object) + TeamCity.

Что происходит, когда на тестирование дается новый билд, (в нашем случае каждый раз мы имеем дело с регрешшеном)? Тестировщик создает новый тест ран, в который включаются все тест-кейсы с определенного тест-сьюта и — пошло поехало веселье. Уверен, всем знакомо то чувство, когда ты в 4-й раз прогоняешь вручную регрешшн или смоук на автомате, кликая/тапая на все элементы и проставляя статус для очередного теста. В этот момент пред красными глазами наверняка все плывет и картинка в голове повторяет знаменитое:

Именно сейчас приходим на помощь мы. Так уж получилось, что возникла идея. Если у нас есть автоматизация, то почему мы все еще не используем результаты нашей работы, чтобы жить стало проще? Мысль заключается в том, чтобы использовать отчет с TestRail вместо громоздких и непонятных отчетов с Cucumber. Довольно интересная задач — сделать так, чтобы тесты в TestRail сами меняли свой статус, в зависимости от того, как прошел автотест.

С помощью поиска всемогущего гугла была найдена документация по TestRail API для реализации сией благой цели. Мы решили для начала сделать так, чтобы запуская наши автотесты вся информация о текущем состоянии тестов отображалась в TestRail. Собственно, цель была достигнута — по нажатии на кнопку запуска тестов в RubyMine мы автоматически создавали новый тестран и отсылали результаты на сервер. Довольно просто, учитывая существующую информацию на сайте TestRail.

Как оказалось, это было всего лишь начало.

В конечном итоге удалось сделать довольно неплохую функциональность, а именно — мы настроили интеграцию TestRail + TeamCity + Automation Framework.

Теперь же подробности, уважаемые дамы и господа.

TestRail

Первая остановка у нас будет TestRail.

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

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

Начнем мы с того, что первое, что должен сделать наш юзер/мануал тестировщик — это создать собственно тестран, который в последствии мы и будем использовать для апдейтов.

Требования:
Фича: Запуск автотестов.
Для того, чтобы использовать автоматизации в реальной жизни.
Как пользователь я хочу, чтобы была волшебная кнопка «запустить ран с автотестами».

Сказано — сделано. Благо функционал TestRail позволяет нам интегрировать свой собственный код.

Как результат, мы имеем вот такую вот кнопочку:

Да, да — Start Tests.

Поскольку у нас для одного сьюта тесткейсы есть для веб и мобайл, то на первой стадии мы проверяем по имени тестрана, какой именно фреймворк используется. В зависимости от того, для чего предназначен тестран, мы запускаем билд на TeamCity.

Дабы юзер не кликал слишком часто на кнопочку, у нас организована защита от дурака — после клика на кнопку мы добавляем ключевое «in progress» к имени тестрана, это блокирует волшебную кнопку, пока наши автотесты не закончат свое дело.

Automation Framework

На конечной стадии был создан гем/библиотека, которая при разворачивании дает нам интеграцию с TestRail на любом нашем под-проекте.

Создание гема — совсем другая история, достойная отдельной статьи.

Если вкратце, то наша библиотека test_rail_integration имеет небольшой функционал, который мы используем у себя, но мне кажется, что кому-то тоже может быть полезной.

Для начала нужно его установить:

В after |scenario| hooks. И в env.rb файл:

Вот команды для запуска:

В нашем случае тесты запускались для 6 различных локализаций и все результаты отображались в 1 тестране. Иногда возникала ситуация, когда два апдейта приходили в одно время. Получалось так, что они не видели друг друга и после фейла приходил пасс статус. Такой вариант менял общую картину статуса теста. В общем, эта команда проходит все тесты и проверяет в ней соответствие, что в зеленых тестах нет красных результатов. Если же есть — то меняет статус теста на красный.

Тут все просто, данной командой мы создаем тестран с указанным именем в проекте-сьюте, который мы записали в конфиг файле. Команда возвращает номер созданного тесана:

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

Это и есть core фунционал c флагами:

Тут и так все понятно, нужно указать номер тест рана:

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

Этот флаг тоже специфический и, думаю, никому больше не пригодится:

Здесь можно указать новую команду для текущего запуска:

Так как у нас используется вся интеграция для 6 локализаций, то по номеру тестрана мы ищем имя и парсим его на параметры так, что тестран должен иметь имя, допустим, DT SG staging. Здесь мы и находим необходимую информацию для запуска.

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

Можно определить также номер типа тестов, которые буду запущены.

Полная команда для запуска тестов с существующим тестраном будет выглядеть так:

TeamCity

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

Вот и все. Так как это мой первый опыт с написанием статьи, критика приветствуется. Надеюсь, что написал я все это вполне понятно и данное руководство будет кому-либо полезно.

Источник

TestRail: как сначала подумать, а потом протестировать

Надеюсь, многие из вас знают, что в тестировании тоже есть документация. И вести ее можно по-олдскульному, в xls-файлах да в папочках или же, как настоящие джедаи, использовать специализированный инструмент.
Вот об одном из таких инструментов под названием TestRail, который мы недавно внедрили у себя в TestLab², я и хочу сегодня рассказать. Инструмент оказался настолько удачным, что молчать сил не было и я решил наконец-то сделать что-то полезное для общества.

Для всех проектов, которые мы тестируем, всегда обязательно пишется тестовая документация, от небольшого чеклиста до развесистого test suite с кросс-ссылками и сотнями кейсов. От идеи хранить документацию в локальных файлах отказались сразу и напрочь, это неудобно и просто непрофессионально. Пробовали «универсальное» решение, wiki (DokuWiki), но она не прижилась. Тут сложно сказать почему, пожалуй, дело привычки, и можно было бы «насадить добро палками», но тут подвернулся TestRail и понеслась.

Установка и системные требования

Два варианта: типичный LAMP или «IIS+SQLServer+FastCGI/PHP». Также потребуется ionCube и cURL, но это не редкость. Работает достаточно быстро, а после включения gzip через mod_deflate стало вообще пулей летать.

Основные возможности

Многопользовательская многопроектная система для ведения тестовой документации и учета результатов выполнения тестов. В продукте предусмотрено место для всех: для тест-менеджеров, которых больше интересует «когда будет» и «сколько багов», для простых тестировщиков, которым удобно отчитываться о пройденных кейсах, для аналитиков, которые смогут вгрызаться в самые дебри и выяснять чего ж оно всё так хреновов чем соль.

Как выглядит рабочий процесс

Сравнение с конкурентами

Личные впечатления

Для нас система оказалась практически идеальной и в плане минимально необходимого набора фич, и в плане удобства ежедневного использования. Мы занимаемся аутсорс-тестированием и ведем достаточно много небольших проектов, что отлично ложится в лицензионную политику вендора: лимит ограничивает только количество активных пользователей системы, поэтому мы деактивируем клиентские эккаунты по окончании проектов.
Из недостатков стоит отметить два: в текущей версии TestRail не поддерживает Unicode что означает, что вести документацию на русском/украинском языке в текущей версии без хаков невозможно. Но соответсвующий feature request уже заявлен, должны скоро добавить. Для нашей команды это непринципиально потому, что пока все проекты, достойные попадания в TestRail, ведутся на английском языке.
Вторая проблема — это отсутсвтие какого-то wysiwyg-редактора во всех text edit-полях. Это радует инженеров, но регулярно смущает заказчиков.

Резюме

Если вы ведете тестовую документацию по большому проекту, или уже теряетесь в тоннах doc- и xls-файлов с кейсами — вам стоит обратить внимание на TestRail. Это продукт, который не нужен всем и каждому, но если вы занимаетесь тестированием профессионально, то запомните это название, возможно, TestRail пригодится вам в следующем проекте.

Если будет интересно — я готов развивать тему различных тулов для тестирования и, к примеру, внимательно изучить ту же Testopia, чтобы рассказать вам о ней. Пишите в комменты.

*Умеющие гуглить могут найти в интернетах купоны на скидки.

Источник

Что такое риск-тестирование?

Цель тестирования на основе рисков — сфокусироваться на ключевых функциях и уделить им больше времени.

Риск — это непредвиденное событие, которое может отрицательно повлиять на измеряемые критерии успеха проекта. Так, непредвиденные события могут повлиять на стоимость всего проекта, коммерческие, технические и качественные цели.

Что такое тестирование на основе рисков?

Тестирование на основе рисков (risk-based testing) — это метод тестирования программного обеспечения, который базируется на вероятности рисков.

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

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

В результате, если пользователь даже и обнаружит дефект, это не помешает ему использовать приложение и не окажет существенного влияния на бизнес.

Риски продукта, проекта и процесса

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

Существует три группы рисков, с которыми команда может столкнуться в процессе разработки программного обеспечения:

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

Стратегия тестирования на основе рисков

В стратегии risk-based testing риск используется в качестве критерия во всех фазах цикла тестирования, включая планирование, проектирование, реализацию, выполнение и отчетность.

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

Основная цель анализа рисков — разбить по категориям элементы с высоким и низким рейтингом. Компоненты с высоким рейтингом оказываются в фокусе как автоматизированного, так и ручного тестирования. Элементам с более низким рейтингом уделяется меньше внимания.

Анализ рисков — первый шаг перед началом любого тестирования на основе рисков.

Преимущества тестирования на основе рисков

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

Улучшение качества. В risk-based testing приоритет отдается областям, наиболее подверженным рискам. Из них в первую очередь проверяются наиболее важные функции. В результате программа может быть выпущена с гарантией того, что ее основные и важные для клиентов функциональные возможности находятся на должном уровне.

Лучшее покрытие тестированием. Когда риски обнаружены, а их потенциальное влияние оценено, становится легче решить, что тестировать, с чего начать и когда прекратить тестирование. Другими словами, становится легко определить объем тестирования, а также приоритет выполнения тестов в ограниченные сроки. Это дает каждому проекту разработки структуру, необходимую для организации сотен тестов. Эта структура может использоваться при автоматизации регрессионного тестирования.

Когда использовать тестирование на основе рисков

Риски могут возрасти из-за целого ряда факторов. В частности, из-за неудачного проектирования, плохого тайм-менеджмента и неадекватных ресурсов. Это именно те ситуации, когда следует использовать risk-based testing.

Тестирование на основе рисков в Agile

Тестирование на основе рисков имеет большие преимущества в Agile, когда для поддержания качества ПО необходимо выполнять тесты в рамках отдельных спринтов. Оно помогает создать структуру, позволяющую тестировщикам, разработчикам и другим заинтересованным сторонам четко обсуждать имеющиеся риски. При таком подходе риски разделяются, и тогда их можно идентифицировать и устранить.

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

Выбор объектов тестирования

Итак, кто должен оценивать риски и как проходит этот процесс? Лучшие кандидаты в оценщики — те, кто хорошо осведомлен о проблемах приложения в целом.

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

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

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

Распространенные ошибки при тестировании на основе рисков

Критически важно начать анализ рисков еще на стадиях планирования и разработки. Это позволяет должным образом проанализировать приложение и разработать эффективный подход к тестированию.

Заключение

При эффективном выполнении оценка рисков и risk-based testing могут быстро принести хорошие результаты. Эффективность тестирования на основе рисков и развертывания будет определяться рядом важных факторов: строгим и хорошо структурированным анализом, планом тестирования и его выполнением, а также надлежащим обменом информацией со всеми заинтересованными сторонами проекта.

Источник