вторник, 28 февраля 2012 г.

План тестирования - когда, кто и зачем?

И снова о тестировании. И снова теория в виде перевода.
На этот раз "Thoughts on Testing - Breaking Down the Test Plan".

Вопрос 1: Кто и когда им пользуется


Этапы проекта
Кто использует
Для чего
Этап дизайна
Разработчики
Менеджеры продукта
Тестировщики
Менеджеры тестировщиков
Тестируемость функционала
Прототип функционала
Соотношение  и объем ручного и автоматического тестирования
Влияние на другие функции
Сколько времени займет тестирование
Стратегия тестирование (зачем нужно)
Этап реализации
Разработчики
Менеджеры продукта
Менеджеры тестировщиков
Внешние тестировщики
Эксперты безопасности
Объем покрытия тестами
Список одобренного функционала
Сценарии безопасности
Стратегия тестирование (зачем нужно)
Этап стабилизации
Менеджеры тестировщиков Менеджеры продукта
Тестировщики
Внешние тестировщики
Служба поддержки
Объем покрытия тестами
Список одобренного функционала
Стратегия тестирование (зачем нужно) 
Пострелизная активность
Служба поддержки
Эксперты безопасности
Тестировщики
Объем покрытия тестами
Стратегия тестирование (зачем нужно)
Сценарии безопасности
Список одобренного функционала


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

Кто использует
Для чего
Тестировщик
Этап дизайна
Тестируемость функционала
Объем ручного и автоматического тестирования
Стратегия тестирования (зачем нужно)
Этап реализации
Объем покрытия тестами
Объекты для проверки
Тестовые сценарии
Сценарии проверки безопасности
Этап стабилизации
Объем покрытия тестами
Тестовые сценарии
Список одобренного функционала
Менеджер тестировщиков

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

Итак, как же должен выглядеть план тестирования:
  • Тесты
    • Тестовые сценарии
      • Ручные
      • Автоматические
      • Специфические (например на безопасности)
    • Объем покрытия тестами
      • Кода
      • Сценариев использования
    • Список реализуемого функционала
      • Все что обсуждалось с менеджером продукта
    • Общие вопросы стратегии тестирования
  • Спецификации
    • Функционал
    • Приоритизированные сценарии
  • Должен быть легко изменяем
  • Соответствовать текущему состоянию продукта
PS Бюрократизировано выглядит, но выкинуть действительно ничего не получается. Все по делу. 

пятница, 24 февраля 2012 г.

Visual Studio 11 - готовимся к Beta Preview

С. Сомасегар (S. Somasegar) в своем вчерашнем посте анонсировал скорый выпуск Visual Studio 11 Beta. Ждем его 29 февраля.

А чего же следует ждать?

Для меня в первую очередь интересен C++11 со всеми его вкусностями. Кстати недавно в Редмонде проходило супермероприятие посвященное C++: Going Native 2012. Два дня целиком и полностью о С++ 11. Все действо можно теперь посмотреть в записи. Правда Microsoft как обычно умудрился добавить ложку дегтя в бочку меда: нельзя будет без плясок с бубнами собрать С++ проект, который будет работать на версиях OS ниже Vista. Похожее мы уже проходили с VS 2010. Но если тогда это было понятно (С++ был мягко говоря в ж...), то сейчас с анонсом поддержки нового стандарта это как не очень коррелируется. Ну посмотрим...

Update: нашел статью, про то как завести новую студию, с++ и XP. Правда только в статической линковке и без поддержки С++ 11 :(
Update 2: интересная дискуссия про VS11 и WinXP. Если коротко, то сообщество бушует из-за отказа от поддержки WinXP. Microsoft должен задуматься. Интересно, чем закончится...

Дальше интересна новая штука WinRT API. Выглядит как реинкарнация старого-доброго COM. Смущает правда C++/CLI синтаксис в созданных по шаблонам приложениях Metro (обратите внимание на ^ и -> )
// C++
MainPage::MainPage()
{
    InitializeComponent();
}

MainPage::~MainPage()
{
}

void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{     DisplayText->Text = "Hello World";  }
но похоже это не он. Самому помацать это в Dev Preview еще не удалось, но думаю как раз после Beta и посмотрим.

Новый .Net 4.5 меня мало интересует, но народ в интернете гудит.

Из остального MS обещает новый VS Studio UI (см. Introducing the New Developer Experience part 1 и part 2). Но если вся эта красота будет тормозить, то толку от нее будет мало.

Developer Preview наш монстрообразный C++ солюшен из 30 проектов переварила и даже начала дерево включений хедеров строить (новая фича VS 2011), но работала после этого недолго :)
Ну и, ...барабанная дробь..., они добавили Unit testing for native C++. О чудо, не прошло и 5 лет :)

