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

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

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

  • Регрессионное тестирование. Повторное тестирование ПО после выявления ошибок на предыдущем этапе или после добавления новой функциональности.
  • Тестирование безопасности. Важнейший вид тестирования позволяет проверить программный продукт на уязвимость к различным атакам и попыткам несанкционированного доступа к информации.
  • Системное тестирование. Выявление дефектов и недочетов программного продукта в соответствии с требованиями спецификации.
  • Тестирование мобильных приложений. Проверка полной работоспособности, поиск ошибок и несоответствий данного ПО.
  • Тестирование установки. Установка и удаление программного продукта также требует тщательного тестирования.
  • Конфигурационное тестирование. Тестирование программного продукта на различных аппаратных и программных окружениях.
  • Интеграционное тестирование. Важнейший вид тестирования позволяет проверять взаимосвязь компонентов между собой, а также выявить недостатки взаимодействия между различными системами.
  • Smoke-тестирование. Это небольшие тесты, которые позволяют быстро и эффективно проверять основную функциональность системы.
  • Тестирование документации. Любая документация также требует тщательной проверки, так как она должна соответствовать заявленным стандартам.
  • Обеспечение тестового покрытия. Как бы не старались люди оптимизировать и автоматизировать тестовые процессы, все равно невозможно охватить весь функционал системы авто-тестами. Поэтому проводится оценка плотности покрытия системы тестами, чтобы выявить слабые места, требующие дополнительной ручной проверки.
  • Тестирование удобства использования. Определение эргономичности функционала, оценка удобства пользования ПО для конечного пользователя.

Любой долгосрочный проект без надлежащего покрытия тестами обречен рано или поздно быть переписанным с нуля

  • Без покрытия тестами. Обычно такие системы сопровождаются спагетти-кодом и уволившимися ведущими разработчиками. Никто в компании не знает, как именно все это работает. Да и что оно в конечном итоге должно делать, сотрудники представляют весьма отдаленно.
  • С тестами, которые никто не запускает и не поддерживает. Тесты в системе есть, но что они тестируют, и какой от них ожидается результат, неизвестно. Ситуация уже лучше. Присутствует какая-никакая архитектура, есть понимание, что такое слабая связанность. Можно отыскать некоторые документы. Скорее всего, в компании еще работает главный разработчик системы, который держит в голове особенности и хитросплетения кода.
  • С серьезным покрытием. Все тесты проходят. Если тесты в проекте действительно запускаются, то их много. Гораздо больше, чем в системах из предыдущей группы. И теперь каждый из них – атомарный: один тест проверяет только одну вещь. Тест является спецификацией метода класса, контрактом: какие входные параметры ожидает этот метод, и что остальные компоненты системы ждут от него на выходе. Таких систем гораздо меньше. В них присутствует актуальная спецификация. Текста немного: обычно пара страниц, с описанием основных фич, схем серверов и getting started guide’ом. В этом случае проект не зависит от людей. Разработчики могут приходить и уходить. Система надежно протестирована и сама рассказывает о себе путем тестов.

Дополнительные ссылки

Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.
Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.
Еще два неплохих источника информации: https://tproger.ru/digest/free-software-testing-books/ и https://automation-remarks.com/.
Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

View the discussion thread.

blog comments powered by DISQUS

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

Это продолжение текста про архитектуры интерпрайз-систем. Рассуждения это хорошо, но какой в них толк без практического применения. Я покажу свой фреймворк в деле.

Всё началось с того, что я рассказывал про проблематику проектирования приложений на .NET и ныл про нелёгкую жизнь в кровавом интерпрайзе. Затем я описал решение, которое сам придумал и реализовал — Reinforced.Tecture. То была теория, концептуальные рассуждения, визионёрство и снова нытьё. На этот раз о том, что на дворе 2020 год, а HKT в C# так и не завезли.

Сегодня я продемонстрирую свой подход в действии на примере простенького проекта и покажу профиты, которые он даёт: от сокращения количества кода до автоматизации тестирования и оригинального подхода к документации. Как советовал старина Торвальдс: «Болтовня ничего не стоит, покажите мне код».

Описание некоторых фреймворков

