Цена документации

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

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

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

Если вы всё же решили, что документ стоит писать, то я бы посоветовал писать его не «залпом», накануне срока сдачи, выискивыя необходимые данные, тратя тем самым ещё больше времени, а постепенно и непрерывно. Таким образом, к моменту, когда документ должен быть готов, его останется только просмотреть и обновить какую-то минимальную информацию.

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

Нет! Тестированию ради тестирования.

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

Форсаж для тестирования

Обсуждая тестирование с разными людьми, я часто слышу такие фразы «тестирование занимает слишком много времени», «тестеры работают медленно», «тестирование очень сильно растягивает итерацию», «тестирование – узкое место на проекте» и т.п.
Если так случилось, что такую фразу вы услышали в свой адресс – надо незамедлительно решить этот вопрос. Я предлагаю такое решение:

Измерить то, как члены команды тестирования используют своё рабочее время. Не для отчётности конечно, а для того, чтобы понять что и как надо изменить, чтобы эффективность команды возросла. Итоги зачастую будут подходить под закон Парето – т.е. 80% времени тратится на сорбрания (meetings), документацию, согласование действий, емэйлы и прочий «хлам», которым обросло тестирование в большинстве формализованных и не очень подходов; а оставшиеся 20% - тратятся непосредственно на тестирование.

Форсаж для этой ситуации будет заключаться в превращении соотношения 80/20 в соотношение 60/40 – например, можно попытаться убедить менеджмент в том, что часть действий из упомянутых выше 80% снижает эффективность команды тестирования и предложить отказаться от этих действий.

Также следует обратить внимание и на тот факт, что ещё около 20% (входящих в упомянутые 80%) времени уходит на воспроизведение дефектов (для уточнения шагов и добавления скриншотов или видео), написание отчётов о найденых дефектах, верификацию исправленых дефектов и т.п. Суть в том, что это не совсем проблем тестирования – это скорее проблема разработки.

Форсажем в данном случае будет служить – вовлечение тестировщиков в процесс разработки на более ранних стадиях, что обеспечит уменьшение количества дефектов в коде к окончанию разработки функциональности (feature complete) и ускорит проект в целом.

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

Выдающийся тестировщик

Что делает выдающего тестировщика выдающимся? Я думаю, что практически каждый тестировщик задавался этим вопросом хотя бы раз.
Большинство профессиональных тестировщиков сразу начнут вещать про то, что выдающимся тестировщика делает знание методологий, тулов, процессов и т.п. Это всё конечно немаловажно, но, я считаю, что не это главное. Это делает тестировщика хорошим, но не выдающимся.
В конце концов те самые упомянутые методологии и процессы были разработаны обычными людьми, а людям, как известно, свойственно ошибаться – в этом мы все преуспели.
Так каким же всё таки должен быть выдающийся тестировщик? Я считаю, что для этого тестировщик должен быть бунтарём - любознательным, ставящим под вопрос всех и вся, не доверяющим общепризнанным подходам и методологиям, лично «испытывающим на прочность» практики, проверенные временем, пере-изобретающим тестирование, совмещающим подходы из других областей знаний, не перестающим учиться и совершенствоваться...

Выбор тулы для скриншотинга

Каждому тестеру ежедневно создаёт отчёты о найденых дефектах – баг репорты или проще – баги. В этом блоге, я уже поднимал вопрос о том, насколько важно писать грамотный баг репорт. Однако очень часто срабатывает правило «лучше один раз увидеть, чем сто раз услышать» - тут на помощь тестерам приходят тулы для «захвата» содержимого экрана (screen capture tools). О них сегодня и пойдёт речь.

Естественно, что данная ниша рынка представлена очень широко и многообразно – ведь делать скриншоты приходится не только тетстировщикам.

На мой взгляд, оптимальными тулами для тестеров являются: 1. SnagIt и 2. Win7 Snipping Tool

1. SnagIt

