А/в-тестирование: зачем нужно и как помогает бизнесу

Тестирование и его результаты

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

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

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

Методика тестирования

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

1) Модульное тестирование

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

3) Системное тестирование

4) Приемочные испытания

Модульное тестирование

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

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

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

Системное тестирование

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

Приемочные испытания

Это последний тест, который проводится перед передачей программного обеспечения клиенту. Он проводится, чтобы гарантировать, что программное обеспечение, которое было разработано отвечает всем требованиям заказчика. Существует два типа приемо-сдаточных испытаний — то, которое осуществляется членами команды разработчиков, известно, как внутреннее приемочное тестирования (Альфа-тестирование), а другое, которое проводится заказчиком, известно, как внешнее приемочное тестирования.

Если тестирование проводится с помощью предполагаемых клиентов, оно называется приемочными испытаниями клиента. В случае если тестирование проводится конечным пользователем программного обеспечения, оно известно, как приемочное тестирование (бета-тестирование).

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

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

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

Формы используются для получения информации от пользователей и взаимодействия с ними.

Что нужно проверить в формах:

• Правильность работы валидации в каждом поле формы.
• Значения полей, используемые по умолчанию.
• Опции для создания форм, удаления, просмотра и редактирования форм (если такие имеются).

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

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

Тестирование файлов cookie

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

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

Проверьте HTML/CSS

Если вы оптимизируете сайт для поисковых систем, то валидация HTML/CSS особенно важна. Первым делом проверьте сайт на наличие синтаксических ошибок в HTML-коде. Проверьте, доступен ли сайт для различных поисковых систем.

Тестирование базы данных

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

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

При тестировании функциональности сайтов нужно проверить:

Тестирование серых ящиков

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

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

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

Другие классификации видов тестирования

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

Под системным тестированием подразумевается тестирование на уровне пользовательского интерфейса.

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

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

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

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

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

Само по себе приложение тоже может являться частью какой-то более крупной информационной системы.

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

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

То есть у нас система состоит из каких-то модулей. Модули в свою очередь состоят из других более мелких модулей. Эти мелкие модули состоят еще из более мелких, и так далее.

 И так, получаем в результате:

Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.

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

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

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

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

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

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

Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.

Тестирование производительности

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

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

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

Правила составления тестов

Когда студент проходит тестирование, он остается один на один с заданиями. Если ему что-то непонятно — спросить не у кого. Приходится отвечать наугад, а это снижает объективность результата. Ниже мы подготовили правила составления тестов, следуя которым вы сможете существенно повысить качество своих тестов.

Как составлять вопросы для теста

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

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

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

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

Сократите отрицанияИзбегайте использования негативных суждений в формулировке задания. При использовании отрицания четко обозначьте его — например, выделите строчными буквами «НЕ», «НЕТ», «НАИМЕНЬШЕЕ», «КРОМЕ».

Как составлять ответы для теста

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

Внешний видПравильные и неправильные ответы должны быть однозначны по содержанию и структуре. Желательно, чтобы все ответы были краткими и одинаковыми по своей длине. Старайтесь максимум текста выносить в тело вопроса. Длинный вопрос и короткие ответы предпочтительнее, чем короткий вопрос и развернутые ответы.

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

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

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

Случайный порядокПравильные ответы должны располагаться среди всех предлагаемых ответов в случайном порядке.

Количество ответовРекомендуемое количество вариантов ответа для теста с одиночным выбором — 4, для теста с множественным выбором 5-6.

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

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

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

Когда составлены вопросы и ответы, нужно поместить их в уроки электронного курса.

Словарь тестировщика

Термины идут не по алфавиту, а по смыслу. Сначала база, а потом, те, что на неё опираются.

Объективное доказательство

(Objective Evidence)

Объективные доказательства описывают то, что наблюдал тестировщик, что на самом деле произошло или не произошло.

Объективные доказательства должны содержать достаточные данные, чтобы рецензент мог доказать их
соответствие критериям приёмки (Acceptance Criteria) теста.

Сравнение объективных доказательств с критериями приёмки приводит к прохождению или провалу теста.

