эти хрупкие автотесты

Ни для кого не секрет, что одним из обстоятельств, удерживающих некоторых от создания gui-шных автотестов по типу Selenium-овских , является большая вероятность написания хрупких (fragile) тестов. И действительно , для подобного вида тестов вероятность получить хрупкий тест более высока, чем для других видов.

Посмотрим, что же делает подобные тесты хрупкими:

1. Несогласованность с разработчиками. Зачастую тестировщику-автоматизатору достается интерфейс и функционал мало пригодный для "нехрупкой" автоматизации. Например (Если говорить о web), беспорядочное отношение к именованию контролов, присовению идентификаторов важным контейнерам, таблицам и т.д. В данной ситуации необходима совместная выработка общих правил и дальнейшее соблюдение соглашений. Разработчики любят хорошие ТЗ для того, чтобы было "комфортно" программировать, а тестировщики любят предсказуемый код и интерфейсы, которые "комфортно" автоматизировать.
2. Бездумное использование "записанных" тестов. Тут лучше привести пример. Есть таблица со списком объектов из БД. Гипотетический тест проверяет то, что она содержит запись об определенном объекте. Записывалка тестов генерирует код, который ищет нужную ячейку с текстом по xpath локатору с явным индексами tr и td. Тестировщик использует сгенерированный код без изменений и через некоторое время получает провал теста. В чем дело? А просто список объектов пополнен новым и старый сдвинут. Или разработчик выводит список без сортировки и СУБД вдруг "сфетчила" записи в новом порядке. Тут, конечно, можно запросить "поддержку тестирования" в виде добавления сортировки. Но правильнее сначала отредактировать локатор , убрав индексы (если, конечно, соблюдение порядока следования записей не критично), ну а потом можно и сортировку попросить.. для предсказуемости )
3. Часто меняющиеся требования к продукту. Тут уж никуда не деться от переделывания тестов. Рынок диктует свои условия. Поменялись требования, поменялся функционал / внешний вид , меняются тесты. Если подобные правки слишком часты и накладны, то стоит подумать о том, чтобы отказаться от автоматизации данного участка.
4. Плохой дизайн тестов. Тестируемая система не менялась,  а тест то и дело проваливается. Причиной может послужить недостаточно вдумчивое проектирование теста, не учитывающее возможное изменение тех или иных внешних по отношению к тесту условий при неизменности тестируемого функционала. Грубо говоря, тестировщик создал код , похожий на тот, что создают "записывалки". Рекордеры ничего не "знают" об особенностях, которые обязан знать и учитывать автоматизатор.

Наверняка, можно еще добавить несколько пунктов. Но навскидку - приведенные кажутся мне основными.

Платежные системы: непридуманный случай использования

Спешка.
Не вовремя заканчиваются средства на счету мобильного телефона.
Первый аппарат привычной системы оплаты.
Абонент закидывает в "кошелек" последнюю на данный момент наличность, например  500р, чтобы из "кошелька" уже совершить беспроцентное пополнение баланса мобильника.
Тут же в терминале заходит в кошелек и видит несколько предложений, как оплатить - но нужной возможности оплаты прямо из кошелька в терминале уже нет (закрыли в целях безопасности?).
Есть возможность отправки кодовой смс на кодовый номер - оператор берет плату - не подходит, так как баланс отрицательный.
Есть возможность оплаты из соответствующего android-приложения - не подходит, так как надо его качать ,  а 3g-сессии тоже не бесплатны.
Есть возможность через оплатить через сайт системы оплаты, что тоже неподоходит, так как халявного мобильного инета ОПСОСы еще не предоставляют.
В итоге: терминал деньги принял,  а потратить их не дает. Результат: у абонента наличных нет, связи все еще нет, абонент бегает ищет халявный вайфай (макдональдс, например) или банкомат (если есть карточка с нужным количеством средств)....

Вопрос авторам этой очередной версии ПО для терминала оплаты - вы о людях вообще думаете, когда патчи накладываете? ))

как ведут себя люди в последние 2 недели на рабочем месте

