Любой сайт или приложение нуждаются в тестировании. Сделать это можно вручную или с помощью автотестов. А что лучше для бизнеса? Зависит от ситуации. Меня зовут Ксения, я тимлид команды тестировщиков в Fojin.
Расскажу о разных вариантах с примерами из нашей ежедневной практики.
498 просмотров
Кратко: что такое ручное и автоматизированное тестирование?
Из названий понятно, что автотестирование основано на работе специализированного ПО при минимальном вмешательстве человека, а мануальное (ручное) целиком полагается на QA-специалиста для написания и выполнения тестов.
Тестировщик цифровых продуктов / QA-инженер использует в работе много узконаправленных инструментов. Необходимость в этом не зависит от специализации. Например, у «ручников» может быть Postman, а у автотестировщиков – Selenium.
QA-специалист, особенно мануальный, не может обойтись и без «общеайтишных» сервисов. К примеру, мы в Fojin обычно используем Confluence для создания единой базы знаний и ClickUp для управления задачами по тестированию.
ИНСТРУМЕНТЫ ДЛЯ ТЕСТИРОВЩИКА? Чем и как я тестирую? Показую все на примере!
Confluence: тестировщик расписал план и уже выполнил все тесты. А рядом можно найти ссылки на всевозможную документацию по проекту – очень удобно.
Какие проблемы решает тестирование цифрового продукта:
- Ошибки в UX, которые усложняют навигацию по сайту или приложению;
- Некорректное отображение элементов интерфейса при работе с разных устройств (ноутбук, смартфон и т.д.);
- Баги, из-за которых продукт работает не так, как ожидалось;
- Проблемы с производительностью, из-за которых продукт «тормозит» или не выполняет требуемое действие;
- Неуспешная интеграция со сторонним сервисом (например, не работает оплата онлайн на сайте)
- Проблемы с безопасностью данных, и многое другое.
Так какой же тип тестирования лучше для продукта?
На первый взгляд, специализированное ПО справится быстрее человека и точно не допустит ошибок в процессе. (Спойлер: это не всегда так.) А с другой стороны, ничто не сравнится с работой профессионала, без которого в любом случае не обойтись: даже автоматизированное тестирование предполагает, что нужно сначала написать тесты.
На самом деле однозначного ответа на вопрос нет, потому что необходимо прежде всего изучить конкретный проект и его особенности.
Чтобы проиллюстрировать эту мысль, далее приведем несколько примеров из практики QA-специалистов компании Fojin.
Когда лучше выбрать автоматизированное тестирование?
Приложение большое, и тестировать его вручную – долго и дорого для бизнеса. Автотестирование чаще всего используется именно на сложных и крупных проектах.
Кейс из нашей практики
Проект по созданию платформы-агрегатора, где мы настроили полноценные процессы тестирования и написали документацию с нуля. Явно не хватало автоматизированного тестирования, и мы предложили клиенту внедрить эту практику. Были проведены smoke-тесты и регрессионные тесты. Автоматизация позволила ускорить ряд процессов и на треть приблизить большой E2E-тест к завершению. В итоге удалось ускорить прогресс всей команды, улучшить качество продукта и приблизить дату релиза.
Тестирование НА ПРИМЕРЕ | Тестирую DEVBY
Приложение сложное, и функционал регулярно обновляется. В этом случае требуется регулярно проводить регрессионное тестирование – чтобы обнаружить баги, которые возникли в уже протестированном коде после обновлений.
Кейс из нашей практики
Приложение для аренды и продажи строительных инструментов имело очень много различных функций, пользовательских путей и сценариев. Автотесты помогали в каждом спринте находить баги и поддерживать в актуальном состоянии информацию о стабильности системы.
Автотесты найдут проблемы, которые может не заметить ручной тестировщик.
Необходимо оценить, как система справляется с высокой нагрузкой. Для этого моделируется большое количество пользователей/продуктов, и затем проводится нагрузочное тестирование.
Кейс из нашей практики
Та же платформа-агрегатор, где все процессы тестирования были выстроены нами с нуля. Мы предложили заказчику и успешно внедрили автоматизацию. В первую очередь это помогло с нагрузочным тестированием, т.к. появилась возможность совершать все рутинные действия за пару секунд через API. Это ускорило процесс и освободило время для сложных задач.
Проект большой, и планируется развивать его несколько лет. Целесообразно уменьшать ручной труд тестировщиков программного обеспечения и постепенно внедрять автоматизацию. Тестовые сценарии пишутся один раз, а затем используются повторно.
Кейс из нашей практики
Проект по тестированию банковского приложения длится уже более 3 лет, поскольку продукт имеет сложную логику, а также постоянно обновляется и эволюционирует. Частые релизы неизбежно сопровождаются проблемами и багами (например, в результате поломки интеграций). Всё это нужно выявить и устранить как можно оперативнее, иначе клиента ожидают большие потери – в том числе денежные. Поэтому автоматизированное тестирование тут незаменимо: с его помощью время на проверку всей системы сокращается в десятки раз.
Тестирование API с помощью инструмента Postman
Когда стоит использовать ручное тестирование?
Нужно полностью протестировать пользовательский интерфейс: оценить удобство и общее впечатление. Адекватно справиться с такой задачей может только человек. Отчет опытного мануального тестировщика можно использовать как обратную связь от потенциального пользователя.
Кейс из нашей практики
Установщик ПО проектировался с нуля командой аналитиков, дизайнеров и мануальных тестировщиков. Продукт предназначался для внутренних процессов, и вначале было неясно, как именно он должен функционировать, чтобы решать определенные задачи. При создании подробного флоу мы выявили несколько неудобных и непонятных пользователю UX-кейсов.
Заметить все «узкие места» и неочевидные моменты способен только опытный специалист по мануальному тестированию. Во время и после реализации мы дополнительно провели юзабилити-тестирование. Получилось приложение с довольно сложным функционалом, но пользователь не испытывает трудностей благодаря понятному и удобному интерфейсу.
Автоматизированное тестирование по какой-либо причине невозможно или просто нецелесообразно. На начальных этапах разработки происходят частые изменения, тестирование которых вручную – намного удобнее и быстрее для команды, а также дешевле для заказчика.
Кейс из нашей практики
В процессе разработки приложения для E-commerce долгое время не было стабильно работающей сборки, что не позволяло начать проектирование и разработку автотестов. Также была проблема с развертыванием тестового стенда, на котором могли бы прогоняться автотесты. Поэтому мануальный QA-специалист успешно тестировал все сборки на локальном устройстве и находил все баги, даже в очень сырой версии продукта.
В ручном тестировании важен опыт и доля творчества. «Ручник» полностью контролирует качество продукта на всех стадиях разработки и сопровождения.
Пользователи сайта или приложения столкнулись с технической проблемой и сообщили в службу поддержки. Используя информацию о проблеме, тестировщики смогут воспроизвести ее и подробно описать для разработчиков, а те уже найдут оптимальное и быстрое решение.
Кейс из нашей практики
Посетители интернет-магазина регулярно жаловались на техническую проблему в процессе оформления заказа. Мы провели серию тестов (запросы к базе данных, совместимость расширений и т.д.) и смогли воспроизвести проблему с оформлением заказа и ошибкой тайм-аута. Затем наши разработчики успешно всё пофиксили. Жалобы от пользователей перестали поступать.
Воспроизвести проблему пользователей – задача как раз для специалиста по ручному тестированию.
Важно проверить работу приложения на разных видах устройств и операционных систем. Ручное тестирование можно успешно проводить даже на таких устройствах, для которых не предусмотрены автотесты: фитнес-браслеты, датчики движения и т.п.
Кейс из нашей практики
Для сервиса потокового аудио была разработана веб-версия и мобильная версия под Android и iOS. Необходимо было проверить корректность работы с аппаратными средствами. Для полноценного ручного тестирования приходилось настраивать эмуляторы под множество версий операционных систем и моделей устройств. Использование эмулятора помогло избежать проблемы маленького парка устройств для тестирования и позволило всё покрыть тестами.
Проект небольшой и отличается простым функционалом либо имеет ограниченный бюджет. Там, где не подразумевается сложная логика оплаты, расчетов, вычислений и алгоритмов, не всегда рационально использование автотестов.
Кейс из нашей практики
Для небольшого фермерского приложения, с маленьким бюджетом и небольшой командой разработки, идеально подошла роль мануального тестировщика. Два специалиста по ручному тестированию отлично справились с работой и вывели продукт в релиз.
Мануальный инженер-тестировщик всегда в гуще событий на небольшом проекте, знает все актуальные доработки функционала, сроки релиза и другие детали, а значит, может быстрее реагировать на изменения.
А когда лучший подход – совмещать оба вида тестирования?
Требуется дополнительная ручная проверка для обнаружения ошибок, существование которых нельзя предугадать. Это дает QA-специалисту возможность задаваться вопросом: «А если пользователь сделает вот так, что будет?» и отклоняться от тестового сценария при необходимости.
Кейс из нашей практики
Упомянутое выше банковское приложение – хороший пример тестирования программного обеспечения, когда невозможно обойтись только одним видом специалистов. Мануальные тестировщики на этом проекте создают тестовые сценарии, проверяют новый функционал и решают задачи, которые невозможно автоматизировать. Автотесты ежедневно мониторят состояние сервисов и компонентов фронтенда, а перед каждым релизом помогают покрыть тестами большее число тест-кейсов, и значит, повысить скорость и качество проверки.
Успешное тестирование основано на повторениях и вариациях. С первым отлично справятся автотесты, а второе обеспечит программный тестировщик.
Ежедневные прогоны автотестов позволяют быстро выявить непредвиденные баги системы. Мануальный тестировщик программного обеспечения может обнаружить баги аналитики, найти несостыковки в макетах дизайна и неудобные UX для пользователя, а также предложить продуктовые улучшения.
Если на проекте есть ресурсы для работы ручного и автоматизированного тестировщика – это идеальный вариант. Специалисты будут дополнять друг друга, решать нетривиальные вопросы, помогать в решении любых задач по тестированию. В общем, работа будет максимально эффективной, а количество багов на проде станет минимальным.
Источник: vc.ru
Делаем простые автотесты на Python
Продолжаем погружаться в работу тестировщика, он же — QA, quality assurance engineer. Его задача — проверить код на наличие ошибок и работу программы в разных условиях.
Программирование на C, C# и Java
Уроки программирования, алгоритмы, статьи, исходники, примеры программ и полезные советы
Модульное тестирование в Visual Studio
Модульное тестирование (или Unit-тестирование) предназначено для проверки правильности выполнения небольшого блока кода, решающего свою конкретную задачу. В статье рассказывается, как проводить в модульное тестирование в Visual Studio. Разработка ведётся на языке C#.
Создание проекта программы, модули которой будут тестироваться
Разработаем проект содержащий класс, который вычисляет площадь прямоугольника по длине двух его сторон.
Создадим в Visual Studio новый проект Visual C# -> Библиотека классов. Назовём его MathTaskClassLibrary.
Class1 переименуем в Geometry.
В классе реализуем метод, вычисляющий площадь прямоугольника. Для демонстрации остановимся на работе с целыми числами. Код программы приведён ниже.
using System ;
using System . Collections . Generic ;
using System . Linq ;
using System . Text ;
using System . Threading . Tasks ;
namespace MathTaskClassLibrary
public class Geometry
public int RectangleArea ( int a , int b )
return a * b ;
Площадь прямоугольника, как известно, это произведение двух его сторон.
Создание проекта для модульного тестирования в Visual Studio
Чтобы выполнить unit-тестирование, необходимо в рамках того же самого решения создать ещё один проект соответствующего типа.
Правой кнопкой щёлкните по решению, выберите «Добавить» и затем «Создать проект…».
В открывшемся окне в группе Visual C# щёлкните «Тест», а затем выберите «Проект модульного теста». Введите имя проекта MathTaskClassLibraryTests и нажмите «ОК». Таким образом проект будет создан.
Перед Вами появится следующий код:
using System ;
using Microsoft . VisualStudio . TestTools . UnitTesting ;
namespace MathTaskClassLibraryTests
public class UnitTest1
[ TestMethod ]
public void TestMethod1 ( )
Директива [TestMethod] обозначает, что далее идёт метод, содержащий модульный (unit) тест. А [TestClass] в свою очередь говорит о том, что далее идёт класс, содержащий методы, в которых присутствуют unit-тесты.
В соответствии с принятыми соглашениями переименуем класс UnitTest1 в GeometryTests.
Затем в References проекта необходимо добавить ссылку на проект, код которого будем тестировать. Правой кнопкой щёлкаем на References, а затем выбираем «Добавить ссылку…».
В появившемся окне раскрываем группу «Решение», выбираем «Проекты» и ставим галочку напротив проекта MathTaskClassLibrary. Затем жмём «ОК».
Также в коде необходимо подключить с помощью директивы using следующее пространство имён:
using MathTaskClassLibrary ;
Займёмся написание теста. Проверим правильно ли вычисляет программа площадь прямоугольника со сторонами 3 и 5. Ожидаемый результат (правильное решение) в данном случае это число 15.
Переименуем метод TestMethod1() в RectangleArea_3and5_15returned(). Новое название метода поясняет, что будет проверяться (RectangleArea — площадь прямоугольника) для каких значений (3 и 5) и что ожидается в качестве правильного результата (15 returned).
Тестирующий метод обычно содержит три необходимых компонента:
- исходные данные: входные значения и ожидаемый результат;
- код, вычисляющий значение с помощью тестируемого метода;
- код, сравнивающий ожидаемый результат с полученным.
Соответственно тестирующий код будет таким:
using System ;
using Microsoft . VisualStudio . TestTools . UnitTesting ;
using MathTaskClassLibrary ;
namespace MathTaskClassLibraryTests
public class GeometryTests
[ TestMethod ]
public void RectangleArea_3and5_15returned ( )
// исходные данные
int expected = 15 ;
// получение значения с помощью тестируемого метода
Geometry g = new Geometry ( ) ;
int actual = g . RectangleArea ( a , b ) ;
// сравнение ожидаемого результата с полученным
Assert . AreEqual ( expected , actual ) ;
Для сравнения ожидаемого результата с полученным используется метод AreEqual класса Assert. Данный класс всегда используется при написании unit тестов в Visual Studio.
Теперь, чтобы просмотреть все тесты, доступные для выполнения, необходимо открыть окно «Обозреватель тестов». Для этого в меню Visual Studio щёлкните на кнопку «ТЕСТ», выберите «Окна», а затем нажмите на пункт «Обозреватель тестов».
В студии появится следующее окно:
В данный момент список тестов пуст, поскольку решение ещё ни разу не было собрано. Выполним сборку нажатием клавиш Ctrl + Shift + B. После её завершения в «Обозревателе тестов» появится наш тест.
Синяя табличка с восклицательным знаком означает, что указанный тест никогда не выполнялся. Выполним его.
Для этого нажмём правой кнопкой мыши на его имени и выберем «Выполнить выбранные тесты».
Зелёный кружок с галочкой означает, что модульный тест успешно пройден: ожидаемый и полученный результаты равны.
Изменим код метода RectangleArea, вычисляющего площадь прямоугольника, чтобы сымитировать провал теста и посмотреть, как поведёт себя Visual Studio. Прибавим к возвращаемому значению 10.
Как Вы видите, красный круг с крестиком показывает провал модульного теста, а ниже указано, что при проверке ожидалось значение 15, а по факту оно равно 25.
Таким образом мы рассмотрели на практике модульное тестирование программы на языке C# в Visual Studio.
Вы можете скачать исходник решения по ссылке ниже или перейти в репозиторий данного проекта на GitHub:
Тестирование программного обеспечения — рекомендации
Приведём правило, которым следует руководствоваться при написании и проведении тестов для оценки правильного функционирования программ.
Удобнее всего будет рассмотреть пример основанный на математике.
Так или иначе тестируемый метод или функция (или вся программа в целом) имеет свою область допустимых входных значений. Для проверки правильности работы метода достаточно провести тестирование метода на входных значениях начала и конца области допустимых значений (ОДЗ), одного значения из внутренней части области, а также -1 от левой и +1 от правой границы области.
Например, если ОЗД функции F — это отрезок [0; 100], то для проверки корректности работы функции достаточно протестировать следующие варианты: F(0), F(50) [не обязательно 50, можно взять любое число из внутренней части ОДЗ], F(100), F(-1), F(101).
Источник: vscode.ru