Сказка о профессионализме... )

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

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

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

— Конечно, — говорит Недозайцев. Он директор, и всегда готов взвалить на себя проблему, которую придется нести кому-то из коллектива. Впрочем, он тут же уточняет: — Мы же это можем?

Начальник отдела рисования Сидоряхин торопливо кивает:

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

— Очень приятно, — говорит Морковьева. — Ну, меня вы все знаете. А это — Леночка, она специалист по дизайну в нашей организации.

Леночка покрывается краской и смущенно улыбается. Она недавно закончила экономический, и к дизайну имеет такое же отношение, как утконос к проектированию дирижаблей...........ЧИТАТЬ ДАЛЕЕ

Как говорится , сказка - ложь, да в ней намек... )

Новый сотрудник

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

1. Неточности во всевозможных HOWTO для новых сотрудников. Как правило не всегда хватает времени , чтобы держать подобные мануалы в полностью актуальном состоянии - поэтому при работе нового тестировщика с этими документами появляется неплохой шанс привести инструкции в соответствие реальному положению дел. В данном вопросе можно пойти на дополнительную хитрость: обеспечить новичка документом, заведомо содержащим изъян и понаблюдать за тем, как человек будет решать возникшую проблему, заметит ли он ее вообще? Немного по-иезуитски, но это позволяет лишний раз убедиться в правильности решения после собеседования.
2. Порция некритичных ошибок в тестируемом ПО Незашоренность взгляда,а также отсутствие груза важной и срочной работы у нового сотрудника позволяет ему замечать множество мелких ошибок и недочетов в тестируемом ПО. Как правило это незначительные ошибки в GUI, ошибки эргономики , пропущенные более опытными коллегами, а также порция замечаний и предложений по улучшению. Многое из всего, что "замечает" новый тестировщик в итоге не приводит к изменениям и улучшениям, но какой-то процент действительно полезных замечаний обеспечен в любом случае.
3. Ошибки в документации к ПО Не знаю как у других, но в число обязанностей моей команды входит и тестирование пользовательской документации к ПО. В силу разных причин пользовательская документация неизбежно начинает накапливать неточности, несоответствия с реальным поведением системы. И новый тестировщик, априори внимательно относясь к пользовательской документации (ведь зачастую именно по ней он знакомится с системой ), неизбежно натыкается на эти несоответствия , а также на отсутствие необходимых ему сведений. Это позволяет повысить качество этой самой документации.
4. Повторение - мать учения. Во время помощи новому коллеге часто приходится вспоминать некоторые аспекты функционирования тестируемого софта, пояснять и уточнять последовательности настройки, развертывания тестовых стендов и т.д. и т.п. - все это может показаться скучным, но иногда это позволяет вспоминать уже подзабытые ньюансы, освежая и закрепляя таким образом собственное знание системы.
5. Новые техники. Новый сотрудник, особенно опытный, может привнести с собой новые техники тестирования. Например, когда-то давно пришел к нам тестировщик, хорошо знакомый с техниками пентеста. Его знания и умения пошли на пользу и успешно дополнили уже имевшиеся на тот момент наборы тестов безопасности системы. Сотрудник уже давно перешел в другую компанию, но его опыт продолжает приносить нам пользу.

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

Требования: по ту сторону баррикад

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

"ПРИНЦИПЫ РАБОТЫ С ТРЕБОВАНИЯМИ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ" (Дин Леффингуэлл, Дон Уидриг)

Книга написана в 2002 году и за это время условия рынка разработки ПО ужесточились, но многие принципы работы с требованиями по-прежнему остаются актуальными. Например, описанные техники выявления всех явных и скрытых пожеланий заказчика ( о которых он и сам с трудом пока еще догадывается ) , считаю, могут действительно помочь сэкономить кучу сил и времени.

lsof+gdb - надежные помощники при "трудном" моделировании

Совсем недавно в ходе попыток моделирования очередного "мигающего" и трудновоспроизводимого бага потребовалось запустить очень продолжительную серию испытаний , в ходе которой требовалось эмулировать частую потерю соединения приложения с СУБД. Эмуляция активности приложения , естественно, автоматизирована. Продолжительность теста - минимум 30 минут, максимум - 2-3 часа. В общем, понятно, что вручную "дергать" витую пару - не вариант =) Первое, что пришло в голову использовать файер (iptables). Попробовали - и по ряду причин (здесь их не описываю) вынуждены были отказаться от этого способа.