Многим из нас приходилось менять места работы, многим приходилось видеть как увольняются коллеги.
Наблюдая за та тем , как это все происходит иногда поражаешься со знаком "+" , как некоторые профессионально ведут себя последние стандартные 2 недели... Никакого послабления в качестве, никакой расслабленности. Все дела закончены. Все инструкции написаны. Человек заботится о своей репутации. Ему дорого мнение остающихся на этом месте коллег и иногда даже друзей.
А иногда поражаешься со знаком "-" тому, как люди воплощают в жизнь "а после нас хоть потоп" в те же стандартные 2 недели... Бумага написана. "отрицательно стимулировать" уже точно никто не будет. Хочу работаю, хочу не работаю. Хочу опоздаю на 2 часа, хочу приду вовремя.
Одних провожают всем отделом, уход других или не замечают вовсе или встречают с облегчением.
Разные все-таки люди бывают при том, что "чемоданное настроение" посещает любого , кому скоро придется подписывать обходной лист )

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

На собеседование приходит молодой "специалист". Опыта почти нет. Всячески показывает желание трудиться на поприще, которое ты ему готовишь. Обнаруживает в себе цепкий ум, умение и не боязнь задавать вопросы, технический склад ума, неплохой IT-кругозор.. Понимает , что ему учиться и учиться и соглашается на самую начинающую из всех начинающих должностей.  В команде появляется стажер.
Испытательный срок пашет, пыхтит, упирается , спрашивает профильную литературу и самое главное читает ее, применяет ее... Но сразу после прохождения срока , улучшения фин.условия,  получения похвал и ободряющих оценок с человеком начинает происходить необяснимое..
Куда-то девается вся любознательность, стремление к развитию, об эффективности речи не идет. Книги? Нет. Судя по всему порфильные книги не интересны. Интересны автофорумы, всякая гуманитарная ботва в рабочее время... Перспектив уйма, задач всяких разных выше крыши, коллектив наилояльейший, график близок к очень гибкому - трудись, развивайся. Нет. Спрашиваешь, узнаешь , беседуешь , подкидываешь "интересненькие" задачи... пытаешься понять , может ты не так что-то делаешь, анализируешь...
Ну и наконец, чтобы не стоять постоянно у человека над душой и не тратить на него свое время и нервы , увольняешь.. Круглые глаза, и опять это дежурное " у меня вчера болела голова " ...
Как раздолбая распознать на собеседовании, если он обладает нужными навыками способностями и ему очень нужна эта работа ... настолько, что он на три испытательных месяца способен наступить на горло своей натуре?

Чтение логов в рамках тестирования безопасности

При тестировании защищенности приложений, в том числе и веб-ориентированных, уделяют внимание защите от всяческих красивых аббревиатурных приемов типа xss, csrf , mitm и еще куча всяких красивых сокращений и еще более красивых расшифровок... Но порой частенько забывают о такой банальщине как логи.
Чем же они могут навредить приложению, честным пользователям, владельцам бизнеса?
Недавно один мой коллега столкнулся с реальным примером вывода (видимо, дебаг) в логах одного веб-портала системы дампы авторизационных данных пользователей системы... пароли в чистом виде в логах, при том, что в бд только хеши... ужас.
Само по себе наличие в логах таких данных никому не вредит.. до них ведь еще добраться надо.
Но кто помещает, например, недобросовестному админу, обиженному на всех и вся, слить налево такие данные , абсолютно не рискуя навлечь на себя подозрения ?
А про сценарий, когда на сервер проник злоумышленник извне (например, пробив какой-нибудь давно не патченный сетевой сервис) .. В этой ситуации , ему надо только уметь читать и ничего более ) Понятно, что ребята, которые могут легко пробивать "непропатченные сетевые сервисы" пробьются затем и в БД, и еще куда захотят, но зачем им облегчать жизнь? В общем, к логам хорошо бы относиться повнимательнее. Как разработчикам и тестировщикам , так и админам с их пермишенами :)

virtualenv в помощь

В этой статье хочу поделиться опытом того, как можно без лишней головной боли организовать тестирование web-приложения , написанного на python c различными версиями этого языка. И даже с различными версиями того или иного фреймворка (django, pylons etc)...если, конечно , фреймворк используется.
Итак , есть сервер , для определенности : на нем установлен linux.. для еще большей определенности - debian )
Любой linux - дистрибутив уже включает в себя ту или иную версию python. Допустим "из коробки" имеем python v2.5. Мы же хотим протестировать наше гипотетическое приложение на совместимость с python 2.5, 2.6 и 2.7 (на совместимость с версией 3 лучше не тестировать - под нее надо писать отдельно =), чтобы быть уверенным, что наше приложение будет работать на большинстве python-хостингов.

