У нас в проекте тестировщик должен хорошо знать математику. Особо глубоких познаний, в общем-то, не требуется, но твердо знать основы необходимо. Умение не путать интеграл с логарифмом, внятно объяснить физический смысл производной и не ответить "50%" на вопрос, чему равна вероятность выпадения 11 очков на двух кубиках - это минимальное требование, при невыполнении которого дальше и разговаривать не о чем. Поразительно, но даже на этом требовании отсеиваются девять из десяти кандидатов, хотя практически все - выпускники технических вузов. Помню девочку - выпускницу СпбГУ между прочим! - отличницу, которая упорно доказывала, что интеграл не может быть меньше нуля. Ну, как "почему"? Ведь интеграл - это площадь, а как площадь может быть меньше нуля?..

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

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

Имеется бассейн с водой, в котором уровень воды можно замерять. В бассейне плавает лодка, а в лодке сидит человек с чемоданом. В какой-то момент человек выбрасывает чемодан за борт.

Вопрос: изменится ли уровень воды в бассейне, и если да - то в какую сторону?

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

Под катом - пара намеков на решение задачи и рассказ о том, как ее решают на собеседованиях.Читать дальше

Некоторое время назад я писал про своего бывшего коллегу по UBS, автора онлайновой программки для склонения словосочетаний и имен "Морфер.ру". Сегодня он объявился со своим новым творением под названием summa-pro.ru. Эта программа предназначена для бухгалтеров, которым часто приходится писать сумму прописью в платежных документах - она генерирует уже готовую фразу, полностью соответствующую всем бухгалтерским и законодательным требованиям. НДС, если он требуется, вычисляется автоматически и тут же вставляется в текст:

Разумеется, ее вид возбудил во мне живой профессиональный интерес, и я с энтузиазмом взялся это дело ломать :) И вскоре поиски увенчались успехом: я довольно быстро понял, что ограничение в два миллиарда связано с максимальным значением для int. Число 2147483648 было честно отбраковано, а вот 2147483647 привело к внутреннему сбою, в результате чего текст ошибки был выведен прямо в поле шаблона:

Не бог весть какая бага, конечно, но неплохая иллюстрация важности тестирования граничных случаев.

Дальше мы совместно нашли еще парочку багов, но это я уже оставлю желающим потерзать систему самостоятельно :)

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

Под катом - мой перевод статьи. Читать дальше

Вот и наступил 09.09.09 :) Помимо того, что это просто красивое число, это еще и шестьдесят четвертая годовщина первого найденного бага. Как гласит одна из легенд, "багом" оказался мотылек, застрявший в контактах реле машины Mark II, что послужило причиной неисправности:

Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book September 9th 1945 [sic]. Stemming from the first bug, today we call errors or glitch's [sic] in a program a bug.

Вот, как он выглядел: Читать дальше

Когда я скачиваю какой-то файл из Интернета, я редко сразу определяю, куда его класть. Обычно он скачивается в некий каталог, специально предназначенный для всего, что скачано из Интернета - так называемая "файлопомойка". Разгребание файлопомойки - процесс при таком подходе неизбежный, но, на мой взгляд, это меньшее из зол, если сравнивать его с необходимостью сразу определить файл в конкретную папочку. Во-первых, это отвлекает от основной мысли :) Во-вторых, я наверняка через полчаса забуду, куда его положил. А в-третьих, все равно впоследствии обычно возникает желание пересмотреть систематизированные файлы и категории: что-то объединить, что-то разделить, какие-то файлы переместить и так далее. А раз этот процесс все равно неизбежен, зачем торопить события? Пусть пока отлежится в файлопомойке, потом определим, куда его деть.

Все бы хорошо, но "потом" обычно наступает сильно потом :) В итоге я уже и не вспомню, что за файлик hlm.zip и откуда он взялся - такие "безымянные" файлики, как правило, лежат мертвым грузом в файлопомойке. Впрочем, все современные браузеры (не считая, разумеется, IE), не говоря уже о специализированных менеджерах закачек, хранят информацию обо всех скачанных файлах: когда, откуда был скачан, иногда даже сохраняется информация о странице, с которой была получена ссылка на закачку.

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

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

Есть такая штука, как жесткие ссылки (hard links). Про них мало кто знает, и еще меньше народу пользуется (линуксоиды, молчать!) - и все потому, что Microsoft не потрудилась предоставить штатных средств для управления ими. А между тем технология очень удобная, логичная и простая до безобразия. Читать дальше

У нас же... формат!.. Только все такое качественное! Никакой попсы, никакого кабака...

