Test Everything

Про профессиональную пригодность

2011-11-01T13:06:00.001+03:00

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

Нужно было автоматизировать тест-кейс с помощью Selenium IDE. Шаг первый: "Откройте yandex.ru"

Сидит... смотрю что то не так.. Подходжу спрашиваю:

- Как дела у Вас?

- Вот тут написано... это что мне делать нужно?

- Это нужно пройти по этому адресу в браузере

- ???

- Ввведите вот это в адресную строку в браузере.

- ??? Это сюда?, - дрожащими руками кликает в файрфоксе в поле поиска, что справа от адресной строки...

Где-то ещё по пути к адресной строке, мы обсудили, что из всего открытого на компьютере есть браузер.

Но окончание занятия меня порозило ещё больше. Сохраняли написанный тест. Открылось стандартное виндошное окошко Save As.. Смотрит на него.. чё-то пытается кликнуть куда-то. Я смотрю не понимаю, что там такое происходит.. Мужчина, сосед по парте, благо нарушил эту глупую ситуацию:

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

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

Очень часто в последнее время слышу «брошу свою работу – пойду в тестировщики». Реально – не жалко, идите. Но неужели вы не пониманиете, что как минимум компьютерная грамотность пусть даже без знаний программирования, должна присутствовать??

А ещё психология...

Прособеседовав довольно большое количество кандидатов я осознаю вмеми возможными рецепторами насколько всё таки важны те самые замусоленные всеми качества тестировщика: внимательность к деталям, любознательность, ответственность, аналитическое мышление..

Первый раз в жизни вчера отказала отличнейшнему кандидату с технической стороны, но с психологической - нам не подходящему. И я уверена в своём решении, потому что психология - это правильно. Мне, конечно, повезло - в human resources у нас девушка-психолог. Без нее было бы сложнее. Я очень многому у неё учусь.

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

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

Неожиданные открытия

2011-10-23T01:35:00.001+03:00

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

Недавно определили меня бизнес-аналитиком на проект. Аналитика всегда мне нравилась.. да..

К тому же в виду определённых обстоятельств, выполняю некоторые функции прожект-менеджера.

И в конце то концов, у меня сейчас есть QA Club Minsk.

Пыталась сконцентрироваться на чём-то одном. Пыталась всё вместе, но всё равно уже очень давно подметила, что не получаю удовольствия от работы.

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

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

Картинка нравится. Если бы браузеры были девушками.

2011-09-21T10:36:00.000+03:00

Тестирование производительности

2011-05-13T20:10:00.003+03:00

Эта статья написана новичком, человеком, который не занимался нагрузочным тестированием, но очень пытался понять: сходил на тематическую встречу QA Club Minsk и очень много лазил в интернете, пытаясь как-то систематизировать знания. Пост оформлен как FAQ по тем вопросам, ответы на которые, вероятно, могут быть полезными совсем новичкам в этом деле:
·         Что такое тестирование производительности?
·         Что такое автоматизированный нагрузочный тест или тест производительности?
·         Где взять тестовые сценарии для проведения тестирования производительности?
·         Инструменты нагрузочного тестирования.
·         Настройки и возможности тестов.
·         Что нужно знать, чтобы стать специалистом по тестированию производительности?
·         С чего начинать, когда задание по тестированию производительности формулируют как «система должна быть производительной» или «проведите нагрузочное тестирование»?
·         Как организовать тестовую среду.
·         Пример отчёта о проведении нагрузочного тестирования.

Ошибки в изложении возможны – потому комментарии только приветствуются. Не судите строго. =)

Общее

Тестирование производительности – это отдельный вид тестирования, объектом которого является производительность приложения. Т.е. это вид тестирования, направленный не на проверку, например, корректности работы функциональности, как при функциональном тестировании, а на проверку скорости работы, на получение информации о затрачиваемых ресурсах системы или её частей при определённых условиях (например, заданное количество пользователей, их действия, длительность работы системы в целом и т.д,).
В зависимости от того, какая ставится цель у тестирования производительности, или же - на какой бизнес-вопрос должен ответить проводимый тест, можно выделить следующие виды тестов:
·         нагрузочные (load): проводятся для того, чтобы оценить поведение приложения при заданной ожидаемой нагрузке:
·         стрессовые (stress): проводятся с целью оценки поведения системы при превышении стандартной нагрузки. Если к моменту организации нагрузочного тестирования нет никакой информации о производительности приложения, то - как минимум для сбора показателей максимальной нагрузки, будет проведён стресс тест.
·         стабильности (stability, uptime) - то же самое что и load тест, но который длится в течение месяца-двух с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени (при проведении uptime тестов наибольшее внимание уделяется использованию ресурсов).

Как типы тестов на встрече назывались rump up тесты и rush hour тесты - это не виды тестирования, но специфические тесты, используемые в рамках проведения того или иного вида тестирования производительности для получения конкретной информации. Более подробно о них - в разделе о настройках тестов.

Что такое автоматизированный нагрузочный тест или тест производительности?