SnagIt – очень мощная тула, позволяющая не только сделать скриншот, но и налепить на него кучу плюшек (сделать обводку «особо опасному» месту, понатыкать стрелочек, добавить текст и т.д. и т.п). SnagIt имеет большое число настроек для захватываемой области (область, окно, видимая часть контента – экран, область со скроллом, скрин с сохранением ссылок и т.п.), что позволяет приаттачить к баг репорту максимально точный скриншот. Помимо «захвата» картинок, можно ещё и видео записывать, которое после архивации имеет символический «вес». Тула также имеет широкие возможности по экспорту (Word, Excel, PowerPoint, IM), а также отсылке (email, FTP)

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

2. Snipping Tool

Snipping tool – встроенная в Windows7 тула, являющая собой отличный пример минимализма в решении поставленой задачи. Тут нет большого числа настроек и твиков, но есть всё необходимое, чтобы сделать качественный скриншот. Виды захватываемой области представлены 4 опциями – свободная область (free-form), четырёхугольник, окно и экран, что в принципе покрывает 99% случаев скрин шотов. Также радует поддержка сохранения ссылок. Из плюшек есть только ручка и хайлайтер, что немного удручает, поскольку в 50% случаев этого явно не хватит. Экспорт напрямую из тулы невозможен, однако отослать полученный скрин непосредственно из тулы можно, но только по email.

Подводя итог, Snipping Tool – отличная тула для создания простых скриншотов.

Итак, если вам в работе чаще требуется создавать «сложные» скриншотов, следует обратить внимание на SnagIt, а в случае когда надо просто подтвердить степы картинкой – вполне хватит и Snipping Tool.

Сделай жизнь ярче - раскрась свой powershell

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

# Prompt

function prompt
{
$_locationStackDepthString = New-Object string ([char] '+'), (Get-Location -Stack).Count
$color = 'Cyan'
Write-Host '>> ' -nonewline -ForegroundColor $color
Write-Host $(Get-Date -Format T) -ForegroundColor 'DarkYellow' -NoNewLine
Write-Host " " $PWD.Path -ForegroundColor 'Green'
Write-Host ($_locationStackDepthString + '>') -nonewline -ForegroundColor $color
$host.UI.RawUI.WindowTitle = "POWERSHELL"
return " "
}

Ну, а если уж захочется чего-то большего, то начать можно отсюда.

HTML5 Тест браузеров

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

Win7
Chrome beta (5...) - 142
Chrome 4.1.2 - 118
Opera 10.53 - 102
Firefox 3.6.3 - 101
IE8 - 19
Safari 4 - 70

Mac OS X 10.6
Safari 4 - 113
Firefox 3.6.3 - 101
Chrome beta (5...) - 137

iPad - 115

iPhone (3я прошивка)
Safari 4 - 113
Opera mini 5.0 - 14

Samsung GALAXY (android 1.5)
Chrome Light - 39

Провести Тест

Автоматизация Flex приложений на QTP

Некоторое время назад я столкнулся с проблемой автоматизации flex части проекта с помощью QTP.
Даже с установленным Flex 3.0.0 Add-in'м объекты flex части не распознавались, соответственно автоматизация не представлялась возможной.
Однако, после недолгих поисков наша проектная команда qa нашла приемлемое решение.
Шаги такие:
1. Запускаем Flex Builder.
2. Создаём новый Flex проект.
3. Выбираем его в навигаторе.
4. Выбираем Project > Properties > Flex Compiler.
5. В поле "Additional compiler arguments" прописываем следующее:

-include-libraries "flex_builder_dir\sdks\3.0.0\frameworks\libs\automation.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_agent.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\qtp.swc"
"flex_builder_dir\sdks\3.0.0\frameworks\libs\automation_dmv.swc"

( -include-libraries работает с директорией Flex Builder'a (в Windows по дефолту "C:\Program Files\Adobe\Flex Builder 3\")
6. Кликаем OK,чтобы сохранить изменения, а потом ещё раз на OK, чтобы закрыть Properties проекта.
7. Компилим Flex приложение.

Негативные моменты этого подхода в том, что:
1. Придётся всегда параллельно собирать по 2 версии приложения (для продакшена и для тестирования), такое сработает далеко не на любом проекте
2. "probe effect", хоть и минимальный, но всё же присутствует

P.S. Работает с 7м IE, Flex 3.0.0 Add-in обязателен.