Хроники лаборатории

Переререереезд

2012-08-10T11:04:00.003+07:00

Этот блог я закрываю и переезжаю на свой собственный сайт ua9msn.ru. Потому как со своим блогом играться интереснее. Все записи отсюда, а так же из других своих давно похороненных блогов я перенесу на новый сайт.

FirePHP и FireBUG1.8

2011-08-05T11:46:00.000+07:00

Экстренный выпуск!!!

Случилось страшное. FireBUG обновился до версии 1.8! Сама по себе новость отличная, но вместе с этим перестал работать FirePHP!

Кристофа Дорна захлестнула волна возмущенных писем и вот, на сайте разработчика FirePHP, Кристофа Дорна, даны разъяснения произошедшему. Привожу их краткий вольный перевод:

Если вы недавно обновили FireBUG до версии 1.8 то вы получали предупреждение о том, что FirePHP больше не работает и предложение обновиться до DeveloperCompanion.......

Выход FirePHP1.8 принес с собой кучу изменений, которые поломали взаимодействие с FirePHP0.5. DeveloperCompanion был к этому времени практически готов и я решил не обновлять FirePHP, будучи уверенным, что пользователи установят DeveloperCompanion и продолжат использовать его как FirePHP......

Однако, далеко не всем понравилось, что у DeveloperCompanion закрытый исходный код и часть функциональности является платной. Мне казалось, что это не проблема, поскольку бесплатная часть DeveloperCompanion намного мощнее, чем FirePHP.....

Вобщем, я решил и дальше поддерживать FirePHP, однако не ждите, что в нем появится функциональность, присутствующая в FirePHP1.0 (интегрированной в DeveloperCompanion)...

Вобщем, ситуация исправлена выходом FirePHP 0.6.

Более подробно обо всем можно почитать в блоге Кристофа Дорна

Мера ответственности

2011-07-29T09:22:00.004+07:00

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

Дальше »

Разбор WYSIWYG

2011-06-29T00:44:00.006+07:00

Тестирование онлайн редакторов, как оказалось, весьма забавная штука. Хотя истины ради, тут не совсем тестирование, поскольку требовалось сделать выбор между несколькими, а не протестить какой то один. Тем не менее...

Условно можно разбить все редакторы на два типа - первые пользуются элементом textarea, вторые - свойством contenteditable. Первые генерируют код, одинаковый для всех браузеров, код же вторых - от браузера зависит достаточно сильно. Подробно на английском и перевод. Однако, одним из требований к выбираемому редактору была возможность использования в режиме inplace. То есть, редактор должен уметь сам, без посторонней помощи, конвертировать любой элемент в себя, редактировать его содержимое, сохранять на сервер, и собственно, безболезненно возвращать элемент на место уже с обновленным содержимым. Редакторы первой группы (в большинстве своем), несмотря на свои достоинства, без посторонней помощи произвольные элементы конвертировать в себя не могут. Им требуется форма, над которой они могут навесить свою функциональность. Либо придется использовать еще какой либо плагин для превращения их в inplace.
Редакторы же из второй группы, как раз напротив, не имеют особых пристрастий к определенным элементам. С их помощью (опять же, не у всех) можно редактировать любой элемент страницы. Всеми любимые и популярные TinyMCE и CKEditor относятся как раз ко второй группе, а вот GoogleDocs от редактора на базе contenteditable отказался по причине несовершенства выдаваемого HTML. Тут надо бы ссылку, но я её сам потерял, а искать лень.

Из этих соображений, а так же из невысоких требований к качеству выдаваемого HTML было решено копать в сторону contenteditable-редакторов. Поиск по просторам интернета выдал пачку простых и не очень редакторов. Мощные редакторы TinyMCE, CKEditor и elRTE были отброшены изза большого веса и излишней, в моём случае, функциональности. Как оказалось, многие из редакторов второй группы все равно требуют для встраивания элемент textarea, что было достаточно удивительно. Вторым удручающим моментом было использование ими элемента iframe для редактирования. Причины этого понятны - свойство designmode применяется ко всему документу. Но кто мешает использовать contenteditable? Третьим фактором, мешающим использованию, было жесткое встраивание работы с сервером в сам редактор. В моём случае работа с сервером не базируется на классической модели поведения - поправил-сохранил. Скажем, если требуется редактировать несколько элементов, а потом сохранить их за один раз, то встроенная функция сохранения только мешает. По вышеуказанным причинам отпали CLEEditor, Aloha.