С помощью специального инструмента обычные тестовые сценарии превращаются в некий программный код, который может быть этим же инструментом выполнен. По сути - это эмуляция работы пользователей системы, однако не столько в смысле выполнения конкретных действий в тестируемом приложении (GUI), но скорее в смысле создания нагрузки на сервер, соответствующей работе пользователей в системе. В зависимости от целей тестирования, эти тестовые сценарии выполняются с различными входными данными и настройками: количество пользователей, скорость их подключения, количество повторений тестового случая, длительность теста и т.д. и т.п.
Как в тестовом сценарии есть ожидаемый результат, так и в нагрузочном тесте можно установить некие элементарные контрольный точки, в соответствии с которыми определяется успешно или нет прошёл тест. Например:
·         можно установить максимальное время ожидания отклика сервера;
·         можно установить проверку на код ответа сервера (200, 300 и т.п);
·         можно проверить наличие элемента (кнопка, список, текст и т.д.) на странице;
·         и т.д.
Наиболее важными результатам работы теста являются комплексные графики и таблицы, изучая которые, специалисты проводят оценку работы системы и, по возможности, дают рекомендации.

Где взять тестовые сценарии для проведения тестирования производительности?

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

Инструменты нагрузочного тестирования

При выборе инструмента важно понимать, что проводя нагрузочное тестирование, мы тестируем не GUI представление нашего приложения, а создаём в первую очередь нагрузку на сервер, который отвечает за необходимую нам функциональность. А средство нагрузочного тестирования просто «внедряется» в их общение. И если оно не понимает язык общения (JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP), то использовать его мы не сможем. Так, например, с JMeter можно протестировать web сервисы и http запросы, но в общение клиента и сервера через tcp/ip протокол внедриться он уже не сможет.

По структуре все инструменты в принципе своём одинаковы и состоят из следующих компонент:
·         recorder – записывает действия, выполняемые пользовате в соотетствии с тестовыми сценариями, и превращает их в программный код;
·         code IDE – среда разработки;
·         generator - та самая штука, которая создаёт виртуальных пользователей, выполняющих описанные тестовые сценарии;
·         analyzer – анализатор показателей-результатов теста.
Инструментов тестирования производительности большое множество, однако на встрече клуба были выделены:
·         Apache Jmeter. Средство бесплатное, что, пожалуй, является главным его достоинством и причиной популярности. Инструмент, в целом, неплохой и, как заявлено, вполне полнофункциональный, несмотря на не самый удобный интерфейс. Вот так выглядит скрипт:

К сожалению, этот инструмент имеет достаточно много проблем и ограничений: как упоминалось выше, он может не поддерживать необходимые протоколы; в нём отсутствуют удобные средства мониторинга; выдаваемые им результаты требуют дополнительной обработки; и он содержит довольно много багов сам по себе (например, в последней версии на текущий день (16 апреля 2011г.) не работает несколько блоков IF подряд). Однако приятно то, что у данного инструмента есть хорошая поддержка со стороны разработчика: баги не игнорируются и могут исправляться довольно быстро (естественно, определённых severity =)), инструмент вполне активно развивается.
В целом, JMeter - неплохой инструмент для решения не самых больших и не самых сложных задач при скромном бюджете.
·         HP LoadRunner. В отличие от предыдущего инструмента, LoadRunner имеет гораздо больше достоинств, однако наибольшим его недостатком является весьма серьёзная стоимость. Однако если бюджет позволяет, то использование продукта HP будет гораздо более предпочтительным по сравнению с JMeter: LoadRunner имеет более удобный интерфейс, имеет больше возможностей, имеет встроенный мониторинг и предоставляет по результатам выполнения тестов более понятные графики. В целом, на собрании клуба был назван коэффициент 1,5 - во столько раз потребуется меньше усилий при решении одной и той же задачи в LoadRunner по сравнению с JMeter.

Были также названы, но столь серьёзно не рассматривались:
·         Borland SilkPerformer.
·         Visual Studio Test tools
·         Oracle Automation Testing Suites (OATS).

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

Настройки и возможности тестов

В зависимости от используемого средства автоматизации тестирования производительности, при запуске тестов могут быть настроены некоторые опции:
·         При старте теста заданное количество пользователей может быть сгенерировано сразу, а может добавляться для нагрузки системы постепенно - «партиями» через определяемые интервалы времени. Такие тесты называются ramp up. Одной из целей таких тестов может быть: с помощью увеличения нагрузки определить пределы возможностей системы. Ramp up тесты могут проводиться как первый этап выполнения тестирования производительности.
·         Может быть установлена длительность тестирования (в минутах, например), а может быть задано количество повторений (итераций) выполнения теста.
·         Тестовый сценарий может быть один, а может быть и их набор. Каждому тесту может быть выставлено процентное отношение количества его использования в общем количестве выполняемых тестов.
·         Может эмулироваться использование различных браузеров и смешанных типов сетевых протоколов - опять же выставляется процентным соотношением.
·         Все тесты из заданного набора могут выполняться по очереди, в установленном порядке, а могут и в случайном.
·         С помощью соответствующих настроек можно провести тест, который называется rush hour: сначала подаётся стабильная стандартная (нормальная, ожидаемая) нагрузка, затем идёт резкое увеличение нагрузки до максимума и возврат к нормальному состоянию. Анализируя результаты теста, следует обратить внимание на показатели до и после скачка - если в этих показателях есть более ли менее значительная разница, то это говорит о наличии в системе проблемы.

