С чего начинаются тесты

Содержание:

Кто участвует в процессе тестирования программного обеспечения?

Покупатель и/или пользователь ПО должны играть главную роль в процессе его тестирования. Заказчик должен работать с разработчиком во время процесса планирования и проектирования так, чтобы все стороны достигли договоренностей о том, из чего будет состоять заключительный продукт и как он должен выглядеть и работать. Джоэл Джилмен  в колонке «Law Report» журнала «Systems Integration» в феврале 1991 предложил, чтобы документ  тестовых критериев был составлен и включен в исходные требования к продукту или контракт.  Программисты должны быть ответственны за основное тестирование программного обеспечения. Хороший программист никогда не должен передавать программу к тестеру или отделу тестирования без первой обработки  тестовых сценариев,  которая определяет, отвечает ли программа определенным требованиям.  Нужно отметить, однако, что у тестировщиков и программистов есть различные цели, когда они тестируют программное обеспечение. Борис Бейзер  в  «Software Testing Techniques »- превосходной книге по основам тестирования — сказал,  что тестировщик  — это «тот, кто пишет и/или выполняет тестирование программного обеспечения с намерением  продемонстрировать, что программа не работает, в то время, как  программист – это тот,  чьи тестирования (если таковые имеются) предназначены, чтобы показать, что программа действительно работает».

Размер заработной платы и место работы

На работу QA-инженеров могут взять:

  • IT-компании по разработке ПО, игр, мобильных приложений, систем безопасности;
  • поставщики программно-аппаратных комплексов;
  • финансовые учреждения, например, банки или брокерские компании;
  • автомобильные заводы;
  • СМИ;
  • ритейлеры;
  • онлайн-школы.

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

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

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

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

  1. Стажер.
  2. Младший сотрудник, или junior.
  3. Работник среднего звена, или middle.
  4. Старший сотрудник, или senior.
  5. Ведущий специалист, или lead, он же может быть начальником отдела тестировщиков.

В среднем стажеры получают от 20 до 30 тыс. руб., junior – 40–60 тыс. руб., middle – от 60 000 до 90 000 руб., senior – от 90 000 до 130 000 руб., lead зарабатывает от 140 и выше.

Если говорить территориально, то в регионах средний уровень зарплаты составляет около 60 000 руб., в столице – около 100 000 руб.

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

Попытать счастья и найти выгодные вакансии можно на зарубежных биржах фриланса. Иностранные клиенты готовы заплатить 15–20 $ за час работы, а опытные специалисты могут зарабатывать и в 2 раза больше.

Из-за дефицита грамотных профессионалов-тестировщиков востребованность в специалистах только растет.

Доступ к коду программного продукта

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

  • Тестирование «белого ящика» – с доступом к коду.
  • Тестирование «черного ящика» – без доступа к коду продукта.
  • Тестирование «серого ящика» – на основе ограниченного знания внутренней структуры ПО. Часто говорят, что это смесь тестирования «белого ящика» и «чёрного ящика», но это в корне неверно. В данном случае тестировщик не работает с кодом программного продукта, но он знаком с внутренней структурой программы и взаимодействием между компонентами.

Проверка программного продукта по каждому из сценариев требует достаточно глубоких знаний. К примеру, об особенностях тестирования «чёрного ящика» в своей книге подробно рассказал Борис Бейзер. Это фундаментальная работа, с которой полезно ознакомиться каждому на старте работы в QA. Об этой и других полезных книгах мы рассказали в статье.

Жизненный цикл продукта и тестирование

Все чаще в наше время используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process (Рис. 1). При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код. Работа над тестами начинается с самого начального этапа выявления требований к будущему продукту и тесно интегрируется с текущими задачами. И это предъявляет новые требования к тестировщикам. Их роль не сводится просто к выявлению ошибок как можно полнее и как можно раньше. Они должны участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения. А в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не нужно ли изменить принципы и инструменты проведения тестов. В свою очередь, каждый обнаруженный дефект должен пройти через свой собственный жизненный цикл.

Рис. 1. Жизненный цикл продукта по RUP

Тестирование обычно проводится циклами, каждый из которых имеет конкретный список задач и целей. Цикл тестирования может совпадать с итерацией или соответствовать ее определенной части. Как правило, цикл тестирования проводится для конкретной сборки системы.

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

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

В первой фазе — Начало — основное внимание уделяется задачам анализа. В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений

В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рис. 2. Итерации жизненного цикла программного продукта

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

Мотивы появления тестера

Итак, типичные сегодня условия, в которые попадает начинающий: маленькая организация, которая берет заказы по разработке некоего ПО и состоит из директора и нескольких программистов, каждый из которых выполняет все возможные задачи — от общения с заказчиком до программирования, отладки, внедрения и технической поддержки. Из документации — только «политическое» ТЗ, чтобы формально удовлетворить требования заказчика, и договор.

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