1. доставляем отсутствующие версии python. Для этого wget-ом, например, выкачиваем соответствующие исходники, распаковываем (tar), конфигурируем НЕ ЗАБЫВАЯ УКАЗЫВАТЬ ПРЕФИКС установки отдельно для каждой версии python, затем make и make install. В итоге получаем:
   • /usr/bin/python - дефолтный
   • /usr/python2.6/bin/python
   • /usr/python2.7/bin/python
2. теперь самое интересное - у нас три одинаковых бинаря python в трех разных местах. Если вызвать python из командной строки, то будет дернут тот, чей путь левее всего в PATH. Как быть? каждый раз руками менять PATH? мучаться с симлинками? Слава Богу нет. Нам на помощь приходит замечательная штукенция - virtualenv !

   
   sudo apt-get install virtualenv
   mkdir ~/projects/
   cd projects
   virtualenv --no-site-packages -p /usr/bin/python app_test_python2.5
   virtualenv --no-site-packages -p /usr/python2.6/bin/python app_test_python2.6
   virtualenv --no-site-packages -p /usr/python2.7/bin/python app_test_python2.7
   

   В результате мы имеем три директории - по одной для каждой версии питона. Интересное внутри этих директорий. Внутри же создается окружение - бинари, инсталляторы библиотек (pip , easy_install) - сюда же надо помещать и код тестируемого приложения, отсюда же и деплоить с локальным web-сервером (apache, nginx..)
3. еще не все. Чтобы работать в окружении , надо его активировать:

   
   cd ~projects/app_test_python2.6
   . env/bin/activate
   
   

   теперь можно не боясь вызвать python, pip, easy_install - будет вызвана именно версия 2.6, будут использованы именно библиотеки для версии 2.6 и ставиться будут они не в /usr/lib/python , а в ~projects/app_test_python2.6/lib !
   

Полная изоляция, никакой мороки и путаницы.
Таким образом, создавая для каждой тестовой конфигурации свое виртуальное окружение, мы не засираем систему хаотичными симлинками, конфликтующими версиями библиотек и т.д. и т.п. В общем сплошные плюсы.
Расписал, конечно, не все максимально детально. Но, думаю, тому , кто решить освоить эту технику организации тестовых стендов помогут гугл, здравый смысл и прямые руки )
p.s. только python к сожалению ( Пока писал стало интересно есть ли аналоги для perl, php ... )

Вы уверены , что хотите выполнить операцию?

На тему о том, как делать удобные приложения написано немало статей, howto, "стандартов" и так далее. С каждым днем все больше действительно качественно продуманных приложений, по-настоящему дружественных и "обходительных" пользовательских интерфейсов. Развиваемся. Радует.
Но иногда встречаются просто умопомрачительные косяки.
Чтобы не быть голословным приведу пример.
Многие, наверное, знают о нашумевшей криптовалюте bitcoin. Одной из ее особенностью является принципиальная невозможность отмены транзакции. Например , если вы переводите монеты с одного кошелька на другой и при этом ошибаетесь в номере целевого кошелька , то отменить перевод невозможно. Вы можете ошибиться так, что укажете реально существующий кошелек и тогда, маловероятно, но есть шанс вернуть , уговорив его владельца сделать обратный перевод (найти владельца будет посложнее чем иголку в стоге сена). Если ошибетесь так , что такого кошелька просто нет - то монеты просто исчезают.
При всем при этом описанное именно особенность, связанная с изначальными архитектурными принципами этой по-настоящему безопасной криптовалюты. Зная об этой особенности , разработчикам стоит проектировать и реализовывать интерфейсы для работы с этой валютой, а тестировщикам , соответственно, тестировать. Но так ли думают разработчики авторы guiminer ? Это питоновский фронтенд над питоновским же майнером криптовалюты. Занимается он тем, что "добывает золото" . Кроме того , есть у него кнопочка "withdraw", по нажатию на которую все наработанное улетает на некий кошелек. Нет предложения ввести адрес перевода, нет предупреждения о том, что монеты уйдут на такой-то кошелек (чтобы юзер мог сверить лишний раз), нет предупреждения о невозможности отменить транзакцию. Есть только обработка сабмита кнопки в виде списания монет с баланса ))
Сколько же новичков майнинга тут "полегло" ! )) Наиболее распространенные сценарии потери с трудом намайненных монет такие:

• пользователь недавно переставил винду и потерял свой кошелек, сгенерировал новый, а в настройки адресата переводов в учетной записи пула (например deepbit.net) новый адрес своего не внес, в итого withdraw на кошелек, который никогда нигде не увидеть больше
• пользователь отправлял биткойны в биржу , где для получения средств каждый раз генерируется новый адрес..Соответственно, при очередном переводе, забывает указать новый адрес. Результат тот же - видеокарта жгла мазут зря.

В общем..если абстрагироваться от этого печального примера, то на ответ "выводить окно подтверждения или нет" можно так:

1. если совершаемое действие может быть легко и без последствий отменено, то можно и не предупреждать
2. если совершаемое действие не может быть отменено, то предупреждать
3. если речь идет о финансах и клавиатура, которая может быть разбита, то ПРЕДУПРЕЖДАТЬ да еще и с описанием всех ньюансов)

"Сыпятся" диски - "валятся" тесты

Все мы привыкли к провалам автотестов из-за ошибок в тестируемом коде, в самих тестах , в конфигурации и т.д.
Но иногда случаются действительно редкие вещи. Как, например, сегодня в моей практике.
На одном из серверов автоматического тестирования часть тестов провалилась без видимых на то причин. Изменений, способных привести к провалам, не было ни в коде, ни в самих тестах , ни в тестовом окружении. Тесты имели длинную историю успешного прохождения - скучно даже было. И вот провалились.
После поверхностного анализа стало ясно, что не были созданы все тестовые данные - Oracle ругнулся так, что я никогда такого раньше не видел ) А точнее - не смог добавить extent в один из TABLESPACE-ов.
Смотрю в субд - инстанс в RO-режиме.
При попытке перезапустить бд получаю ошибку:

ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u02/oradata/index01.dbf'

Пробую рекавери файла данных не помогает - из ругани Oracle становится ясно, что файловая система, где располагается том для файлов данных, находится также в RO-режиме. Сервер никто не трогал. Свет не отрубали (uptime сервака 52 дня). Лезу в /var/log/messages и вижу, что возникла проблема с ФС из-за проблемных блоков харда и ядро само перемонтировало раздел в RO-режиме. Теперь все встало на свои места. Далее лечение последствий в виде последовательных вызовов: umount, fsck, mount Ну и перезапуск oracle. В общем, мораль , железо тоже не выдерживает иногда :)

"Везет" мне на IE в последнее время..

Буквально за пару последних дней дважды наткнулся на сообщения типа "Ваш броузер не поддерживается. Используйте IE..". Причем в приложениях довольно нужных: одно - важный интранет-портал (сделан на asp), другое - банковская веб-ориентированная система (написанная на jsp).
Если в случае ASP-шного портала запуск IE действительно помог, то банкиры удивили не на шутку.. Дословно "Ошибка: работа возможна только в IE5 и выше".
Хорошо, думаю, будет вам IE. Windows 7, думаю, IE 9. Хватит? Запускаю. Вижу "Ошибка: работа возможна только в IE5 и выше" Не смешно. На этот раз я выступал в роли не тестировщика, а обычного пользователя. Мне нужен был этот софт!)
Вот так вот. В обоих случаях, наверняка, разработка стоила кучу денег. Живо представляю себе пункт в требованиях к программно-аппаратному "Допускается работа только в IE5 и выше")) Толстые дяди с умным видом месяц согласовывали, потом подписывали, потом денежки перечисляли, потом в конверте часть назад приносили... А на дворе 21 век, а сайт работает только в IE5 , и не никак выше )))
p.s. вот найду на досуге ie5 иль эмулятор и затестирую изделие до... )

Офтопы на software-testing

Хорошо, когда твой профессиональный блог транслируется на такой посещаемый и авторитетный ресурс как, например, software-testing. Ты пишешь, делишься мыслями, рецептами - люди практически сразу это видят и могут дать отзыв о твоей записи, дельный совет и т.д.

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

В общем к чему это я..  Хорошо бы иметь механизм автора влиять на то , будет ли данная конкретная статья опубликована или нет. Сейчас я имею в виду конкретно трансляцию  на software-testing ... Думаю, можно сравнительно легко решить такую задачу. Например, автор добавляет некий код <!--DONTTRANSLATE--> в тело материала, если не хочет данной статьей флудить в ленте, а разрабочики сайта , немного "допиливают" свой транслятор, небольшим парсингом поступающего материала... Если знать точно, как именно происходит трансляция на S-T , то было бы легче "предлагать" и "советовать" и даже "приложить патч", но пока идея лишь в такой форме..

Если кто знает о "велосипеде" , который уже изобретен - буду рад совету )