Что нужно знать, чтобы стать специалистом по тестированию производительности?

1.    Важно знать основы функционального тестирования.
2.    Опыт автоматизированного тестирования иметь желательно, но не обязательно.
3.    Очень полезно иметь опыт администрирования (знание протоколов, возможность самостоятельной настройки системы, т.д.).
4.    Необходимо научиться хорошо понимать архитектуру приложения.
5.    Аналитический склад ума и знание математики будут необходимы для анализа результаты тестов, часто представленных в виде сложных графиков и таблиц.
А вот исходный код приложения знать не обязательно - специалисту по тестированию производительности непосредственно с ним взаимодействовать необходимости нет.
Если у вас нет готового специалиста, и вы думаете, кому поручить провести нагрузочный тест – программисту или не имеющему опыта в этом деле хорошему функциональному тестировщику, - то поручите его тому, кто проявляет к этой деятельности наибольший интерес и у кого есть необходимые для этого навыки и склонности, а так же понимание терминологии, или хотя бы горячее желание всему этому [самостоятельно] обучиться.
Кстати, начинать изучение нагрузочного тестирования можно с изучения словаря (hit, transaction per load, response time, и прочего, что можно увидеть на экране в попытках организовать свои первые запуски теста производительности).

С чего начинать, когда задание по тестированию производительности формулируют как «система должна быть производительной» или «проведите нагрузочное тестирование»?

Попробуйте пойти по следующему пути:
1.    Уточните задачу и её условия:
·         что конкретно нужно узнать: время отклика системы при некой нагрузке, длительности выполнения транзакции, либо максимальное количество пользователей, при работе которых будут выполняться определенные условия (время отклика не более чем время N, сервер отвечает Service Unavailable) и т.д.
2.    Уточните информацию о тестируемой системе:
·         на какое количество пользователей направлено её использование;
·         какие браузеры будут использованы, из каких стран ожидается больше всего пользователей, их соотношение и прочая статистическая информация (при проведении тестирования конфигурации будет важным узнать, какие операционные системы и аппаратное обеспечение будет у большинства конечных пользователей);
·         наиболее часто используемые бизнес-сценарии и то, какие компоненты системы они используют (например, для интернет-магазина это поиск, просмотр каталога товаров, совершение покупки);
3.    Узнайте о том, какое аппаратное обеспечение будет использовано или используется для продакшн серверов. Организуйте такую же тестовую среду.
4.    Узнайте, где находятся реальные рабочие сервера и какова доступная ширина канала. Попробуйте организовать такие же условия.
5.    Выберите инструмент для проведения тестирования. Не забудьте убедиться в том, что он поддерживает протоколы общения клиента и сервера.

Как организовать тестовую среду

На встрече сообщества не рассматривался полностью вопрос организации тестовой среды, но были выделены следующие отдельные моменты:
1.       Лучше всего проводить тестирование на системе, идентичной той, что будет при реальной работе приложения. Масштабировать результат нельзя, как бы ни хотелось и ни мечталось. =)
2.       Каждый элемент системы (база данных, сервер приложения, генератор нагрузки, который забирает очень много ресурсов, и пр.) желательно устанавливать на отдельную машину. Именно таким образом, будет намного проще определить – какой из элементов является «слабым звеном».
3.       Доступная при тестировании ширина канала должна быть адекватна генерируемой нагрузке. В противном случае - результаты тестирования будут некорректными только из-за ограничений по ширине канала. Как правило, всей системе тестирования лучше работать в одной и той же сети, чтобы пропускная способность была максимальной. Тестирование через интернет уменьшает ширину канала.
4.       Для проведения нагрузочного тестирования не рекомендуется использовать виртуальные машины: когда ваша система будет работать на основе реальной «железной» - результаты её работы могут оказаться отличными от результатов тестирования на виртуальных машинах.
5.       При отсутствии или недостатке собственных ресурсов можно использовать внешние специализированные, например, площадки amazon.com (облака). Но помните, что это те же виртуальные машины. Существуют также риски нарушения безопасности, некомпетентности персонала по конкретно вашему приложению или вопросу.
6.       При необходимости провести нагрузочное тестирование, с учетом работы пользователей из разных уголков планеты, можно:
a. Использовать инструменты/сервисы, с помощью которых можно проверить, например, сколько времени будет открываться некая страница из разных точек мира. Примером является сервис http://newrelic.com.
b. Можно поискать дата-центры, имеющие нужное географиеское местоположение, и провести сеансы тестирования, используя их оборудование. Довольно трудоёмкий и дорогостоящий вариант, но результаты его использования наиболее близки к реальным.
c. Обратится к специалистам, проводящим аутсорсинг нагрузочного тестирования.