Первый — действительно «тыкать кнопки». Естественно, при работе таким способом ошибки у тестировщика быстро заканчиваются, а у пользователей — остаются, что приводит всех к обвинению его в непрофессионализме (а чего вы хотели от «тыкающей кнопки девочки»???).

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

  На этом этапе главное понять основные цели тестирования.

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

Почему ручное тестирование не вымерло?

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

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

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

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

________________________________

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

________________________________

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

Списки требований и регистрация ошибок

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

Собственно про начальную структуру документов все, однако эти документы не самодостаточны, они только описывают, что нужно проверять, а во время проверки обнаруживаются ошибки, которые нужно обрабатывать и отслеживать.

И вот на этом этапе наступает время для внедрения BTS.

  Bug Tracking System — системы регистрации и отслеживания жизненного цикла дефектов

Для начала это может быть даже Excel-файл с настроенными автофильтрами, но, в идеале, желательно сразу определиться с программным обеспечением, которое будет в дальнейшем использоваться для автоматизированного тестирования, отслеживания ошибок, управления требованиями, документирования и пр. Есть достаточное количество производителей, которые делают целые специализированные комплексы. Зная, в какой области IT работает организация, с какими СУБД и в каких средах разработки, можно подобрать соответствующий продукт. Например, если предполагается использовать Rational, то в качестве системы регистрации и отслеживания ошибок лучше установить Rational Clear Quest. Причем, на начальном этапе в качестве рабочей БД лучше выбирать Access в связи с легкостью преобразования данных из нее во что угодно при последующей смене управляющего ПО.

Как и всякая писанина, BTS сначала встречает неприятие у программистов, но уже практически через неделю они не могут работать без нее. Еще один дополнительный плюс данных систем — формализация общения между отделами и исключение недоразумений в вопросах ответственности. Плюс для менеджеров – способ объективно оценивать уровень квалификации и вклад в общее дело своих сотрудников.

7 QA-шных грехов, которые помогут или помешают тестировщику (стать тем, кем ты хочешь)

Привет, меня зовут Иван, я работаю руководителем горизонтали автоматизаторов в Skyeng. Занимаюсь менеджментом ресурсов автоматизаторов, внедряю процессы, которые упрощают работу ребят, пишу инструменты для команды (слак-бот, всякие интеграции с TMS и др.), менторю начинающих автоматизаторов и, иногда, пишу авто-тесты.

Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем 🙂

Популярные вопросы о тестах

Сколько онлайн тестов нужно разработать для урока?

На одной странице А4 в среднем рассматривают 2-3 ключевые идеи. На каждую ключевую идею нужно создавать, как минимум, по одному тесту. Например, если в уроке 15 страниц, то общее количество тестовых вопросов должно быть не менее 45.

В какой программе создавать онлайн тесты?

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

Сколько стоит создание профессиональных онлайн тестов на заказ?

Команда Unicraft разрабатывает тесты всех типов на заказ — на запоминание, понимание и применение полученных знаний. Соблюдает баланс теории и практики, выделяя ключевые аспекты и доводит сотрудников до максимального уровня усвоения информации. Стоимость одного теста — 250 р, блок из 100 тестов — 21500 р.

Как создать тест для урока?

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

Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать

Перевод

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

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

Спецификация, требования, SRS.

Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?

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

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

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

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

И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке

 

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

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

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

Виды тестирования

Unit-тестирование (модульное тестирование) — данный вид подразумевает тестирование отдельных модулей приложения. Для получения максимального результата тестирование проводится одновременно с разработкой модулей.

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

Тестирование БД — проверка работоспособности БД при нормальной работе приложения, в моменты перегрузок и многопользовательском режиме. 

Unit-тестирование

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

В выходную документацию данных тестов входят тестовые процедуры, входные данные, код, исполняющий тест, выходные данные. Далее представлен вид выходной документации. 

Функциональное тестирование

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

Данный вид тестирования не может быть полностью автоматизирован. Следовательно, он подразделяется на:

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

Цель: протестировать ввод, обработку и вывод данных;

Ручное тестирование (в остальных случаях).

Цель: тестируется правильность выполнения пользовательских требований.

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

  • продукт адекватно реагирует на все вводимые данные (выводятся ожидаемые результаты в ответ на правильно вводимые данные);
  • продукт адекватно реагирует на неправильно вводимые данные (появляются соответствующие сообщения об ошибках).

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

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

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

Tags:

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

View the discussion thread.

blog comments powered by DISQUS

Почему программное обеспечение нужно тестировать?