JSDOM является реализацией JavaScript-стандартов WHATWG DOM и HTML. Другими словами, JSDom имитирует среду браузера, не запуская ничего, кроме простого JS. В этой моделируемой среде браузера тесты могут выполняться очень быстро. Недостатком JSDom является то, что не все может быть смоделировано вне реального браузера (например, вы не можете сделать снимок экрана), поэтому его использование ограничивает доступность ваших тестов.

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

Phantom.js — реализует «headless» браузер Webkit, который находится между реальным браузером и JSDom в скорости и стабильности. Достаточно популярен.

Karma — позволяет запускать тесты в браузерах, включая настоящие браузеры, Phantom, JSdom и даже устаревшие браузеры. Karma размещает тестовый сервер со специальной веб-страницей для запуска тестов в среде страницы. Эта страница может быть запущена во многих браузерах. Это также означает, что тесты можно запускать удаленно с помощью таких служб, как BrowserStack.

Chai — самая популярная assertion библиотека.

Unexpected — это также assertion библиотека с немного отличающимся синтаксисом от Chai.

Sinon.js — это набор очень мощных тестовых шпионов, заглушек и макетов (mocks) для модульного тестирования.

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

Jasmine — представляет собой платформу тестирования, обеспечивающую все, что вам требуется для ваших тестов: работающая среда, структура, отчетность, assertion и mocks инструменты.

Mocha — в настоящее время является наиболее часто используемой библиотекой. В отличие от Jasmine, она используется со сторонними библиотеками mocks и assertions (обычно Enzyme и Chai). Это означает, что Mocha немного сложнее настроить, но она более гибкая и открыта для расширений.

Jest — это платформа тестирования, рекомендованная Facebook. Он использует функционал Jasmine и добавляет функции поверх него, поэтому все упоминания о Jasmine относится и к нему.

Ava — минималистическая библиотека, которая имеет возможность запускать тесты параллельно.

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

Protractor — это библиотека, которая использует Selenium, но добавляет улучшенный синтаксис и специально встроенные хуки для Angular.

Nightwatch — имеет собственную реализацию selenium WebDriver. И обеспечивает собственную среду тестирования, тестовый сервер, assertion и другие инструменты.

Сasper — написан поверх Phantom и Slimer (так же, как Phantom, но в Gecko FireFox), чтобы при помощи специальных утилиты более просто создавать Phantom и Slimer скрипты. Каспер предоставляет нам более быстрый, но менее стабильный способ запуска функциональных тестов в браузерах с интерфейсом UI.

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

Тест Сонди

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

Этот способ тестирования разработан психиатром Леопольдом Сонди в 1947 году. Врач заметил, что в клинике пациенты ближе общались с теми, у кого были такие же заболевания. Разумеется, интернет-тест не поставит вам диагноз — он просто поможет обнаружить некоторые склонности. Причём в зависимости от состояния психики результаты будут разными, так что проходить тест Сонди можно в любой непонятной ситуации.

Базовые требования к профессионалу

  • Опыт технической поддержки — это плотное изучение технологий в сжатые сроки, умение понимать проблемы и быстро сопоставлять их с причинами и путями решения + навыки документирования заявок. Отличная почва для старта карьеры тестировщика.
  • Основы программирования — желательно Java, SQL, Python, но сойдёт буквально всё.
  • Знание методологии Agile, умение встроиться в микро-команды. 
  • Основы Linux.
  • Основы архитектуры ПК.
  • Модель OSI и сети (базовое понимание, знание структуры заголовков пакетов и проч.). Практически сразу потребуется свободная работа с утилитой Wireshark.
  • Инструменты управления тестированием — Bugzilla, Jira или любой другой багтрекер.
  • Selenium — инструмент для автоматизации действий веб-браузера. Очень популярный инструмент тестирования. 
  • Желательно — понимание стратегий тестирований чёрного, белого, серого ящиков и осознание того, где вы наиболее хорошо применимы как специалист.
  1. Станьте QA-фрилансером, чтобы выполнять небольшие проекты по ручному тестированию. Платят мало, но вы научитесь мыслить как тестировщик, писать контрольные примеры и сообщать о результатах. 
  2. Если цель — тестирование веба (а это чаще всего), создайте свой кривой-косой, но полноценный сайт без шаблонов и готовых CMS. Так вы поймёте, как среда работает изнутри и будете знать места обитания всех типичных багов.
  3. Найдите программу любого курса по тестированию, ищите по ней материалы и накапливайте теоретическую базу, чтобы успешно пройти первое собеседование.

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

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

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

Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций.