Пример отчёта о проведении нагрузочного тестирования

В процессах поиска информации для этого обзора, в дебрях интернета нашёлся пример отчёта о проведённом нагрузочном тестировании. Возможно, кому-то будет полезен.

Спасибо экспертам в вопросе Анатолию Лётычу (Epam) и Дмитрию Тищенко (Itransition) за то, что участники очередной встречи QA Club Minsk смогли с нуля получить представление о нагрузочном тестировании. =)

Автор: Савастюк Наталья. Редактор: Елена Первая. Огромное спасибо за подсказки Масловскому Михаилу и Кныш Надежде.

ATC 2. Требования.

2011-02-13T08:52:00.003+02:00

Продолжается регистрация на вторую встречу нашего кружка тестировщиков (Минск), которая состоится 26 февраля 2011 года в 15 00 в инкубаторе бизнес-проектов БГУИР (ул. Гикало, д. 9, аудитория 601)

Встреча будет посвящена теме управления требований. Как и все наши встрече, эта будет формироваться по идеям Ваших вопросов, которые можно высылать на qaclub.minsk@gmail.com в том числе и анонимно. :)

Пока примерно вот так:

Вступление:

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

б) Как есть на самом деле частенько (делимся опытом)

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

1.1. User Stories. Эффективно ли? Как много противоречий между ними? Кто занимается их поиском? На какой стадии?

2. Какой лучше предложить использовать шаблон описания требований, если тестировщику предлагают разработать такой шаблон;

3. "Когда тестировщик в виде набора кейсов пишет спек это не нормально как-то." (с) один тестировщик. Кто как считает?

4. Тестирование без требований? Возможно ли? Или по итогу превращается в дополнительную работу для тестировщика по описанию требования?

Если останется время... Тестирование требований.

Заявки на участие ждём на qaclub.minsk@gmail.com.

Требование к каждому участнику иметь свою точку зрения по заявленным вопросам.

У нас нет слушателей, у нас есть участники!

ATC 1. Organization.

2011-02-06T03:57:00.003+02:00

Ну вот, и прошла в Минске первая встреча нашего кружка анонимных тестрировщиков. Говорить о чём-то рано, делать выводы рано, но прогнозировать, мне кажется можно! Есть очень много людей, которые «за», которым нужно, которые хотят. Просто не знают как. Возможно, несколько человек, которые пришли сегодня, не придут следующий раз, просто потому что ожидания у них были другие от первой встречи.. более конкретные, что ли, а оказалось всё более организаторским. Но(!) я просто уверена, что они вернуться к нам через год и будут с гордостью говорить о том, что именно они стояли у истоков!

И самое главное - начало положено. Я очень боялась. Очень. Но свою задачу «минимум» сегодня я считаю, выполненной.

Огромное спасибо всем, кто пришёл и ещё большее тем, кто поддержал, кто учавствовал, кто готов помогать!!

Это была нелёгкая задача, и получилось не совсем так как я хотела, и этим я не очень довольна.. Хотелось таки затронуть упомянутую мною в заявке тему про тест-план, а не получилось.. Не получилось по нескольким причинам:

1. Из-за опозданий (надеюсь, это было в последний раз)

2. Как следствие из первой – потеря времени, зарезервированного именно за нами.

3. Уделение большого временени организационным вопросам, но, может быть оно и хорошо. Мы сформировали позицию о том, как большинство из нас хотит видеть эти встречи, и это нам поможет в дальнейшнем..

Да простят меня читатели.. Очень многие из нас готовы прийти на «готовенькое». Я, в принципе, не против. Это прекрасно, Это отлично. Это супер. Но для этого существуют и платные и бесплатные тренинги довольно известных персон, и публичные конференции, которые проводятся довольно часто. Прийти и послушать – можно туда. А вот прийти и поучавствовать – лучше к нам. =)

Цель нашего клуба – помочь коллеге в его земной проблеме, чем можем, а не пропиариться, рассказав о том, что мы можем прочитать в книге или найти в интернете.

«Кружок анонимных тестировщиков.» Откуда это вообще? Никаких анонимов, естественно не будет. Будут имена, будут личности. А ещё будут проблемы этих личностей. И именно на них акцент. Проблемы разного плана:

· Не уверен, что делаю правильно

· Не знаю, как попросить об увеличении зарплаты

· Не знаю, какое средство тестирования выбрать

· Не знаю, как организовать процесс тестирования

· Не знаю, из того, что я делаю, организовать свой собственный бизнесс

Все, думаю, заметили, что предложения начинаются с «НЕ». Вот их то мы и будем зачёркивать из Вашей жизни!! Но.. один вариант вычёркивания - это когда пришел на встречу и сразу задал вопрос, а другой вариант – психологический, человеческий, от которого никуда не убежать - «боюсь; не знаю, как спросить» или «спросил вроде, но хотел бы ещё мнений услышать» или «не знаю у кого спросить» или «не хочу срашивать, потому что рядом со мной сидит коллега» или... ещё что-то. Все мы люди, все мы чего-то боимся и какие-то простые вещи почему-то не делаем..

