Заметки тестировщика

Что такое Jira и как с ней работать?

2022-09-01T13:26:47.876Z

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

https://www.atlassian.com/ru/software/jira

Содержание:

Система Atlassian построена по принципам Kanban и Scrum досок, давней практики организации задач.

Название, кстати, происходит от японского слова Gojira, что переводится как «Годзилла».

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

https://www.atlassian.com/ru/software/jira/templates/scrum

Kanban — это методология, которая обеспечивает наглядное представление всего процесса и обычно используется в методиках Agile и DevOps для обеспечения непрерывной поставки и улучшения. Шаблон Kanban в Jira Software помогает командам легко разрабатывать и улучшать рабочий процесс, а также управлять им, обеспечивая прозрачность в ходе выполнения работы.

https://www.atlassian.com/ru/software/jira/templates/kanban

Особенности Jira (помимо Scrum и Kanban досок):

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

Список всех инструментов Atlassian можно посмотреть здесь

Алгоритм работы с Jira

Процесс работы с Jira можно разложить на 6 простых шагов:

Для начала нужно загрузить Jira, создать профиль и запустить утилиту. Можно использовать аккаунты Apple и Google.
В окне приложения необходимо выбрать пункт Create Project.
Программа предложит список шаблонов для доски с задачами (для разработчиков, для маркетологов и т.п.). Выбираем ту, что лучше всего соответствует целям команды и стилю работы в вашей компании.
Затем Jira задаст пару вопросов по поводу того, пользовались ли вы ранее Agile и канбан. На основе ответов программой будет принято решение о целесообразности внедрения обучения в интерфейс.
Настраиваем колонки под свои нужды (если то, что было предложено в шаблоне, не на 100% удовлетворяет вашим требованиям).
Создаем задачу (пункт Create).
Приглашаем других пользователей (то есть членов команды) работать с созданной вами доской (пункт Invite).

https://www.testingdocs.com/create-scrum-project-in-jira-software/

Как устроена Jira?

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

https://www.atlassian.com/ru/software/jira

Интерфейс

Интерфейс Jira делится на несколько ключевых вкладок. Во вкладке «Projects» хранятся все канбан/скрам-доски, которые вы можете просматривать или редактировать. Фактически это основное рабочее пространство. Здесь же можно перейти в режим отслеживания релизов продукта, взглянуть на все активные спринты, проанализировать отчеты о проделанной работе и т.п.

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

Также в списке вкладок есть окно с дашбордами – удобно скомпонованными аналитическими сводками. Отдельное окно со списком сотрудников, с которыми вы взаимодействуете, система планирования релизов на манер инструментов в духе OmniPlan и вкладка с приложениями от сторонних компаний, интегрированными в ваш профиль Jira.

Задачи

Задачи в оригинале называются Issues, что можно перевести как «проблемы». Issue – это единица информации. В нее закладывается либо какая-то функция, которую нужно реализовать, либо ошибка в программе, которую необходимо исправить.

Issues – это составные части проекта и спринта. Именно список задач формирует рабочий процесс. Поэтому он и состоит из создания задач, наблюдения за ними, выполнения, анализа, дополнения, изменения и т.п.

Типы задач

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

https://www.atlassian.com/software/jira/templates/bug-tracking

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

Дорожная карта (расписание)

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

К примеру, если есть ряд новых функций для приложения, которые совместно формируют какую-то общую важную особенность ПО, то их объединяют в эпик как некую общую цель, к которой стремится команда в ходе спринта (или нескольких спринтов).

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

https://www.atlassian.com/ru/software/jira/guides/roadmaps/basic-roadmaps

Релизы

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

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

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

Код и деплой

Одно из преимуществ Jira – возможность тесно интегрировать ее с другими продуктами, например с платформами Bitbucket, Github и Gitlab.

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

https://medium.com/@partialcoder/jira-can-show-better-git-commit-messages-with-a-git-hook-360a2880a0b7

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

https://docs.gitlab.com/ee/integration/jira/issues.html

Pages

