Тестирование веб приложений и сайтов — полное руководство

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

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

• Стимулы – это данные, которые подаются на вход программе.
• Реакции — это то, что получается на выходе.
• Оракул — это способ проверки наблюдаемого результата, совпадает он с некоторыми ожиданиями или не совпадает.

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

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

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

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

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

Тестирование переполнения памяти

При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программное обеспечение выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неопределенное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться обнаружить ошибки доступа к памяти в программном обеспечении, использующем такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus.. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или работает неправильно, и напрямую указывают на то место в коде, где есть ошибка. Классно, правда?

Ручное тестирование

Ручное (мануальное) тестирование — это тестирование без помощи каких-либо программ, автоматизирующих работу.

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

Напомню, что ручное тестирование строится на методах тестирования. Сюда относятся и техники тест-дизайна, и техники, основанные на опыте

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

Плюсы ручного тестирования:

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

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

Минусы ручного тестирования:

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

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

Как уже было указано выше, тестирование проводится в соответствии с программой и методикой испытаний, которая разрабатывается в соответствии с ГОСТ 34.603-92.

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

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

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

Если результат тестирования отрицательный, проводится устранение недостатков и повторное тестирование.

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

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

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

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

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

________________________________

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

________________________________

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

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

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

Тестирование программного обеспечения

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

Тестирование – это одна из техник регулировки качества программы. Его этапы:

• планирование работ;
• дизайн тестов;
• проведение тестирования;
• анализ результатов.

Процесс проверки качества (quality assurance) проводит специальный человек или группа людей, которых называют тестировщиками.

iSpring — платформа для онлайн-обучения и тестирования и сотрудников

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

Обзор возможностей iSpring

iSpring — интернет-сервис. Не нужно устанавливать его на свой сервер и привлекать IT-специалистов для настройки. Создаёте аккаунт и тестируете сотрудников.

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

Описание iSpring

1. Пробная версия. У iSpring есть бесплатная пробная версия на 14 дней. Чтобы её получить, заполните форму на сайте: имя, почта и номер телефона.
2. Возможности. В iSpring встроен мощный конструктор для создания опросов, психологических тестов и тестов на проверку знаний.
3. Виды тестов. В iSpring можно собирать опросы, психологические тесты и тесты на проверку знаний. В вашем распоряжении 14 типов заданий: на соответствие, выбор одного или нескольких вариантов ответа, выбор области, drag-and-drop, последовательность.
4. Особые опции. Вы можете изменить дизайн каждого вопроса и задать правила тесту: установить баллы и штрафы, автоматически перемешивать задания перед тестированием, указать количество попыток и ограничить время ответа на каждый вопрос, чтобы сотрудники не списывали.
5. Формат платформы. iSpring работает через интернет. Тестируйте и обучайте сотрудников онлайн сразу после регистрации.
6. Уровень сложности интерфейса: 1 из 5.
7. Брендирование. Вы можете оформить платформу под корпоративный стиль: добавить логотип, изменить цвета и URL-адрес.
8. Статистика. В iSpring доступно 15 типов отчетов. Платформа самостоятельно проверяет, какие варианты ответа выбирают ваши сотрудники по каждому заданию, в каких вопросах они допускают ошибки, какие результаты получают и сколько времени в целом тратят на тест. Всю информацию система собирает в отчёты, которые можно скачать в excel-формате.
9. Цена. Вы платите за количество пользователей. Цена за одного пользователя — 82 рубля в месяц. Минимальный пакет — 12 человек.

Кому подходит iSpring

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

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

Клиенты iSpring

Платформу используют как крупные корпорации, так и средний бизнес. Среди клиентов Johnson & Johnson, Redmond, «Яндекс», «Додо Пицца», «Альфа Капитал» и мясоперерабатывающий завод «Богородский»

QA ≠ QC: как их различить

QC: кто эти люди, какие у них задачи, какие у них ограничения

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

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

QA: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это. Какая у них задача? Задача QA-инженера  —  не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод. 
В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.

Пример реальной задачи по разработке

Предположим, перед вашей командой ставят задачу:

Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)

Первым делом разработчики прорабатывают дизайн системы.

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

Дизайн системы Contact Us

Далее, разработчики детализируют схему добавляя описание шагов:

Схема работы системы Contact Us

