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

Подготовительная фаза тестирования сайта

Специалист–тестировщик на основании полученной документации, составляет тест-план (Test Plan).

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

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

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

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

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

Usability Testing

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

Тестирование безопасности

На этом этапе тестировщик занимается проверкой защиты всех закрытых страниц.
Performance Testing (Тестирование производительности)
Задача — определить скорость работы сайта при заданной нагрузке. Здесь применяют нагрузочное тестирование (Load Testing) и тестирование быстродействия.

Читать дальше →

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



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

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

Преимущества мутационного тестирования ПО:

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

Из недостатков отметим:

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

Итак, Mutation Testing — наиболее универсальный метод тестирования программного продукта.

Необходимость в тестировании мобильных приложений стремительно растет, но в этой сфере еще немало сложностей и вопросов. От стандартного тестирования ПО Testing Mobile Technologies отличается рядом определенных требований. Тестирование мобильных приложений подразумевает тестирование:

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

В чем специфика функционирования мобильных приложений?

Во-первых, мобильные сервисы должны правильно работать в любом месте, в любых условиях. Они должны поддерживать различные мультимедийные технологии, функции управления голосом, жестами, время их работы зависит от батареи, отличаются операционными системами, размером экрана. Наконец, функционируют в беспроводных сетях Wi-Fi, 2G, 3G, 4G, WiMax.

Что тестировать в мобильных приложениях?

• тестирование функциональности приложения (дается оценка сервисных функций, пользовательских интерфейсов),
• испытание QoS — выполняется проверка нагрузки на систему, производительности, пропускной способности,
• тестирование пользовательского интерфейса, позволяет опробовать мультимедийный контент, графику, функцию распознавания голоса, жестов,
• проверка способности системы работать в разных условиях, браузерах, беспроводной среде,
• тестирование безопасности (соблюдение конфиденциальности при идентификации пользователей, сохранность сведений),
• тестирование мобильности, подразумевает исследование функций географического положения клиента, его профиля и АРІ. К примеру, это информация о авиа-, ж/д рейсах, карты местности и т.д.
• тестирование совместимости (проверка соединения между пользователем и сервером, подключение к Интернет, работа в беспроводных сетях).

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

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

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



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

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

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

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

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

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



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

Какие модули и места следует подвергать автоматизации?

1. Участки кода, исполнение которых трудно визуализировать и получить осязаемую информацию о протекающих процессах (back-end процессы, занесение в базу данных, занесение логов в файл).
2. Функциональность продукта, которая будет использоваться наиболее часто и возникновение ошибок которой связано с достаточно высоким риском. Автоматизированное тестирование узловых моментов функциональности потребует меньше времени для поиска ошибок. И соответственно, сократит время на их устранение.
3. Типовые часто выполняемые операции, которые обычно связаны с обработкой данных. Например – формы, в которых количество заполняемых граф и полей довольно значительное. Цель – автоматизировать занесение требуемых данных в нужное поле и проверить правильность выполнения задачи после сохранения результата.
4. Сообщения об ошибках. Требуется автоматизация разнесения некорректных данных по соответствующим полям и тестирование корректности проверки правильности данных и сообщений об ошибках.
5. Комплексная проверка поведения всей системы, как целостного объекта (end-to-end testing).
6. Проверка числовых массивов, нужных для достоверных математических операций.
7. Тестирование корректности отображаемых результатов поиска в ответ на запрос по нужным данным.
8. Предложенный список только ориентировочный. Всё зависит от предъявляемых к проверяемой системе требований, возможностей, которые позволяет реализовать выбранный для автоматического тестирования инструмент.

Читать дальше →

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



Слабым местом стандартизации результатов тестирования является невозможность учета ошибок, обусловленных воздействием человеческого фактора, который в свою очередь проявляет себя на всех этапах процедуры. Главный стандарт в данной области – ISO 9126 («Стандарт для оценки качества ПО») Международной организации по стандартизации указывает, что тестирование должно осуществляться путем соблюдения следующим критериям: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability

Также, действует стандарт IEEE 829-1998 («Стандарт для тестовой документации тестирования программного обеспечения»), который определяет перечень необходимых документов для проведения тестирования, а именно: план и журнал его проведения, отчеты об общих и промежуточных результатах тестирования.

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

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



Существует два главных уровня конфигурационного тестирования: серверный и клиентский.

Серверный уровень тестирования конфигурации

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