Еще одна разработка Atlassian – проект Confluence. Это что-то в духе Google Docs, только работающее в рамках Jira и менее функциональное.

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

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

В Pages по умолчанию есть несколько шаблонов для текста:

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

Дашборды

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

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

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

Плагины

Jira можно сделать еще функциональнее, если подключить к ней плагины сторонних компаний.

Некоторые из них продвигает сама Atlassian. В их числе интеграция с Git-системами, к примеру. Это один из наиболее распространенных и очевидных вариантов использования плагинов.

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

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

Коллекция плагинов в Atlassian Marketplace насчитывает сотни дополнений. Как платных, так и бесплатных. Есть из чего выбирать.

Как создать задачу в Jira?

Создать задачу можно несколькими способами.

Научиться создавать Issues – понять, как работать с Jira в целом. Создать новую задачу в Jira можно двумя путями:

Кликнув по кнопке Create в верхней панели управления.
Кликнув по кнопке Create issue в нужной колонке канбан-доски.

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

Уже после этого можно кликать по кнопке Create, и новая issue автоматически появится в списке и на выбранной доске. А если поставить галочку напротив Create another, то тут же появится окно для добавления еще одной задачи.

Список issues также можно импортировать из другого приложения. Для этого нужно загрузить в Jira CSV-файл с соответствующим содержанием.

Атрибуты задач

Создавая issue, можно указать для нее ряд атрибутов:

Summary. Краткое описание текущей задачи. Буквально в одно предложение.
Issue Type. Тип задачи выбирается в соответствии со стандартными или доступными на данном проекте. Подробнее.
Description. Полноценное описание, если таковое требуется.
Assignee. Член команды, которому нужно делегировать создаваемую задачу.
Labels. Что-то вроде тегов для более удобной сортировки задач по другим признакам, не входящим в список типов.
Reporter. Пользователь, который будет отчитываться за выполнение задачи.
Attachment. Файл, прикрепленный к задаче. Это может быть что угодно: аудио, картинка, документ docx и т.п.
Linked issues. То, с чем связаны создаваемые задачи (другие задачи/проекты).

https://scriptrunner.adaptavist.com/latest/jira/fragments/CreateConstrainedIssue.html

Основные принципы повышения производительности в Jira

Есть как минимум 5 способов сделать работу с Jira эффективнее.

Делите большие задачи на мелкие

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

Каждая issue должна быть понятной единицей информации, представляющей собой компонент более глобальной цели.

Делите даже небольшие цели на еще более маленькие составные части. Так всем будет проще. Легче будет выполнять работы, легче будет отслеживать прогресс. Не будет зависаний на выполнении какой-то одной задачи. Интерфейс Jira позволяет без проблем ориентироваться даже в большом списке задач.

Комментируйте задачи

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

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

Записывайте все выполненные действия

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

Логи работают по тому же принципу, что и коммиты. Коммит – это фактически выгрузка любого изменения приложения в git-систему. Поменяли цвет иконки? Сделайте коммит и отправьте его в git-систему. Добавили новую функцию в код? Сделайте еще один коммит. И так на любой чих.

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

Планируйте спринты

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

Планирование даст возможность быстрее влиться в спринт и без переработок выполнить все поставленные задачи. Четко и без аврала.

Делайте записи на регулярной основе

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

Стоимость Jira

В бесплатной версии Jira есть ограничение на количество участников в команде и на количество сохраняемых файлов. Чтобы их снять, нужно оплатить подписку. Она стоит около 500 рублей на пользователя. То есть команда из 20 человек заплатит за месячную подписку 10 000 рублей.

Аналоги Jira

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

https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

Trello

Trello появился раньше, чем Jira. Это тоже продукт Atlassian, но более универсальный. Trello не заточен исключительно под нужды разработчиков и может использоваться для решения любых задач. Его используют маркетологи, бизнесмены, HR, копирайтеры и т.п.

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

Basecamp

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

YouTrack

Система управления проектами от знаменитой компании JetBrains, создавшей популярные IDE для разных языков программирования. У YouTrack много преимуществ: встроенная база знаний, принадлежащая конкретной команде, умный поиск по задачам, комментариям и другим единицам информации, удобные методы организации карточек на досках.

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

