Bugs have feelings too

Кросс-пост отсюда

I've got the Power...Shell

При тестировании своих проектов, мне зачастую надо выполнять набор каких-либо определённых действий. Чаще всего, действия эти простые, но требуют затрат некоторого количества времени.
Мне это дело изрядно надоело, поэтому я твёрдо решил автоматизировать эти действия.
На помощь пришёл PowerShell, а также разработчики, которые оказали содействие. Суть автоматизации - написать функцию, прописать её в профиле PowerShell на локальной и удалённой машинах и выполнять её, когда необходимо выполнять вышеупомянутые рутинные действия.
А дело происходит так:
Открываем PowerShell и cоздаём профиль(ну, если ещё не создан конечно): new-item -type file -path $profile -force
Открываем профиль: notepad $profile
Пишем функцию:
function DoSomething([string]$Param1 = "") {
if ($Param1 -eq "") {
Write-Host "You are an IDIOT!!!! You need to enter Param1 value!" -ForegroundColor Red
return
}
$A_OUTPUT = "D:\Destination\"
$B_INPUT = "D:\Files\Images\"
$C_FILE = "Info.txt"

$currentDate = Get-Date -Format yyyyMMdd
$destinationFolder = $A_OUTPUT + $currentDate

if ((Test-Path -path $destinationFolder) -ne $True)
{
New-Item $destinationFolder -type directory | Out-Null
}

$Destination = "$destinationFolder\$Param1"

if ((Test-Path -path $Destination) -ne $True)
{
New-Item $Destination -type directory | Out-Null
}

$files = ls $B_INPUT

$files | %{copy -path $_.FullName -Destination $Destination}
Write-Host "$($files.Count) files" -ForegroundColor Yellow -noNewLine
Write-Host " copied from $B_INPUT to $Destination"

New-Item ($Destination + "\" + $C_FILE) -itemType File -Force | Out-Null
Write-Host "$C_FILE" -ForegroundColor Yellow -noNewLine
Write-Host " is created"
Write-Host "Files $Param1 are reorganizes!" -ForegroundColor Green
}
Сохраняем профиль. Тут есть вопрос безопасности - если вам операционка говорит "низя" - её надо вежливо попросить:
1. Запустить PowerShell под админом
2. Прописать следующее: Set-ExecutionPolicy unrestricted
3. Согласиться на все, что предложит :)
Перезапускаем PowerShell.
Запускаем функцию DoSomething TestB13. И функция благополучно копирует файлы из D:\Files\Images\ в D:\Destination\\TestB13 и создаёт текстовый файл Info.txt для последующего ввода описания.
Ответ PowerShell'a будет такой (с учётом, что в ресурсе лежит 3 файла):
3 files copied from D:\Files\Images to D:\Destination\\TestB13
Info.txt is created
Files TestB13 are reorganized!
В итоге, экономия рабочего времени составила более 50% (точно не замерял), которое я могу тратить на более важные аспекты тестирования.

P.S. Курс молодого бойца PowerShell можно пройти тут

Контекстное тестирование

Некоторое время назад, прочитал о контекстном тестировании (context-driven-testing). Оказалось, что то, как я работаю, по большому счёту – контекстное тестирование.

Что же такое контекстное тестирование и с чем его едят.

Школа контекстного тестирования – одна из пяти школ тестирования программного обеспечения (наряду с аналитической и стандартной школой, а также школой обеспечения качества и школой «гибкого» тестирования ).

Контекстное тестирование – это подход к тестированию ПО, суть которого описана семью основными принципами:

1. Ценность любых практик зависит он контекста.

2. Панацеи в тестировании не существует, существую оптимальные для данного тестирования практики

3. Проектная команда – самая важная часть контекста

4. То, как развивается проект с течением времени – зачастую непредсказуемо

5. Программный продукт – это решение какой-либо задачи. Если задача не решена – продукт не работает

6. Качественное тестирование – интеллектуальный и непростой процесс

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

Mind map как апгрейд для чек-листа

Любому, даже малоопытному, тестировщику знаком такой артефакт тестирования как «чек-лист» (checklist). Сей артефакт представляет собой список того, что необходимо проверить в ходе тестирования той или иной функциональности. Обычно он используется для тестирования функциональности, не покрытой тестами и требующего проверки большого количества объектов.

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

Другие же спецы ищут пути оптимизации процессов тестирования. К такой оптимизации можно отнести использование майнд-мэпов (mind maps) как апгрейд для тестирования по чек-листам. Суть сводится к тому, что пункты чек-листа представляются не списком, а в виде диаграммы, построенной вокруг центральной идеи (функциональности) с отображением связей между объектами внутри этой идеи (отображение связей между частями функциональности) .

Использование майнд-мэпов делает процесс тестирования по чек-листам более наглядным : можно сфокусироваться на определённой части функциональности, свернув остальные ветки диаграммы; на диаграмме хорошо видно текущей статус тестирования функциональности (например, путём выделения цветом или любым другим способом, статуса по отдельным частям: pass, fail, not ran, blocked, etc).