Клиентский уровень тестирования конфигурации

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

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

Автоматизация тестирования

Тестирование программного продукта, в процессе которого главные этапы проверки осуществляются при помощи автоматических инструментов (запуск, инициация, проведение, обработка результатов и оформление выводов) в английском варианте выглядит как “functional automation testing”. По-русски – автоматизированное тестирование программного обеспечения.

Предпосылки для автоматизации

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

К неоспоримым достоинствам автоматического тестирования относятся:

• Цикличность – гарантия того, что созданные автотесты всегда будут соблюдать один алгоритм проверок, который не пропустит предусмотренного теста при одном из случаев применения.
• Быстрый результат – отпадает необходимость во времени, которое нужно человеку для сверки промежуточных итогов, подтверждения безошибочности при выполнении требований.
• Дешевизна – однократно созданный софт для тестирования требует меньше усилий для анализа полученных данных, в итоге, заменяя те же объёмы ручного тестирования без потерь в качестве.
• Простор в отчётности – готовые результаты легко обрабатывать, а сами отчёты нетрудно распространить по заинтересованным лицам.
• Свободные руки – человек-тестер, во время работы программы, может выполнять другую полезную деятельность, которая автоматизации не подвержена. Позволительно проводить тестирование в то время, когда нагрузка на числовые ресурсы снижена (в нерабочее время).

Минусы автоматического тестирования ПО

• Цикличность (да-да) – однообразные тесты не могут зацепить другие элементы, чем те, для которых они написаны. Человек же способен заметить мелкие нестыковки и на уровне тестирования сделать выводы о природе ошибки или внести исправления.
• Поддержка – хоть и затраты на ручное тестирование больше, автоматические тесты также нужно обновлять и доводить, чтоб функциональность проверок соответствовала уровню тестируемого приложения (с повышением сложности проверяемого ПО, возникает потребность в обновлении кода автотестов).
• Разработка – написание, а главное – отладка и тестирование автотестов требует много времени. Ведь, по сути, софт для тестирования программного обеспечения – не что иное, как то же самое программное обеспечение. Только функционал очень узкий.
• Стоимость – лицензионный экземпляр фрейворка для автоматизации может обойтись в приличную сумму. И хоть бесплатные варианты тоже, как правило широко используются, их функциональность часто оставляет желать много лучшего, а лицензия должна помочь при возникновении проблемы, описанной в п.2 данного списка.
• Мелкие ошибки – автотесты могут не замечать мелких дефектов, не наносящих вреда функциональности кода, но портящих визуальный интерфейс и затрудняющих работу конечного пользователя (сдвиг окон, грамматические ошибки…).

Читать дальше →

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



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

Написание тест кейсов на основе спецификации требований

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

Написание тест кейсов на основе функциональности программы

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

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

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

Юзабилити тестирование

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

Результат тестирования позволяет оценить степень комфортности приложения по нескольким критериям:

1. Продуктивность и результативность (efficiency) – характеризует время и количество последовательных действий, предпринимаемых пользователем для получения конечного результата.
2. Точность (accuracy) – обозначает количество ошибочных действий пользователя при использовании приложения.
3. Закрепление в памяти (recall) – показывает объём информации о работе с приложением, сохранившийся у пользователя в памяти, спустя много времени после последней работы с продуктом.
4. Эмоциональный отклик (emotional response) – даст оценку ощущениям пользователя, оставшимся после работы с софтом; вероятность рекомендации другим людям.

Usability Testing на разных уровнях тестирования

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

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

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

Как улучшить Юзабилити тестирование сайта?

Перво-наперво следует предусмотреть безупречно себя зарекомендовавшую систему защиты «от дурака». Англоязычные ресурсы называют её fail-safe или японским термином Poka-yoke. Общий принцип прост: предотвратить получение ложных вводных вследствие невнимательности либо безграмотности конечного пользователя. Подходом в этом случае может стать схема контроля над вводимыми данными (для примера – не допускать числовых значений в текстовом поле).

Учёт мнений пользователей готового продукта должен стать основой в совершенствовании приложения. Правильно интерпретируя отзывы, можно вывести комфорт пользования на несколько порядков выше первоначальных. Цепочка Plan-Do-Check-Act – планирование-действие-проверка-коррекция. Это так называемый цикл Деминга-Шухарта – алгоритм менеджмента по управлению процессом и решению поставленных задач.

Читать дальше →