Для запуска большой системы может быть недостаточно функционального и интеграционного тестирования. За обилием технических моментов можно упустить важный для бизнеса аспект, который может заставить отложить запуск вроде бы готового продукта (услуги, предложения). Мы говорим про тестирование бизнес-процесса (end-to-end-тестирование или просто e2e). Рекомендуем проводить его целиком, не фрагментируя на спринты и релизы систем, пройти от и до на тестовой среде без риска для пользователей и инфраструктуры.
О том, как подготовиться к такому тестированию, расскажем в этой статье. Владельцам продукта (product owner, далее — PO) и QA будет полезно узнать о возможных ошибках при планировании и способах оптимального распределения ресурсов на реализацию задачи для нескольких команд.
Когда и кому нужно end-to-end-тестирование
У PO и QA есть инструменты, которые позволяют понимать состояние продукта и процессов. Они тестируют, снимают метрики, планируют и автоматизируют независимую поставку изменений пользователю, чтобы сократить time-to-market и быть готовыми реализовать любые потребности бизнеса.
Бизнес-процессы в рознице
Рассмотрим поставку бизнес-ценностей на примере Scaled Agile Framework, где взаимодействует много внутренних и внешних систем и сервисов, есть вендоры, разный технологический стек, состав команд, функциональность, а значит и субъективный взгляд на бизнес-ценности, когда каждая команда всё видит «со своей колокольни».
Зачастую бизнес-ценность не укладывается в компетенцию одной команды и даже одной системы. Назовем такую ценность capability (высокоуровневое функциональное решение, которое реализуется за один цикл). Кто отвечает за реализацию capability в нескольких системах и командах? Чтобы это не стало общей ответственностью, у capability должна быть ведущая команда. И ей требуется новый инструмент — end-to-end-тестирование (e2e), которое обеспечит поставку ценности.
E2e проверяет работу бизнес-процесса, проходящего через разные системы, например, от регистрации клиента до закрытия сделки. Кажется, всё просто: определили системы, команды и срок запуска, запланировали и провели. Но давайте разберемся, так ли это.
Внедрение e2e: как не наступить на грабли
Главная проблема внедрения нового инструмента – ресурсы. А точнее оценка и планирование e2e-тестирования при отсутствии практики. Ведь если у нас всё хорошо, то лишних ресурсов нет ни в одной команде, которые реализуют capability. Клиенту важно знать, что всё готово к запуску бизнес-процесса.
И вот QA-специалистов просят оценить задачу «на тестирование» capability, которое реализуется, например, в течение четырех спринтов в трех командах и четырех системах. При этом оценить нужно свою часть тестирования, учитывая имеющиеся ресурсы. Хорошо, если оценивает QA-лид, который имеет опыт тестирования разных систем.
Моделирование бизнес-процесса тестирования ПО в ELMA
При этом PO и аналитики уже проработали зависимости и знают, кто будет участвовать в e2e. Хорошо, если у всех есть опыт е2е-тестирования, всё учтено, и бизнес знает, чего хочет или всегда готов к диалогу. К сожалению, так бывает не всегда.
Рассмотрим ситуацию, когда команда системы «Г», которая поддержала зависимость по capability, проводит подготовку к квартальному планированию. Так может выглядеть диалог PO и QA:
- У нас планируется e2e по сделкам в армянских драмах. Давайте оценим.
- А что нужно проверить? – робко интересуется QA.
- Что сделка в драмах закрывается.
- А чем это отличается от других сделок? – не унимается QA.
- Валютой.
QA думает: «Боже, я каждый день на тесте закрываю сделок на 10 млн рублей и на 12 в тенге. Тут что-то не так», – а сам спрашивает:
- А для чего e2e?
- Сайт локализуют для Армении и их команда – ведущая в e2e.
- У них в команде есть QA? Нужен будет его контакт.
- Да, конечно.
- Наша доработка по новым валютам уже на проде за фичатогглом (feature toggle – переключатель, настройка доступности функционала на проде). Пусть будет 2 сторипойнта с учетом коммуникаций и оформления отчета.
Дальше всё будет так, как бывает, когда нет тест-плана: забыли включить в тестирование одну из систем, начали е2е до того, как исправили баги и не закрыли сделки. В итоге, в системе «Б» весь спринт проходился раз за разом один и тот же сценарий. В следующем спринте тестирование завершили. Об успешном «сквозном» тестировании сообщили на демо. Что сделали не так?
Во-первых, растворилась цель тестирования, результатом стала убежденность, что дефектов нет.
Во-вторых, не соблюдается принцип раннего тестирования – чем раньше выявлена проблема, тем дешевле исправление. О том, как QA своевременно подключать к задачам команды, мы рассказывали в этой статье .
В-третьих, QA отрицают свою ведущую роль в e2e. Они не применяют тест-дизайн в рамках всего бизнес-процесса, ограничиваются лишь своей системой. Покрытие может быть избыточным или недостаточным, если продолжать воспринимать тестирование бизнес-процесса фрагментарно, разделенным по требованиям систем.
В результате такое е2е-тестирование не только тратит ресурсы нескольких команд, но и не достигает цели. Затраты могут быть не оценены, как при планировании, так и в итоге. И пока неясно, по каким метрикам оценивать эффективность e2e, важно должным образом к нему подготовиться, чтобы снизить потери и риски.
ЛАЙФХАК: о тест-дизайне capability можно написать отдельный материал, но опыт показывает, что оптимально использовать попарное и парное тестирования. Первое позволит учесть максимум требований в разных системах. При этом покрытие будет достаточным, так как тестирование релизов проводится параллельно. Парным тестированием (именно QA из разных систем) следует пройти хотя бы один сценарий. Свежий взгляд позволит заметить то, что могли забыть или пропустить.
Подготовка: как сделать эффективнее
В идеале подготовку к e2e при участии QA нужно начинать до планирования и оценки задач. QA могут запросить доступы к тестовым стендам смежных систем, получить тестовые устройства и настроить инструменты. Важно провести установочную встречу с QA из всех привлекаемых команд. Желательно «пройти» бизнес-процесс с аналитиком или с клиентом, который погрузит QA и даст представление о бизнес-ценности.
ЛАЙФХАК: если организовать встречу с клиентом сложно, то это может быть созвон QA-специалистов, работающих в разных системах. Объединив знания о продукте, они смогут получить необходимые сведения для дальнейшего планирования.
Главное – у QA ведущей команды должна собраться информация, которая нужна для проведения тест-дизайна и постановки цели тестирования:
- ожидания бизнеса, особенности, новизна, преимущества нового процесса;
- поведение пользователей, их действия по бизнес-процессу вне системы, которые нужно учесть;
- особенности взаимодействия систем, проблемы и выявленные требования;
- возможность пройти схожий процесс или ознакомиться со всеми системами, чтобы иметь представление о тестировании каждой, готовности и количестве предстоящих изменений в ней.
Необходимо сфокусироваться на бизнес-процессе и интеграции систем, чтобы проверить и определить достаточный состав участников. На своём опыте мы поняли, что роль команд в тестировании может быть разной:
- организация, составление тест-кейсов, плана и отчета;
- прохождение сценариев;
- утверждение тест-кейсов и проверка результатов в своей системе;
- настройка тестовых стендов или подготовка тестовых данных.
В результате у нас вырисовывается не только покрытие и план, но и шаги по оптимизации ресурсов. Например, настройка систем и подготовка тестовых данных могут быть делегированы команде, которая разгрузит QA при необходимости.
Как доступы могут сэкономить ресурсы
Прекрасно, когда есть все доступы. Можно ввести данные в систему «А» и в ней же, как пользователь, видеть результат, после обработки данных в «Б» и «В». Затем взять тестовое устройство и под другой ролью в системе «Г» продолжить и завершить процесс. В итоге проверить его артефакты в «А» и «Д». Это e2e-тестирование выполняет один специалист — без потерь на коммуникации и синхронизацию между QA из разных команд.
Однако не всегда можно получить доступ, или его бывает недостаточно, чтобы проверить что-то сложное. Важно оценить необходимость и пользу от привлечения к e2e QA-специалиста из другой команды, у которого есть доступы и знание системы, или будет эффективнее получить доступы для своей команды. Возможно, они будут полезны вам в дальнейшем.
Поскольку в тестировании могут участвовать вендоры и команды без QA, доступы помогают концентрировать ответственность и делать коммуникации функциональными.
Запуск: без чего не обойтись
Итак, мы практически подготовили тест-план, получили понимание о бизнес-процессе и представление о цели тестирования. На этом этапе есть сценарии, участники, их роли. На квартальном планировании мы расставили и обсудили зависимости, оценили задачи на разработку, e2e и настройку стендов, возможно даже запланировали «окно», когда настройки нельзя ломать. Теперь мы знаем:
- цель тестирования относительно бизнес-процесса;
- что и где будет и не будет проверяться;
- что и где нужно сделать, чтобы начать проходить сценарии;
- сами сценарии.
Да, может быть много неизвестных и переменных. Все вопросы стоит фиксировать в плане. Важно получить ответы до спринта, когда запланировано e2e, чтобы участники могли переоценить свои задачи на тестирование.
ЛАЙФХАК: тест-план не обязательно представляет из себя документ. Можно создать чат, задачу или страницу в confluence для фиксации договоренностей и обмена артефактами, или в системе управления тестами, например, в Test Rail. Важно не пренебрегать коммуникациями, чтобы не только следовать плану, но и вовремя его корректировать.
Исходя из количества неизвестных можно определить критерии завершенности e2e. Например, не обязательно всем участникам проводить ретест по некритичным дефектам или тестировать доработки одной из систем, необходимость которых выявил e2e. Всё это важно обсудить с участниками, зафиксировать в плане. Тогда e2e не станет черной дырой для ресурсов.
С таким планом даже отменившееся e2e превратится в работу, которая не выполнена по конкретной причине. Без плана может получиться ничего не стоящий отчет.
Подведем итоги
Своевременное подключение QA позволит не потерять бизнес-ценность в ходе e2e-тестирования.
На практике QA могут подсветить требования, не учтенные в другой системе, основываясь на предыдущем опыте и проблемах подобных интеграций. Например, если в базе CRM нет валидации клиентских данных, но она есть во фронтовых системах, где пользователь обслуживает клиента. Зачастую новые приложения не учитывают общие правила валидации, и могут сохранять неверные данные в CRM, нагружая пользователей других приложений. Если QA подключатся вовремя, до начала e2e-тестирования, они подскажут, что нужно учесть.
Погружение QA в бизнес-процесс позволит запланировать e2e оптимальным образом:
- определить необходимые команды
- определить степень их участия и подготовительные мероприятия
- распределить ресурсы с помощью получения доступов
- договориться о критериях завершенности.
Исходя из плана каждая команда оценит и запланирует свою работу. Так мы получим не простую формальность, а гибкий процесс на уровне проекта.
На уровне команд: ресурс одной не будет тратиться на тестирования функциональности в другой, так как разграничены степень участия и определены критерии начала (готовности). Прописанные критерии завершенности (Definition of Done, DoD) позволят понять, в какой момент общая задача готова и начинаются доработки и исправления в отдельной команде.
На выходе владельцы продукта получают информацию, как о состоянии отдельного продукта, так и готовности всего capability к запуску.
Больше интересных кейсов — на нашем сайте.
Понравилась статья?
Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.
Источник: www.simbirsoft.com
Тестировании новых бизнес процессов это
Настоящий методический документ устанавливает единые требования к процессу тестирования эффективности контрольных процедур.
Тестирование контрольных процедур включает в себя следующие этапы:
- Составление планов тестирования
- Проведение оценки дизайна и операционной эффективности контрольных процедур
- Документирование процедур тестирования
- Анализ выявленных недостатков контрольных процедур владельцем процесса
Порядок формирования плана тестирования
Планы тестирования должны разрабатываться для контрольных процедур с учетом данных, собранных в ходе документирования контрольных процедур, и результатов сквозного тестирования.
Период тестирования
Период тестирования должен быть выбран таким образом, чтобы иметь возможность подтвердить эффективность контрольных процедур в течение периода, в котором осуществляются финансово-хозяйственные операции, включаемые в отчетность, и подготавливается отчетность, при этом период тестирования должен захватывать только операции текущего финансового года.
По новым или измененным контрольным процедурам период тестирования должен быть равен периоду действия этой контрольной процедуры в новом или обновленном дизайне. При этом необходимо оценить необходимость тестирования нового или измененного контроля в текущем финансовом году либо перенос тестирования на следующий год, когда период тестирования будет более представительным и показательным.
В случае, если контрольная процедура была изменена в рамках тестируемого периода, необходимо провести тестирование операционной эффективности предыдущей контрольной процедур с начала периода по дату изменения дизайна.
Выбор метода тестирования
Существует несколько методов тестирования, предполагающих различную степень гарантии того, что контрольная процедура выполняется эффективно:
- проверка документации;
- воспроизведение контрольной процедуры;
- наблюдение;
- опрос.
Проверка документации — проверка эффективности контрольной процедуры путем изучения соответствующих документов.
Воспроизведение контрольной процедуры — повторное выполнение контрольной процедуры проверяющим (сверка, пересчет и т.д.), либо воспроизведение процесса под наблюдением проверяющего. Само по себе не является достаточными способом при тестировании ручных контрольных процедур так как факт того, что в ходе воспроизведения проверяющий приходит к правильному результату, не означает, что контрольная процедура была проведена. Данный метод тестирования является эффективным способом при тестировании автоматизированных контрольных процедур.
Наблюдение — наблюдение за выполнением контрольной процедуры для подтверждения вывода об эффективности контрольной процедуры.
Опрос — заключается в проведении интервью, с целью получения информации о выполнении контрольных процедур. Onpoc обычно используется на этапе сквозного тестирования.
Одновременное использование двух и более методов тестирования позволяет получить более высокую степень уверенности, чем использование только одного из них. Чем более существенной является контрольная процедура (сумма операций, вероятность возникновения ошибки), тем важнее обеспечить получение доказательств ее эффективности несколькими метода тестирования.
Формирование выборки
Выборка должна соответствовать следующим требованиям:
- Совокупность, из которой производится выборка, должна быть полной (то есть включать все операции, имевшие место в течение проверяемого периода).
- Выборка должна быть репрезентативной.
Для обеспечения репрезентативности выборки целесообразно распределить ее элементы по следующим признакам:
- равномерно в течение тестируемою периода (случайно) либо по количеству pas выполнения контрольных процедур / объему операций и их влиянию на финансовую отчетность в течение периода (большее количество процедур в конце квартала);
- по подразделениям;
- по иным параметрам.
При этом выборка должна производиться самим сотрудником, проводящим тестирование, а не владельцем контрольной процедуры. При выборе из разных кварталов или месяцев внутри периода рекомендуется выбирать декабрь или месяц конца квартала.
Выборка должна соответствовать тестируемым утверждениям финансовой отчетности
В зависимости от утверждений финансовой отчетности компании (в первую очередь таких, как полнота и существование) выборка может осуществляться из различных источников. В случае, когда контрольная процедура направлена на утверждение «существование или возникновение»,выборку следует строить от данных учета / отчетности к первичным документам, являющимися доказательствами контрольной процедуры. При тестировании процедуры, направленной на утверждение «полнота», следует строить выборку от первичных документов к данным учета / отчетности.
Размер выборки зависит от следующих факторов:
- Частота осуществления контрольной процедуры.
- Метод контроля (ручная или автоматическая процедура).
При тестировании ключевых контрольных процедур основных бизнес-процессов необходимо использовать подход, не противоречащий требованиям и стандартам, применимым внешним аудитором финансовой отчетности. Размер выборки для таких контрольных процедур рассчитывается таким образом, чтобы предоставить разумную гарантию в том, что контрольная процедура является эффективной и фактически выполнялась в течение всего проверяемого периода.
На основании профессионального суждения сотрудника, ответственного за тестирование, может быть принято решение об увеличении либо уменьшении размера выборки. Если контрольная процедура, направлена на покрытие существенного риска, размер выборки для данной контрольной процедуры может быть увеличен.
Факторы существенного риска:
- Вероятные случаи мошенничества со стороны сотрудников Компании.
- Изменения принципов бухгалтерского учета.
- Сложность учета транзакций.
- Существенные транзакции со связанными сторонами.
- Нестандартные транзакции.
- Применение оценок руководства для отражения операций в учете.
- Обработка данных, используемых для отражения операций в учете, вручную, без применения информационных систем.
Если риск, покрываемый контрольной процедурой, является низким, контрольная процедура была протестирована, используя стандартный размер выборки, хотя бы один раз за последние три года и дизайн контрольной процедуры с момента последнего тестирования не менялся, может быть принято решение о снижение размера выборки. Одним из факторов, способствующих снижение риска, является наличие эффективных для бизнес-процесса ККУ.
Методы формирования выборки
Допускается применение одного из следующих методов формирования выборки:
- При использовании метода систематической (или механической) выборки, из полного пронумерованного списка элементов генеральной совокупности (N), выбирают элементы через равные интервалы (шаги), например каждый N / 25 элемент, начиная от случайно выбранного элемента.
- При применении метода простого случайного отбора, необходимо следить за распределением выбираемых элементов в совокупности во времени.
Обоснование выборки и применения профессионального суждения должно быть задокументировано в результате теста.
Источник: xn--h1adgdebxi5g.su
Зачем вам нужен QA и как это позволит сэкономить деньги
В этой статье речь пойдёт не о том, как QA-инженеры делают свою работу. Мы поговорим о том, почему обеспечение качества (Quality Assurance, QA) — незаменимая часть процесса разработки.
Цель профессии QA-инженера — помочь создать качественный продукт. Их работа заключается не просто в поиске багов и не в обыкновенном тестировании. Основная задача QA-инженера — предотвратить дефекты и, следовательно, обеспечить высокое качество процесса разработки и его результатов. Это достаточно общее определение, поэтому в этой статье мы попытаемся рассказать о некоторых деталях, которые помогут осознать ценность QA.
Дефект или баг — фрагмент кода с ошибкой, из-за которого система не может выполнять свою функцию. Это не всегда означает, что всё не работает. Оно может работать, но не так, как надо.
Так чем занимаются QA-инженеры? Они:
- Выявляют слабые места и несоответствия в продукте на всех этапах разработки;
- Помогают определить требования к проекту;
- Предоставляют исчерпывающую информацию о качестве продукта;
- Тестируют продукт на протяжении всех фаз жизненного цикла разработки системы (software development lifecycle, SDLC).
Важно отметить, что QA заинтересованы в том, чтобы сделать любой продукт удобным для пользователя как в плане функциональности, так и в плане дизайна. Для этого они тесно взаимодействуют со всеми членами команды и постоянно обращаются к заданным требованиям.
Теперь давайте разберём все этапы, на которых нужны QA, их роли на этих этапах и значимость их работы для бизнеса.
Когда вам нужен QA?
В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).
Сбор требований
Это, наверное, самый важный этап. На первой встрече клиенты в общих чертах описывают, что они хотят. Они описывают функциональность приложения или сервиса и какими особенностями он должен обладать, но редко упоминают технологии, которые должны использоваться в продукте.
Во многих компаниях анализ требований к функциональности является обязанностью бизнес-аналитиков. Однако они не могут гарантировать совместимость технических компонентов. Поэтому на этом этапе кроме бизнес-аналитиков заняты и другие специалисты, включая QA. Задачи последних включают:
- Анализ и принятие решения о том, совместимы ли между собой требования, и могут ли они быть реализованы в рамках одной системы.
- Оценка того, какие решения будут работать, а какие — нет.
- Планирование необходимых методов тестирования (подробнее об этом ниже).
Валидация — процесс оценки проекта до начала разработки с целью выяснить, удовлетворяет ли потенциальный продукт требованиям пользователей и стоит ли вкладывать в эту идею усилия.
В течение этого этапа QA работают вместе с бизнес-аналитиками с целью выяснить, какой программный продукт может удовлетворить потребности пользователя. По сути, они проверяют, нужен ли продукт пользователям и рынку. Очень важно собрать отзывы пользователей, чтобы узнать, чего не хватает или что может быть улучшено (дизайн, функции) для обеспечения лучшего пользовательского опыта.
До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?
Планирование тестирования
На этом этапе QA определяют стратегию тестирования. Под определением стратегии имеется в виду оценка времени и усилий для всего проекта. После анализа требований QA создают документ, известный как тест-план. Он включает в себя ожидаемые результаты проекта, его масштаб и цель, а также определяет среду тестирования.
Без этого этапа процесс тестирования был бы полон неожиданных препятствий и непредвиденных обстоятельств. Чтобы дальнейшие этапы следовали строгой последовательности действий, QA должен составить и задокументировать план действий. В противном случае процесс может получиться неуклюжим.
Разработка тестов
Когда у нас есть тест-план, мы можем приступить к настройке среды тестирования и созданию тест-кейсов. Тест-кейс — это набор шагов, которые нужно выполнить, чтобы удостовериться, что в продукте нет ошибок и он работает согласно требованиям. После этого можно думать о критерии приемлемости — техническом стандарте, которому должен соответствовать программный продукт, чтобы считаться успешным.
Выполнение тестов
Этот этап многие считают единственной задачей QA — выполнение всех тест-кейсов по плану. Если какая-то часть системы работает хорошо, мы отмечаем её как прошедшую тестирование. Таким образом мы можем удостовериться, что ничего не пропустим и на выходе получим качественный продукт.
Если тест-кейс прошёл неудачно, значит в коде есть ошибка, и QA отправляют отчёт разработчикам, чтобы они проверили, что не так.
Отчёт о результатах
После тестирования продукта наступает время обсуждения, что было хорошо, а что не очень, для улучшения дальнейших циклов тестирования. Чтобы обеспечить быстрое исправление ошибок без каких-либо недопониманий со стороны разработчиков, каждая обнаруженная проблема должна быть хорошо задокументирована. Позже мы посмотрим на наиболее распространённые методы, которые используют QA для тестирования продукта с разных точек зрения.
Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.
Особенности работы QA
Множество компаний-разработчиков программного обеспечения работают спринтами — даётся список задач и две недели на их выполнение. Во время каждого спринта мы реализуем определённую часть требований к продукту и проходим через все пять стадий тестирования. Важно понимать, что тестирование не подразумевает только проверку каждого способа взаимодействия с продуктом. Конечно, и это тоже, но зачастую с системой можно сделать гораздо больше.
Если QA не участвуют в процессе разработки, то позже может оказаться, что команда разработчиков сделала что-то, что работает и работает хорошо, но не то, что нужно. Также QA помогают сократить время, необходимое для разработки новых тест-кейсов, так как чем раньше мы поймём, что и как мы собираемся тестировать, тем проще будет провести тестирование. Очень важно, чтобы разработчики и QA работали вместе, иначе всё превратится в соревнование «кто найдёт больше багов», что редко приводит к качественным результатам.
Теперь, когда мы знаем о циклах тестирования, можно вкратце рассказать, почему каждой команде нужен QA:
- Безопасный бизнес. У вас есть платёжная система, и она работает нормально. Пользователь платит за услугу и получает её. Однако вы не проверили все возможные случаи, и деньги идут не вам, а на случайный банковский счёт. Такой недочёт может очень дорого обойтись;
- Экономия денег. На приведённой ниже диаграмме хорошо видна взаимосвязь между этапами жизненного цикла и затратами. Гораздо дороже исправить ошибку, чем предотвратить её. Исправление одной ошибки может повлечь за собой другие, поэтому количество ваших проблем будет быстро увеличиваться;
- Защита репутации. Если выпустить багованный продукт и пользователи не будут довольны работой с ним, в дальнейшем их будет сложно убедить, что проблема решена и они могут снова им пользоваться. Первое впечатление сложно изменить, поэтому предоставьте качественный продукт. Если он не был протестирован вдоль и поперёк, то продукт может работать неправильно или не работать вовсе. Тестирование требует теоретических знаний, поэтому будет сложно обеспечить качество, если вы не профессионал;
- Контроль процесса. Если процесс разработки не контролируется и идёт вразрез с установленными требованиями, итоговый продукт может сильно отличаться от запланированного.
Вы могли заметить, что часто упоминается тестирование. Это потому, что есть такая отдельная дисциплина, как контроль качества (Quality Control, QC). Далее мы поговорим о работе QA, о разнице QA и QC, взаимосвязи SDLC и STLC, а также дадим детальное описание некоторых методов тестирования, используемых QA-инженерами.
QA
Обеспечение качества и контроль качества
Контроль качества (Quality Control, QC) охватывает всю деятельность, направленную на то, чтобы убедиться, что продукт хорошего качества и отвечает заданным требованиям. QC-инженеры занимаются поиском дефектов в продукте до его выпуска. Можно сказать, что обеспечение качества включает в себя контроль качества.
Есть случаи, когда продукт не требует QA, а только QC. Например, если команда получает продукт, разрабатываемый другими людьми, с целью проверить, соответствует ли код требованиям.
В некоторых командах QA и QC совмещаются с другими ролями. Иногда разработчики пытаются проверить свой собственный код. Тем не менее, это сказывается на качестве, так как гораздо сложнее найти ошибки в своём коде, чем в чужом.
Цикл разработки программного обеспечения и цикл тестирования
Разработка и тестирование должны быть синхронными. Команда, как единое целое, несёт ответственность за продукт. Если разработка и тестирование не выполняются одновременно, то возможны задержки и несогласованности, что ведёт к низкому качеству продукта.
Надеемся, нам удалось вас убедить в важности одновременного проведения SDLC и STLC. Теперь мы перейдём к некоторым популярным методам составления тестов, которые QA-инженеры используют для обеспечения качества.
Методы составления теста
Тест-кейс (или просто тест) — пошаговый подход к тестированию функциональности программного продукта. По сути сюда входят тестируемый объект и способ тестирования.
Метод составления теста — процесс выбора тестов, которые подтвердят, что продукт соответствует спецификациям до его релиза.
Есть разные методы составления теста, каждый из которых выявляет недостатки определённого типа. Поэтому выбор метода зависит от типа продукта, его готовности и требований.
На картинке ниже представлены основные методы составления теста:
Давайте рассмотрим подробнее каждый метод и случаи, в которых мы их используем.
Статический. Этот метод тестирует исходный код, функциональные спецификации и спецификации требований до выполнения кода (до выхода в релиз). Этот метод определяет структурные недостатки. Это не одноразовая работа, поэтому мы стараемся начать её на ранних этапах процесса разработки.
На основе структуры. Мы используем такой метод, когда у нас есть полный доступ к коду. Проще говоря, он касается внутренней логики и структуры кода. Такие тесты помогают определить неправильную или отсутствующую логику и опечатки в коде.
На основе спецификации. Также известный как тестирование чёрного ящика, данный метод тестирования анализирует функциональность программного продукта без изучения кода. Исходя из требований, мы выбираем соответствующие методы составления тестов, которые помогают нам получить тест-кейсы.
На основе опыта. Это больше вспомогательный метод, который позволяет QA тестировать программное обеспечение на основе их предыдущего опыта работы с подобными системами.
Теперь вы знаете достаточно, чтобы понять, какой теоретической базой должен обладать специалист, проводящий тестирование качества. Количество требуемых навыков делает практически невозможным обеспечение качества продукта человеком, не являющимся QA.
В заключение
Неважно, каким простым кажется продукт, ведь в основе его качества лежит тонна проделанной работы. Как заметил Дон Норман, «Хороший дизайн гораздо сложнее заметить, чем плохой». В большинстве случаев QA-инженеры дают людям возможность наслаждаться продуктом, проверив, что всё работает хорошо.
Обеспечение качества включает много всего, от тестирования до анализа результатов. Большинству программных продуктов нужны QA-инженеры, чтобы:
- Контролировать процесс разработки.
- Предотвращать ошибки в системе до того, как их найдут пользователи.
- Обеспечивать качество выпускаемого продукта.
Не так просто протестировать систему без особых навыков, даже опытному разработчику это вряд ли под силу. По этой причине в лучших командах QA и разработчики работают вместе; они могут объединить свои навыки для создания качественного продукта.
Источник: tproger.ru