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

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

Вот так отличается отношение людей к работе.

Один монотонно и без интереса делает одно и то же каждый день, лишь бы за это платили (тешет камни). Ему не интересно что нового появилось в области, которой он занимается, не интересно когда и как будет выпущен текущий релиз и что в него войдет. Работа для него, это потерянные 8 часов жизни.

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

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

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

1. Ввести во все поля тестируемой формы следующее:

2. Запостить форму

3. Зайти на форму просмотра результата

4. Открыть запись

Результат: если скрипт выполняется, то атака получилась.

Но как оказалось, xss атака может скрываться не только в скриптах, но еще и в тегах.

Например, в нашем проекте, где не срабатывал вышеуказанный пример, отлично сработал следующий:

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

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

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

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

Главное чтоб через полтора месяца не забыли сменить на поздравление с новым 2011 годом ;)

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

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

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

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

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

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

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

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

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

Имитаторы браузеров

Постоянно приходится тестировать веб-приложения под разными браузерами.

Для этих целей есть множество инструментов. Я перечислю только те, что я использовала.

1. Browser Sandbox. Позволяет запускать имитаторы различных браузеров и в них проверять работу приложения.
Одно время я пользовалась этим инструментом, но не долго. Мне не понравилась его медлительность.

2. Browsershots. Позволяет быстро проверить как выглядит страница во всех известных браузерах под Windows, Linux, MacOS, BSD. Но не позволяет проверить работу приложения. Он только снимает скриншоты страниц.

3. IETester. Совсем недавно открыла для себя это десктопное приложение. Позволяет запускать в отдельних вкладках имитаторы различных версий браузера Internet Explorer.
Примечание: не совсем корректно работает под WinXP SP3.

Хочу заметить, что не стоит полностью полагаться на эти или любые другие инструменты имитируюшие работу различных браузеров. Поскольку, они в некоторых случаях не ведут себя так, как настоящие браузеры. Это и понятно, имитаторы это ж тоже приложения, и тоже содержат баги. Например, тот же IETester выдает ошибки java script там, где настоящий браузер IE их не выдает.

Лучше всего установить на рабочем компьютере или сервере несколько виртуальных машин с различными операционными системами и браузерами. В таком случае мы тестируем приложения в реальном браузере и можем быть уверены в правильности результатов тестирования.

Mailinator - инструмент для создания мейлов

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

Пользователей понадобилось создавать очень много и скоро мои личные мейлы закончились.
Коллега подсказал инструмент, с помощью которого можно быстро и просто создавать тестовые мейлы.
Инструмент называется Mailinator. Находится в интернете по адресу http://mailinator.com/.
Для создания почтового акунта нужно всего лишь ввести имя (например, mytest1) и нажать "GO".


Все! Адрес mytest1@mailinator.com можно использовать в тестовых целях.

Осторожно, люди!

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

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

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