Ряд надстроек над редакторами, позволяющими встраивать их inplace были выброшены из рассмотрения сразу. Сюда попали IPWeditor, делающий CKEditor и TinyMCE inplace-редакторами и аналогичная поделка для Xina - WIP. Надстройки над надстройками - это костыль.

Достаточно интересным показался "визуальный редактор" от Imperavi, но посмотрев его код, я все таки думаю от него отказаться. Большое количество глобальных переменных, плагины, по сути плагинами не являющиеся. Несколько сумбурный исходник заставляет думать что над проектом работали не менее двух человек с абсолютно разной квалификацией. Сыро, в общем. Но если над ним хорошенько поработать, тут есть серьёзный потенциал. Редактор невелик, функциональностью не пересыщен. Ведь не всем нужен онлайн Word.

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

Свой выбор я еще не сделал. Комментарии приветствуются.

Тест

2011-06-19T00:09:00.002+07:00

Если этот пост появится в агрегаторе на software-testing.ru, значит там есть баг.

У этого поста нет тега "тестирование", соответственно, он там появиться не должен.

Чуть о политике

2011-03-23T18:15:00.002+07:00

Телевизор нас растлевает. Мы уже начинаем терять связь реальностью. Позволю себе вот такое вот обобщение, говорю о себе, но думаю что не уникален.

Поймал себя на мысли, что болею за Каддафи. Бля, как футбол прямо. Ну ведь реально, это не игрушки! Там на людей ракеты сбрасывают, там люди УМИРАЮТ по чьей то прихоти, из за чьей то жадности! А мне как войнушка в денди, и то по телевизору было и это... Неправильно это все.

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

Стратигия, План, Методика

2011-03-23T17:25:00.003+07:00

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

Однако, тесты писать - надо. Вопрос в подробности написания. Нужно ли расписывать все до точки или достаточно названия теста? Я задаю себе этот вопрос по другому. Кто будет это читать? Если читать никто не будет, незачем и писать. Ну не придут ко мне тестиовщики из детского сада, что бы я всё дотошно и подробно расписывал. И штат в 10 раз внезапно не увеличится. Да пока я все напишу программеры успеют пять раз все поменять. То что я напишу, буду читать в первую очередь я, мои коллеги, которые и так в курсе как это проверять, и программеры, которые при нахождении бага прибегут и будут пытать "А что вы тут делали что бы оно вот так вот....?" Многие тесты сокращаются в одну строчку и из них получается чеклист.

Feature List. Еще немного о списке фич

2011-01-28T00:21:00.002+07:00

Вот как обычно происходит создание отдела тестирования? Есть “контора”, “контора - пишет”, причем в прямом смысле, пишет код. Контора маленькая, программа – маленькая, требования все три с половиной программиста знают и так, то есть не фиксируют. Заказчик один, он продукт получает, платит сколько то денег. Главный находит еще и еще клиентов, нанимает еще программистов… Коммуникации между программистами неизбежно ухудшаются, хотя бы просто в силу увеличения команды. Требования и баги от клиентов превращаются в бесконечный поток, и программисты в первую очередь пытаются избавиться от непродуктивной работы, то есть – от тестирования. И тогда на сайтах с работой появляются объявления – требуется тестировщик.

Приходит тестировщик, и начинает писать… А вот что? Часто от тестировщика требуют написать “процесс”. Или регламент. Или сразу внедрить автоматизацию. Или начать тестировать и писать тесты. Требуют отчетов и планов. Голова идет кругом, работы непочатый край, и за что не возьмись – срок непредсказуем. Начальство теребит – когда?

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

Список фич хорош тем, что он конечен. Список требований или список тестов – очень непредсказуемые по объему документы. А список фич – нет. Пишите его как вам удобно, тестлинк мне показался самым удобным из бесплатных, хотя для этого не сильно приспособлен, да и сырой он как тряпка под дождём. Я задумываюсь написать собственный инструмент для ведения списка, ибо навыки необходимые есть, и задача не кажется слишком сложной. Останавливает только то, что потом захочется туда приклеить и требования, и тесты, и баги, и прогоны по ревизиям, и построение отчетов. И получится какой то аналог какого ни будь платного продукта, причем заведомо худшего качества.

