Лидерство и управление командой

Интро: В этой статье делается попытка описать основные качества тим-лидера как в общем, так и в контексте тестирования ПО.

Прежде всего, попробуем определиться, кто такой тим-лидер.

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

Итак, поставим несколько вопросов:

Какими качествами должен обладать тимлидер ?
Каковы его обязанности и зона ответственности?
Каких ошибок следует избегать тим лидеру?
Легко ли быть лидером в команде?

Качества

1. Отличные профессиональные навыки (но не обязательно лучшие в команде): нужны для того, чтобы обосновано принимать или отвергать аргументы и предложения других "игроков" команды.
2. Известная доля смелости: для того чтобы не бояться принимать решения и нести личную ответственность за эти самые решения.
3. Дипломатичность: для того чтобы успешно разрешать возникающие конфликты и всякого рода противоречия. Без этого качества также не обойтись в ситуации, когда тим лиду надо указать человеку на недостатки в его работе.
4. Навыки психолога: для того , чтобы понимать мотивы тех или иных поступков и действий людей.
5. Чувство юмора: хорошая шутка зачастую вернейший способ разрядить напряженную обстановку и снять напряжение в коллективе.
6. Самоанализ: для того, чтобы вовремя заметить, что причина той или иной проблемы команды не в том или ином ее "игроке" , а в самом тим лиде.
7. Оптимизм: без этой черты тим лиду будет очень трудно воодушевлять людей на достижение целей.
8. Аналитик: для того, чтобы адекватно оценивать сроки, риски , возможные проблемы и запасные варианты на случай их возникновения
9. Опыт: тим лидером вряд ли может стать человек без богатого опыта в сфере деятельности команды.

Обязанности и сфера ответственности
1. Принимать непосредственное участие в процессе формирования команды
2. Делать общие цели понятными каждому члену команды
3. Делать все возможное для поддержания общего уровня мотивации и увлеченности общей целью на уровне , позволяющем решать задачи максимально эффективно
4. Выбор наиболее подходящего для данной конкретной задачи исполнителя
5. Обеспечивать обмен опытом и знаниями между членами команды, повышение степени взаимозаменяемости людей.
6. Поддержание дружеской и конструктивной атмосферы в коллективе.
7. Проведение внутрикомандных совещаний
8. Учет инициатив и предложений исходящих от членов команды. Поддержка полезных и беззастенчивая фильтрация вредных и бесполезных.
9. Предоставление "наверх" информации о состоянии дел в коллективе, сроках задач, степени завершения, имеющихся проблемах, которые невозможно решить только силами команды.

Несколько советов
1. "Хочешь, чтобы было сделано хорошо? -Сделай сам!" Доверие (с проверкой =) и делегирование гораздо лучше изнуряющих попыток сделать все самому.
2. "Начальник полютует и забудет" . Принимая то или иное решение необходимо сразу думать о том, как именно будет контролироваться его выполнение.
3. Не просите людей делать то, за что сами никогда бы не взялись.
4. Вы - лидер, не потому что вы сами о себе так думаете, а потому, что вам доверяют.

"Фобосом" навеянное

ВЕРОЯТНАЯ ПРИЧИНА ПАДЕНИЯ аппарата "фобос-грунт" - ошибка в программировании. Версия с "происками Запада" , похоже, не состоятельна.
Многие, вцепившись , в версию "ошибка разработчиков" уже начали костерить деградацию образования, пресловутое снижение качества знаний выпускников, тут же пробежались по ЕГЭ, отдавая дань моде.. Да, деградация.. Да, снижение... Да, ЕГЭ, будь он неладен...
Но вот вспомнилась мне почему-то одна лекция по "Численным методам" в институте.. читал ее профессор Михайлов - человек с богатейшим опытом решения задач прикладной математики. Он поведал нам о подобном случае, который случился еще в СССР , когда был утерян очень дорогой спутник из-за ошибки программистов... Насколько я помню, тогда речь шла всего лишь о проблеме округления и накопления погрешности. В общем, из-за ошибки в вычислениях спутник улетел совсем не туда, куда планировалось и миллионы народных рублей сейчас возможно еще летают где-то в солнечной системе ).. Тогда не было ЕГЭ, не было "деградации" и "снижения" - все было, судя по всему, наоборот, но подобные ошибки случались и времена, которыми принято гордиться...

Internet Explorer на страже стандартов =)