ClickUp

ClickUp – это своего рода прокаченная версия Jira. Здесь есть возможность делегировать комментарии, создавать упрощенные списки задач, работать с полноценным текстовым редактором, устанавливать рабочие статусы пользователям и так далее. Много мелочей, которые будут полезны для разработчиков.

Вместо заключения

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

Заметки тестировщика

Источники:

https://www.testingdocs.com/create-scrum-project-in-jira-software/
https://startpack.ru/application/jira
https://www.atlassian.com/ru/software/jira
https://timeweb.com/ru/community/articles/kak-rabotat-v-jira

#it

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

#заметкитестировщика

#qa

#bugs

#features

#testing

#protesting

#jira

Баг и фича. В чем разница? Классификация и жизненный цикл дефектов.

2022-07-14T17:43:20.074Z

Содержание:

Нет, скажите мне можно одно слово - пофикшено!

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

Начнем с терминологии (определения из ISTQB):

Просчет (mistake): См. ошибка;
Недочет (fault): См. дефект;
Помеха (bug): См. дефект;
Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы;
Отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.
Ошибка (error): Действие человека, которое приводит к неправильному результату;

Тестировщиков или разрабов?

Однако же на практике редко кто используют именно эту терминологию. Как правило, тестировщики в России пользуются следующими терминами:

Ошибка (Error) возникает из-за просчета (Mistake) в написании кода разработчиком;
Дефект (Defect) это скрытый недостаток в ПО, возникший из-за ошибки в написании кода;
Когда дефект (Defect) обнаруживается тестировщиком, он называется багом (Bug);
Если тестировщики упустили дефект и его нашел пользователь, то это сбой (Failure);
Если программа в итоге не выполняет свою функцию, то это отказ (Fault).

Баг и фича. В чем разница?

Как нам вообще определить, что является багом, а что фичей на живом проекте? С опытом приходит насмотренность и понимание многих вещей. Но как же быть всем неокрепшим юным умам?

Шуточная картинка, которая отлично передает разницу между понятиями

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

На своей первой работе в компании, которая занималась развитием социальной сети для соседей и УК, мне приходилось чуть ли не постоянно уточнять, действительно ли я нашла баг. Но в этом нет ничего страшного. Запомните одно правило - лучше не бояться и несколько раз спросить, но знать потом наверняка. Чем полагаться на собственные силы и допустить кучу ошибок.

Серьезный тестировщик. December 25, 2020

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

Это баг, если: - работало, но вдруг перестало;

- работает, но неправильно;

– реализация не соответствует описанию и в задаче в явном виде не зафиксированы корректировки;

– нужно изменить название кнопки/страницы/раздела, потому что в них есть опечатка или “Отменить отмену” (классика!);

– опечатки в принципе (легко может иметь разный приоритет в зависимости от целей и задач проекта);

– после сохранения информация не появляется на странице, даже если в консоли 🟢 200 ОК;

Так выглядит Сhrome DevTools

– не все указанные при сохранении поля отображаются на странице, но поля неизменно показываются при редактировании;

– при нажатии на кнопку “УДАЛИТЬ ВООБЩЕ ВСЕ ДАННЫЕ КЛИЕНТА” нет модального окна с подтверждением Да/Нет, да и сделать это может любой пользователь без авторизации, который нашел ссылку;

– по переходу по прямой ссылке на услугу не проверяется какой пользователь сейчас авторизован и таким образом можно посмотреть чужие профили или детали услуг, если подобран валидный id;

– можно c URL’ом заказать услугу другому клиенту или в Elements через DevTools изменить стоимость в корзине;

– информация торчит за границами своего блока или “наслаивается” на другой (ж-ж-ж-жуть, но на некоторых проектах этим можно легко пренебречь);

– страница очень долго открывается, ну о-о-очень долго — секунд 30 на стабильном интернете (взбешённый клиент гарантирован);

