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

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

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

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 можно использовать в тестовых целях.

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

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

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

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

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

Наверное, никто не будет спорить, что работу тестировщика оценивают в большинстве случаев по количеству багов, пролезших в релиз. Причем никого не интересует, сколько этих багов было найдено, отслежено и надцать раз перепроверено, сколько противоречивых требований было проанализировано, сколько сил потрачено на добывание этих требований из кастомеров, сколько времени потрачено на консультирование разработчиков… Видно только одно - в релизе найдено 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 пользователя в день и то не каждый день. То есть такая производительность модуля устраивает всех уже на протяжении нескольких лет. И еще несколько лет будет устраивать. Как только нарисуется тенденция к увеличению интереса пользователей к модулю, вот тогда найденная проблема станет действительно актуальной и ей уделят необходимое внимание.

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