Броузер Internet Explorer хорошо известен тем, что старается уж очень четко следовать стандартам, разработанным ответственными комитетами типа W3C
Там, где остальные броузеры закрывают глаза на некоторые опечатки, небольшие огрехи вебмастеров, IE каленым железом выжигает всякую "крамолу" )) Вот несколько граблей, на которые пришлось наступить в последнее время:
1. <!DOCTYPE
Сегодня довольно долго бился над выяснением того, почему на одном из сайтов "слетает" верстка в IE , которая идеально выглядит в Chrome, Opera, Firefox.
Перелопатил все стили, исправил пару незначительных кроссброузерных различий, но в целом IE продолжал показывать мне совсем не то ,что остальные броузеры.
Причина оказалась банальна - в первой строке html-ответа не было директивы <!DOCTYPE ...>, после его добавления в базовый html-шаблон все сразу стало выглядеть так, как требовалось (с небольшими допустимыми для IE отличиями типа отсутствия теней у некоторых элементов).
Вот что пишет w3c об этой преамбуле: W3C-HTML5#DOCTYPE

2. js-движок и синтаксис записи словарей в js
Довольно много приходилось писать на perl и в последнее время на python. При записи структур типа:

my $dict = {
      'key1': 1,
      'key2': 2,
   }

давно выработалась привычка всегда ставить запятую после очередной записи в хеше, даже если она последняя - это позволяет избегать синтаксических ошибок при возможном будущем добавлении новых записей в этот словарь. Эта привычка меня недавно подвела при написании js-кода, содержащего в большом количестве структуры, подобные описанной выше.
Отладка кода проводилась в Chrome и Mozilla. Когда начал проверять работу в IE ошалел от кучи js-ошибок (при возникновении ошибок компилляции js - IE просто перестает рендерить страницу). Пришлось перелопатить все js исходники и повычищать последние запятые, которые оказались несоответствующими синтаксису описания словарей, к которому я так привык.
Теперь взял за правил ставить запятые ПЕРЕД элементами словаря ))

3. подчеркивания в именах хостов
На эти грабли наступал уже давно и , может быть, даже описывал на страницах этого блога. Но недавно, когда коллега начал в ярости постукивать по клавиатуре, я поинтересовался в чем у него проблема , понял, что он наступил на то же самое (спросил бы раньше))))
Пример: есть тестовый стенд одного веб-проекта. Тестируется в основном под Chrome, Mozilla. Начали проверять под IE. Полезли глюки в виде странной работы с куками. После ряда возгласов "мистика" стало ясным, что виноваты символы подчеркивания в имени тестового хоста, которые оказалиcь "не по стандарту".

4. зацикливание при редиректе из-за некорректного http-euiv
Вот такой вот код:

<meta http-equiv="Refresh" content="1; /" />

отлично понимается Chrome и Firefox - в результате выполняется редирект на главную страницу сайта.
В IE (например в 8.0) делается редирект на ту же самую страницу. В результате - ежесекундные бесконечные редиректы.
Чтобы сделать понятным для всех броузеров ,опять же обратимся к стандарту W3C-HTML5#PRAGMAS



Это далеко не полный список того, чему IE предельно жестко учит)) Буду пополнять эту коллекцию

Oracle: небольшая помощь для отладки и тестирования

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

То, насколько легко решить данную задачу , зависит от архитектуры конкретного приложения и среды его выполнения.

Каждый ухищряется по-своему : самодельные заглушки, перевод системного времени и т.д. и т.п..

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

Вот как заставить sysdate возвращать фиксированную дату:

ALTER SYSTEM SET fixed_date = '2011-12-31 23:59:59';

А вот так все можно "вернуть вернуть на место":

ALTER SYSTEM SET fixed_date=NONE

Плюсы:

1. легко включается и отключается
2. не влияет на системное время ОС

Минусы:

Условный минус по сути вижу один - это особенность, на которую не все сразу обращают внимание:
Данный трюк работает на уровне "системы" , а не "сессии" и меняет поведение sysdate для всего инстанса. Соответственно, необходимо не забывать "возвращать на место" и вообще отдавать себе в этом отчет, если это инстанс может одновременно использоваться несколькими пользователями.

Драйвер сидирома в интернете, драйвер модема на болванке (с)

Попалась на тестирование программка. Читаю , значит требования. Абстрактно если, то озвучить их можно так:

Требование 1: найти объект по номеру одного из его дочерних объектов и вернуть код ошибки 1, если дочерний объект с указанным номером не найден

Требование 2: если у найденного объекта список дочерних объектов пуст, то вернуть код ошибки 2

И ведь считается, что разработчик все закончил , система ДОЛЖНА соответствовать требованиям и остались "только баги" (вероятные) :)

Вот такие вот "дедлоки" )

Эти страшные системные ограничения )