Но это я отвлекся. Программу на фичи дробить следует по своему усмотрению. Основным критерием я избирал такой показатель как тестируемость. Если я нечто могу протестировать и сказать – вот, это работает – я объявлял это фичей. Разногласий с программистами здесь как правило не возникает. Есть, например, отчеты, 20 штук. Отчеты объявляются фичей, и каждый отчет тоже объявляется фичей. В отчёте есть графическая и табличная части? Ещё две фичи. Древовидная структура становится очень удобным способом представления списка.

На сегодня всё. Пора дочку спать укладывать.

Feature List

2010-12-30T11:26:00.002+07:00

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

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

Пункто нумре два - фичи можно скучковать. Кучи фич ;) тоже можно сгруппировать при желании. Да и фича может состоять из подфич. Для каждого уровня названия придумывать замучаешься. Поэтому - просто фича. И эти фичи удобненько так складываются в дерево, не всегда правда, бывает что это граф с циклами, но не будем пока о плохом. Фича в данном случае может быть отдельным требованием, пользовательской историей, набором функций, удобством использования и даже цветовой гаммой или документацией пользователя. Важно только одно - она должна быть реализована.

Как водится - пример. Блокнот. У него есть фичи - редактирование, сохранение, чтение, сами продолжайте. У редактирования есть фичи копирование, вставка, удаление, набор текста... Сам блокнот тоже может быть фичей в каком либо приложении. Обращаю внимание, фичи, это не обязательно требования. Фича - это то чем пользователь, извините за тавтологию, пользуется. Вобщем, можно считать следующую фразу определением. Фича реализует потребность пользователя.

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

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

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

PostgreSQL VS MySQL

2010-12-09T01:04:00.001+07:00

Как то так сложилось, что большинство хостингов предоставляют связку LAMP для web, поэтому вопрос выбора базы данных для личного проекта передо мной не стоял. MySQL популярен, надёжен, удобен и ещё куча разных положительных эпитетов. Однако, с недавних пор, по роду работы, мне периодически случается работать с Postgre. И вот какие наблюдения я для себя сделал.
Postgre DML будет побогаче чем у MySQL. Это плюс. Например,

INSERT INTO table (id, name) VALUES (DEFAULT, 'qweqwe') RETURNING id;

Вставка записи сразу же возвращает ID записи. В MySQL для этого требуется вызов LAST_INSERT_ID().

Еще пример: конструкция WITH в Postgre позволяет выполнять рекурсивные запросы. То есть ветку дерева можно вытащить одним запросом. В MySQL5 такого нет, к сожалению.

Вынесенные за пределы определения таблиц последовательности в PG сильно гибче чем AUTOINCREMENT в MySQL. Они могут быть цикличные, могут быть, эм… как сказать то… непоследовательные, в смысле с шагом. Они, что самое интересное, могут быть завязаны более чем на одну таблицу. Например, если мы хотим разнести функциональные и нефункциональные требования по разным таблицам (поскольку набор полей для них разный), но хотим для них общее пространство идентификаторов, то в Postgre это решается очень даже элегантно. В MySQL придется городить, я даже пока плохо представляю что.

Обратная сторона медали тоже присутствует, куда ж без неё.
Бесплатных, функциональных и удобных программ для администрирования MySQL пруд пруди. Может и для Postgre есть, но я не видел. Штатный PGAdmin, мягко скажем, корявка та ещё. Регистрозависимый синтаксис для имён таблиц в Postgre – это потенциальный источник багов. Кром того, таблицы, именованные в camelcase стиле требуют обрамления в кавычки, что требует их экранирования в коде, что требует недюжинного терпения. Да и в глазах рябит от подсветки синтаксиса каждой “заэскейпленой” кавычки.

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

SCRUM или рыночные отношения

2010-11-14T00:28:00.001+07:00