В вопросе выбора ПО для построения майнд-мапов я бы посоветовал либо "платный" Mindjet Mind Manager либо бесплатный FreeMind

«Плавающие» дефекты

На любом проекте время от времени появляются дефекты, которые воспроизводятся не на постоянной основе – их ещё часто называют трудновоспроизводимыми или «плавающими». Однако, несмотря на то, что вероятность появления таких дефектов после поставки значительно ниже 100%, ущерб наносимый ими даже единожды, может иметь серьёзнейшие последствия. Чтобы минимизировать количество «плавающих» дефектов можно использовать следующие методы:

1. Добавление/изменение подходов к воспроизведению (и тестированию в целом)

- фокусировка на интуитивно выявленных критических местах

- привлечение помощи сторонних (возможно с другого проекта) тестировщиков для более (exploratory) или менее (ad-hoc) глубокого тестирования

2. «Bug bash» мероприятия

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

3. Парное тестирование (тестировщик + тестировщик или тестировщик + разработчик)

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

- в разы снижается риск того, что часть функциональности будет пропущена или недостаточно тщательно протестирована

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

- помимо повышения качества тестирования, увеличивается и его скорость

Латаем дыры в тестовом покрытии

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

1. Ошибка при выполнении теста

Причина: Ошибки могут быть всевозможными - непосредственно в шагах, в настройках "железа", в настройках софта... и причины этих ошибок также могут быть весьма разнообразными.

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

2. Неактуальный тест кейс

Причина: Тест кейс писался на ранних этапах разработки, когда ещё не совсем ясны детали; фунциональность проапдейтили, а тест нет; тестировщик недопонял фичу и написал тест с соответствии с ошибочной точкой зрения;...

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

3. Отсутствует тест кейс

Причина: Если на написание тестов и выделяют время, то его, как правило, недостаточно для детального покрытия фич тестами. Поэтому не стоит удивлсяться случаю, когда на проскочивший баг не найдётся тест кейса, который мог бы его выявить.

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

4. Ошибка в спеке

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

Что делать: Читая спеку тестировщик должен всё ставить под сомнение - это поможет выявить ряд дефектов системы на раннем этапе и не допустить написания ошибочных тест кейсов.

5. Некорректный баг репорт

Причина: Такой баг был занесён в баг-трэккер, но "прошёл мимо" разработчиков - виной тому неверное выставление приоритета, версии, компонента, платформы и т.д. и т.п.

Что делать: Придерживаться установленных в компании/на проекте правил написания отчётов о дефектах. А если возникает ситуация в которой тестировщик сомневается к какому компоненту отнести тот или иной дефект, то не зазорно обратится к разработчикам или тех лиду.

Пишем отчёты о дефектах

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

1. Summary
Резюме бага, оно же саммари (summary) - это лицо бага, это та самая "одёжка", по которой встречают. Очень многое зависит от того, насколько удачно сформулировано саммари. В идеале, прочтя саммари, разработчик должен на 80% понять суть проблемы.
Советую учесть следующие моменты при написании саммари для дефекта:
а) указание платформы (например, test или prod), если на проекте используется несколько платформ
б) указание компонента (например, аdmin, reports, upload и т.п.), если последующее описание может подойти нескольким компонентам
в) указание браузера (например, IE7), если ошибочное поведение наблюдается специфически под определённым браузером
г) указание частоты воспроизведение (например, occasionally или 4 of 10 times), если воспроизводится не на постоянной основе
д) использование терминологии, использующейся в тестируемой системе (например, не photos, а images или не scroll bar, а slider)

2. Description
Описание шагов (description) - по сути самое важное во всём отчёте, поскольку от того, как тестировщик сумеет объяснить суть бага и шаги к его воспроизведению, зависит его (бага) дальнейшая судьба. Слишком кратко - высока вероятность того, что баг вернётся к тестировщику для уточнения. Слишком детально - разработчик скорее всего отложит такой баг на потом, поскольку его даже читать лень, не говоря уже о качественном фиксе. Осюда вывод, что для того, чтобы избежать временных потерь, надо искать оптимальный размер описания.
Лично я, при написании баг репорта, советую выбрать довольно высокую степень детализации шагов, однако, по возможности, группировать несколько простых действий в один шаг.
Помните, что хорошо описанная проблема - проблема наполовину решённая.

3. Attachment
Правилом хорошего тона в данном случае будет добавление к описанию бага визуального подтверждения. Более распространённым видом такой визуализации является снимок экрана, он же скриншот (screenshot), однако с нынешним выбором ПО нет никакой проблемы прикрепить и заархивированное видео. Многие разработчики оценят такого рода апгрейд - ведь, как говорится, "лучше один раз увидеть, чем сто раз услышать два раза прочитать"

Задача тестировщика состоит не только в том, чтобы найти баг, но и в том, чтобы найденный баг был исправлен.
Помните, что если ваш баг вернулся к вам со статусом не Resolved, то скорее всего в этом виноваты вы.


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