– система делает что-то, что она не должна делать согласно изначальной задумке. Например, закрытие аккаунта не только переводит его в статус “Закрыто”, но и возвращает клиенту все деньги, которые он принёс проекту за всё время сотрудничества за уже оказанные услуги (о-о-ой!);

– неудобно пользоваться. Например, чтобы посмотреть детали услуги клиента, нужно зайти на три вкладки вглубь аккаунта, а смотреть нужно 2–3 раза в день. Или неудобно копировать информацию со страницы, а по рабочим вопросам это нужно делать несколько раз в день — это баг интерфейса и он должен быть исправлен.

Это фича-реквест, если:

– нужно изменить название кнопки/страницы/раздела, потому что есть ощущение, что оно не отражает действительности;

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

– знаете как улучшить ту или иную часть системы, чтобы было удобней. Например, меню необоснованно занимает 30% ширины экрана, а полезная информация ютится на оставшихся 70%;

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

– на странице не хватает какой-то информации или возможности её добавить;

– на странице не хватает фильтров и пагинации, когда информации много и трудно найти нужное или отображение 1000+ элементов существенно сказывается на скорости загрузки страницы;

– пользователь ведёт дополнительную отчетность в блокноте/экселе, когда проблему можно решить выводом ID на странице и несколькими фильтрами.

Хорошо если в команде есть UX/UI дизайнер, а если нет? Тестировщику стоит различать что в дизайне баг, который может привести к печальным последствиям, а что запрос на улучшение, который сделает взаимодействие пользователей с системой более гладким и удобным, но может быть реализован позднее.

Поговорите с Главным По Проекту, узнайте кто ваш пользователь, спросите про критичные для пользователя и бизнеса фичи, запишите что будет “шоу-стоппером” для релиза (кроме очевидных “ничего-не-работает-памагити”), скорректируйте свои проверки в соответствии с этими знаниями и не бойтесь предлагать улучшения.

Классификация дефектов

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

Классы дефектов:

Дефекты требований и спецификаций (Requirements and Specifications Defects):

Начало жизненного цикла ПО важно для обеспечения высокого качества разрабатываемого ПО. Дефекты, введенные на ранних этапах, очень трудно и дорого устранить на более поздних этапах. Поскольку многие документы с требованиями написаны с использованием представления на естественном языке, они могут стать:

- Двусмысленными
- Противоречивыми
- Непонятными
- Избыточными
- Неточными

Некоторые специфические дефекты требований / спецификаций:

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

Дефекты дизайна. Дефекты дизайна возникают когда неправильно спроектированы:

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

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

К дефектам дизайна относятся:

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

Дефекты кода: Дефекты кодирования возникают из-за ошибок при реализации кода. Классы дефектов кодирования аналогичны классам дефектов дизайна. Некоторые дефекты кодирования возникают из-за непонимания конструкций языка программирования и недопонимания с разработчиками.

Алгоритмические дефекты и дефекты обработки:

Непроверенные условия overflow and underflow;
Сравнение несоответствующих типов данных;
Преобразование одного типа данных в другой;
Неправильный порядок арифметических операторов;
Неправильное использование или пропуск круглых скобок;
Потеря точности (Precision loss);
Неправильное использование знаков.

Дефекты управления, логики и последовательности: этот тип дефектов включает неправильное выражение операторов case, неправильное повторение циклов и пропущенные пути;
Типографические дефекты: в основном это синтаксические ошибки, например неправильное написание имени переменной, которые обычно обнаруживаются компилятором, self-reviews, or peer reviews;
Дефекты инициализации: этот тип дефектов возникает, когда операторы инициализации пропущены или неверны. Это может произойти из-за недопонимания или отсутствия связи между программистами или программиста и дизайнера, небрежности или непонимания среды программирования;
Дефекты потока данных: дефекты потока данных возникают, когда код не следует необходимым условиям потока данных;
Дефекты данных: на это указывает неправильная реализация структур данных;
Дефекты интерфейса модуля: возникают из-за использования неправильных или несовместимых типов параметров, неправильного количества параметров или неправильного порядка параметров;
Дефекты документации кода: когда документация по коду не описывает, что программа на самом деле делает, либо является неполной или двусмысленной;
Внешнее оборудование, дефекты программных интерфейсов: эти дефекты возникают из-за проблем, связанных с Системными вызовами, Ссылками на базы данных, Последовательностью ввода / вывода, Использованием памяти, Использованием ресурсов, Обработкой прерываний и исключений, Обменом данными с оборудованием, Протоколами, Форматами, Интерфейсами с файлами сборки, Временными последовательностями.

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

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