В этом-то и будет анонимность. Вы можете с любого емейла (в том числе и фейкового) отправить письмо на наш почтовый адрес qaclub.minsk@gmail.com именно с тем вопросом, который интересует Вас в данный момент больше всего, который обязательно мы постараемся решить на одной из ближайших наших встреч. Варианта решения два:

а) организация темы встречи, в которой каким-то секретным образом будет затронут именно Ваш проблемный вопрос;

б) «вопросный получас» до обсуждения основной темы встречи.

Анонимность гарантирована! (с)

Итак, наша встреча прошла в организационном формате. Собрались люди совершенно разные:

· Одним интересна работа с требованиями (а ещё интереснее работа при их отсутствии)

· Другим - нагрузочное тестирование

· Всем интересно общение с командой

· Кто-то хочет сделать акцент на психологию

· Кому-то важны процессы.. scrum, rup.. у кого как работает?

· А кто-то вообще хотел бы побеседовать об организации тестирования, как отдельного сервиса, который можно продавать

Все мы разные и у всех у нас разные цели. У кого-то горизонтальные, у кого-то вертикальные, а у кого-то и диагональные.. И все имеют право на жизнь!

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

Увы и ах на следующей встрече присутствовать я не смогу, но уж точно сделаю всё, что от меня зависит, чтобы она прошла успешно. Результаты опроса, тема следующей встречи и дата будут выложены в течение следующей недели!

Спасибо Инкубатору БГУИР за поддержку.

И привет и с днём рождения, сообщество тестировщиков Минска ! =)

Как дела делаются.. =)

2011-01-25T14:06:00.002+02:00

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

- Ну.. Давай попробуем. Таки у тебя чуйка есть.
- Что такое чуйка? :)
- Чутье, как там это по-женски называется, забыл..
- Женская интуиция что ли?
- Вово.

По делу.

2011-01-10T22:03:00.002+02:00

Начинаешь свою карьеру и не понимаешь куда попал.. Тестирование.. что это? Я даже до конца не сформировала собственное мнение о чём это, когда в него окунулась.

Помню, как всем говорила в малолетстве:

- Я буду как мама.

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

А сейчас хожу и думаю.. мама же у меня тоже тестировщик. Просто другой.. хлебный.. И вообще всё в этом мире тестируется. ВСЁ. И жить не понимаю, как можно без другого.

Но вообще я не об этом...

Вот устраиваешься ты на первую работу.. зелёный такой.. несмышлёный пластелин. Помню пишу первое резюме. А рядом сосед по общаге.. «старикашка».. бывалый... в те времена-то кричит мне на ухо:

- Пиши, что 500 баксов зп хочешь!

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

- Я не знаю сколько хочу. А вдруг это не моё? Вдруг не смогу? Я вообще не знаю ни расценок, ни толком, что в обязанности входит.

Ну тогда-то, если честно, я и слов таких не знала.. «расценки», «обязанности»... не то, что не знала.. но не бросалась.

А сейчас ко мне приходят.. такие же зелёные.. несмышлёные деревяшки и заявляют:

- Я ничего не умею, но зарплату хочу большую.

А не охренели ли вы, мои дорогие? Лично я считаю, чтобы заявлять о себе в таком тоне, нужно начать что-то значить.

Спасибо маме за моё воспитание. Пусть она меня этому и не учила, но интуитивно я каким-то чудом могла дать себе никчемной адекватную оценку. (Ну мне так кажется во всяком случае.. даже если это эгоистично.)

Но это я тоже не об этом...

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

10 Usability Crimes You Really Shouldn’t Commit

2010-09-29T15:54:00.000+03:00

Over time certain conventions and best practices have been developed to help improve the general usability of websites during their design and build. This roundup of ten usability crimes highlights some of the most common mistakes or overlooked areas in web design and provides an alternative solution to help enhance the usability of your website.

Crime 1: Form labels that aren’t associated to form input fields

Using the ‘for’ attribute allows the user to click the label to select the appropriate input fields within a form. This is especially important for checkboxes and radio fields to give a larger clickable area, but it’s good practice all round.

Crime 2: A logo that doesn’t link to the homepage

Linking the logo of a website to the homepage has become common practice and is now second nature for (most) web surfers to expect the logo to head back home. It’s also worth mentioning the logo should appear in the top left.

Crime 3: Not specifying a visited link state

Visited link states do exactly as they say on the tin. It’s not the most advanced CSS selector, but it’s one that is often overlooked. Give users a visual clue as to which link has already been clicked.

Crime 4: Not indicating an active form field

You can use the ‘:focus’ selector on lots of elements, but it’s super handy when used on inputs and textareas to indicate that the field is active. Add CSS styling such as a highlighted border, or a subtle change to the background color.

Crime 5: An image without an alt description

