пятница, 18 сентября 2009 г.

Проект одного тестировщика часть 2

Продолжая, вспоминаю, "как все начиналось".
Поставил себе несколько целей на начальном этапе:

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

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

3. Уделять достаточно времени на ручное тестирование отдельных модулей приложений. Здесь можно долго сокрушаться об отсутствии внутренних релизов, о внедрении которых напишу позже, но тем не менее разработка велась. Велась в бардаке... с элементами SCRUM. Поэтому периодически поступали задачи протестировать тот или иной функционал. И эти задачи должны были быть выполнены в независимости от остальных факторов. То есть бралась существующая документация по реализации задачи, брался ее разработчик, выяснялся "смысл жизни" (имею ввиду как оно должно работать и чего не должно делать) и проводилось тестирование. Тут сразу всплыл и пункт 4.

4. Необходимо было определиться с багтрекинговой системой, попутно воюя со всеми, кто желал получить в результате тестирования файлик с багами. В этом направлении повезло в том, что в организации использовалась самописная система постановки, учета, выполнения задач для сотрудников, которая вполне сгодилась на первое время. Сгодилась потому, что все необходимые атрибуты дефект репорта вполне в ней
нашлись и могли использоваться. Однако для объективной оценки возможностей и невозможностей этой самописной сисемы была попытка использовать Bugzilla для сравнения. То есть мы решили поднять у себя багзиллу и посмотреть на разницу между этими двумя системами. Про поднятие багзиллы можно очень долго рассказывать с использованием русских и английских идиоматических выражений в больших количествах. В принципе в инете есть описание сего процесса, есть решения сложностей, так что углубляться не стоит. В итоге на второй день поднял багзиллу и отдал на сравнение разному начальству. Тут имеет смысл сказать о том, что ни одна из этих двух систем не воспринималась как основная, на которой мы будем вести весь учет
дефектов и т.д. Все потому, что на гаризонте уже маячил TFS со всеми его хвалеными возможностями и реалиями. И все потом планировалось завязывать на него.
После сравнения мне сказали, что багзилла бедна функционально по сравнению со своей системой и мы ее юзать не будем. Сомнительно конечно, но... всегда сложнее переходить на что-то новое, чем использовать старое, проверенное, пусть даже и устаревшее. Идем дальше.

5. Так как задумывалось регрессионное тестирование проводить в автоматическом режиме, необходимо было подобрать оптимальный инструмент для этого дела. Сразу скажу, что решение об использовании автоматизации принималось без меня. Но оно вполне обосновано, если учесть, что клиентских приложений второго типа (см.
предыдущий пост) планировалось великое множество. Про выбор средств автоматизации написано достаточно много, есть тренинги. Чем я с удовольствием и воспользовался. Итак- на входе были следущие требования в инструменту: бесплатный или максимально дешевый (дело было в разгар кризиса, который наложил свой
отпечаток :( ), обладал возможностью проведения тестирования Win приложений, web приложений, нагрузочного тестирования. Напомню, что требовалось тестировать: связка клиент-сервис-БД и 2 типа приложений (в первом
можно создавать второй). Здесь куча всяческих ограничений, которые необходимо было учесть при выборе, которые при необходимости опишу позже. Также должна была быть возможность интеграции с VSS (и TFS в будущем), а также с Visual Studio 2008.Наверное не все вспомнил, но пусть так будет. В результате бесплатные инструменты как-то отпали по мере ознакомления, а из доступных платных остались TestComplete и
QTP. Триальные версии обоих были успешно установлены и сравнивал уже непосредственно "в деле". К слову, у обоих достаточно понятная документация, некоторые вещи даже на русском языке есть, помог форум на ресурсе
it4business.ru Это позволило достаточно быстро разобраться и пробовать применять инструменты в необходимых направлениях. По итогам выбран был TestComplete 6*.
Завершилась эта задача намного позже, чем остальные. Все помнят простую истину- нельзя автоматизировать
то, чего нет.

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