В англоязычной Wikipedia описано плюс-минус то же самое.

Жизненный цикл дефекта (Defect/Bug Life Cycle)

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

https://www.guru99.com/images/1-2015/012715_0802_BugLifeCycl1.png

Статусы дефекта

Новый (New): когда новый дефект регистрируется и публикуется впервые;
Назначен (Assigned): после публикации бага тестировщиком руководитель тестировщика утверждает ошибку и передает ее команде разработчиков;
Открыт (Open): разработчик начинает анализ и работает над исправлением бага;
Исправлен (Fixed): разработчик внес необходимое изменение в код и проверил его;
Ожидает повторного тестирования (Pending retest): как только дефект будет исправлен, разработчик предоставляет тестировщику конкретный код для повторного тестирования кода. Поскольку тестирование программного обеспечения остается незавершенным со стороны тестировщиков, ему присваивается статус «ожидает повторного тестирования»;
Повторное тестирование (Retest): на этом этапе тестировщик выполняет повторное тестирование кода, чтобы проверить, исправлен ли дефект разработчиком;
Проверен (Verified): тестировщик повторно тестирует баг после его исправления разработчиком. Если баг исправлен, то присваивается статус «проверено»;
Переоткрыт (Reopen): если баг сохраняется даже после того, как разработчик исправил баг, тестировщик меняет статус на «повторно открыт». И снова баг проходит жизненный цикл.
Закрыт (Closed): если баг больше не существует, тестировщик присваивает статус «Закрыто».
Дубль (Duplicate): если дефект повторяется дважды или дефект соответствует той же концепции ошибки, статус изменяется на «дублировать».
Отклонен (Rejected): если разработчик считает, что дефект не является таковым, он меняет статус на «отклонен»;
Отложен (Deferred): если текущий баг не является приоритетным и ожидается, что он будет исправлен в следующем выпуске, таким багам присваивается статус «Отложено»;
Не является багом (Not a bug): если это не влияет на функциональность приложения, то багу присваивается статус «Не является багом».

https://www.guru99.com/images/defectcyclechart.png

Статусы могут различаться в зависимости от того, какой баг-трекинговой системой вы пользуетесь.

Утечка дефектов и релиз бага (Bug Leakage & Bug Release)

Утечка бага (Bug Leakage): возникает когда пропускается баг в билде, который вышел в Production. Если баг был обнаружен конечным пользователем или заказчиком, мы называем это утечкой ошибок.

Выпуск бага (Bug release): выпуск программного обеспечения в Production с некоторыми известными багами. Эти известные баги следует включить в примечания к выпуску (release notes). Другой вариант - передача программного обеспечения группе тестирования с некоторыми известными багами, серьезность и приоритет которых невысоки. Эти ошибки можно исправить перед выпуском в Production.

В заключение

Если вам нравится мой канал, его атмосфера и наполнение, то вы можете поддержать меня донатом! На вкусную шоколадку и кофе. Сделать это можно нажав на кнопку вверху/внизу статьи или перейдя по ссылке https://teletype.in/@qanote. Есть возможность анонимного доната. Заранее спасибо!

Заметки тестировщика

Источники:

Дефекты и ошибки
Баг или фича? Вот в чём вопрос!
Defect/Bug Life Cycle in Software Testing

#it

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

#заметкитестировщика

#qa

#bugs

#features

#testing

#protesting

О СТАНДАРТАХ ДОКУМЕНТАЦИИ

2022-07-11T17:03:42.031Z

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

Стандарты можно разделить на следующие группы: ГОСТы (наши, российские) и международные (буржуйские).