This is straying a little into the realm of accessibility, but it’s still an important consideration! Remember to always add a descriptive alt attribute to your images, unless of course they are used for decorative purposes, then the ALT attribute can be left empty (but should still exist!). When using an image as a link, enter a description of where the link goes.

Crime 6: A background image without a background color

It’s common to use background images behind passages of text, but it’s worth remembering that if background images are disabled by the user, there needs to be a similar tone in the form of a background colour to avoid the text becoming unreadable.

Crime 7: Using long boring passages of content

There’s nothing more off-putting than landing on a webpage that’s laid out as a continuous passage of text. Break up your content with images, headings and clear sections to make it easier to scan, read and digest.

Crime 8: Underlining stuff that isn’t a link

Everyone knows that text that’s underlined, or is a different colour is likely to be a link. Don’t go confusing people by throwing in underlined text elsewhere! To draw attention to a certain word, try using the strong or emphasize tags instead.

Crime 9: Telling people to click here

The words click here have been around since the dawn of the Internet, but have been shunned aside in favour of more usable options. Using the words click here requires the user to read the whole sentence to find out what’s going to happen. Instead, describe what’s going to happen in the actual anchor link text.

Crime 10: Using justified text

This is another tip that’s heading a little deeper into accessibility but is also an important point to consider. Justified text might look at neat and square to the eye, but it can generate some real readability problems, particularly for Dyslexic users who can find it troublesome to identify words due to the uneven spacing of justified paragraphs.

Оригинал статьи.

Scrum вопрос

2010-09-10T14:52:00.000+03:00

На обеде вдруг возник рабочий вопрос.

Я вот никогда по Scrum не работала. А тут вдруг часть команды решила делать скрам-митинги с тремя стандартными вопросами: что сделал, сделаю, что мешало.

Один человек себя поставил скрам-мастером и озвучил правила:

- о вчера говорить в прошедшем времени «я сделал»

- о сегодня тоже говорить в прошедшем времени «я сделал»

Лично мой психологический настрой не может сказать о сегодня «я сделал». Я могу сказать «я сделаю» (без всяких «попытаюсь», «планирую», «хочу» сделать), настраивая себя на свершение горы дел, но не «сделал» с утра пораньше, когда ещё, может, не успел и компьютер включить.

В их команде тоже нашёлся такой правильный и что-то у них разразился скандальчик-спор небольшой. А мы задумались… а может быть этот скрам-мастер прочитал какой-то неправильный перевод с английского языка? Может быть правильно говорить «сделаю»?

Если есть знатоки scrum, подскажите кто прав, кто виноват. Уж очень интересно.

Романтика...

2010-04-30T13:01:00.000+03:00

Когда соотношение тестировщиков и разработчиков приближается к 1:1

2010-03-23T16:04:00.003+02:00

Теорема. Если количество человек в вашем отделе тестирования приближается к соотношению 1:1 с девелопмент отделом, то это проблема именно вашего отдела тестирования.

Доказательство-рассуждение.

Расспрашивал меня недавно коллега о той компании, куда я ухожу, об условиях, о перспективах.. И подняли вопрос о количестве тестировщиков..

В моей настоящей конторе их 6 в Минске и 3 в Лос-Анджелесе, учитывая то, что один QA manager.

Девелоперов у нас в Минске 4, а там - около 10, из которых где-то 3-4 Project Manager’a и один директор.

Итого: 9 тестировщиков на 14 программистов.

Если учесть то, что ищем ещё одного тестировщика, то ситуация становится жёстче.. Скоро дойдём до соотношения 1:1 с учётом вычета менеджеров и директоров.

Возможно, вам нужна автоматизация, возможно, вам нужна другая стратегия, возможно, ваши люди не справляются со своими задачами, возможно, qa manager неправильно распределяет задачи. Возможно всё.

Усугубим задачу добавлением человеческого фактора.

Из QA отдела за мой год работы ушёл один человек по собственному желанию после испытательного срока.

3 человека уходят в период март-апрель сего года: один из американской команды, два из минской.

Одного тестировщика мы ищем второй месяц безуспешно.

Из DEV отдела за мой год работы ушёл один человек из минской команды, один из американской.

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

Решение. Не забывайте хотя бы иногда объективно смотреть на то, что происходит в вашем отделе.

А вот, кстати, информация от Юлии Нечаевой по данной проблеме Опрос «Соотношение разработчиков и тестировщиков» и выдержка про обсуждаемое соотношение:

«Немногие могут себе позволить соотношение 1:1 тестировщиков и разработчиков, но такие компании есть. И они позволяют себе это. Мы не можем назвать ни причин сложившейся ситуации, ни условий её возникновения, это факт.»

Хорошо, что такие компании есть, но я уверена, что не всё так уж и хорошо в этих компаниях. Такое соотношение – просто растрата материальных ресурсов. Я не видела ещё на среднестатистических наших фирмах проекта сложнее, чем мой настоящий, и я воспользуюсь этим, чтобы сказать:

- Даже самый сложный проект не потребует затрат 1:1.

Browser Sandbox - Run any browser from the web

2010-03-16T19:21:00.007+02:00

IE Tester это скучно и не функционально. Как и Multiple IE. И ещё куча всего. Виртуальные машины это хорошо, но часто медленно.. слишком уж много ресурсов они хотят, отчего их использование ещё чаще превращается в просто «нудно».. пока запустишь, пока настроишь, или лицензия закончилась.. А что-то стоящее стоит денег. Правда, всё, конечно же, зависит от проекта и заказчиков.. как всегда.

Я долго искала то, что облегчит конкретно задачу нашего отдела тестирования: 6 браузеров – IE6,7,8, Safari, Chrome, FF. Это хорошо, что с FF проблем было меньше, чем с Safari, которое частенько нужно было 4-е, а иногда 3-е. Вот и приходилось извращаться..

Пока в один прекрасный день не пришёл линк на Spoon Browser Sandbox – РАБОТАЕМ по-настоящему, а не делаем скриншоты, с браузерами online. Правда только на Windows XP. На данный момент это браузеры:

IE8, IE7, IE6
FF3.5, FF3, FF2
Chrome
Opera10, Opera9

Всё очень просто:

1. Устанавливаем ТОЛЬКО их небольшой плагин. (Хорошо работает с Firefox.)

2. Одним кликом запускаем с упомянутой выше страницы необходимый браузер (первый раз буферизация будет идти несколько минут, во второй и последующие – несколько секунд).

3. Всё. Работаем :)

На Win XP sp2 с установленными IE7, FF3.5, Safari 4, Opera 10, Google Chrome 4, Microsoft Office 2007:

Никаких проблем с куками. (Вместе все браузеры, естественно, используют одни и те же куки/кеш файлы, но если работать в них последовательно – всё проходит гладко).
И с прокси тоже. Использует наши обычные Internet Options.
И даже с визуализацией. Впрочем, здесь не утверждаю, потому что в моём приложении упор шёл на функционал, а не визуализацию.
Естественно, блокируется IE Developer Toolbar при старте IE8, потому что необходимо обновление. Если его используете, то спокойно закрываете ошибку и работаете дальше.
При запуске IE6 Office пытается что-то себе установить. Спокойненько останавливаем данный процесс, ждём отката и работаем.
Как только узнаю что-нибудь ещё.. сразу допишу.

И ещё один важный момент: даже с медленным интернетом всё работает быстро и без «поедания» вечно необходимых памяти и CPU.

P.S. Пара линков просто в тему о средствах cross-browser тестирования:

Useful Tools for Testing Cross Browser Compatibility

10 Helpful Resources for Cross Browser Testing

Заметка. Повышение квалификации сотрудника.

2009-12-03T10:58:00.001+02:00

Обязать раз в 3-4 месяца каждого сотрундника команды к чтению доклада на какую-нибудь тему. Например, в данный момент мы изучаем нагрузочное тестирование. Пусть, А расскажет нам о WinRunner, Б - о SilkPerformer и т.д.
Мне кажется никто так не делает и это плохо.

Шахматные игры или просто про руководителей и подчинённых

2009-12-01T13:21:00.000+02:00

Бывает несколько типов руководителей:

· слоны (контролёры)

· короли (рабовладельцы)

· ферзи (командиры)

Контролёры лишь исполнители. Они никто, ничто и ни за чем. Я бы отвела им роль слонов на шахматной доске. Они исполняют приказы. Они иногда прикрывают, ловко и незаметно, спины как высших так и низших по рангу. Но, по сути, они никогда не могут обеспечить ни гарантированную защиту, ни разумное решение. Я всегда любила шахматы, но никогда не пониманила ценность слонов. Это одни из первых фигур, которые идут в бой, и одни из первых, которые гибнут.

Рабовладельцы – вот истинные разрушители жизни в коллективе, настоящие политики демотивации. Им не свойственна человечность и понимание. У них присутствует либо неугомонное желание царствования, либо неиссякаемая жажда денег, либо и то и другое вместе. Их роль как руководителей сводится к отдаче приказов, за невыполнение которых – публичное битьё палкой. Я лично считаю, что ни к чему хорошему такой руководитель свою компанию привести не сможет, кроме как к потери у своего подчинённого собственной значимости в частном, и, следовательно, кровавого убийства фирмы/отдела в целом.

Ферзи. Вот истинные управленцы.. жёны королей. Правые руки. Шеи мужей. Вот кому будет принадлежать мир, стоит только этого захотеть и грамотно всё спланировать. Внимание, понимание, своевременная реакция вознесут их в руки подчинённых. Дисциплинированность, предприимчивость, умение четко формулировать свои мысли, желание добиться истинности выложат им красную дорожку в совет директоров.

Бывает несколько типов подчинённых:

· пешки (исполнители)

· кони (инициаторы, патриоты)

· ладьи (фашисты)