Цели тестирования программного обеспечения, независимо от того, кто совершает  тестирование или где это сделано, состоят в том, чтобы обеспечить необходимое качество программного обеспечения и снизить риск ошибок в программе — «багов». Баг — код программы, который приводит к искажению или вовсе несовпадению фактического результата и того, который мы ожидаем. Баги могут быть относительно малозначимыми  (типографическая ошибка на экране),  средней значимости (определенная комбинация нажатий клавиш приводит к ошибке в работе программы), или очень серьезными (процедура вычисления среднего арифметического числа из нескольких заданных  является дефектной). Тестирование и отладка ПО – совсем не одно и то же. Тестирование фокусируется на предотвращении багов и нахождении их в готовом коде. Отладка может быть логическим следствием тестирования. Цель отладки состоит в том, чтобы найти код, который привел к отказу программы и исправить его. Тестирование программного обеспечения может показать некоторые, но не все дефекты в коде программы. Оно также  демонстрирует, что функция программы и ее производительность могут быть корректными  или неправильными, или обнаружить логический отказ —  это означает, что программа делает то, что ей сказали сделать, но чье-то обоснование (разработчика или программиста) было в некотором роде дефектным.

Важность

Дымовое тестирование – проверка самой важной функциональности программного продукта.

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

Расширенное тестирование – проверка всей заявленной функциональности.

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

  • тестирование мобильных или десктопных приложений;
  • банкинг;
  • социальные сети;
  • игры;
  • и другое.

Надеемся, с этой статьёй вам будет проще ориентироваться в самом начале пути в тестировании программного обеспечения. А что ещё поможет на старте карьеры? Обучение на курсе QA Academy. Записывайтесь прямо сейчас!

SunRav Web Class — простая система опроса и тестирования

SunRav Web Class — сервис от компании SunRav Software для онлайн-аттестации сотрудников.

Описание SunRav WEB Class

  1. Пробная версия. Вы получите доступ к программе после регистрации на сайте.
  2. Возможности. Web Class — это площадка для хранения тестов и проверки знаний сотрудников. Встроенного конструктора нет. Тест придётся собирать в другой программе компании — tMaker.
  3. Формат платформы. Только коробочная версия.
  4. Уровень сложности интерфейса: 3 из 5.
  5. Брендирование. Можно сменить логотип.
  6. Виды тестов. В системе вы можете собрать задания двух : «верно — неверно», «поставь балл от 1 до 10». Программа tMaker поможет расширить этот список до семи: появятся вопросы с единственным и множественным выбором, соответствие, упорядоченный список и вопрос с открытой строкой, в которую нужно вписать вопрос.
  7. Особые возможности. Нет.
  8. Статистика. Есть четыре типа отчётов: матрица ответов, результаты пользователей, групповые отчёты и отчёты по темам. Формат отчётов — csv.
  9. Цена. Компания продаёт только бессрочные лицензии. Цена на устройство — 29 000 рублей. Корпоративная лицензия обойдётся в 95 000 рублей.

Обзор возможностей SunRav WEB Class

Кому подходит SunRav WEB Class

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

Клиенты SunRav Software

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

Что такое исследовательское тестирование

Ad-hoc тестированиеИсследовательское тестированиеСценарное тестированиеВ пользу сценарного тестирования:

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

В пользу исследовательского тестирования:

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

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

А что же другие тесты?

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

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

В развитием проекта вы обнаружите, что вас уже не устраивает только проверка «в целом всё работает». Со временем архитектура вашего нового приложения неизбежно «устаканится», крупных изменений будет всё меньше и меньше. В какой-то момент вы поймёте, что вы хотите навесить побольше проверок на какой-нибудь компонент (потому что он уже точно никуда из проекта не денется, и его интерфейс точно проработан), или даже на конкретный класс… А для особо важных участков кода и вовсе желательно проработать все возможные ветвления. Или же вам очень интересно, как поведёт себя программа при непосредственном обращении к API. Чувствуете, да? Вот и другие тесты снова в деле!

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

  1. В самом начале, когда проект активного развивается с нулевого состояния, необходимо писать только системные тесты. Тестов нужно написать столько, чтобы у вас была четкая уверенность, что «в целом моя программа работает нормально». Это будет отличный базис для дальнейшей работы.
  2. По мере развития проекта и «устаканивания» его архитектуры и основных компонентов можно добавлять интеграционные тесты. Если у проекта появилось чётко выраженное и стабильное API — нужно начинать писать API-тесты.
  3. Наконец, для особо важных изолированных участков кода, от правильной работы которых зависит очень многое, можно написать Unit-тесты.
  4. Помнить, что из любого правила есть исключения. При возникновении достаточно веских объективных причин — повышайте приоритет интеграционных и Unit-тестов. Не нужно откладывать разработку тестов более низкого уровня, если вы в них действительно нуждаетесь здесь и сейчас.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector