Тэг: qa

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

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

Релиз - выпуск очередной версии программного обеспечения.

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

Релиз проходит следующие стадии:

1. Планирование
2. Анализ 
3. Разработка
4. Тестирование

• фича тест
• релизное тестирование

  5.  Выпуск

  6.  Сопровождение

Планирование

Что делают

1. Определяют задачи для выпуска в будущем релизе.
2. Собирают оценку от аналитики, разработки, тестирования по будущим задачам.
3. Формируют итоговый список задач и заносят их в Jira(например).
4. Проставляют ответственных по задачам.

Кто основные участники

• Руководитель проекта(Project Manager)
• Владелец продукта(Product Owner)
• Бизнес-аналитик
• Лид разработки
• Лид тестирования 

Анализ

Что делают

1. Проводят детальную аналитику по задачам.
2. Пишут требования разного уровня детализации: 

• Бизнес-требования
• Системные требования

Кто основные участники

• Аналитики

Разработка

Что делают

1. Пишут код.
2. Пишут unit-тесты.
3. Дополняют api-документацию.
4. Делают сборку версии с изменениями.

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

Сборка представляет собой физически: набор файлов с изменениями для установки на стенд.

Вопрос установки сборки команды решают по разному.

Обычно стараются наладить процесс CI/CD с помощью таких инструментов как TeamCity, Gitlab и т.д.

Кто основные участники

• Разработчики

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

Фича тест

Изначально новая функциональность тестируется отдельно.

Что делают

1. Устанавливают обновления на нужный стенд.
2. Тестируют новые изменения.
3. Правят найденные баги(делают разработчики).
4. Производят ретест починенных багов.

В рамках тестирования qa общаются с разработкой и аналитикой по возникшим вопросам.

На выходе: чек-листы, тест-кейсы, тест-план, дефекты в системе управления задачами(например, Jira). 

Релизное тестирование

Что делают

1. Регрессионное тестирование версии.
2. Правят найденные баги(делают разработчики).
3. Производят ретест починенных багов.

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

Хотфикс - горячее/быстрое исправление дефектов на промышленном стенде.

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

Кто основные участники

• Тестировщики

Выпуск

Выпуск версии - передача/установка версии на стенд конечного пользователя.

Что делают

Передают и устанавливают новую версию(релиз) на промышленный стенд.

Кто основные участники

• Инженеры сопровождения

Данный этап часто выполняется либо инженерами сопровождения или девопсами.

Иногда версию на промышленный стенд устанавливают тестировщики или разработчики.

Сопровождение

Что делают

1. Собирают вопросы/дефекты после наката версии на промышленный стенд.
2. Воспроизведят дефекты от пользователей.
3. Отвечают на вопросы пользователей/заказчиков по новому функционалу.

Кто основные участники

• Специалисты по сопровождению

*Другие материалы о тестировании и IT на канале TESTOREST

Большую часть времени работы в сфере тестирования на пространстве СНГ не очень то ценились навыки специалистов по тестированию.

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

Но системы начали усложняться, а именно их логика и те процессы, которые происходят под капотом.

Поэтому тестирование наконец-то начали ценить:

Сейчас, чтобы качественно протестировать такое ПО нужна: 

 -определенная доля погружения в предметную область;

 -понимание взаимодействия компонентов ПО друг с другом;

 -понимание каналов, по которым двигаются данные;

 -учет и понимание критериев качества, таких как:

•     функциональная пригодность;
•     производительность;
•     совместимость со средой эксплуатации;
•     удобство;
•     надежность;
•     защищенность;
•     сопровождаемость;
•     переносимость.

Тестировщик сейчас решает задачи не только непосредственного тестирования, но и :

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

Наряду с привычными видами тестирования на первый план начали выходить: безопасность и нагрузочное тестирование.

Особенно актуально для web mobile продуктов с доступом для любого пользователя в интернете.

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

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

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

Какие базовые знания важны на первом этапе, чтобы начать?

Для каждой компании это будет немного своя вариация.

Для примера, составленная мной карта развития для начинающего джуна(может называться в компании "младший тестировщик" или как-то по другому) может помочь вам понять какой примерный объем знаний и навыков от вас могут ожидать:

Уверенный джун:

*В графе "Тестирование производительности"  "Введение" означает, понимание основ тестирования производительности: для чего, какие возможные кейсы и т.д.

Данные таблицы можно рассматривать как карта развития сотрудника.

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

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

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

Любите то, что делаете и развивайтесь!

Краткое содержание статьи(перевод):  https://clck.ru/32C2y5

Автор: Bas Dijkstra

Ниже будет представлено краткое содержание статьи, отвечающее на вопрос как лучше начать изучать автоматизацию?

В основном, почему-то, большинство начинает изучать UI-автоматизацию.

В какой-то степени понятно, что люди начинают свой путь по автоматизации именно с этого. 

Причины по которым начинают именно с автоматизации  UI:

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

2. Команды часто начинают свои усилия по автоматизации с «автоматизации регрессионных тестов». Поскольку они обычно пишутся с точки зрения конечного пользователя, они часто ссылаются на UI.

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

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

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

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

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

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

В качестве альтернативы можно рассмотреть API тесты.

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

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

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

Дорогие друзья, сегодня произошел запуск сайта для моего IT-клуба!

Я решила создать более постоянную площадку для информации о жизни IT-клуба и интересов в этой сфере.

Сайт запущен в тестовом режиме - считайте это бета-версией)) (возможно что-то будет меняться по-ходу дела).

Новости в телеграм продолжу постить, а тут будет площадка для статей.

Так же разместила здесь раздел услуг, так как многие спрашивают.

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

Скоро планируется очередная встреча клуба, следите за новостями.

Всем добра!=)