вторник, 16 ноября 2010 г.

Притча о пирамидах

...Идет строительство пирамиды Хеопса. Работает много людей. Подходят к одному человеку, который тешет камни, и спрашивают: "Что ты делаешь?". Тот отвечает: "Что не видите - тешу камни." Подходят к другому, который тоже тешет камни, и задают такой же вопрос. Тот отвечает "Я строю самое величественное сооружение на земле!"

Вот так отличается отношение людей к работе.
Один монотонно и без интереса делает одно и то же каждый день, лишь бы за это платили (тешет камни). Ему не интересно что нового появилось в области, которой он занимается, не интересно когда и как будет выпущен текущий релиз и что в него войдет. Работа для него, это потерянные 8 часов жизни.
А другой живет тем, что делает, стремится улучшить процессы, производительность, свои знания и навыки. Именно у таких людей часто на стенах развешены странные каракули, которые на самом деле являются базовыми алгоритмами системы, майндмепами продукта, планами версий и еще мало ли чем. В статусах месенджеров у них часто можно встретить сообщения типа "Ура! Новая версия (название разрабатываемой системы) выпущена!". Если надо, они выложатся на 200% и успеют вовремя сдать отстающий проект, в то время как "тешущие камни" будут в основном только жаловаться, рассказывать как все плохо и искать виновных.


четверг, 11 ноября 2010 г.

Полнота проверки на xss атаку

Большинство тестировщиков, которые не специализирутся на секюрити тестировании, при его выполнении (проверить то надо) пользуются стандартной процедурой:
1. Ввести во все поля тестируемой формы следующее:


2. Запостить форму
3. Зайти на форму просмотра результата
4. Открыть запись
Результат: если скрипт выполняется, то атака получилась.
Но как оказалось, xss атака может скрываться не только в скриптах, но еще и в тегах.
Например, в нашем проекте, где не срабатывал вышеуказанный пример, отлично сработал следующий:


Так что "век живи, век учись". Кстати, кто еще знает как можно запостить xss атаку, кроме этих двух способов? Делитесь знаниями :)

Главное вовремя!

Вчера по неосторожности установила QIP 2010. Мало того, что через 10 минут пользования сразу его снесла - это ужас, так еще и получила на почту очаровательное письмо с поздравлением с Новым 2010 годом :)

Я так понимаю, что эта рассылка задумывалась для работы в перед и после новогодний период, но видимо разработчики так хорошо отметили Новый 2010 год, что забыли отключить ее. Зато теперь все новые пользователи QIP 2010 получают поздравления круглый год. А че, весело!
Главное чтоб через полтора месяца не забыли сменить на поздравление с новым 2011 годом ;)

среда, 3 февраля 2010 г.

Когда заносить баги в трекер?

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

Но на практике очень многие тестировщики (в том числе и я) не придерживаются такого подхода. На то есть несколько причин и на этот счет каждый имеет свое мнение и свои причины.

Лично мне не удобно отрываться от процесса тестирования. Когда находишься «в потоке» и все мысли и чувства заострены под нахождение багов, то заведение отчетов об ошибках «здесь и сейчас» очень отвлекает, выбивает из процесса.

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

Единственное, что я считаю неприемлемым – это заносить все найденные баги в конце дня. Во-первых, их тогда очень нудно описывать. Во-вторых, очень велика вероятность провтыкать какой-то баг и не занести. И в-третих, это плохо сказывается на здоровье программистов :), которые не видя в течении дня ни одного нового бага, радуются и спокойно, с чистой совестью собираются себе домой… И тут вдруг обнаруживают несколько десятков багов. А-а-а!!! Так и до нервного срыва недалеко :)

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

А для того, чтобы не забыть баги очень удобно по ходу тестирования делать скриншоты. Ведь практически на каждый баг можно сделать скриншот. А по скриншотам уже очень легко вспоминать суть бага. Также можно делать заметки на бумаге. Завязывать узелки на память :) ... у каждого свои методы.

PS: Про узелки на память - это шутка.