Следует иметь в виду, что такие утверждения, как Пройдено (Passed), Провал (Failed) и как ожидалось (As Expected), никогда не
рассматриваются как объективное свидетельство выполненного теста.

Верификация дизайна

(Design Verification)

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

Проверочные мероприятия проводятся на нескольких этапах и уровнях проектирования устройства.

Деятельность по проверке может включать испытания, инспекции/обзоры и анализы.

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

Валидация дизайна

(Design Validation)

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

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

Видите, какие скучные и не до конца внятные определения даны выше?

Если во время собеседования вас начнут грузить подобной информацией — скорее всего
работа будет не очень интересной.

Выбор фич для следущего релиза, подробности

здесь

Фото: freepik.com

Результат теста

Должен включать в себя:

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

Идентификационный номер тест кейса, который был проведён. Это особенно актуально для больших компаний с обширными библиотеками тестов.

Дату проведения теста.

Описание тестового окружения, использованного во время тестирования. Например, тип компьютера.

Заключение об Успехе/Провале теста. Так называемое Pass/Fail statement

Объективное доказательство (Objective Evidence)

Список найденных дефектов в случае провала теста.

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

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

Системное тестирование важно по следующим причинам:

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

Типы онлайн тестов

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

Обучающие тесты

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

Такие тесты помогают подсветить ключевые идеи урока и сосредоточить на них внимание студента. Обучающие тесты, как правило небольшие, 1-2 вопроса на 7-10 минут обучения

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

Аттестационные тесты

Цель аттестационного теста — иная, проверить и оценить полученные студентом знания. Такие тестирования обычно проводят в конце курса и называют Аттестацией или проверкой знаний. Поскольку аттестационный тест проверяет внушительный объем знаний, он содержит большое количество вопросов. Как правило, не меньше 15-20 . Результат прохождения такого теста показывает, чему фактически научились студенты в процессе обучения. Такие тесты могут сопровождаться блокировкой доступа к теории и ограничением времени на прохождение.

Главная деятельность тестировщиков

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

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

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь»:

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

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

И та, и другая разновидности обратной связи равноценно важны.

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

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

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

Что такое процесс обеспечения качества (QA) и чем он отличается от контроля качества (QC)?

Процесс обеспечение качества при разработке программного обеспечения или QA (quality assurance) — это процесс, который предотвращает появление ошибок в конечном продукте и гарантирует, что компания выпустит по-настоящему качественное приложение. Процесс QA — это больше, чем просто контроль качества и тестирование. В то время как контроль качества (QC) сосредоточен на проверке конечного продукта, QA является частью всех этапов и стадий разработки программного обеспечения. Другими словами, QA — это комплекс мероприятий, направленных на предотвращение дефектов и ошибок, а QC — на их выявление. Правильно настроенный процесс QA гарантирует, что все члены команды будут работать эффективно, время, необходимое для разработки, сократится, а затраты снизятся.

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

Технология составления теста

На первый взгляд может показаться, что разработать тест достаточно просто — придумал вопрос, набросал варианты ответов и готово. На практике же многие испытывают сложности с разработкой. Чтобы быстро составить эффективный тест, мы рекомендуем следующие этапы разработки теста: выбрать правильный ответ, поставить к нему вопрос, подобрать неправильные ответы (или дистракторы). Разберем это подробней.

Правильный ответ

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

Смысловая единица — это то самое важное, что студент должен вынести из пройденного урока. Главное ключевое данное урока

Тесты мы всегда делаем на смысловые единицы. По-хорошему на каждую смысловую единицу нужно делать минимум по 3 теста.

Постановка вопроса

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

Дистракторы

Или раздражители. Так называют неправильные варианты ответов в тесте. Как составить дистракторы? Чтобы придумать неверные варианты ответов, попробуйте сначала сделать простое противопоставление правильному ответу. Затем можно поменять одну деталь формулировки из нескольких и сделать погранично верный ответ. И так далее. На разработку дистракторов можно привлечь самих студентов, оставив ответ незаполненным и попросив их закончить фразу.

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

