Тестирование глазами молодого специалиста

Написал мой коллега:

Тестирование глазами молодого специалиста.

К процессу тестирования, зачастую, относятся довольно пренебрежительно, не видя необходимости прибегать к разработке отдельных программных средств нахождения ошибок. Максимум, что может своевременно найти ошибку – это проверка самим разработчиком измененного кода, ревью кода других разработчиков или специальный человек (или коллектив), который контролирует работоспособность конечного продукта. Так мне казалось, когда закончив ВУЗ, поступило предложение заняться тестированием. Казалось бы, что может быть проще, чем проверить работоспособность программы, когда в твоем распоряжении находится актуальное ТЗ, архив с уже созданными и, в большинстве своем, исправленными ошибками, огромное количество обсуждений, в которых можно найти ответ практически на любой вопрос. Но ожидания оказались не совсем верными. И дело даже не в не умении найти нужный материал, а в разнице между текущим поведением программы и неясностями (двояким толкованием, пробелами) в текущих требованиях. И самый надежны способ определить единственно верное поведение – обратиться к людям, это поведение реализовывающим. К разработчикам. Но, естественно, с течением времени, с ростом количества реализованных и назначенных задач знания об определенных объектах и методах их реализации подзабываются. Это человеческое естество и с ним ничего не сделать. И на первый план выходят выходят автоматические тесты – минипрограммы, в которых четко зафиксировано ТЕКУЩЕЕ поведении системы, особенности ее работы. И чем больше этих программ – тем лучше, т.к. они будут охватывать всю систему (в идеале). Любое отклонение от нормы будет зафиксировано и человек вынесет решение – новая ли это ошибка или требования изменились и нужно изменить тест (эталон). Эту систему невозможно обмануть, новую ошибку нельзя пропустить (при наличии работоспособного теста), как это мог бы сделать, например, не вовремя отвлекшийся человек, ищущий ошибку. Но сильно забегаю вперед, перенесемся в самое начало пути – к тестированию системы вручную.

Моя работа тестировщиком началась со знакомства с системой. И сразу же появились первые вопросы – “Почему это работает так?”, ”Верно ли это?”. Вообще говоря, именно первые недели наиболее благоприятны для поиска ошибок, т.к. новый человек может заметить то, что большинство уже и за ошибку не считают. Новый сотрудник обращает внимание на каждый клик, каждое новое открывающееся окно, к любому событию он относится с подозрением - “А верно ли это?”. Далее, ответ на спорное поведение ищется в описании прецедентов в требованиях. Конечно, всегда можно спросить у знающих людей, но самостоятельный поиск информации ведет к гораздо более глубокому пониманию системы. Со временем, эти знания накапливаются, и новую ошибку уже можно найти не только в результате выполнения тесткейсов, но и проанализировав текущие изменения в системе. Приходит понимание возможных причин появления ошибок. С другой стороны, ежедневный поиск ошибок по четко зафиксированным алгоритмам интересен и разнообразен лишь первые 2-3 прогона всех заданий. Далее, внимание притупляется, тесткейсы уже вызывают меньше вопросов, становится очень трудно проверять задания не механически. Выходом стало тестирование другого проекта. И пусть задания похожи, но нужно вновь разбираться, активно работать с ТЗ, учиться новому. Далее следует возврат к первому проекту, затем опять на новый. Только такой подход, на мой взгляд, позволяет эффективно находить всё новые и новые ошибки. Но рано или поздно, сам процесс такого тестирования начинает казаться неэффективным. И я стал присматриваться к работе с автоматическими тестами, благо все условия были для этого созданы. Но жизнь вносит свои правки, и не успев даже поверхностно познакомится с автоматизированным тестированием, меня выбрали основным человеком, который этими тестами и занимается.

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

: Кликаем_на_кнопку_ДАЛЕЕ

 : Действия

  “Переместить курсор мыши на кнопку ДАЛЕЕ”

  “Кликнуть левой кнопкой мыши”

  “Определить, был ли переход по Далее”

 ; \\ Действия

 “Запомнить позицию курсора мыши и выполнить {(@ Действия)}”

; \\ Кликаем_на_кнопку_ДАЛЕЕ

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

Поначалу, небольшие сложности вызывала обратная польская запись кода, а также обилие форм, контролов и классов. Но это объяснимо: последний раз самостоятельно программировать пришлось в далеком 2005 году в колледже (если не ошибаюсь, последней работой стала программа “Определение уровня безопасности помещения” на Delphi). Программированием это назвать сложно – все в рамках учебных курсов. Но тем не менее, основы, заложенные тогда, помогают разбираться и теперь с тестами. Когда приходит понимание, как найти контрол на форме, как передать ему фокус – настроение сразу поднимается. Это увлекательно, здесь нет однообразия: нужно успевать фиксировать результаты прогона тестов, писать новые, править старые, распределять тесты по пресетам, разбираться в старых ошибках, чужом коде и думать (последнее самое ценное). Поэтому, мое отношение к автотестам – очень позитивное и положительное. Да, можно проверить уже исправленные ошибки вручную, но здесь главную роль играет время – его уйдет неимоверно много на повторение старой ошибки, по сравнению со временем прохождения теста.

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

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

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

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

Прим.: Мнение автора может не совпадать с мнением коллег.

Трофимов Андрей