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

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

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


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

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

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

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

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

Тестировщик – профессия не для слабонервных

Наверное, никто не будет спорить, что работу тестировщика оценивают в большинстве случаев по количеству багов, пролезших в релиз. Причем никого не интересует, сколько этих багов было найдено, отслежено и надцать раз перепроверено, сколько противоречивых требований было проанализировано, сколько сил потрачено на добывание этих требований из кастомеров, сколько времени потрачено на консультирование разработчиков… Видно только одно - в релизе найдено N багов! И каким бы малым не было это число N или какими бы некритичными были эти баги, и даже то, что эти баги найдены в функционале, который был объявлен как «not to be tested» - на вас все равно смотрят с недовольством и грустью в глазах. Даже, если никто не говорит этого в голос.

Вообщем, к важным качествам тестировщика нужно причислить еще умение трезво оценить в чем ты виноват, а в чем нет. Где-то нужно честно и обьективно признаться себе – тут я действительно провтыкал, shame on me и стараться больше такого не допускать (хотя всем людям свойственно ошибаться, но вот тестировщикам этого не разрешается). А где-то нужно так же обьективно осознать - вот тут я ничего не мог поделать, и морально казнить себя за это не стоит.

Это очень-очень важное качество. Иначе развитие страшного комплекса неполноценности и в итоге погружение в депрессивное состояние – это только дело времени.

PS: Вспомнились замечательные слова Уинстона Черчилля

«Success is the ability to go from one failure to another with no loss of enthusiasm»

Хотят ли тестировщики быть программистами?

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

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

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

Я конечно не знакома в тестировщиком Васей и не могу сказать хочет или не хочет он быть программистом, также не могу судить о его отношении к тестированию и его тестерских способностях, но могу сказать с уверенностью на 100%, что я вот никогда, с тех пор как начала работать тестировщиком, не мечтала стать программистом. Более того, по образованию инженер-программист я осознанно пошла в тестировщики, поскольку мне эта профессия показалась намного интереснее. И ни разу не жалею о своем выборе.

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

• те, кто пытается пробраться в программисты через временную работу тестировщиком (типа поработаю, освоюсь в компании, наберусь знаний и опыта и постепенно...)
• те, кто вообще ни кем не хочет быть, а деньги нужны, кушать хочется - почему бы и тестировщиком не "работать".

Стало мне очень интересно, есть ли среди нас такие, что мечтают стать программистами.

Коллеги, если не трудно и не секрет, напишите в комменты. Хотите ли Вы перейти в программисты? Если да, то по каким причинам Вы хотите стать программистом? Если нет и никогда не хотели, тогда напишите что же Вам так нравится в профессии тестировщика? Почему она нравится вам больше чем профессия программиста?

Особенности формирования требований к производительности В2В систем

С точки зрения тестирования производительности все системы разделяются на:

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

Низконагруженные. Например, системы В2В взаимодействия (системы межкорпоративного взаимодействия). Такую систему обычно используют около 100-500 сотрудников компании и 1000 – 5000 клиентов компании и, конечно же, не все одновременно.

Если в высоконагруженных системах производительность стоит на первом месте, то в В2В системах на первом месте - функциональность. Неотъемлемая характеристика В2В систем – сложная бизнес логика. И эта сложная логика должна работать без сбоев и глюков.

Поэтому, при тестировании В2В систем основная часть средств и времени отдается таким видам тестирования как: функциональное, юзабилити и интеграционное тестирование. На тестирование производительности остается очень мало времени.
Но его все равно проводить необходимо.

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

Мы можем потратить кучу времени и средств на обеспечение супер производительности нашей системы. Допустим, она будет чудесно работать под нагрузкой миллион хитов в день. Но в реальности максимальная нагрузка, которой подвергается наша система – 10 тысяч хитов в день. И, по прогнозам экспертов, до миллиона хитов ей еще расти и расти. Что мы сделали? Мы просто выбросили деньги на ветер и потратили силы зря. Не нужна нашей системе такая производительность, и еще много лет будет не нужна. Лучше бы мы разработали какую-то новую функциональность, которая действительно облегчила бы жизнь нашим пользователям.