Обычно, функциональное тестирование проводится на двух уровнях:

  • Компонентное (модульное) тестирование. Тестирование отдельных компонентов программного продукта, сфокусированное на их специфике, назначении и функциональных особенностях.
  • Интеграционное тестирование. Данный вид тестирования проводится после компонентного тестирования и направлен на выявление дефектов взаимодействия различных подсистем на уровне потоков управления и обмена данными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags:

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

View the discussion thread.

blog comments powered by DISQUS

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

Тестирование тестированию рознь.
Требования к начинающему ручному тестировщику не очень высоки. Пожалуй, это и есть та самая “легкая дорога в ИТ”. Здесь нужно знать базовые принципы тестирования, о которых мы поговорим чуть позже, и иметь упомянутую выше базу. Правда, от ручных тестировщиков постепенно уходят, чтобы проверять программные продукты быстрее и эффективнее. Поэтому так или иначе со временем все “ручники” начинают писать код или заниматься метриками и анализом. Но это не значит, что нельзя начать свою карьеру в статусе джуна-”ручника”.
Автоматизатор тестирования уже ближе к разработчику. В базе знаний у каждого автоматизатора обычно значится как минимум один язык программирования — тот, на котором ведется разработка автотестов (это не всегда основной язык разработки на проекте)

Занимаясь автоматизацией, также важно знать шаблоны проектирования и уметь применять общие принципы разработки — расширяемость, читаемость, легкость переиспользования. По сути автотест — это та же программа, которая должна соответствовать заранее заданному сценарию.
Чтобы начать работать автоматизатором, помимо знаний о тестировании в целом, необходимо иметь минимальные знания в объектно-ориентированном программировании, представлять, как написать простейший “Hello World!”.
Выбирая направление, вряд ли стоит смотреть на сиюминутную популярность специалистов на рынке труда

Средние показатели спроса и зарплат в ИТ — вещь очень специфическая, они зависят в том числе и от смежных знаний. Кто бы мог подумать, но специалисты по разработке на каком-нибудь Delphi сейчас в банковском секторе востребованы, несмотря на то, что в других отраслях язык не пользуется вообще никаким спросом. Здесь все работает по законам рынка: специалистов мало, а спрос на них остался, поскольку кому-то же надо поддерживать легаси.
Так и в тестировании. Сейчас есть спрос на JS-автоматизаторов. Он велик, потому что запросы у бизнеса большие, но еще не успели выучиться те люди, которые встали на данный путь с первым появлением интереса рынка. Как только они выучатся и пойдут работать, ситуация может измениться.
В этом изменчивом мире именно базовые знания — понимание, что и как тестировать в принципе, какие бывают подходы, — а также умение быстро усваивать информацию помогут быстро переориентироваться на смежный стек технологий.

Лучшие книги и средства обучения

▍Книги

  • Арбон Джейсон, Каролло Джефф, Уиттакер Джеймс «Как тестируют в Google» — познавательная книга, которую лучше читать уже с каким-то опытом, как минимум junior. А, впрочем, о чём я! Читайте и наслаждайтесь на любом уровне, очень полезно и неплохо написано.
  • Борис Бейзер «Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем» — классика литературы для тестировщиков. Это скорее академический учебник о тестировании, весьма толковый.
  • Гленфорд Майерс, Том Баджетт, Кори Сандлер «Искусство тестирования программ» — библия тестирования (на мой субъективный взгляд).
  • Роман Савин «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах» — реально добрая, немножко смешная и в то же время умная книга для начинающих и постарше. Мне бы она зашла как настольная книга тестировщика.

