Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Организация просесса тестирования с нуля.

backend
architecture
framework
qa
Теги: #<Tag:0x00007f7b6445f6f0> #<Tag:0x00007f7b6445f5b0> #<Tag:0x00007f7b6445f470> #<Tag:0x00007f7b6445f308>

#1

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

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

Немного о технологиях. Язык программирования - Java, склад кейзов и их результатов - TestRail, среда в которой вертятся все приложения - Docker.

Как происходит процесс тестирования:

  1. Пишу тест кейзы в тест рейл.

  2. Объединяю все кейзы в наборы.

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

  4. При запуске тестов для каждого набора создается отдельный запуск в тест рейле.

  5. В сами тесты передается айдишник созданных в тест рейле ранов.

  6. По апихе вытаскиваю все айдишники тестов, которые должны быть запущены.

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

  8. Запускаю тесты.

  9. По той же апихе отправляю в тест рейл результаты работы тестов и закрываю раны.

Для всего этого точно есть какие-то инструменты, но гугл оправляет на стак оверфлоу, но ответы там совершенно не те.


(Александр Илюшкин) #2

Ну, во первых, это у вас не процесс тестирования. Это процесс написания автоматизированных сценариев и их запуск.

Для понимания процесса тестирования прочитайте istqb foundation (на русском).

Что касается того, как вы это автоматизируете, то у нас так же сделано. Единственное, что хочется, чтобы вы подумали над следующими вопросами:

  1. Вы тратите время на тест рейл, а вы уверены, что эти кейсы кому-то сейчас нужны?
  2. Вы отправляете результаты в тест рейл. А вы уверены , что кому-то это надо?

Я считаю, что пока вы нормально не можете ответить на эти вопросы, то надо сокращать свои трудозатраты на такие вещи.

Не надо делать на будущее или потому что так другие делают и говорят, что надо.

Например, 1 пункт можно исключить, потому что если вы пишете чистый, понятный и хорошо документированный код, то по сути вам не нужно ещё какое-либо описание вашего теста.
2 пункт. Попробуйте в своем CI в сборке тестов прикрутить просто html отчёт. Снова не нужен тест рейл. Попробуйте report portal.
Но отчёт - это лишь способ представления состояния SUT. Информативен ли ваш отчёт? Можно ли заглянув в ошибку понять сразу из отчета, где сломалось и тут же идти писать багу или надо копать глубоко? Если надо копать, то займитесь улучшением локализации дефектов тестами.

Любой процесс должен базироваться на целях и принципах. Процесс автоматизации состоит из своих целей, своих принципов, своих запахов. Об этом подробно прочитайте в книге xunit паттерны. Рефакторинг кода тестов. Эта книга - концентрат опыта автоматизации.

http://www.ozon.ru/context/detail/id/4127815/


#3

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


(Anton Karpenko) #4

Может, как вариант перенести тесты в BDD фреймворк типа Cucumber? Сам сейчас об этом задумываюсь, т.к. поддерживать тесты в TestRail становится сложно.