Entry tags:

it, me, тестирование

Про мою жизнь в IT, или как я дошёл до жизни такой - часть третья.
Начало здесь.
Часть вторая.

Вполне очевидно, что, проработав почти полтора года программистом С++, я искал соответствующую вакансию, но тут мне "по знакомству" предложили посетить одну компанию. Собеседование со мной проводил руководитель Управления Java-разработки, подробно расспросивший меня о том, чем занимался на предыдущем месте работы и ещё подробнее - о том, чему учили в ВУЗе. Об этом я достаточно подробно рассказывал в первых двух частях своего повествования, и внимательный читатель легко поймёт, что в компании, разрабатывающей софт на Java, Delphi и FoxPro программист моей квалификации не подходил, разве что на позицию junior-разработчика Delphi. И тогда мой собеседник выдал пассаж примерно такого содержания: "Пожалуйста, не воспринимайте в штыки, но что, если я предложу Вам позицию в Управлении тестирования? Ваш опыт программиста тут поможет, ведь у них свободна вакансия автоматизатора тестирования...", - а потом нарисовал мне словесную картину того, как по экрану сам собой двигается курсор, нажимаются кнопки, вводятся значения...

В общем, я не только не воспринял в штыки, я был просто в восторге от этой идеи!

Так и началась моя жизнь в тестировании. Разумеется, первое время я знакомился с тестируемой системой (MS SQL Server + MS Visual FoxPro) и с совершенно новой для себя областью программного обеспечения - ПО для автоматизации функционального тестирования. Не буду растекаться мыслью по древу, в этом цикле постов речь всё-таки обо мне, посему, о видах тестирования, их целях, средствах и задачах будет отдельный пост, может, даже не один. Первое, с чем я столкнулся, - это AutomatedQA TestComplete весьма бородатой (третьей) версии.

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

• Знание предметной области - похвастаться нечем. Тестируемая система крайне специфическая - софт для бюджетного учёта (по заказу Федерального казначейства РФ). Поэтому по любому вопросу я обращался к руководителю группы тестирования или к кому-нибудь из более опытных "прикладных" тестировщиков.
• В качестве входных данных автоматизатор получает описание последовательности действий, которые нужно выполнить в ПО с указанием точек контроля. То есть, на какую кнопку нажать, где что вписать, где какие суммы должны сойтись и т.п. В различной терминологии этот документ может называться: вариант использования (use case), тест, test case, методика тестирования, в отдельных случаях - "программа приёмочных испытаний", business case.
• Получив задание в том виде, в котором оно описано в предыдущем пункте, автоматизатор проводит все действия, проверят все контрольные точки (checkpoints), и, убедившись, что всё выполняется корректно, начинает запись автотеста.
• Первое, что должен изучить функциональный тестировщик - это то, где у средства автоматизации тестирования находится кнопка "Record". Обычно это кнопка с красным кругом, как на магнитофонах :-)
• После того, как кнопка "Record" нажата, следует в тестируемом ПО провести все действия, описанные в тест-кейсе и нажать кнопку "Stop". Тут необходимо сделать замечание, что очень большое значение имеет и сама тестируемая система (в частности, языки и технологии, с использованием которых она написана), и средство автоматизации тестирования (о своём опыте по этой части я буду рассказывать в других постах).
• А дальше средство автоматизации тестирования сохраняет записанные действия... и вот тут-то становится понятно, почему более предпочтительным кандидатом на роль автотестера является человек, имеющий хотя бы минимальный опыт программирования: всё, что было произведено с ПО, оказывается записанным в виде скрипта, кривизна которого зависит от двух факторов, приведённых выше: от тестируемого ПО и от средства автоматизации тестирования. Мне, можно сказать, "повезло": FoxPro крайне плохо записывался третьим ТестКомплитом, а сами скрипты разрабатывались на входящем в поставку DelphiScript - кастрированном варианте Delphi, функциональность которого при этом была расширена набором встроенных объектов (весьма, кстати, удобных).
• Самый ужас был далеко не в DelhiScript. Ужас был в том, что у нас не распознавались объекты и я, как человек, не имеющий опыта, принял как данность то, что они не распознаются. Поясню, что это значит. Когда всё настроено правильно, при нажатии на кнопку ты видишь, что распозналась кнопка, а если неправильно, то ты видишь только её координаты. Для тех, кто в танке: при изменении размера окна координаты легко могут "сползти".
• Чтобы не быть голословным, покажу вам пример "правильного" скрипта, записанного следующим образом: на встроенном в Windows калькуляторе я посчитал "2+2" и нажал кнопку "равно":
  

    Dim w1
    Dim w2
    Set w1 = Sys.Process("calc").Window("SciCalc", "Калькулятор")
    Set w2 = w1.Window("Button", "2")
    w2.ClickButton
    w1.Window("Button", "+").ClickButton
    w2.ClickButton
    Call w1.Window("Button", "=").DblClick

  
  Внимательный и программерски-подкованный читатель заметит, что приведённый скрипт на Visual Basic, а вовсе не на клоне Delphi, но это несущественно.
• В общем, несколько месяцев я занимался тяжёлой и, увы, почти бесполезной работой - записывал скрипты, состоящие из нажатий кнопки "Таб" и её комбинаций вроде "Shift+Tab", "Ctrl+Tab" и прочих.

Всё изменилось, когда в компанию пришла чрезвычайно опытная девушка Ира, обладающая солидным опытом и обширными знаниями в области тестирования вообще, автоматизированного тестирования в частности, а также опытом организации тестирования с нуля. Причём, пришла из компании-партнёра, с которой был подписан "пакт о ненападении" (запрет на переманивание кадров друг у друга), то есть, перевод этой девушки согласовывался на уровне генеральных директоров, но она действительного того стоила. За считанные месяцы у нас была выстроена полноценная система тестирования из HP (Mercury) Qualtiy Center и TestComplete 6 (купленного так же после весьма долгих и непростых переговоров Иры с нашим начальством).
Вот тут наконец пошло настоящее тестирование: тестами было покрыто несколько больших функциональных областей ПО, и на каждой сборке и патче прогонялся полный набор тестов, благо, машин у нас хватало, и общее время всех тестов не превышало 3-4 часов (а сборок бывало от одной до четырёх-пяти в день, иногда чаще, но тогда, как правило, часть сборок не тестировалась).</li>

Так и жил я ещё почти год - писали тесты, тестировали, старались, в общем, работы было много и была она интересная.

Проработав в компании год, я получил диплом (в июне 2008-го), и сразу за ним - должность ведущего тестировщика и приличное повышение оклада.
И вот однажды, как раз летом, ко мне обратился один из ведущих тестировщиков (помощник руководителя группы тестирования) с просьбой помочь с программированием на VB.NET, который я раньше и в глаза не видел. Так начался мой временный, но крайне интересный период возврата к программированию, о котором я расскажу вам в следующей части :)
Читайте в следующей серии:

1. Как я искал работу в кризис (в сентябре-октябре 2008-го);
2. Как я проходил собеседование на детекторе лжи;
3. Как за два собеседования и час за клавиатурой я заработал 120 WMZ
4. Как я стал ведущим тестировщиком по нагрузочному тестированию.