⭕️ГОСТЫ

Обратимся сначала к ГОСТ-ам. Они расстраивают датами разработки (впрочем, похоже, за эти годы в документировании не многое изменилось) и радуют бесплатностью.

ГОСТ Р ИСО 9127-94 «Документация пользователя и информация на упаковке для потребительских программных пакетов». Довольно кратко (весь документ – около 20 страниц), указаны основные требования к составу и содержанию документации пользователя.

ГОСТ Р ИСО/МЭК 15910-2002 «Процесс создания документации пользователя программного средства» — стандарт больше отвечает не на вопрос «Что» должно быть в документе, а «Как» должен создаваться документ. Дополнительно есть подробное описание стиля документа с примером – довольно удобная штука для создания шаблона: один раз запариваешься (и забиваешь в шаблон всё: от выравнивания до формата подписей рисунков), а потом клепаешь документы все одного вида, а не с заголовками разного шрифта.

ГОСТ-ы серии 19.хх – серия ЕСПД, страсть, какая древняя (в среднем, документы созданы в 78-м году), но зато такие же лаконичные, как в ГОСТ 9127, требования ко многим видам документов.

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — стандарт на ТЗ.

⭕️МЕЖДУНАРОДНЫЕ

Узнала, что международные стандарты не бесплатные. Это как правила дорожного движения делать платными. Но в принципе, может, и резонно: организации-то не государственные. Хотят – могут и деньги брать за свою работу. К счастью, многие стандарты можно скачать по-привычному, по-пиратски.

IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» — в документе обозначены требования к структуре, содержимому и формату инструкций пользователя.

IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» — рекомендации к документам, описывающим архитектуру программного обеспечения (http://en.wikipedia.org/wiki/Design_document), то бишь к техническому описанию.

ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» — рекомендации по созданию документации пользователя. Так сказать, советы «хозяйке на заметку». Довольно приятное руководство с большим количеством примеров (имхо, больше подходит для чтения до или в самом начале создания документации, так как подходит к процессу основательно, от самого планирования). Также в приложениях есть чеклисты «что не забыть сделать в процессе разработки документации» и «что должно быть в документе».

ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» — довольно свежий и, судя по содержанию, полезный документ. Но, как раз, видимо, ввиду его свежести, этот стандарт нигде не найти бесплатно.

Заметки тестировщика

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

#ит

#информационные_технологии

#it

Источник

Плюсы и минусы работы в американской компании

2022-07-11T16:23:29.324Z

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

К преимуществам, помимо релокации, могу отнести:

✅ Постоянная работа на английском языке
👩🏼‍🏫 60+ уроков в SkyEng с личным преподавателем
🌟 Высокоразвитая корпоративная культура
🔥 Общение с мега крутыми и опытными профессионалами
🏥 Глубокое погружение в медицинскую отрасль
📈 Возможность сменить направление внутри компании
💰Конкурентная заработная плата
👩🏻‍💻 Возможность миксовать удаленку и офис
💫 ДМС, страхование жизни и от онкологических заболеваний
🌴 Полис путешественника
🙇🏻‍♀️ Занятия с психологом
🖇 3 дополнительных оплачиваемых дня отгула
🏊🏼‍♂️ Компенсация тренировок и спортивного инвентаря
🖥 Компенсация техники/периферии

Недостатки ниже для кого-то покажутся преимуществами, но к этим моментам я не была сразу готова:

Очень много работы с людьми. По личным ощущениям, QA общается с куда большим количеством людей разных взглядов и характеров, чем тестировщик. Нужно уметь находить подход к каждому, чтобы делать качественный продукт.
Повышенное чувство ответственности и, как следствие, визиты к психологу риск выгорания
Рутина. Конечно, все мы постоянно учимся новому, но однотипные задачи это большая часть работы, от которой со временем устаёшь.
Сидячий образ жизни. Не каждый может себя мотивировать заниматься спортом (даже со спортивной программой), особенно когда свободное время тратишь на обучение новым навыкам.

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

Заметки тестировщика

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

#ит

#qa

#информационные_технологии