понедельник, 17 января 2011 г.

О тестировании документации

Documentation is like sex: when it is good, 
it is very, very good; and when it is bad, 
it is better than nothing.
Dick Brandon

Когда заходит речь о тестировании, обычно обсуждается тестирование приложения в том или ином виде. Функциональное тестирование, тестирование безопасности, нагрузочное тестирование, тестирование требований - все это относится к приложению. Это действительно важные аспекты поведения продукта, и количество уделяемого им внимания вполне обосновано. Тестирование документации, поставляемой вместе с приложением (неважно, каким именно способом - в виде книжки, PDF файла или базы знаний на сайте), нередко проводится по остаточному принципу. С одной стороны этот подход делает актуальной фразу вынесенную в эпиграф. С другой - соображения, высказанные в этой фразе могут стать причиной, почему документация так плоха.

Отбросим случай, когда документация не тестируется вообще никогда и никем. Это крайний и маловероятный вариант, к тому же обсуждать тут особо нечего. Как мы тестируем документацию, если уж до этого дошли руки? 

Обычно документация не обновляется вся целиком. Появляются новые возможности в продукте, их описание добавляют в документацию, а потом назначенный человек (или несколько) проверяет, что "все в порядке". Это неплохой вариант, когда проверку выполняет опытный человек, хорошо знакомый с продуктом и прочим контекстом (предметной областью; языком, на котором написана документация; целевой аудиторией и так далее). Проблема в том, что часто нет никаких формальных подходов к выполнению таких проверок. Человек читает документацию, по сути - проверяя, не зацепится ли взгляд за что-то странное. Зацепился - хорошо: обсудил с окружающими, открыл баг. Не зацепился - никаких гарантий, что проблем действительно нет. 

четверг, 13 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 5. Оценка тестирования.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 5): Test Estimation


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

Давайте действовать как тестировщики – будем задавать вопросы.

Существует ли вообще такая штука, как проект тестирования? В частности, может ли проект тестирования существовать независимо от проекта разработки?

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

среда, 12 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 4.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 4)


В нескольких последних статьях исследовательская автоматизация подсказала некоторые интересные идеи насчет динамики проектов и их оценки. Какую пользу можно извлечь из этих математических экспериментов?

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

Похоже, математика поддерживает идеи, расхваливаемые энтузиастами Agile, гуманистами и мыслителями: получайте обратную связь быстро и часто. Глядя на последнюю модель - меньше задач и более короткие проекты - мы можем предположить, что чем короче и управляемей проект, тем меньше шансов у Черного Лебедя нанести вред любому отдельно взятому проекту.

вторник, 11 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 3.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 3)


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

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности

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

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

понедельник, 10 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 2.

Вольный перевод статьи Майкла Болтона  Project Estimation and Black Swans (Part 2)


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

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

воскресенье, 9 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 1.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 1)  


В последние месяцы в сети активно обсуждалось оценивание:
Все это сподвигло меня опубликовать результаты некоторых численных экспериментов, начатых в ноябре 2009-го и основанных на мысленном эксперименте, придуманном Джеймсом Бахом (James Bach). Эта работа совпадает по времени с Лебединой Песней, колонкой для Better Software, в которой я обсуждал книгу Талеба (Nassim Nicholas Taleb) "Черный Лебедь".

Черный Лебедь - невероятное и неожиданное событие, меняющее наше представление о реальности и обладающее тремя качествами. 

вторник, 21 декабря 2010 г.

Правильный багрепорт 2: точность описания и исследование проблем

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

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

четверг, 16 декабря 2010 г.

Авралы как производная от качества планирования

Долгое время я считал авралы/переработки делом обычным - как в IT без этого? Но со временем я стал задумываться и понял, что все не так просто. В целом, понятно, что аврал - производная от планирования. Если мы что-то хотим сделать, но не успеваем, то приходится работать дополнительно по вечерам и/или в выходные. Нюанс в том, почему сложилась такая ситуация. Я выделил для себя три причины авралов со следующими условными названиями: ошибка планирования, тенденция планирования и отсутствие планирования.

Подробнее о каждом из типов.

вторник, 14 декабря 2010 г.

Аттестация в жизни технического человека.

Во многих крупных компаниях существует, в том или ином виде, процедура периодической аттестации сотрудников. Раз в год или в полгода работу сотрудников за прошедший период оценивают по нескольким параметрам. Число и набор параметров может разниться, но сейчас не об этом. Зачастую процедура предполагает, что каждый сотрудник заполняет некую форму, помогающую произвести оценку. Проблема в том, что многие "технические" люди - программисты, тестировщики - воспринимают эту деятельность, как ненужную потерю времени и придурь начальства, которому нечем заняться. Даже зная, что на основе этого документа будут приниматься решения о карьерных и зарплатных изменениях, технари обычно не видят смысла его заполнять, и вообще тратить время на процедуру аттестации: работаем же, все в порядке, и так ясно, кто хорош, а кто нет.

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

среда, 1 декабря 2010 г.

[HDI] Увеличение своп-файла Linux без изменения разделов диска

Если вдруг потребовалось увеличить swap раздел на Linux'овой машинке, а править текущее разбиение диска на разделы не хочется, то можно поступить так:

# dd if=/dev/zero of=/var/swap bs=1M count=1048
# chmod 0 /var/swap
# mkswap /var/swap
# echo "/var/swap none swap defaults 0 0" >> /etc/fstab
# swapon -a


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

P.S. честно своровано отсюда