В этом посте я отступлю от темы тестирования и коснусь управления разработкой, a именно, популярной и многими любимой технологии SCRUM. Эта технология оценки трудоемкости и управления задачами обладает многими преимуществами перед классическим водопадом. Она проста и понятна. За исключением одного момента – Story point. Эти условные “баллы сложности” вначале всегда вызывают вопросы – что же это?
Классики советуют не думать о них в понятиях времени, тем не менее, в большинстве случаев использования, поинты приводятся к часам, ну или дням, кому как удобнее. Думать о storypoint как о строчках кода - тоже неправильно. Количество строк кода очень сложно определить заранее и зачастую это не показатель.
Когда я рассказывал о scrum своим коллегам, я получил вопрос – каков же физический смысл в этих оценках?
Физический смысл донельзя прост – это деньги. Смотрите, что получается…

Давайте для простоты приравняем очко сложности ста рублям. Тогда задачи будут оцениваться в деньгах. Процедура оценки задач станет торговлей – руководитель проекта выставляет задачу на торги, эту задачу один программист готов выполнить за 1000 рублей, другой за 750. Остальная практика оценки задач не меняется, не буду описывать – все по скраму. Мы избавляемся от преобразований баллов в человеко-часы, это больше не нужно. Программисту сразу понятно, сколько он заработает и сколько он теряет занимаясь прокастинацией. Сроки отходят на второй план, они будут минимальны.
Думать о сложности в понятиях денег проще и руководителю и программисту. Руководитель имеет перед собой общий бюджет проекта, как правило согласованный заранее, его задача не выйти за эти пределы. Думая о проекте в абстрактных единицах легко забыть о реальности, а тут – живые деньги, которые получит программист за выполнение определенной задачи. Понятия “хороший” программист и “плохой” программист обретают свой физический смысл – хороший выполняет задачи за более короткое время и, о чудо!, получает больше. Причем сразу, не дожидаясь признания коллег и начальства, зачастую субъективного. Программист волен в определении сроков выполнения той или иной задачи – ему все равно заплатят по сложности. Мотивация налицо – быстрее делаешь – больше получаешь. Вопрос качества пока отложим, тестировщики должны получать зарплату по другому, но очевидно, нельзя засчитывать задачу выполненной без ее принятия ответственным лицом. Это относится не только к скраму. Программист волен в распределении времени в пределах задачи, сколько потратить на код а сколько на изучение проблемы. Смысл в графике рабочего времени снижается до минимума, достаточно определить время общих собраний или вовсе обойтись смс рассылкой.

Я надеюсь, что такой взгляд на SCRUM вызовет обсуждение, жду ваши комментарии

Главный вопрос

2010-11-12T01:41:00.003+07:00

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

Новая работа, новые коллеги

2010-11-11T01:43:00.004+07:00

Вот еще вчера вы были инженером, а сегодня вас позвал директор и сказал - Вася! Ты теперь начальник группы тестирования, в помощь тебе вот эти двое, ибо самые молодые, давай, жду от тебя план действий. Знакомо? Многим руководителям пришлось пройти именно по такому пути.

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

2009-02-21T12:00:00.002+07:00

Прошло два месяца с момента последнего поста, один из них нерабочий, второй - рабочий донельзя. Нервная и физическая нагрузка у всей конторы зашкаливает за красную линию. Близятся бАльшие испытания, "испытания всего"... Ударная сборка стендов, подготовка оборудования, написаний методик и программ испытаний умножается на финансовый кризис. Люди работают на износ, и самое худшее, САМОЕ ХУДШЕЕ, не то, что мы сдачу вовремя почти ничего не получим сверху, не то, что за несдачу вовремя с нас снимут три шкуры, а то, что совершенно непонятно, когда это закончится.

No goals - no results. Аксиома, блин.
Самая худшая цель - "сделать все". Самый худший срок - "как можно быстрее"

Редеплой

2008-12-17T15:15:00.002+07:00

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

BUG удрал.

2008-12-15T12:33:00.001+07:00

Опять о неработе. BUG сбежал. Упустили, теперь будем искать по новой. Ребята шутят - его пофиксили уборщицы

Мы поймали BUG!

2008-12-11T17:31:00.003+07:00

Декабрь. Снег. Лабораторя наша в подвале, форточка под самым потолком в тридцати сантиметрах над землёй. Придя с обеда мы обнаружили, что посреди лаборатории ползает BUG. Самый настоящий, черный такой, здоровый. Назвали "Косяк", теперь это наш талисман. Ищем ему подходящий инсектарий :)