Оборотни в тестировании

Автор: | 19.01.2010

Какой тестировщик не мечтает стать программистом?

Глупый?

Начинающий?

Бородатый?

Ответ: почти каждый тестировщик при очередном посещении бухгалтерии думает о том, что «Елы-палы, а, может быть…»

И очень мало кто может этот переход совершить.

Пояснение: программистом надо становиться сразу, а не через увеличение поголовья скучных дабл-кликеров.

Однако есть очень успешные гибриды, силе и полноценности которых некоторым остается только завидовать:

  • либо это программисты, которые перешли в тестирование,
  • либо это тестировщики, которые уже задрались делать все «как обычно», и ищут эффективные приемы и методы тестирования своих сайтов и сайтищ.

Такие уже отравлены ощутимой силой воображения, которое подсказывает, чего можно наворотить уже с одним только Selenium IDE, но еще не дошли, например, до запуска Selenium RC, затем Selenium Grid, а затем прямого выхода в космос автоматизированного тестирования.

Как до них добраться?

Рекомендую начать с четвергов.

Что еще за четверги?

С удивлением узнал, что сегодня вторник. Казалось, что прошлый вторник был когда-то очень давно.

Значит, очередной четверг уже совсем скоро.

Уже привык ориентироваться в неделе по четвергам, а точнее, по дням, когда <reclama> идет тренинг Алексей Баранцева «Программирование для тестировщиков» </reclama> (я о нем ранее упоминал).

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

По-моему, вот таким тестировщикам и нужен упомянутый тренинг. Не знаю точно, для кого именно этот тренинг готовился, поэтому подчеркиваю «по-моему». Это имхо.

Если бы я сейчас все еще работал бы в большой компании типа GlobalLogic, то этот курс мог бы пройти мимо меня по очень очевидным причинам — на нашем проекте не приветствовались переходы между тестированием и программированием. Для большой компании это весьма репрезентативно — проще взять «с улицы» опытного программиста, чем превращать собственного опытного тестировщика в неопытного программиста, а потом его взращивать.

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

Баранцев рассказывает не о теории программировании as is, а о конкретных приемах записи и дальнейшей грамотной организации тестовых данных и собственно тестов используя возможности JAVA (фреймворк — Eclipse).

Используется прием обучения «делай как я». На экране сразу начинается гуща событий — запись действий с их одновременным комментированием. На экране — код.

Примерно так молодые люди начинают учить игру на гитаре у дворовых владельцев инструментов — нажать туда и сюда, и поехали… Сразу становится понятно — овладеешь ли?!

Если да, то перед тобой открывается большущий мир музыки в перекрестье струн и ладов, и через какое-то время тот, кто тебя учил, перестанет понимать твои вопросы о зачатках теории и способах звукосочетаний и звукоизвлечений — ты перешагнул в новую высоту.

Если нет — ты вовремя остановился. Играй «постой, паровоз» без вывертов, и будь счастлив.

Баранцев сразу помогает это дело понять. Первая запись простого теста в Selenium IDE у него превращается в обширное и слегка сложное для новичков в программировании применение принципа «вынесение общих данных в отдельный метод», и прочая. Если прошел уровень — на тебе вторую сложность.

Потом третью.

На четвертом уровне ситуация вдруг проясняется, и тестировщик начинает понимать, почему программисты так дергаются при сообщениях об ошибках…

Оно же ДОЛЖНО работать 🙂

В итоге получается вот что: тестировщик может проверять программным способом (не руками) какие-то последовательности действий в бразуере; обращаться к базе данных и что-то с ней, озираясь, сотворять; всячески усложнять себе жизнь для того, чтобы ее впоследствии облегчить (парадокс автоматизации); работать со строками; работать с контейнерами, предназначенными для хранения наборов данных; работать с файлами; работать с почтой…

Тестировщик получает возможность создавать довольно сложные комплекты автоматизированных тест-кейсов, которые организованы по основным принципам программирования — храним отдельно действие и отдельно данные, которые надо подставлять в ходе действия…

Тестировщик получает возможность читать код программистов, и руководствоваться его логикой при составлении собственных проверок. Править код программистов пока не рекомендуется. Могут побить. От восхищения.

В комментариях опытный народ говорит: «Упаси вас ВЕРХОВНЫЙ МАНАГЕР от «руководствоваться логикой кода для составления проверок»!!!! Ошибка в логике приведет к ошибке в тестах. Либо ищите ошибки в логике кода, раз есть доступ к коду. Пользы в мильон раз больше«.

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

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

Гибридные оборотни рулят

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

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

