ИНЖЕНЕР ПО ТЕСТИРОВАНИЮ ПО

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

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

Следуя уже сложившейся традиции, предоставляем слово самому представителю профессии:

у нас в гостях Андрей Преткель, сотрудник компании EPAM Systems.

Андрей Преткель, 25 лет

• В 2005 году окончил Белорусский государственный университет информатики и радиоэлектроники (факультет компьютерных сетей и систем, специализация «Ð˜Ð½Ñ„орматика»).

• С 2004-го года-сотрудник отдела функционального тестирования компании EPAM Systems. Ведущий инженер по тестированию/ Lead Software Testing Engineer. Увлекается музыкой и литературой. Пишет стихи и музыку. Иногда выступает в клубах со своими песнями под псевдонимом «ÐÑ…ÐµÐ»ÑŒ».

Software Quality Assurance вообще и функциональное тестирование — в частности

О тестировании,  ÐºÐ°Ðº о неотъемлемой части процесса разработки программного обеспечения,  Ð²ÑÐµÑ€ÑŒÐµÐ· заговорили в конце 80-х годов. К тому моменту на рынке уже начали появляться сложные коммерческие приложения.

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

Развитие стандартов и методов управления проектами по созданию ПО привело к появлению такого направления, как обеспечение качества ПО-Software Quality Assurance, или просто QA.

Что же такое Software Quality Assurance? В первую очередь хотел бы отметить, что встречающееся в последнее время отождествление понятий «Quality Assurance» и «Ð¤ÑƒÐ½ÐºÑ†Ð¸Ð¾Ð½Ð°Ð»ÑŒÐ½Ð¾Ðµ тестирование» не совсем корректно. И вот почему: Quality Assurance представляет собой набор процессов и методов, используемых для обеспечения качества программных продуктов вообще, а функциональное тестирование-это один из инструментов, необходимых для достижения этой благородной цели.

Два главных тезиса тестирования

Тезис №1. Не бывает программ без ошибок.

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

Чтобы обосновать эти тезисы приведу пример. Пусть он будет глобальным, чтобы более наглядно продемонстрировать потенциальные негативные последствия ошибок в программном продукте, не обнаруженных на стадии тестирования. А что может быть более глобальным, чем главное детище компании Microsoft-операционная система Windows (да простят меня все поклонники Linux). Этим программным продуктом пользуются миллионы человек во всем мире. Таким образом, если в оригинальной копии этой операционной системы останется какой-либо незамеченный изъян (тезис №1), то он сохранится и в каждой ее копии.

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

Именно поэтому сотрудникам отдела тестирования придется снова работать совсем набором тестов, которые уже были проведены в предрелизной стадии разработки продукта. Замечу, что на работу с исправленной версией продукта будет потрачено драгоценное время, которое можно было использовать для тестирования новой версии. А временные затраты можно справедливо приравнять к денежным. Заплатку, так называемый «Ð¿Ð°Ñ‚Ñ‡», впоследствии нужно доставить всем пользователям системы. А это затраты производителя на серверы обновлений (доступные и обслуживаемые 24 часа в сутки), затраты на скачивание этих обновлений, время и трафик конечного пользователя.

Вывод очевиден: таких случаев лучше избегать, исправляя ошибки уже на стадии разработки ПО (тезис №2).

Так что же такое тестирование программного обеспечения? Понятия «Ñ‚естирование» и «Ð¸ÑÐ¿Ñ‹Ñ‚Ð°Ð½Ð¸Ðµ» синонимичны, а применительно к программе речь пойдет об испытании программного продукта в условиях, максимально приближенных к реальным. Проще говоря, это не что иное, как проверка на работоспособность ПО.

Разъясним для читателей несколько терминов, используемых в тестировании: системные тесты,  Ð¼ÐµÑ‚оды «Ð±ÐµÐ»Ð¾Ð³Ð¾ ящика» и «Ñ‡ÐµÑ€Ð½Ð¾Ð³Ð¾ ящика».

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

Тестирование методом «Ð±ÐµÐ»Ð¾Ð³Ð¾ ящика» представляет собой анализ исходного кода программного продукта и чаще всего сводится к исследованию логической структуры и соответствия заложенному алгоритму кода.

Тестирование методом «Ñ‡ÐµÑ€Ð½Ð¾Ð³Ð¾ ящика» подразумевает, что внутренняя структура программы неизвестна, известен лишь ее функционал. Т.е. приходится оперировать входными значениями и данными, а также анализировать полученные и ожидаемые результаты.

Иначе говоря, у нас есть Программа, которая должна выдавать определенный Результат (Данные) после выполнения определенного Действия (введения каких-то данных). Сравнивая полученный Результат с ожидаемым, мы можем судить о корректности работы «Ñ‡ÐµÑ€Ð½Ð¾Ð³Ð¾ ящика». В функциональном тестировании используется, как правило, метод «Ñ‡ÐµÑ€Ð½Ð¾Ð³Ð¾ ящика».

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

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

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

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