То есть, мы должны честно ответить на примерно такие вопросы:

• Какое среднее количество пользователей будет одновременно работать с системой (Сколько сотрудников ежедневно пользуются системой?. Сколько клиентов в день заходят в нашу систему?);
• Какое максимальное количество пользователей будет одновременно работать с системой (Скольким людям понадобится достать или загрузить данные в системе в конце квартала, например?);
• Какой запас производительности мы хотим иметь (Что если произойдет что-то непредсказуемое и куча людей ломятся в систему, сколько их может быть? Или, что если мы банально ошиблись в наших расчетах средней нагруженности системы. Насколько мы могли ошибиться?);
• Границы приемлемой производительности системы (Какие показатели производительности мы будем считать хорошими/нормальными/плохими/очень плохими. Время выполнения операции 3 секунды это хороший или плохой показатель для нашей системы, а 10 секунд? Ну, 10 секунд это точно плохо, скажете вы. Ок. А если это операция формирования квартального отчета по результатам деятельности отдела? Вы все еще уверены, что 10 секунд это много для такой операции? Подсказка: тут нет общепринятых стандартов. Для каждой конкретной системы и даже для каждой конкретной операции хорошие и плохие показатели могут отличаться в разы).
  

Иногда слышу нарекания коллег тестировщиков, мол вот я выявил, что система падает при непрерывной работе 20-ти пользователей с таким-то модулем на протяжении 30 минут. Кошмар! Завел баг, сказал менеджерам, а они ничего с этим не делают. Ах они такие!

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

То есть, перед тем как приступать к тестированию производительности какой либо системы, нужно четко понять что мы хотим (в реальности) от нашей системы. Иначе получится тестирование ради тестирования.

«à la desktop» интерфейс для веб-портала

Интерфейс сайта в виде рабочего стола. Видели? Нет. Тогда смотрите.

Получше рассмотреть, покликать можно здесь http://ibpro.com.ua/admin/ .
По-моему смотрится очень интересно.

Для сайтов контентного направления я бы не делала такой интерфейс. А вот, для корпоративного портала, основной целью которого является решение бизнес задач таких как:

• размещение и скачивание документов
• заполнение и просмотр отчетов
• отслеживание логистических операций
• размежение и подписка на мероприятия
• ...

способ предоставления информации в виде десктопа мне кажется целесообразным.

В основном информация на портале отображается табличной форме или в виде списков. Страницы укомплектованы набором фильтров для поиска данных, ну и стандартными кнопками «добавить», «удалить», «сохранить», «скачать», «просмотреть»…

Вид «à la desktop» для портала видится мне примерно вот так.

Возникают вопросы:

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

Хотелось бы узнать мнения как специалистов в ИТ так и обычных пользователей Интернета.
Скажем, если бы Вы попали на такой портал, какой бы была Ваша реакция?

Брутфорс атака

Брутфорс атаки являются самым легким но эфективным способом взлома. Суть атаки состоит в подборе паролей пользователей.

Эффективность такой атаки напрямую зависит от ленивости администраторов и пользователей.

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

Задача хорошо продуманной компьютерной системы - не дать пользователям создать пароль, который легко ломается. Например, Петя, 1234, pass.

Поетому, при тестировании нужно обратить внеимание на следующие моменты:

• не рекомендуется длина пароля меньше 8-ми символов;
• пароль должен содержать комбинацию букв, цифр и символов;
• должно быть ограничение на кол-во попыток аутентификации за промежуток времени (например, не более 4-х раз в течении 1 минуты);
  
• пароли должны храниться обязательно в зашифрованном виде;
• пароли не должны передаваться методом GET;
• при работе с важной информацией должна использоваться защищенная передача данных (https протокол).
  

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