С пешками всё просто. У них нет собственной мысли или желания воздвигнуть нечто великое. Они способны исполнять только приказы, они не запоминают, не думают, не решают, не предлагают, не мешают. У них всё с «не». Без «не» только.. они выполняют. Они рабы, в которых нуждаются рабовладельцы. Эти два фланга не могут друг без друга.

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

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

Хотела нарисовать это всё в диаграмму.. да не успеваю..

Максим Дорофеев: "Обезьянки против роботов"

2009-11-27T18:56:00.000+02:00

TestLabs09 Part I

View more presentations from Cartmendum.

TestLabs Part II

View more presentations from Cartmendum.

Test Labs09 Dorofeev M Part III

View more presentations from Cartmendum.

Зачем тест кейсу одна идея?

2009-11-09T21:25:00.003+02:00

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

У него нет опыта тестирования.

Нет никакого компьютерного образования.

Есть некоторое примитивное знание английского языка.

Я не знаю, что из этого получится. Но я решила попробовать.

В виду отсутствия свободного времени решила для начала дать ему прочитать книгу Романа Савина «Тестирование dot com» Книга до гениальности проста, как мне казалось. Позиционируется по большей части для новичков.. Ан нет.. Даже в ней есть вопросы. Почти каждую часть необходимо пояснять своим собственным языком. Своим примером.

Начинаем..

- Зачем тест кейсу одна идея? (идеей автор книги назвал summary, title.. у кого как.. Я называю это просто заголовком.. или кратким описанием того, что тестируем)

- За тем же, зачем и один ожидаемый результат.

- Так ведь он же жирными буквами выделяет даже, что это нормально, когда ожидаемых результатов много.

- Да. Это нормально на практике. Но в идеале… ты таким описанием ожидаемых результатов можешь не протестировать как работающий, так и неработающий функционал..

Пример.. нужно проверить некую expired password policy :

1. Минимальная длина пароля 7 символов

2. В пароле должны быть как цифры, так и буквы

3. Новый пароль не должен быть таким же, как предыдущий.

В, наверное, 90% случаях человек, начинающий тестировать данную функциональность создаст следующий тест:

Тест 1. Изменение пароля.

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
3	Установить пароль состоящий только из цифр. (больше 7 символов) и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
4	Установить пароль состоящий только из букв. (больше 7 символов) и сохранить	Появляется соответствующая ошибка о не сохранении пароля.
5	Установить старый пароль и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
6	Установить новый пароль состоящий как из цифр так и из букв длиною больше 7 символов	В течение 3х секунд на странице отображается сообщение о сохранении пароля. Вместо страницы редактирования открывается страница со списком всех пользователей.

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

А сейчас по делу.. Всё кажется хорошо: один тест и сразу всё проверили. И не нужно описывать пре-степы, где мы создаём пользователя , не нужно повторять шаг 1, где мы идем на страницу редактирования.. кажется, меньше текста – больше дела. Но.. а если уже на шаге 2м наш тест фейлится: пароль длиною меньше 7 символов сохраняется, страница закрывается и нет больше перед глазами тех полей, что нужно редактировать.

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

А другой, скорее всего уже неопытный, решит что найденный баг блокирует тестирование оставшегося функционала и остановится.

Следствие 1: баг найден, баг записан, кто нашёл - доволен.

Следствие 2: не протестирован функционал, который мог бы быть протестирован. О нём забыли до момента фикса найденного бага.

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

Следствие 3: если тест больше нашего, то этот цикл может продолжаться ещё очень долго.

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

Вывод: не нужно лениться, надеяться на «авось» и думать, что кто-то догадается протестировать оставшиеся после неожиданного фейла шаги. Нужно просто с самого начала создать несколько тестов. :) У каждого из которых своя идея и один ожидаемый результат:

Тест 1. Ошибка при сохранении пароля, длина которого меньше 7 символов

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.

Тест 2. Ошибка при сохранении пароля, состоящего только из цифр

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из цифр. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

Тест 3. Ошибка при сохранении пароля, состоящего только из букв

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из букв. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

И т.д.

- А когда можно совмещать несколько результатов?

- Когда вследствие одних и тех же действий ты можешь проверить несколько точек функционала. Банальный пример:

Шаг	Действие	Ожидаемый результат
1	Открыть страницу редактирования пользователя	Поле «Имя» должно присутствовать на странице
		Поле «Фамилия» должно присутствовать на странице
2	Изменить имя и сохранить.	Сообщение «Имя отредактировано» должно появится на странице
		Поле «Имя» должно стать не редактируемым.

Т.е. ожидаемым следствием шага 1 являются 2 результата: «Поле «Имя» должно присутствовать на странице» и «Поле «Фамилия» должно присутствовать на странице»

Важно понимать, что в данном случае мы не теряем последовательности действий, нам не нужно переделывать какие-то шаги дабы «доделать» тест в случае неожиданной неудачи: мы можем просто двигаться, отмечая полученный результат как PASS или FAIL.

Важно всегда помнить об оформлении теста: неправильное оформление ведёт к неправильному восприятию, а это – лишние ошибки.