Я показал основы этого курса моему нынешнему молодому коллеге, и мир чуть было не потерял перспективного молодого тестировщика — коллега испугался. Ему показалось, что как тестировщик он должен будет все это кодить… Пришлось лечить легкой терапией с применением слабого психотропа Selenium IDE. Дело налаживается, Selenium затягивает, как вождение по льду.

Наверное, стоило бы назвать такой курс «Программирование для тестировщиков-оборотней».

Приходит конец багам, не так ли?

Итог: курс отличный (ставим клеймо — «Алексей Баранцев»).

Но есть еще пара мелких семечек в ваши шелковые простыни: курс требует от слушателя работы.

А отставание просто выкидывает студента с карусели ко всем чертикам. Или догоняешь, или сам по себе отваливаешься.

У меня с этой работой получилась следующая закавыка: анализ полуторачасовой записи действий тренера с записью деталей и самостоятельными попытками воспроизвести все показанное занимал три часа.

Иногда — четыре.

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

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

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

А написуемый код надо обязательно сопровождать комментариями.

Оборотни в тестировании: 10 комментариев

  1. kate

    весьма эмоциональный пост, я вся в предвкушении..остались считанные дни. столько инфы «about» что хочется скорей погрузиться в загадочный мир оборотней)

  2. kuroikaze85

    Тестирование для программиста — штука конечно очень важная 🙂 TDD часто намного удобнее простой разработки, тут хочешь не хочешь научишься.
    Жаль что Селениум я пока так и не освоил 🙂

  3. Василь

    Точно! нужно будет поднять svn для кода.

  4. Albert Gareev

    Отличная статья!
    Так и надо.
    Курс Молодого Бойца — для начинающих тестеров.
    Эвристическое Обучение — для людей зрелых и опытных, как автор сего блога.

  5. kuroikaze85

    У меня кстати было такое же «WooHoo!»-состояние, когда я занялся изучением (и применением) автоматического тестирования. Настолько проще стали некоторые вещи — не передать 🙂 А уж потом, когда нашёл git и в частности git bisect… 🙂

  6. dumtest

    Прочитал. Меня в списках нет:) Биография: тестирование->разработка и тестирование/управление разработкой и тестированием ->тестирование/управление тестированием.
    На второй стадии был ощутимый перекос в сторону разработки.
    По тексту в целом согласен, но:
    тестировщик — НЕ разработчик даже если он и умеет читать код. Кесарю кесарево.
    Цитат нет, так что буду приводить текст:
    1) «Тестировщик получает возможность читать код программистов, и руководствоваться его логикой при составлении собственных проверок.» Упаси вас руководствоваться логикой кода для составления проверок!!!! Ошибка в логике приведет к ошибке в тестах. Либо ищите ошибки в логике кода, раз есть доступ к коду. Пользы в мильон раз больше.
    2) «Тестировщик получает возможность создавать довольно сложные комплекты автоматизированных тест-кейсов» Алексей не уточнял кто должен тестировать эти самые сложные комплексы? Плюс ко всему — Селениум — тестирование ГУЯ, самой часто изменяемой на этапе разработки системы части. Затраты на поддержание тестов случайно не перекроют затраты на обезьяньи методы тестирования? Алексей не уточнил на какие типы систем имеет смысл прикручивать автоматизацию тестирования ГУЯ?
    Сюда же. Сложные комплекты автотестов сами по себе превращаются в объект надзора — версионирование, документирование, сборки и прочий обвес разработки, т.е. говоря проще — тестировщик превращается в «узкоспециализированного» девелопера. Вот уж точно оборотень:)))
    Я сторонник разумной автоматизации, а тут мне кажется слишком впечатлил Алексей вас.
    Будьте бдительны:) А так удачного постигания дао дзен-тестировщика по классификации Макса Дорофеева.
    Мог бы писать ещё долго. Я обернулся на первом переходе, т.е. 6 лет назад:)
    З.Ы. Selenium IDE никакущ при крос-браузерном тестировании, особенно, если речь идет о дотнетных сайтах. А если говорить про RC, то для нормального автоматизированного пакетного тестировния надо достаточно неплохо проникнуться идеологией того языка, на котором пишется код тестов.

  7. Алексей Лупан

    Спасибо.
    Ни фига меня Баранцев не впечатлил. Просто я его оголотелый фанат, потому и… 🙂
    (подпрыгивая) Дык, что Selenium… Не в нем же одном все счастье.
    Это только поперву о нем Баранцев говорит, а ближе к концу учебы от Selenium уже ничего не остается, начинается не автоматизация GUI, а автоматизация по-существу. Обращение к файлам, работа с почтой, работа с базами данных.
    Анадысь мы с коллегой в ходе автоматизации нашего приложения столкнулись с записью мудренного кейса — в нашу систему любой дурак может залогиниться через свой аккаунт на Фэйсбуке (звездно-полосатые жители ценят эту возможность, поэтому она есть). При активации этой замечательной возможности появляется поп-апчик с полями логина/пароля, который опосля логина ТАМ должен вернуть в браузер с НАШИМ приложением все данные.
    Путь GUI-самурая — во что бы то ни стало записать все действия, но Selenium оказался слаб в коленках, и заколбасился. Real marazm in GUI automatization.
    Молдаване-автоматизаторы выбрали более близкий подход к Баранцев-style — мы по-серьезному забили на GUI; мы взяли программистский код из репозитория; мы выцыганили из него URL, по которому определенным образом генерировались обращения из НАШЕГО браузера на сервер Фэйсбука; мы разложили этот код на определенные составные, и собрали собственный линк для генерации логина в НАШЕЙ системе под акаунтом с Фэйсбука; и вот — мы залогинены в НАШЕМ приложении под акаунтом ВНЕШНЕЙ системы посредством одной команды в Selenium. Оставалось только перегрузить страницу в браузере, и двигаться дальше по плану. Вот в такое дао автоматизации мы усердно вкуриваемся, и именно его я и подразумеваю, когда говорю об автоматизации.
    Btw, изменчивость GUI в нашем приложении не так уж и ощутимо, пытуемый нами софт уже много лет здравствует для своих владельцев в определенном состоянии, и изменения в критической области функционала редки. Чаще сталкивались с мелкозаметными изменениями в буквах, которые вписываются в заголовки страниц, чем с передислокацией или переименованием элементов страницы.
    Например, был заголовок ‘Personal Profile Page’, а потом без объяснений превратился в ‘Personal profile page’. Мелочь, но Selenium от такой очевидной разницы сразу колбасит, а поскольку assertTitle у нас используется часто, то — проблема.
    Эту проблему (и ряд других) мы решили посредством предварительного объявления переменных для всех заголовков страниц, которые используются в каждом отдельном сценарии. Фишка отлично работает и непосредственно в Selenium IDE. Selenium IDE — рулит!
    И буквально сегодня выяснилось — нам очень повезло, что мы занимаемся скриптованием и рукоприкладством попеременно. Возня с записью скриптов в какой-то момент реально утомляет. Хочется и покликать, свободно и широко.
    А когда утомляет кликанье (такое тоже бывает), или же пугает предполагаемыми объемами, мы беремся за скриптование, и через некоторое время чувствуем себя белыми людьми на хлопковом поле в штате Луизиана образца 1860-го года.
    Ты, понимаешь, своим делом занимаешься, и изредка на это чудо в отдельном окне поглядываешь, а оно, понимаешь, как бы само по себе шустренько работает… И суть не в том, что оно там ищет новые баги — это дело наших рук и бошек. Суть в том, что оно дает нам информацию, работает ли четко определенный функционал четко определенным, ожидаемым образом.

  8. Albert Gareev

    «тестирование ГУЯ, самой часто изменяемой на этапе разработки системы части. Затраты на поддержание тестов случайно не перекроют затраты на обезьяньи методы тестирования?»
    — Для того и существуют frameworks, позволяющие разносить операции с GUI и бизнес-логику теста на разные уровни (layers), разделять тест данные и код, автоматически проверять тест-код на консистентность.
    И тогда изменения GUI не требуют изменений в тест-коде, единственный тест-скрипт позволяет покрывать десятки или сотни ручных тест кейсов, а в нужных случаях можно проверить не-GUI метод объекта, обратившись к нему напрямую (API call).
    К тому же, кроме Web есть еще и Desktop, Text-Based/Terminal, и Mobile приложения, которые надо тестировать, и объемы тестирования располагают к автоматизации.
    Правда, это все не о Selenium. Надо брать серьезные инструменты — QTP, TestComplete… WinRunner раньше тоже был очень силен.
    Из бесплатных рекомендую AutoIT, но к нему надо будет скачать или разработать тест-библиотеки.
    А можно взять за основу элементы из Microsoft Development Tools и построить практически с нуля, но это как правило application-specific framework получаются.
    Сам я считаю, что от автоматизации максимальная польза когда это «робот на побегушках», а не «робот вместо человека».
    Ну или как у меня на сайте написано: «I implement the methodologies intended to cover and support decision-making process and analysis by saving human time on micro-validations and bringing to the state of better awareness of high-level picture».
    — Альберт

  9. Уведомление: Программирование для тестировщиков, обзор курса @ Роман Твердохлебов. Персональный блог тестировщика и автоматизатора.

Добавить комментарий