День Радио

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

Ну давайте мы уберем нафиг из проекта отдел тестирования (именно тестирования, о каком QA может идти речь при таком подходе?), а заодно и половину бизнес-аналитиков - насколько станет проще работать? Тем более, что то, как происходит процесс разработки, вообще никого не волнует, включая непосредственный менеджмент. Было бы что-то на выходе - и ладно. Иногда удается полюбовно договориться с разработчиками, чтобы и им, и нам легче работалось и процесс был прозрачнее, но иногда находит коса на камень. Начинаешь объяснять, что так дела не делают - так сразу "Влад, отстань, у нас не Microsoft". Что, правда? А я-то думал...

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

- Пол, есть проблема...
- В Production? Если она не в Production - то это не проблема!

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

Current Music: Аквариум - Подмога (кавер на Х... Забей)
Tags: testing, job
Читать дальше

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

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

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

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

Все-таки Шейн очень ценен для меня как минимум тем, что это просто идеальный образец человека, который никогда не читает инструкций и которого не волнует ничего, кроме текущего момента. Этакий ирландский офис-самурай, который просто делает свою работу :-) Именно на нем надо обкатывать все нововведения. Если он понял, одобрил и начал пользоваться - значит, со всеми остальными и подавно проблем не будет.

А наш сегодняшний конфликт мы, думаю, еще как-нибудь зальем парой-тройкой кружечек :-)

Current Music: Sonata Arctica - Replica
Tags: testing, job
Читать дальше

- Вот мисс Ррр, она тоже с Земли. Верно, мисс Ррр? Мисс Ррр кивнула и как-то странно усмехнулась.
- И мистер Ююю, и мистер Щщщ, и мистер Ввв!
- А я с Юпитера, - представился один мужчина, приосанившись.
- А я с Сатурна, - ввернул другой, хитро поблескивая глазами.

Рей Брэдбери, "Марсианские хроники"

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

Но, как это обычно и бывает, самое веселое началось именно под конец рабочего дня. В списке на перетестирование у меня был один плавающий дефект (назовем его X для определенности), который разработчики вроде как с третьего раза, наконец, поймали, локализовали и ликвидировали.

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

Открываю снова, поскольку нашел способ воспроизвести. Похоже, что имеет место переплетение дефектов X, Y, Z и этого - они все относятся к одному куску функциональности и во многом перекрывают друг друга.

Шаги по воспроизводству следующие:

1. Создайте ордер - непременно вручную (если вы это сделаете в автоматическом режиме, вы наткнетесь на дефект Y, и до дальнейших шагов дело попросту не дойдет).
2. Попытайтесь изменить значение. С вероятностью 9 из 10 всплывет дефект Z, поэтому значение хоть и криво, но изменится.
3. Поскольку дефект Z плавающий, продолжайте попытки, пока он не перестанет проявляться. На это потребуется в среднем от 2 до 10 раз (в редких случаях возможно, больше).
4. После очередной попытки изменить значение вся система грохнется.

А что касается дефекта X, то он находится в прямой зависимости от данного, поэтому, пока он не закрыт, полноценное тестирование X не представляется возможным.

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

Current Music: AC/DC - Big Balls
Tags: testing, job
Читать дальше

Сидят Маугли и Каа. Маугли видит банан.
- Каа, этот банан никто не может достать?
- Да, Mаугли, его никто не может достать.
- Каа, даже сильный Балу не может его достать?
- Да, даже Балу не может.
- Каа, даже быстрая Багира не может его достать?
- Даже она не может.
- И даже ты, мудрый Каа, не можешь его достать?
- Да, Mаугли, даже я не могу.
Маугли задумался.
- Тогда я его достану!!!
- Да, Маугли, ты достанешь. Ты кого хочешь достанешь...

Анекдот

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

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

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

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

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

Сначала у меня на машине рухнул клиентский модуль, через который я заходил в систему. Примерно с час я искал причину, нашел, исправил. Пытаюсь зайти в систему - выяснилось, что теперь лежит сама система. Иду к программистам:
- Народ, что случилось?
- Система поломалась, чиним.

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

Пробую - вроде запускается, но не работает:
- Неа, не работает, ошибка такая-то.

Еще через час:
- А теперь?

Запускаю - работает. Быстренько перепроверил все, что хотел - действительно, бага есть. Открываю базу дефектов...

...не открывается.

В общем, потом еще с час чинили рухнувшую базу ошибок. Не день Бэкхема, да...

Current Music: Sonata Arctica - The End Of The Chapter
Tags: testing, job
Читать дальше