Тестирование ПО: виды, подходы и 1С-проекты

В данном материале я сделал попытку подробнее остановиться на вопросе о месте и значении такого вида работ, как тестирование в рамках внедрения программного обеспечения, в частности, во вселенной 1С. Очень подробно на описании видов тестирования и спорах, какой из них лучше или сильнее, я останавливаться не буду. Целью данной заметки является попытка по-новому отнестись к самому понятию «тестирование» в нашей повседневной работе.

1. Альфа-тестирование
2. Бета-тестирование
3. Сценарное и исследовательское тестирование
4. Дымовое тестирование
5. Тестирование в мире 1С
6. Тестирование и комплексные проекты

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

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

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

Альфа-тестирование

Альфа-тестирование — это этап отладки и проверки альфа-версии программы, а люди, которые будут заниматься ее тестированием — альфа-тестерами. Это могут быть штатные тестировщики компании или люди, которые работают по договору, но это квалифицированные специалисты, умеющие работать со специализированным ПО и пользоваться специальными методиками.

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

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

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

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

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

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

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

Сценарное и исследовательское тестирование

Также существуют и другие классификации тестирования: сценарное (scripted) и исследовательское (exploratory).

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

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

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

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

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

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

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

Еще выделяют такой вид тестирования, как «дымовое».

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

Преимущества Smoke-тестирования:

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

Чем различаются Smoke, Sanity и регрессионное тестирование

Smoke проверяет рабочее состояние новой сборки. Sanity-тестирование проверяет изменения, которые были сделаны в текущей сборке. Регресс проводится для проверки всего функционала, который был затронут в ходе изменения в текущей сборке.

Дымовое тестирование можно выполнить на любой сборке. Sanity и Регресс выполняются только на стабильных сборках.

Smoke-тестирование может выполняться как разработчиками, так и тестировщиками. Sanity и Регресс выполняются только тестировщиками.

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

Как выполняется смоук-тестирование

Smoke-тестирование выполняется при каждой новой сборке. Для этого специалисты определяют минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов выделяют приоритетность и серьёзность кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical — как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей.

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

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

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

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

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

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

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

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

1. анализ и сбор требований к ПО;
2. проектирование и моделирование;
3. разработка технического решения;
4. подготовка в опытной эксплуатации ПО;
5. опытная эксплуатация.

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

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

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

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

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