1. Клиент заполняет форму Contact Us и нажимает кнопку «Отправить»
2. Frontend проверяет введенные значения*
3. Frontend отправляет данные на Backend
4. Contact Us Controller проверяет данные и формирует запрос на отправку письма*
5. Contact Us Controller передает данные для отправки письма в Email Sender
6. Email Sender получает данные, проверяет их, формирует письмо и отправляет его**
7. Email Sender отвечает Contact Us Controller, что письмо отправлено
8. Contact Us Controller формирует ответ для Frontend
9. Backend отправляет данные об успешной отправке письма на Frontend
10. Frontend получает данные, понимает, что отправка была успешной и показывает клиенту сообщение

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

Как ты уже знаешь, процесс начинается с наименьших частей системы — модулей / компонентов.

Базовые термины

Баг (bug) ― это ошибка или дефект программного обеспечения. Он проявляется, когда фактическое поведение системы отличается от ожидаемого. Дефекты могут быть критическими и влиять на использование ПО или незначительными, когда их присутствие незаметно для пользователя.

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

Подробно об отличиях данных явлений мы рассказали в нашей статье.

Тестовое покрытие (test coverage) ― это совокупность тестов, которые проявляют работоспособность той или иной функциональности ПО. Чем больше проверок, тем шире тестовое покрытие, тем больше возможностей отследить поведение системы в различных условиях и выявить критические или незначительные дефекты.

Верификация (verification) ― оценка ПО или его компонентов с точки зрения соответствия всем заявленным к нему требованиям.

Валидация (validation) ― это проверка работоспособности функциональности приложения.

Релиз (release, RTM) ― выпуск программного продукта на рынок, например, размещение мобильного приложения в App Store или Google Play.

Артефакты ― это документы, которые используют в процессе тестирования. Подробнее о том, какими они бывают, расскажем далее.

Список вопросов, которые тебе зададут на собеседовании

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

Далее HR или техспециалист захочет проверить общие знания в тестировании. Ты можешь услышать вопросы: Что такое тестирование? В чём его цель? Что такое ошибка/баг? Тебе нужно ответить что-то вроде этого: «Тестирование — это не просто поиск ошибок. Это процесс, который выявляет насколько продукт соответствует предъявленным ему требованиям. Ошибка же — это не просто причина некорректной работы программы. Это несоответствие требованиям, которые предъявлены к продукту».

И, конечно, тебя проверят на полноту теоретических знаний. Подготовь ответы на вопросы: Какие виды/типы/классы/методы тестирования вы знаете? Чем они различаются? В чём суть процесса тестирования? Из каких этапов он состоит? Какие бывают виды и цели тестовой документации? Назовите техники тест-дизайна.

Чтобы разбираться в основных аспектах теории тестирования, обратись к книгам по профессии.

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

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

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

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

Тестирование масштабируемости

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

Граничное тестирование

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

If ( amt < 300 ) {
startWithdrawl ( )
}
else {
error ( «Вы можете снять % s», amt ) ;
}

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

Изучение спецификаций

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

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

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

Interfaces — спецификация интерфесов

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

API

и задача тестировщика здесь сводится к тому, чтобы

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

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

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

Цель

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

• Функциональное
• Нефункциональное

Функциональное тестирование направлено на проверку того, какие функции ПО реализованы, и того, насколько верно они реализованы.

Нефункциональное – проверка корректности работы нефункциональных требований. Оценивается, КАК программный продукт работает. Эта проверка включает в себя следующие виды:

Тестирование производительности – работа ПО под определённой нагрузкой.

• Тестирование пользовательского интерфейса – удобство пользователя при взаимодействии с разными параметрами интерфейса (кнопки, цвета, выравнивание и т. д.).
• Тестирование UX – правильность логики использования программного продукта.
• Тестирование защищенности – определение безопасности ПО: защищено ли оно от атак хакеров, несанкционированного доступа к данным и т. д.
• Инсталляционное тестирование – оценка вероятности возникновения проблем при установке, удалении, а также обновлении ПО.
• Тестирование совместимости – тестирование работы программного продукта в определённом окружении.
• Тестирование надежности – работа программы при длительной средней ожидаемой нагрузке.
• Тестирование локализации –оценка правильности версии программного продукта (языковой и культурный аспекты).