Функциональное тестирование – наиболее распространенная форма тестирования. Когда люди относятся к тестированию программного обеспечения без каких-либо подробностей, они часто имеют в виду функциональное тестирование. Функциональное тестирование позволит проверить основные функции программного обеспечения, как ожидается. План тестирования может быть написан для описания всех функциональных тестовых случаев, которые будут тестироваться, что соответствует основным функциям и возможностям программного обеспечения. Первичным тестированием функциональности будет тестирование « счастливого пути», которое не пытается сломать программное обеспечение или использовать его в любых сложных сценариях. Это должен быть абсолютный минимум тестирования для любого программного проекта.

Приемочное тестирование

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

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

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

Как задавать вопросы

Приведу конкретный пример, чтобы вы знали к чему быть готовым.

Вы ищете тест, который проверяте правильное ли значение у величины
floating_value

Зашли вы, например на

или
gitlab
и ищете в директории tests по слову floating_value
ничего не находите и решате сократить слово до float
мало ли переменная называется по-другому.

Ничего не находите и пишете разработчику или QA-лиду

Первый вариант

Так и так мол искал в тестах https://company.gitlab.com тест на
floating_value. По ключевому слову float
вообще ничего нет.

Получаете ответ

Ключевое слово float это плохой выбор — ищи по floating_value

Второй вариант

Так и так мол искал в тестах https://company.gitlab.com тест на
floating_value. По ключевому слову floating_value
вообще ничего нет.

Получаете ответ

Попробуй поискать пошире, например float

Как нужно было писать

Так и так мол искал в тестах https://company.gitlab.com тест на
floating_value. По ключевым словам floating_value
и даже float
вообще ничего нет.

Вывод: Не оставляйте адресату лишнего пространства для манёвра

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

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

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

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

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

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

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

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

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

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

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

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

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

Подумайте о стресс-тестах, как о космическом шаттле или самолете. Что значит поместить ваше программное обеспечение или систему в режим «СТРЕСС»? Стресс – это не что иное, как интенсивная нагрузка определенного типа, которая, скорее всего, сломает вашу систему. Это может быть похоже на «нагрузочное тестирование» в том смысле, что ваша система подвергается высокому параллелизму, когда к системе обращается множество пользователей. Но напряжение системы может происходить и на других векторах. Например, запуск микропрограммы на аппаратном компоненте, когда аппаратное обеспечение имеет физический износ и работает в ухудшенном режиме. Стресс является уникальным для всех типов программного обеспечения, и при разработке систем и при разработке стресс-тестов следует учитывать, какие естественные или неестественные причины с наибольшей вероятностью могут вызвать нагрузку на ваше программное обеспечение или систему.

Одновременный запуск тестов

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

При этом данной фишкой пользуется достаточно мало тестировщиков: всего 30% респондентов запускает более 10 тестов за раз.

Количество запускаемых одновременно тестов (2019 обведён красным)

Очередная закономерность: практически все, кто не запускает тесты параллельно, тесты не автоматизируют.

Параллельным тестированием пользуются практически все, кто использует в работе скрипты или другие способы тестирования UI, — в отличие от тех, кто выбрал «Запись и повтор» в качестве основного способа тестирования UI.

Синонимы термина «тестирование»

С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества).

 «Контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта.

Итак,

тестирование — это

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

Отсюда и далее будем считать это рабочим определением «тестирования».

Общая схема тестирования примерно следующая:

1. Тестировщик на входе получает программу и/или требования.
2. Он с ними что-то делает, наблюдает за работой программы в определенных, искуственно созданных им ситуациях.
3. На выходе он получает информацию о соответствиях и несоответствиях.
4. Далее эта информация используется для того, чтобы улучшить уже существующую программу. Либо для того, чтобы изменить требования к еще только разрабатываемой программе.

Это весьма близко к определению, данному в SWEBOK, хотя есть несколько отличий. Например, в нашем определении нет слова «тест».

Определение тестирования по SWEBOK

звучит следующим образом:

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

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