▍Онлайн-обучение

  • Бесплатный базовый курс Яндекс.Практикума (брать ли платный расширенный — решать вам по силам и потребностям) — хороший, толковый курс от практиков.
  • www.learnqa.ru — онлайн-школа тестирования (платная, нескольк методологий тестирования, разные уровни)
  • YouTube — сотни обучающих видео, есть толковые
  • QA Club Сообщество тестировщиков Тестирование ПО — общалка тестировщиков ВКонтакте (сообщество)

▍Полезные статьи на Хабре о самой профессии

  • Тестирование. Фундаментальная теория / Хабр
  • Тестировщик — больше, чем профессия / Хабр
  • Краудтестинг, или Где взять опыт для первой работы в тестировании

Интеграционное тестирование

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

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

Тестирование встроенного ПО и соблюдение стандартов в эру Agile

Соблюдение отраслевых стандартов – это не то, чем вы можете пренебречь или заняться позже; это неотъемлемая часть процесса разработки встроенного программного обеспечения (ПО). Для некоторых индустрий, — таких как авионика, автомобилестроение и здравоохранение, — строгое следование стандартам качества при разработке сложных и безотказных встроенных систем становится жизненно необходимым условием выпуска продукта на рынок. Традиционно, тестирование играет важную роль в разработке встраиваемых систем для регулируемых стандартами отраслей. Однако за последние годы устоявшиеся практики и процессы тестирования, их место и роль в подобных проектах значительно преобразились. Это резко изменило все правила игры, а когда правила игры меняются, необходимо меняться вместе с ними, чтобы выиграть.

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

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

Исследование, проведенное Ауригой при поддержке независимой исследовательской компании LTM Research, показывает, что эта эволюция роли тестирования в цикле разработки ПО имеет огромное значение. При постоянном дефиците времени производители по-прежнему не могут пожертвовать качеством, надежностью и безопасностью своего продукта. К примеру, широко обсуждаемые сегодня беспилотные автомобили являются источником повышенной опасности, а значит, требуют неукоснительного соблюдения стандартов. Нельзя обойтись и без тестирования встроенного ПО, поскольку практически все решения в области IoT и Connectivity основаны на встроенных технологиях.

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

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

Джун, миддл, сениор. А есть ли путь дальше?

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

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

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

Стоит ли проводить A/A тесты

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

По мнению Пипа Лайя, основателя агентства ConversionXL, тесты сами по себе трата времени.

Кому верить? С одной стороны, точность превыше всего, и метод A/A – способ ее обеспечить. С другой – трата ресурсов на тестирование, а также подготовку к нему.

Крейг Салливан, эксперт по пользовательскому опыту, считает, что 40 тестов в месяц – высокая нагрузка для сотрудников. Лучше убить полдня на QA, чем 2-4 недели на то, чтобы просто проверить работу инструмента.

Проблема №1. A/A тесты занимают время и трафик, которые вы можете потратить на изучение поведения посетителей сайта.

Проблема №2. И A/B, и A/A нужно тщательно организовывать и мониторить, чтобы не получить ложный результат. Как в примере от Copyhackers.

Потратить время или рискнуть надежностью ПО при принятии решения – решать вам.

Есть потенциально менее затратный вариант – A/A/B.

Уровни тестирования

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

Ссылки:

Интеграционное тестирование — это процесс исследования ПО, при котором тестируется интерфейсы между компонентами или подсистемами.

Ссылки:

Википедия. Интеграционное тестирование.

Системное тестирование — это процесс исследования ПО, при котором тестируется интегрированная система на её соответствие требованиям заказчика. Альфа и Бета тестирование относятся к подкатегориям системного тестирования.

Ссылки:

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

Привет, Хабровчане! Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.

Предисловие

Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.
На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.

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

Тестирование программного обеспечения может быть ручным (мануальным) и автоматизированным. По направлению тестирование делится на нагрузочное и инсталляционное. Также не забываем про тестирование безопасности и удобства пользователя.

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

Автоматизированное тестирование проводится с использованием программных средств. Тестировщик пишет отдельный код для проверки ПО.

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

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

Тестирование безопасности — этот вид проверки определяет, насколько ПО защищено от атак хакеров, а также выясняет, находятся ли данные пользователей в безопасности.

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

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

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

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

ТестированиеНапример, в базе QA Light ты найдёшь актуальную информацию про тестирование

Заключение

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

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