В общем ждем бету, ставим, оцениваем, отправляем фидбек в MS (здесь можно определить будущее C++ X)
Думаю я вернусь еще к этой теме, по мере ознакомления с новыми фичами лично. 

DataArt SPb IT-talk №2 - анонс

Хорошие новости. 29 февраля компания DataArt организует 2-ую встречу IT talk St. Petersburg. Напомню первая встреча проходила в декабре и показалась мне интересной.

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


Для участия требуется заявка (указать ФИО) на e-mail: it-talk.spb@dataart.com
или регистрация по тел.: +7-812-333-4440 /ex 1224, 1225/
+7-921-772-07-65, +7-921-442-44-77

Спешите, количество мест ограничено :)

вторник, 21 февраля 2012 г.

10 причин для отказа от TDD

Давно не читал такой жестко мотивирующей статьи "10 Reasons to Avoid Test Driven DevelopmentJ
Только боюсь, что дороги после этого лучше не станут. При чем тут дороги? Читаем дальше J

Вы можете забыть о практике TDD, не писать автоматические тесты, если:

10. У вас нет клиентов.
Иногда вы делаете продукт, который никем не используется. В этом случае любые затраты на качество – это напрасные затраты.

9. Если вашему клиенту нравится тестировать самостоятельно.
Некоторым людям большего все на свете нравится участвовать в бета-программе. Получить удовольствие от свеженайденной баги и попытаться понять, почему она произошла – это то, ради чего они живут. Другие чувствуют себя учеными в душе и любят поковыряться с стек-трейсах для реверс-инжинирига. Если ваш клиент один из них – то ваши автотесты лишат их удовольствия от использования вашего продукта. Не делайте этого!

8. Ваш проект короткий, простой и понятный.
Если ваша команда может закончить проект за короткий период времени (не больше нескольких недель) и не будет никогда его поддерживать, то все преимущества типа возможности повторного использования, эксплуатационной надежности и расширяемости будут потеряны для вас. Тратить время на эти вещи бесполезно.

7. Ваша архитектура безупречна.
Если больше нет способов улучшить архитектуру вашего проекта, то вам не нужно, чтобы она была расширяемой. TDD – это инкрементальная разработка, она заставляет архитектуру быть расширяемой. Если у вас все в порядке с архитектурой, то TDD вам нужен, как губная помада свинюшке J

6. У вас отличная документация.
Вы никогда не забываете API, все изменения в вашем продукте постоянно документируются. Если ваша документация настолько полная, то написание тестов противоречит принципу DRY (dont repeat yourself), потому что правильно названные и написанные тесты показывают вам все, что нужно для понимания Тесты будут дублировать документацию, поэтому не пишете тесты.

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

4. «Сделано» означает, что код зачекинен.
Многие команды считают, что «сделано» определяет момент, когда фича доходит до пользователя (она закодирована, проверена, развернута, документирована и тд). Многие другие, в том числе и ваша команда, предпочитают более простое и легко достижимое определение, где «зачекинено» означает «сделано». Для вас достаточно того, что разработчик сказал, что он закончил свою часть. Все остальное – это обязанности кого-то другого.

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

2. Отладка не считается, а тестирование занимает много времени.
Вам нужно оценивать сроки, сколько времени уйдет на выпуск продукта. Так как ваше «сделано» не учитывает тестирование, а также вы не можете оценить, сколько времени уйдет на отладку, то вы оцениваете только то, сколько вам понадобиться времени закодировать это. Если вы хотите выдержать сроки, то вам нельзя накинуть 20% сверху (на всякий случай), иначе ваш менеджер может это обнаружить. Лучше не рискуйте.

1. Это все теория.
Аналогично теории эволюции или гравитации, это все просто теория.  Даже если вышеперечисленные причины не верны, то еще никто не доказал, что этот продукт мог быть сделан быстрее и с лучшим качеством, если бы использовались новые методологии разработки (например TDD). Это просто дело вкуса.

Проверьте себя.
Теперь для того, чтобы определить, нужно ли вам использовать TDD, пройдитесь по списку. Посчитайте сколько причин применимо к вам. Если вы насчитали 10 – ВАМ НЕ НУЖНО TDD. Если вы насчитали больше одного (например, п.8 может иметь право на жизнь), то не пишите вообще никакого кода. Возможно, вам нужно выбрать профессию, где мало неизвестных и движущихся частей. Может укладка асфальта?

вторник, 7 февраля 2012 г.