Даже регистр может иметь значение

- Виктор, что здесь написано?
- 77б
- б?
- Да
- А здесь?
- 38а
- Хорошо. - Одевая очки. - А для меня и там, и там "в".
(Возможный разговор)

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

QA из Skype поделятся знаниями 9го апреля

Сегодня, 9 апреля 2012, в Киеве состоится событие, на котором некоторые хотели бы побывать, но не смогут. QA Club Kiev совместно со Skype (!) организуют встречу с презентациями людей из Skype. Они поделятся с нами своим опытом и расскажут про видео тестирование (?).

Для тех, кто не может быть там мой знакомый darkproger у себя на сайте будет вести онлайн трансляцию события http://live.darkproger.net :)

Детали на http://www.ciklum.net/join/community/Building-network-QAs-gathering-in-Kiev-April2012/

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

Некоторым кажется что тестировщики очень любят искать баги. Они специально ковыряются в продукте, ищут что-то, записывают в книжечки, составляют отчеты, рыщут повсюду, разработчикам так вообще досаждают постоянно, отклоняют релизы. Короче, портят всем жизнь.
А вы думаете легко вот это вот все? Думаете нравится, когда багов много везде? Мы по-вашему, уважаемые вот-так-вот-думающие, какое-то наслаждение от этого испытываем? (Иногда бывает, но никто не без извращений маленьких живет)
Нет! Баги - это головная боль для всех. Для тестировщиков в том числе. С багами больше всего возни.

Что бы я писал в тест плане

Давненько не писал тест план я. Давайте поделюсь тем, что получилось.
Нет, я, конечно, не буду прикреплять сюда что вышло. NDA, сами понимаете. Но вот как я вижу что там надо написать.

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


Кто?
Надо описать команду, роли и какая на каком лежит ответственность. Например,

Тест Аналитик - отвечает за тест дизайн, анализ результатов и отчетность - Петя Ёшкин

И никто не мешает при этом написать, что Тим Лид у вас тоже Петя Ёшкин, но тут другие обязанности. Почему бы со временем не стать тестовым аналитиком другому человеку (или лидером команды, а что?). А роль останется.

Что?
Определяем фронт работ. Что мы будем проверять, а что нет. Причем, второе важнее. Например,

Проверяем:Установку приложения
Доступ к функциям приложения согласно правам доступа
Основную функциональность приложения
   Календарь
   Формы отчетности
   Управление пользователями
   и т.п. штуки
Не проверяем:Управление пользователями (доменный доступ)
Логин в систему (доменный доступ)
Печать отчетов

Было бы еще замечательно добавить тут тестовые приоритеты: что важнее и первоочереднее было бы проверить. А также лучше всего, если вы пишите общий план, то разбить по типам тестирования и писать каждому скоуп и ответ на вопрос "как?".

Как?
Определяем подход к работе. Лучше всего разбивать по типам тестирования.
Окружение, общие сценарии запуска тестов (если необходимо). Например, для производительности:

1. Ставим приложение на сервер
2. Разворачиваем нагрузочное окружение
3. Настраиваем параметры теста
4. Прогоняем в тестовом режиме
5. Запускаем
6. Хватаем результаты и анализируем

Как мы будем получать тестовые сценарии (анализ требований, от сторонней команды, путем исследовательского тестирования).
Как определим что использовать для того или иного типа тестирования
Обязательно описать процесс тестирования. Что за чем идет, в целом и поитеративно. Какие активности планируются, описать их, конечно. Кто за них будет ответственный.
Какие инструменты буду использоваться для автоматизация, бактрекинга, тестирования производительности и т.п.

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

А также.
Описать риски связанные с организацией и процессом тестирования и обеспечения качества.
Описать все термины, которые вы используете. Что подразумеваете под различными профайлами, типами и т.п.
Описать все тестовые конфигурации для окружения.
Дать ссылки на соседние документы.
Не превращать тест план в список тестов.
Не превращать тест план в гайдлайны по развертыванию приложения.
Вписывать все что посчитаете необходимым.

Главное - не думать шаблонами.
Enjoy :)

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

Новый проект, первая шишка, или Как подключить testing.xml для TestNG

Закончился предыдущий проект и начался новый. Задача минимум: автоматизировать тестирование консольного приложения, которое является интерфейсом к фреймворку.

Решили использовать Java как базу для работу. Будем запускать консольное приложение и проверять фалы, базы, немного UI, вообщем все. И потому будем использовать для проверки приложений, написанных на базе этого фреймворка. За основу решили взять не jUnit, а TestNG. Почему? За очень полезную штуку по заданию порядка тестов. А порядок для экономии времени оочень важен. Шутка ли каждый небольшой тест разворачивать новую чистую инфраструктуру.

Почитал немного. Написал несколько примитивных тестов. Назвал test1 и test2. Запустил. Сначала прошел test1, потом test2. Отлично. А что тут с порядком? Оказывается TestNg использует специальный конфигурационный xml-файл. В примерах и у меня он testing.xml. Хотя это не так и важно. Главное преподнести его как конфигурационный проекту.
Создал, в том же месте, где и лежит тестовый единственный класс. Запускаем - ничего. Хмм. Нет потяно, что само по себе мало, что работает.

Почему винчестер не назвали автоматом или байтометом?

Не знаю. На английском он тоже "тяжело" называется (Hard Disk Drive).

