Я работаю в автоматизации тестирования уже более пяти лет. Более всего я работал с ОС Windows. Мы пишем скрипты на Borland SilkTest. Я знаком и с другими средами разработки автоматизированных тестов, такими как QTP и TestComplete – у каждого продукта есть свои достоинства, но, к сожалению, и свои недостатки. Возникают проблемы, которые очень сложно решить «не выходя из системы»*

     «Милая „Наталья“, я вам пишу, чего же… » Нет, не такое вступление должно быть для монолога в стиле Роберта Пирсига. Такое обращение оставим для диалога в комментариях.

Книгу Дзен и искусство ухода за мотоциклом я рекомендую всем, кому важно качество, особенно тем, кто близок к тестированию!

Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил быстро научиться вкусно готовить. Нашел книгу «Гурман за 60 минут» Пьера Фрейни, и пошел читать.

Выяснилось, что мистер Фрейни описывал не технику, а свою философию приготовления еды.

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

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

Как обычно строят процесс тестирования непросветлённые тест-менеджеры?

Они стараются протестировать всё. Они тщетно пытаются протестировать всё. В результате в баг-трекере есть ошибка о том, что программа крашится при нажатии на самую редкоиспользуемую кнопочку 286 раз. Ошибка про странный серый пиксель в нижнем правом углу программы тоже заведена. Команда трудилась в поте лица по ночам и выходным.

Релиз.

Не работает основной функционал.

Почему такое возможно?

1. Заведение всех подряд ошибок мешает разработке. Разработчики тратят своё время на исправление минорных ошибок и вносят новые, зачастую более серьёзные.

2. Потраченное на мелочи время не дало возможности проверить более серьёзные пользовательские сценарии и найти более критичные дефекты.

3. Обратная связь по статусу сборки предоставлялась разработчикам с запозданием: вместо критичных дефектов непрерывно сыпались миноры.

4. Проектный паттерн «дохлая рыба» сыграл своё дело: все участники команды прекрасно понимали, что протестировать всё нельзя, и это не могло не сказаться на качестве работы. А реалистичных целей им никто не поставил…

Что просветлённые тест-менеджеры делают по-другому?

Что они поменяют в первую очередь?

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

Начнем с пары историй.

История А.

На днях разговаривал с одним программистом. Пишет он на С++, работает в крупной компании в Чикаго; софтом, к созданию которого он причастен, активно пользуются финансовые и трейдерские компании. У нас, говорит, в продукте 600 тысяч строк кода. Начиналось все с небольшого приложения для анализа биржевой статистики, и вот за 20 лет вымахал такой монстр. Здорово, говорю. Внушает уважение. И как вы его тестируете, вашего монстра? Для этого, отвечает мне программист, есть специальный индус. Он какие-то тест кейсы выполняет, отчеты пишет. А до него этим менеджер один занимался, но тот все больше ручное тестирование делал. Новые функции проверял, например. Теперь вот индус. Хорошо, продолжаю выпытывать я, это функциональное тестирование. А производительность вы как-то тестируете? Нет, говорит, если клиенты начинают жаловаться на медленную работу, мы тогда сами ищем узкие места и сами же из исправляем. Кто разрабатывает продукт, тот его и знает лучше. Какой тестер с этим справится?

Умный человек, подумал я, а говорит глупости.

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

Но экономия времени при написании — это ещё не всё. Едва ли не более важным фактором является то, что в многословных описаниях теряется смысл, который туда пытался заложить тест-дизайнер. Поэтому опытному тестировщику работать с короткими описаниями проще, чем с подробными длинными сценариями. И сегодня я хочу представить вашему вниманию перевод небольшой заметки Роба Лэмберта (Rob Lambert), в которой он описывает эксперимент объясняющий этот феномен.

Less Is More, или Меньше слов — больше смысла.

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

В письменной речи это означает удаление слов, предложений или даже целых кусков текста, которые, как вам кажется, или как вы знаете, будут проигнорированы. Конечно, здесь много субъективности. Я тоже не знаю наверняка, что можно выбросить, а что следует оставить, но тем не менее, подвергаю свои тексты жёсткому саморедактированию.

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

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

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

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

Все более-менее сложные программные системы содержат ошибки (если и не собственные, то наведённые используемыми библиотеками или по причине неточного осознания поведенческих парадигм используемых фреймворков).
Часто, для тестирования системы на этапе разработки используются Unit-тесты.

Так программист может контролировать поведение системы на контрольных точках и пограничных значениях.
Часто именно неверная отработка пограничных значений приводит к проблемам. И опытные программисты это знают и учитывают при проектировании Unit-тестов.

Удобство Unit-тестов ещё и в том, что изменяя код вы ожидаете получить предсказуемые результаты и провести полностью автоматическое тестирование по имеющимся сценариям, чтобы быстро выявить наведённые изменениями неприятности.