Несколько месяцев назад натолкнулся на один очень странный баг в linux-приложении, которое активно использует unix-сокеты для общения своих дрочерних процессов. На одной из инсталляций приложение работало очень странно: запускалось , фурычило, но отказывалось останавливаться , а после принудительной остановки, отказывалось повторно запускаться. После продолжительных копаний со словами "мистика!" выяснилась причина была найдена - приложение было установлено по слишком длинному пути и unix-сокеты (читай файлы) создавались тут же (по их полному пути в системе ) . По их обрезанным именам стало ясно, что уперлись в какой-то системный лимит. Это было странно, потому что помилось, что полное имя файла может быть более 4кб. В данном случае уперлись в странную цифру 108 - не степень двойки, не круглая - вообще черт знает что.
В общем, оказалось это длина буфера одного из поля структуры sockaddr_un, расширить которое нельзя. "Нельзя так нельзя" - подумали мы и больше длинных путей ко временным файлам приложения не создавали и заказчикам деплоили с учетом этой "системой" проблемы. Думать о том, как бы это пофиксить времени тогда не было, раз был неплохой воркэраунд.
Ну вот пару дней назад, когда описанная выше проблема почти стерлась из памяти опять на это напоролись на одной из автоматически создаваемых тестовых инсталляций. В этот раз матчасть перечитали повнимательнее и в код заглянули более въедливо ... в результате поняли , что никакого такого "системного" ограничения на самом деле нет (не считая 4кб на полный путь к файлу), ведь можно указывать относительное имя к файлу unix-сокета, вместо полного) Ну 108 байт на относительное имя хватит на китай..
Смотрели друг на друга с разработчиком и посмеялись сами над собой - "Эх, Семен семеныч!", как говорится))

Забавный секурити баг на досуге

Принимал я тут как-то на досуге участие в тестировании одного веб-проекта.
Функциональное тестирование. Работа с системой требует авторизации, капчи на каждом шагу, сесии и все такое.
В одном из сценариев пользователи аттачат файлы. По логике бизнес-процесса , скорее всего это будут в том числе и приватные документы. При аплоаде много чего проверяется, в том числе и допустимый размер аттача как на клиентской стороне , так и на сервере.
В общем , " как учили ". На залитый аттач пользователь потом может всегда найти ссылку для скачивания. Ссылка располагается в private-части. Вроде все вроде бы ок, если бы не тот факт, что в ссылке есть параметр file_id, который меня и заинтересовал.
Путем перебора от 1 до "пока не надоест" мне удалось вытянуть все аттачи, которые были зарегистрированы в БД всеми пользователями этого проекта.. К счастью заказчика тестирования - пока еще тестовыми пользователями. полный приват, в общем :) О баге, конечно же доложено.
Название проекта, конечно же , не сообщаю :)

"А король то голый.." (с) :)

p.s. Надо будет антивирусом проверить все выкачанное, а то как бы на радостях самого себя не протроянить через какой-нибудь "документ"...:D
Всем удачи и побольше любопытства - без него в нашем деле никуда )

Автотесты: почему важно "не делать лишних движений"

Несколько слов о дизайне автоматических тестов.
Точнее о вопросе избыточности проверок. Существует подход к разработке модульных (Unit) автоматических тестов, который можно описать так "Проверяем одно условие за один тест" (Verify one condition per test). Применение такой стратегии дает множество плюсов: при провале тестов можно максимально быстро выявить узкое место, и, как следствие, максимально быстро устранить проблему. Пусть тестов станет больше, но плюсы, как правило перевешивают.
При автоматизации более громоздких регрессионных функциональных тестов подобная стратегия также применима. Только в роли единицы проверки должны выступать уже не "условия" , а конкретный вариант поведения. При этом, все что лишнее, и не влияющее на данный конкретный вариант поведения должно быть безжалостно ампутировано. Лишними могут быть: некоторые инициализирующие параметры объектов, а также проверки , которые уже делались или будут делаться в тестах, специально для этого предназначенных. В общем, не надо делать лишних движений, у которых нет конкретных целей.
Вот пример из реальной практике, иллюстрирующий вышесказанное:

1. есть автоматический функциональный тест, проверяющий некий вариант поведения системы
2. в ходе его инициализации создается объект "клиент", у которого есть как обязательные так и необязательные параметры, причем данному тесту ни один из них не важен - важен факт наличия объекта "клиент" и все..
3. тестировщик, который создавал тест, то ли копипастом, то ли для разнообразия решил заполнить поле email , причем указал там строку с емейлом "не по RFC" (на момент написания теста проверке необязательного email внимания не уделялось)
4. тест долгое время работал, проверял нужные варианты, давал результат
5. в какой-то момент проверке полей данного объекта уделили внимание, и ужесточили ее, создав соответствующие автотесты на эту новую "функциональность"
6. старый же тест начал проваливаться, причем, не доходя до своей целевой проверки - проваливаться на этапе инициализации. Причина, думаю, ясна - строка "отбалды" в поле email.

Тест пришлось править, тратить время. Пусть не много времени ушло данный конкретный тест, но в принципе - это лишняя трата времени, лишнее отвлечение внимания на провал теста. Причина - "лишние движения" и никому ненужная "кучерявость" теста. Всему свое место - фантазии и творчеству, в том числе :)

