Охотник на жуков

Есть профессия плодить ошибки, и есть - их отлавливать или Размышления о скромном труде тестировщиков.

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

Кто такой программист — в Израиле знают все. Быть программистом здесь — все равно что в России работать бухгалтером на большой фирме. Все хотят быть программистами, потому что они а) зарабатывают кучу денег, б) нравятся девушкам, в) получают от фирмы машины почти бесплатно и г) постоянно ездят заграницу по приятным и небольшим делам.

На самом деле я не программист, а тестировщик. В переводе на язык оригинала это называется Quality Assurance или кратко — QA. С программистами мы скорее антиподы. Он хочет написать свой кусок программы, сесть в казенную машину и поехать к девушкам тратить деньги. А я должен сделать все, чтобы найти в программе побольше ошибок и заставить ее автора сидеть до позднего вечера за своим компьютером, вместо пустой траты денег и девушек.

Еще полгода назад я отвечал только правду.

- Кем ты работаешь?
- Тестировщиком.
- Это что такое?
- Ну, программы тестирую.
- Какие программы?
- Разные. Компьютерные.
- А как ты их тестируешь?
- Сижу, нажимаю кнопочки и жду, пока она заглючит.
- И что, ЗА ЭТО еще и деньги платят???

Что интересно — платят. Деньги, вполне сравнимые с теми, что получает программист. Давайте вместе попробуем разобраться — за что.

Давным-давно, лет 15 назад, тестировщиков как отдельной специальности практически не было. Новые версии софта выходили нечасто, число новых игр в месяц можно было пересчитать по пальцам, программисты спокойненько, с расстановкой писали код, а потом так же спокойно проверяли плод своих рук на способность работать. Функций у программ было относительно немного, так что проверить их все было делом не очень сложным. Игрушки же проверяли еще проще — раздавали бета-версию по друзьям и знакомым. CD-Recorder'ы тогда были мало распространены, Интернет — тоже, так что опасности, что игрушку, отданную утром на тестирование приятелю из Алабамы, уже к вечеру будет лечить от вирусов Евгений Касперский, практически не было. Теперь скажите мне — чем обычно новая версия программы отличается от старой? Стабильностью работы? К сожалению, не всегда. А вот новых функций, полезность которых вызывает множество сомнений, напихают завсегда и с удовольствием. Версии через три узнать оригинальную — маленькую и быструю —  программу уже невозможно. Мы видим что-то вроде танка с элементами бетономешалки и массажной щетки, массирующей только подмышки и большие пальцы ног). Вы и сами лучше меня знаете особенности этого превращения — сравните хотя бы CorelDraw версий 1 и 10.

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

Циклы выпуска новых версий тем временем неуклонно сокращаются. Одна версия в три года, в два с половиной, в два, в год, в полгода. Программисту некогда все это проверять, ему надо добавлять новые навороты. Нанять еще десять программистов, чтобы они только искали ошибки? Но это удовольствие из серии гонок на «Феррари» по трассам города Ухрюпинска, получается дороговато и не эстетично. Потому что для Ухрюпинска надо «уазик» или, на крайний случай, «Ниву».

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

Тестировщиком же может работать любой человек, который:

1. Имеет опыт работы за компьютером не менее трех лет;
2. Использовал несколько операционных систем (пусть даже одной фирмыJ);
3. Понимает, что в программе — баг, а что — фича.
4. Знает английский язык.
5. Умеет запоминать, а потом описывать, как именно воспроизвести полученную ошибку.

Получается так, что простым тестировщиком может работать каждый второй пользователь? Совершенно верно. Правда, речь идет только о так называемой ручной проверке. Для того чтобы заниматься автоматическим тестированием, необходимо знать язык программирования, вроде C++.

Это относительно новая область тестирования программ, так что о ней подробнее.

