Волею случая пришлось мне крепко заняться и погрузиться в процесс тестирования. До этого совершенно не обращал внимания на эту тему. Не то, что полагал ее слишком заумной или наоборот совершенно обычной, просто по роду занятий не было особой нужды сталкиваться.
Было и такое предвзятое мнение, что труд тестера несложный, работа не престижная и малоквалифицированная, что тестером берут неопытных новичков, чтобы быстрее въехали в систему и поняли что к чему, прежде, чем займутся более серьезными и продуктивными задачами.
Однако оказалось не все так просто. Для начала с некоторыми элементами тестирования (зная, что мне это предстоит) я начал знакомиться еще на TrainingLabs. Правда сразу попал на тренинг управление рисками тестирования.
В целом мой сегодняшний опыт - 2,5 недели. Получилось так, что сразу начал изучения с инструмента по созданию тестов TestComplete. Обложился кучей книг: Тамре, Канер, Бейзер, Рэшка и т.п. Всего аж 5 книг + статьи, презентации, хелп TestCompleta.
Не знаю много или мало это 2,5 недели, чтобы получить определенные знания и начать работать. Возможно и достаточно для определенных целей.
По крайней мере, имею такой навык:
1. создание довольно гибких скриптов по тестовым сценариям на TestComplete
2. запуск тестовых заданий по расписанию в автоматическом режиме с аккуратной в нужное место записью логов прохождения тестов, посылкой сообщения и даже самого лога по почте
3. понял и настроил тестовый стенд
4. приступил к разработке набора шаблонов документов по тестированию
5. немного разобрался какие тесты бывают, каково назначение тестирование, каково его место в общей системе качества проектных решений, каково место его в процессе разработки
6. понял также, что у большинства окружающих очень скептическое мнение по поводу автоматизированного тетстирования и вообще тестирования в целом
7. понял, что в реальной практике работ часто требуется объем работы, а не его качество. И если ты бьешься целый день над возможностью получить результаты из прохождения теста сразу на почту в аккуратно расфасованном виде и с предварительым интеллектуаьным парсингом, но при этом сделан только один два простеньких теста, то тобою будут не очень довольны
8. понял, что тестирования штука столь же сложная как и любой другой этап или дисциплина проектирования
9. услышал множество строго диаметральных мнений: одна группа утверждает, что автоматизированное тестирование лажа, но при этом по сути не имеют сами никакого положительного или отрицательного опыта его использования, другая (это в основном авторы книг) очень положительно отзываются о таком подходе. Бейзер вообще утверждает (у него 40 летний опыт работы в ИТ), что ручное тестирование похоже на всадника бегущего перед мчашимся локомотивом - выглядет смешно и неудобно. Мол тестирование следует сводить у автоматизированному однозначно, все остальное ересь и глупость.
Что же я все-таки понял?
Для начала нужно ясно понять что и зачем мы собираемся тестировать. Если до этого момента тестирование проводилось, а бы как. Не было выделено в отдельную дисциплину, то трудно сразу построить сколь-нибудь серьезную систему тестирования, даже при хорошем понимании того, как это делается. Приходится понимать, что если практически использовался подход случайного тестирования, то скорее всего при начале систематического тестирования приходится выделить некоторое важное направление и двигаться в его направлении. Однако нужно точно задать цель, что мы хотим получить от этого процесса.
Если целью будет (как в нашем случае) потребность выяснить не приводит ли добавленная новая функциональность к нарушению работы определенной части старой функциональности, то нужно понимать, что отсутствие ошибок в тестах не будет означать реальное их отсутствие.
С другой стороны нужно также понимать, что построение всеобъемливаеющей системы тестирования можно осуществить только очень активной работой, бросанием практически всех ресурсов на эту задачу. Постепенное выстраивания в ходе живого, постоянно обновляющегося проекта и изменяющегося приложения на мой взгляд практически не возможно. Если правда на каждого разработчика не будет по одному, а то и двух тестировщиков. Или элементы тетсирования будут встраиваться в саму проектную разработку.
Пока я не могу быть оптимистичным, потому остаюсь пессимистом, по крайней мере, это позволяет не разочароваться в себе.
В качестве примера хочу рассказать о том, что планируется или уже частично сделано:
суть задачи в том, чтобы обеспечить проверку того факта, что внедрение новой функциональности не приводит к нарушению алгоритмов работы одной, но важной задачи по клиентам: выставление платежной документации клиентам в соответствиис определенными правилами и параметрами. Формирование платежей определяется достаточно сложными правилами и на них влияют многие параметры как статические, так и динамические, в первую очередь время.
Общее количество возможных сочетаний параметров велико, правда я затрудняюсь ответить сколько (надо вспонимать наверное математики). Скажем так пусть есть 20 параметров так или иначе влияющих на результат формирования счета. Каждый параметр либо активен либо дезактивен. Какое количестве входных сочетаний должно быть для покрытия всех возможных ситуаций?
В принципе, если удасться сделать один единый скрипт, а только менять входные параметры и сопоставлять выходные результаты с известными и достоверными, то можно все 2000 клиентов прогнать. Правда тут есть трудность: сравнение результатов будет осуществляться сравнением скриншотов или регионов. Т.е. по каждой компании делает снимок счета (из формы перваритьельного просмотра) и при прогонке теста такие скриншоты сравниваются. Тут как вы понимаете трудность именно в получении всех этих 2000 скриншотов. Даже если тратить на сохранение такого скриншота примерно 2 минуты (найти нужного клиента, вызвать его форму его счета, вызвать форму предварительного просмотра, сделать чек-поинт региона, задать имя для региона, сохранить), то очевидно для охвата всех 2000 компаний нужно 4000 минут или 67 часов или примерно 9 рабочих дней, а реально в два раза больше, т.е. три недели как минимум.
Правда можно все-таки надеяться, что таких сочетаний все-таки меньше в реальной практике и их можно всести к 100 или меньше. Тогда работу можно сделать примерно за день, без учета разработки и отладки самого скрипта. Возможно на всю эту работу нужно отвести минимум неделю.
Зато, конечно, появляется выгода, если в последствии такой скрипт запустят как минимум раз 10. Он гораздо быстрее просканирует задачу, чем бы это делал человек. Это можно выполнить ночью, к примеру. Правда все-таки остаются но.
Возможности скриптования зависят от самого приложения. В моем случае формирование счетов можно инициировать только через пользовательский интерфейс.
Далее в случае изменения интерфейсов форм, придется переделывать сам скрипт, правда скорее всего это не займет слишком много времени. Однако, если изменятся формы отчетов, по сути придется полность создавать заново регионы, т.е. на это может уйти день, а то и два работы. Если вносимые изменения не будут слишком часты - это еще нормально. Однако если потребуется поддерживать не один, а множество таких скриптов, то либо нужно больше народу, либо тетсировщик просто захлебнется только поддерживая старые скрипты, не успевая подумать и создать новые. А ведь еще нужно анализировать результаты, понять их причину, создать возможно новые тестовые случая для их проверки.
Ясно, что устремленность на автотестирование только малоперспективна и вряд ли возможна. Кроме того если сейчас я начелен на ГУИ тесты, то ясно, что следует вовлекать более устойчивые к изменению тесты, например сделав некоторые манипуляции в ГУИ, осуществить выборку требуемых данных из БД и сравнить из с контрольными.
Вообще работа творческая. Правда что-то мне подсказывает, что я ее не смогу поддерживать одновременно работая на ставку в вузе и имея там множетсво других обязательств. Хочу надеяться на то, что моя работа на компанию летом - есть часть исследовательской работы, работы по выработке технологии, с возможностью в будущем оказывать консультации, но не отвечать за эту работу...
Автоматизированное тестирование + и -