Это я к чему. Если вы решили померять производительность своего нового мощного production сервера, то учтите при проектировании тестов, что самая медленная его часть это именно жесткий диск ;) И очень много вариантов того, как система может тормозить только из-за него на любомом очень быстром сервере


А вообще первый жесткий диск в том виде, как мы к нему привыкли состоял из двух пластин по 30 Мб. И его разработчики называли "30-30", что также является обозначением калибра популярного охотничьего ружья производства компании Winchester

Немного про покрытие

О да, это вот маленький aftercomment к моему выступлению на IT-Jam 2011 в прошедшую субботу

Кстати, кто докажет какой-нибудь матрицей покрытия, что не все было проверено?
Матрица покрытия отвечает вам на тот вопрос, который вы поставили. А если изначально вы не всё учли в вашем вопросе?

Сертифицироваться ли на нагрузочное тестирование или нет?

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

И был коментарий в виде поста Andy Gloverа. Вот не могу быть более согласен :)

Как бы я писал тестовые сценарии

Хочу вкратце осветить подход как я люблю писать тесты. Хотя между делом я это не очень люблю и потом постарался максимально удобный для себя подход подобрать.

Итак, что важно:
Создавать сценарии, а не отдельные тесты. Это может быть набор из тестов связаных друг с другом. Это экономит время. Например,
Выделять в большом сценарии отдельные точки проверки (verification points) с ожидаемыми результаами и отмечать их по мере прохождения. А  не ставить большую кучу в конце. Как-то в процессе вы должны были ожидать вот это. Видел такое, и не в полугодовом наколеночном проекте. А в зрелой большой успешной компании
В отчетах учитывать каждую точку проверки. Она влияет прошел сценарий/сьют/модуль/набор или нет
Но для общей статистики избегать дублирующий учет точек проверки. Учитывать vp только где это необходимо. Например, если в каждом сценарии вы проходите логин, то не надо считать, что это каждый раз отдельная точка проверки. Либо исключите его как точку проверки: уберите оттуда ожидаемый результат и не ставьте резолюцию. либо при отчетности не учитывать его кроме как только один раз во время проверки самого логина: оставьте ожидаемый результат (жалко копипаста?), но не ставьте резолюцию. Но обязательно оставьте коментарий и пометьте, что в данном случае тест провалился на логине, если только в этом тесте свалился логин. Или только он запускается сейчас.

Вообщем не надо быть гибкими или консервативными, надо с чувством, с толком, с расстановкой подходить к решению поставленых задач ;)

Рейс #666

Ничего не предвещало беды. Сидим вечером в офисе и готовим демо заказчику, которое должно было пройти 3 часа назад: как всегда в планируемых фичах начали обнаруживаться всякие блокеры.
И тут ко всему прочему падает билд. Что?! Как?! Оракл?! Где он?!
Вот так вот билд #666 лихо вырубил Оракл на тестовых средах и гордо смотрит на нас сквозь красную иконку "Build Failed"

P.S. Что было с билдом #13 я не знаю

Автоматизировать можно быстрее

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

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

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

З.Ы. надеюсь, что этой быстрой статье наконец-то пробью затишье в своих записях и не только доведу до ума свои черновики, но и сяду за описание своих идей и мыслей

Простые истины для простых тестеровщиков

Хороший QA всегда разберется в сути проблемы и поможет решить ее.
Тестеровщик всегда найдет ошибку.

Организация работы

1. Всегда озвучивайдля начальника свое понимание задания, чтобы у вы оба говорили на одном и том же языке
2. Всегда перед началом постарайся понять владеешь ли ты полностью всей необходимой информацией для выполнения задания
3. Уверен ли ты, что владеешь всеми необходимыми знаниями для выполнения задания
4. Перед выполнением убедись, что в наличие имеется все необходимое тестовое окружение
5. Держи своего руководителя в курсе выполнения и особенно в курсе проблем. Это скорее поможет решить проблемы и/или вовремя предотвратить их. Руководитель может либо думать, что все плохо; либо, что все хорошо
6. Планируй свое время так, чтобы ты смог поместиться в выделенные временные рамки

Непосредственная работа

7. Любая возникшая ошибка должна быть изучена и описана наиболее детально.
8. Сразу после выполнения ошибки:
- сделай скриншот
- повтори ошибку, чтобы убедиться в надежности и полноте шагов для воспроизведения
- изменяй шаги и настройки, чтобы убедиться в том, что ошибка не касается "соседней" функциональности
- записать отчет о найденной ошибке
9. При записи ошибки в Кратком описании необходимо указать модуль/страницу, и описать проблему в 5-8 словах
10. Нельзя использовать слова "не работает", "не получается" при описании ошибки. Если окно не открывается, то оно "не открывается", а не "не работает"; если появляется системное сообщение об ошибке, то "появляется сообщение о системной ошибке", а не "не получается выполнить функцию"
11. При описании ошибки необходимо отобразить всю найденную в процессе изучения информацию; указать шаги для воспроизведения; полученный результаты; и ожидаемый результат
12. Ошибка должна быть описана так, чтобы у другого человека хотя бы немного знакомого с проектом не возникало желания пройтись по шагам воспроизведения , чтобы понять что же все-таки не так и где
13. Все сбои в контрольном списке (check list) должны иметь в комментариях ссылки на соответствующий отчет об ошибке