Если речь идет о тестировании графического редактора или почтового клиента, здесь должен работать живой человек. Но вот представьте, что надо проверить сервер, который одновременно использует двадцать тысяч человек. Где найти столько людей? Даже монстрам типа Microsoft или IBM эта задачка доставит массу неприятностей, а что делать, если на фирме работает всего человек 100? На помощь приходят программы вроде WinRunner или LoadRunner (есть и другие, но эти наиболее популярны). С помощью скриптов на языкеочень похожем на C++, тестировщик описывает поведение некоего виртуального юзера, потом клонирует его несколько десятков тысяч раз, и — о чудо! — нам уже не нужно такого безумного количества живых тестировщиков. Эта работа уже ничем не уступает по сложности программированию, а порой и превосходит его.

Посмотрим на моем примере, как происходит процедура тестирования программ.

Утром, придя на работу, прочитав почту, новости, свежий рассказ Экслера, ответив на почту, выпив стакан молока… это к тестированию, как вы понимаете, не относится, но создает антураж… итак, выпив стакан молока, я начинаю вспоминать — что не доделано вчера. Как правило, на утро я оставляю совсем немного вещей, чтобы как-то перебиться в ожидании новых указаний руководства, которые начинают поступать около 11 утра. Потом я открываю PR-Tracker.

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

Итак, PR-Tracker открыт. Я вижу, что из 5 багов, найденных вчера, три проверены главным программистом и признаны таковыми; один сразу же закрыт с недвусмысленным намеком в мой адрес, что неплохо бы и описание программы читать изредка; еще один оставлен в подвешенном состоянии, потому что программист должен посоветоваться с коллегами, и принять окончательное решение — баг это или фича.

Теперь можно приступать непосредственно к тестированию. Фирма, где я работаю, выпускает комплекс программ для дистанционного образования. Разумеется, весь комплекс один человек тестировать не может, так что есть несколько отделов, каждый из которых занимается чем-то своим, но, конечно, идя по прямой дороге, старается не пропустить бриллиантов, которые лежат на обочине. Мой отдел занимается тестированием «Кампуса». Это место, куда стекаются все виртуальные преподаватели и студенты, откуда посылаются команды серверам и прочая, и прочая.

Чисто теоретически, есть подробные руководства — как и что тестировать. Но следовать им а) довольно скучно и б) очень долго. Пользователь именно тем и отличается, что никогда не читает руководств. Разумеется, что если все делать по правилам, то и Windows глючить не будет, но, пардон, мы не за то деньги платим немалые, чтобы еще и правила соблюдать. Я заплатил деньги, и продавец товара должен сделать так, чтобы любое мое действие, пусть даже откровенно идиотское, вроде стократного нажимания кнопочки Snapshot, как минимум, не наносило вреда основной работе.

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

Я запустил на одном компьютере сразу два виртуальных сервера. Вообще-то, нормальные люди так не делают. Они для каждого сервера имеют отдельную машину. Но я — чайник, у которого до конца рабочего дня осталось двадцать минут, и заниматься конфигурированием второй машины было просто в лом. Сделаем все на одной, авось да и заработает. Ой, и правда заработало! Еще один сервер добавляем… Опять работает! Красота! Теперь быстренько приделываем к каждому виртуальному серверу по виртуальному же уроку, и идем домой пить пиво и смотреть футбол.

А в это время на разных концах земного шара начинаются уроки. Три класса — японский, немецкий и американский — внимают учителю. Все отлично работает, пока вдруг американцу не приходит в голову, что народу собралось мало, и неплохо бы всех отпустить и пойти играть в бейсбол. Его студенты с радостью соглашаются и отсоединяются от сервера. Американец решает, что оставлять урок в онлайне совершенно необязательно, заходит на «Кампус» и удаляет СВОЙ урок.

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

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

P.S. А тот баг с несколькими серверами на одной машине уже давно исправлен. Теперь можно безбоязненно запускать хоть десяток. Думаете, почему японцы снова активизировались в вопросе возвращения островов? У них стало одной большой проблемой меньше.