Вывод: чуть больше осознанности может сэкономить чуть больше времени для чуть более полезных вещей :)

Анализ покрытия кода с помощью gcov+lcov

Сегодня наконец-то выделил время на то, чтобы наладить анализ покрытия кода. Пока только покрытие операторов и функций.
Тестируемое приложение написано на Си, ОС linux. Компиллятор gcc. Приложение должно быть собрано с флагами компиллятора : -ftest-coverage -fprofile-arcs.
Для анализа покрытия использовалась утилита gcov, которая помогает провести анализ того, какие строчки кода и сколько раз были задействованы в ходе выполнения приложения.
В результате выполнения приложения генерируются специальные файлы для каждого файла исходников , в которых и содержится собранная информация о покрытии. Дальше с помощью утилиты lcov полученные данные обрабатываются и генерируется , цветастый и веселый html-отчет . Я , как преимущественно визуалист, особенно был рад получившейся наглядности :) Даже в первом приближении мне стало понятно, что в плане автоматизации будут некоторые изменения :)
Упомянутые утилиты бесплатны, присутствуют в репозиториях всех популярных дистрибутивов linux, а также могут быть скачаны с sourceforge, например.
Итак, метод опробовал. Планирую проводить отдельный анализ покрытия для сеансов unit-тестирования и отдельно для сеансов автоматического регрессионного тестирования.
В более отдаленной перспективе постараюсь также наладить анализ покрытия путей выполнения и условий, а также освоить gcov в связке с gprof, для профилирования приложения.

Тем, кто планирует внедрять подобные практики позволю сразу дать совет. Использование тех или иных инструментов для генерации статистики покрытия влияет на скорость работы приложения, поэтому для анализа покрытия необходимо запускать сеансы отдельные от сеансов регрессионного автоматического тестирования.
p.s.

лучше 1 раз увидеть, чем 100 раз предположить :)

UPD 05/10/2011
При анализе результатов ночного прогона обнаружил небольшой бонус - gcov умеет и условия анализировать (см. пример на картинке вверху статьи ) . Приятная неожиданность :)

Стандарты именования объектов БД

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

По своему личному опыту могу точно утверждать, что единообразие наименований объектов в БД очень часто существенно экономит время . Преимущественно речь идет о времени на написание SQL-запросов особенно, когда приходится их писать сотнями в день и когда имеешь дело с большой разветвленной БД, где десятки а иногда и сотни таблиц. В этом случае все названия запомнить , конечно же , нереально, но если ты заранее знаешь , что имеешь дело со словарной таблицей и у нее обязательно есть mnemonic , и description, то это существенно облегчает жизнь. Если же проектировщики и разработчики задумывали и создавали БД "кто в лес, кто по дрова", то ты заранее не знаешь, description там или же desc, а может descr или вообще поле с опечаткой.. В итоге запрос с первого раза не пишется, надо смотреть описание таблицы - в общем, делать лишние движения. Они небольшие, но их много и вообще , как в песне поется, "не думай о секундах свысока"...
С экономией времени на составлении запросов вроде бы все ясно, потому что явно. Есть и другие менее явные положительные эффекты от единой стратегии именования.
Буквально на днях сталкивался с конкретной задачей автоматизации, которая решалась бы гораздо меньшими усилиями и существенно меньшим количеством строк кода, если бы не винегрет в названии одинаковых по смыслу полей в разных таблицах. То есть и в направлении автоматизации тестирования возможна экономия сил , нервов и средств при минимально едином подходе.
Еще один положительный эффект - новички ( и разработчики , и тестировщики ) гораздо быстрее осваивают систему, если при ее проектировании и разработке применяются единые правила наименований объектов. Быстрее осваивают - читай, быстрее начинают приносить реальную пользу.

В общем, везет тем , кто везет. А что делать если приходится работать с тем, что есть? Если , к примеру, схема БД росла и множилась годами, накопила кучу болячек, пережила не одну текучку кадров и к стандартизации нотации объектов в этой БД относились "с прохладцей"? Конечно же, не надо посыпать себе и тем более другим голову пеплом , не надо искать виноватых и жаловаться всем на всех.. Просто старайтесь конструктивно доводить до ответственных лиц необходимость рефакторинга схемы БД , если такого осознания у них нет. Если же это осознание уже есть, то готовьте тесты , проверяющие, что в результате рефакторинга система дает конечному пользователю как минимум то же самое, что и до него ))

Полезная информация по теме:
[1] Форумы на sql.ru - искать по "правила именования объектов базы данных" - тут знающий народ, решающий реальные задачи. Много хороших и дельных советов и практик.
[2] Хорошая книга как раз о рефакторинге уже существующей БД: Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series)
Scott W. Ambler, Pramodkumar J. Sadalage