Например, вы пишите код для работы на Intel и PPC, разрабатываете его на Intel, но учитываете порядок байтов. Потом прогоняете свои Unit-тесты, чтобы сравнить выходные данные с эталоном и обнаруживаете расхождения — понятно, где-то забыли байты перевернуть — исправляете — всё в порядке.

Однако, любой пользователь всегда несёт в себе элемент случайности.

Опытный программист сочетает в себе талант качественного тестировщика и может отловить много ошибок до выхода программы в свет.

Если программа делает больше чем печать «Hello World!», то скрытые ошибки в любом случае остаются.
Это могут быть ошибки и в логике в том числе.

Программа компилируется, все Warning'и устранены… но иногда что-то идёт не так… у пользователя (который живёт далеко в домике на островке в тихом океане — приехать к нему и пощупать нет возможности). Программист прокликал и протестировал со своей стороны всё что мог, но ошибки не нашёл. Что же делать?

Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО 'as is'. Возникает путаница.

Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.

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

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

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

Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

Первой праведной мыслью было: тестирование обидели!

На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?

Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.

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

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

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

Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий — степень изолированности кода). Тестирование бывает:

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

Классификация хорошая и понятная. Однако на практике выясняется, что у каждого вида тестирования есть свои особенности. И если их не учитывать, тестирование станивится обременительным и им не занимаются в должной мере. Здесь я собрал подходы к реальному применению различных видов тестирования. А поскольку я пишу на .NET, ссылки будут на соответствующие библиотеки.

На прошедшей в апреле этого года в Санкт-Петербурге конференции SQA Days 2009 состоялись два круглых стола.

Темой первого круглого стола было «Использование инструментов тестирования с открытым кодом». В качестве экспертов участвовали: Анна Лукашик, Виталий Помазёнков, Александр Ихелис и Алексей Баранцев, а также Александр Орлов в качестве модератора. Обсуждались возможные выгоды, которые можно извлечь из использования бесплатных инструментов, и подводные камни, которые могут встретиться на пути к «бесплатному сыру».

(Продолжительность ~2 часа)

Удивительно, что такая книга, как эта, до сих пор не была замечена на Хабре. Не могу не попытаться исправить этот недочет.
Итак, хочу представить вам книгу американского информатика Дугласа Роберта Хофштадтера «Гедель, Эшер, Бах: эта бесконечная гирлянда».

Ахилл: Вот если бы книга называлась «Гориллы, серебро, золото» или «Эму, золото…» — тогда бы я еще мог понять…
Черепаха: Может быть, вы предпочли бы «Медь, серебро, бабуины»?

Будучи написано более тридцати лет назад, это невероятное произведение ничуть не утратило своей интересности.

Нынешние телефоны умеют многое, но помните далёкие 2000 годы, когда телефоны обладали функцией PTT (Push To Talk), одной команде разработчиков из Питера пришла в голову идея перенести данную функцию на нынешние телефоны.

О третьих героях, понятное дело, все знают. Недели времени, потерянного за hotseat-ом, вызубренные характеристики юнитов, тактика застройки, развития. Еженедельные посиделки с друзьями за героями c кофе и рогаликами. Здорово, в общем было. А вот на днях захотелось повторить и сыграть по сети. Уже ж разъехались все, hotseat не прокатит. Скачали дистрибутив клинка Армагеддона, настроили hamachi, да не заладилось что-то. Пинг большой почему-то, не завелось ничего. Ну, занятые все, разбираться некогда, да и неохота. Не пошла игра.

А герои то установлены, желание играть есть. Решил кампанию пройти (к своему стыду, так ни разу не хватило терпения пройти ее в прошлом). Запустил, выбрал кампанию возрождения Эратии, нажал на эпизод «Жертвы войны». И я не знаю, интуиция, наверное, появляется какая-то за то время, пока программированием занимаешься. В общем, показали мне герои такую картинку:

И, как часто у меня случается, игра закончилась, а началась более интересное и захватывающее занятие.

Javascript Enlightenment

Cody Lindley

Уровень знаний: средний
Тщательный обзор мировоззрения JavaScript через разбор встроенных объектов и нюансов.

Открыть

Eloquent Javascript

Marijn Haverbeke

Уровень знаний: начинающий
Вводная книга по JavaScript и программирование в целом.
Открыть

Building A JavaScript Framework

Alex Young

Уровень знаний: продвинутый
Избранные статьи из цикла«Let’s Make a Framework».
Открыть

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Приветствую тебя, читатель. Последнее время, я увлекаюсь Web-безопасностью, да и в какой-то степени работа связана с этим. Т.к. я всё чаще и чаще стал замечать темы на различных форумах, с просьбой показать, как это всё работает, решил написать статью. Статья будет рассчитана на тех, кто не сталкивался с подобным, но хотел бы научиться. В сети относительно много статей на данную тематику, но для начинающих они немного сложные. Я постараюсь описать всё понятным языком и подробными примерами.