четверг, 19 января 2012 г.

"Не баксом единым"

Уже как-то постил видео Дена Пинка. Вот попалось еще одно его выступление очень похожее, но с некоторыми дополнениями.



А также наглядная анимированная интерпретация




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

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

среда, 18 января 2012 г.

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

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

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


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

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

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

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

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

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

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

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

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

среда, 4 января 2012 г.

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

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

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

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