Встала задача "узнать дескрипторы соединений с СУБД нужного процесса" и "извне процесса эти по этим самым дескрипторам закрыть соответствующие соединения".
На помощь пришел всесильный отладчик gdb, который умеет работать в так называемом "batch"-режиме.

С помощью lsof узнаем дескрипторы соединений (у ислледуемого нами их могло быть несколько), а с помощью gdb в "batch"-режиме закрываем сокеты по их дескрипторам.


#генерируем файл с командами на закрытие нужных нам дескрипторов (в данном случае дескрипторы соединения с СУБД висящей на фиксированном порту 1521)

lsof -p 5239 | grep ':1521' | awk '{print $4}' | sed 's/u//' | awk '{print "call shutdown("$1",2)"}' > commands

#скармливаем пакет команд gdb

gdb -p 5239 -batch -x commands



Указанные команды помещаем в цикл с произвольными задержками между итерациями и в результате приложение начинает работать в условиях периодичеких "проблем с сетью и соединением с СУБД".

Все это под linux, все это бесплатно , быстро и эффективно.

Возможно, кто-то спросит "Как сделать аналогичное под Windows?" - сразу не отвечу, но на досуге ничего не мешает выяснить, если это действительно кому-то понадобится =)

Небольшой совет покупающим e-book

Тем, кто надумал приобрести электронную книгу позволю себе дать небольшой совет.
Собираясь в магазин, прихватите с собой SD-карту, на которую предварительно запишите экземпляры книг/журналов в нужных вам электронных форматах. Особенно стоит уделить вниманиe "отсканированным" pdf и djvu - как правило именно с масштабированием таких книг могут возникать проблемы у девайсов для чтения с E-ink технологией.
С такой SD-картой вам не придется верить на слово продавцу о том, что то или иное устройство "отлично справится с любым форматом" - вы просто проверите это сами. Заодно "ПРОТЕСТИРУЕТЕ" usability устройства и гарантированно сможете подобрать то, что вам нужно с первого раза.
В общем, этот совет родился не на пустом месте - сам совсем недавно помучился с обменами и возвратами, не слишком въедливо исследовав первоначально купленный девайс.
Берегите свое время ;)

Повышаем стабильность запуска SeleniumRC по крону

В одном из предыдущих постов я описывал вариант использования SeleniumRC на Linux-машине с использованием cron и виртуального X-сервера Xvfb.

Некоторое время эта связка работала исправно. crond - обеспечивал то, что RC всегда запущен, сам RC прилежно "гонял" тесты. Но время от времени случались непонятные массовые провалы автотестов со следующими записями в STDERR:


10:23:50.037 INFO - Preparing Firefox profile...
Error: cannot open display: :1
10:24:16.152 ERROR - Failed to start new browser session, shutdown browser and clear all session data
java.lang.RuntimeException: Timed out waiting for profile to be created!
at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.waitForFullProfileToBeCreated(FirefoxChromeLauncher.java:348)
....


После некоторого времени "копания" выяснил (по информации от syslog-а), что в Xvfb периодически случался SIGFAULT (причина пока не ясна и требует отдельного времени на анализ). Ну случался и случался - никто не мешает также по крону запускать и сам Xvfb. Да, только есть ньюанс. Эта утилита, как принято у *nix-демонов, при запуске создает лок-файл со своим pid-ом. Делается это для предотвращения попытки запуска нескольких виртуальных серверов на одном и том же виртуальном дисплее.

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

Рассуждая дальше, как говорится "нечего на зеркало пинять.." , ведь я при периодическом запуске Xvfb и RC не позаботился (подобно разработчикам самогО Xvfb) о проверке того, запустился ли виртуальный менеджер окон или нет , поэтому и получал запущенный SeleniumRC, не имеющий в своем распоряжении виртуального дисплея , где бы он мог корректно запустить Firefox. В итоге, простая проверка и принудительная чистка ненужных уже lock-ов позволили "закрыть" глаза на возможные ошибки в стороннем ПО, получая стабильный результат тестирования собственного.

"Мораль сей басни такова": если указываешь другим на их ошибки, старайся сам не допускать аналогичных =)