Недостаточно просто сообщить, что программа протестирована и «Ñ…Ð¾Ñ€Ð¾ÑˆÐ¾ работает», нужно привести факты: на основе каких тестов был сделан этот вывод, каков был критерий достаточности, какие функциональные требования были покрыты тестовыми сценариями, как и когда проводились тесты, какие методы проведения тестов использовались, какие инструменты были задействованы, какие конфигурации были покрыты тестами. Именно благодаря четкой формализации процесса обеспечения качества на каждый из приведенных вопросов ответ находится.

Вот уже  около 5 лет  Ñ работаю в компании EPAM Systems, в данный момент-в должности ведущего инженера по тестированию. В течение этого времени мне довелось работать над созданием разных проектов: крупных, когда в состав проектной команды входило больше сотни человек, и небольших, когда в команде было только 2 человека. В основном работать приходилось с web-ориентированными приложениями, что вполне закономерно, ввиду тенденций последнего десятилетия. Я постараюсь объективно описать процесс тестирования программных продуктов, как это происходит в компании EPAM Systems.

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

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

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

После составления тестового плана создаются тестовые сценарии, которые применяются к первым билдам программного продукта. Как правило, разрабатываются два основных тестовых сценария, так называемые smoke test и acceptance test.

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

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

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

После feature freeze тестирование проводится на основе приемочного тестового сценария.

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

Вопрос производительности программного продукта продумывается еще на стадии проектирования системы. Но практически сделать вывод о том, насколько продукт оптимизирован для многопользовательского режима работы, а также о том,  какие требования следует предъявлять к аппаратной части сервера, оставить можно лишь после проведения серии тестов на производительность, т.н. performance-тестирования. Тестирование производительности проводится на стадии, когда программный продукт, точнее его текущий билд, успешно проходит smoke test.

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

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

Однако бывают ситуации, когда очередной билд успешно проходит приемочный тест, при этом имеется некоторое количество известных и документально зафиксированных ошибок в приложении, а срок выпуска продукта уже подошел. В таких ситуациях решение о выпуске программного продукта может быть принято, однако все известные и вновь обнаруженные ошибки должны быть описаны в документации к продукту (список known issues). Как правило, допустимое количество и серьезность таких ошибок предварительно оговаривается в тест-плане, еще в самом начале процесса тестирования (здесь снова следует напомнить о тезисе №1).

После того,  ÐºÐ°Ðº все этапы разработки и тестирования успешно пройдены, составлена и протестирована вся коробочная документация (а это отдельная область тестирования, ведь никто другой, как тестеры, не знает настолько хорошо программный продукт), наступает долгожданный момент релиза.

Инструментарий тестировщика

Как уже было сказано, одна из главных целей тестирования-обнаружить и документально зафиксировать неверное поведение программного продукта и несоответствия требований к приложению. На профессиональном языке это называется «Ð±Ð°Ð³Ð¾Ð¼» (от англ. «Bug»). В процессе тестирования программного продукта может быть обнаружено несчетное количество таких багов.

Обычно для учета всех ошибок приложения используются специальные приложения-багтрэкинговые системы (bug tracking systems), без которых сложно себе представить разработку любого относительно большого приложения. Как правило, в них заносят все ошибки, обнаруженные в программном продукте, и не только их.

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

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

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

В конце 90-х годов на рынке широкую популярность приобрели продукты, предназначенные для автоматизации тестирования ПО. Высказывались даже мнения, что через несколько лет 90% работы тестировщиков будет выполняться посредством автоматизированных тестов. Однако на практике картина оказалась несколько иной: приложения для автоматизации проявили себя как хорошие помощники в процессе тестирования программного продукта, но не как заменители человеческого труда. Дело в том, что при достаточно большой функциональной сложности программных продуктов, довольно много времени уходит на то, чтобы автоматизировать хотя бы базовый smoke test. А что уж говорить о приемочном тесте.Как правило, работа по автоматизации тестов проводится параллельно с обычным, ручным тестированием.

На протяжении одного релиза автоматизированный smoke test может очень упростить процесс тестирования приложения на, скажем, разных платформах. А web-приложения, как правило, разрабатываются с акцентом на независимость от платформы. Но впоследствии, при разработке новой версии продукта, функционал приложения может измениться, а некоторые элементы могут быть усложнены, добавлены новые, либо удалены старые. В такой ситуации нельзя будет использовать даже самый грамотно продуманный и гибко реализованный автоматизированный smoke test. Поэтому решение об автоматизации тестовых сценариев принимается после тщательного взвешивания всех «Ð·Ð°» и «Ð¿Ñ€Ð¾Ñ‚Ð¸Ð²», а также после подсчета экономической выгоды, которую может повлечь за собой автоматизация.

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