Компромисс 1: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

Поскольку я, по жизни, не очень люблю компромиссы и всякого рода универсальные решения типа плащ-кроватка, они мне бросаются в глаза. И, стоит отметить, в тестировании таких компромиссов хватает, о чем и хочется открыть очередную серию заметок. Кстати, я ещё обожаю Компромиссы Сергея Довлатова.

Итак, компромисс первый: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

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

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

Мифы и грабли: Пятиминутка ненависти к тестированию

Например, на собеседовании можно часто услышать вопрос, почему вы стали тестировщиком и что вам нравится в тестировании. Да и вообще, об это частенько любят потрепаться на форумах и в других местах скопления инженеров по тестированию. Это все конечно интересно, но есть же и другая сторона медали. Не знаю как вас, но лично меня некоторые вещи в тестировании периодически расстраивают. Иногда даже наблюдается пар из ушей. Я немного поразмышлял, что же делает несчастным тестировщика и для начала выделил пять пунктов. Если что-то ещё придет на ум, или подскажет кто - опубликую в другой заметке. Вы можете подумать, что я тут поплакаться решил, но не дождетесь :) - это просто издержки в профессии. У всех они свои. Итак, иногда:

1. Сложно оценить проделанную работу.
Прикол в том, что результат работы тестировщика в большинстве случаев неосязаем. Тут, конечно, можно считать количество обнаруженных\закрытых багов или пройденных кейсов или, на худой конец, затраченных человеко-часов. Но лично мне это кажется самообманом, и часто бывает, что в конце рабочего дня остается ощущение какой-то незавершенности тире неудовлетворенности от выполненной работы.

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

3. Нас учат как правильно тестировать
Чтобы вы сразу поняли, это, к примеру, когда вам какой-нибудь умник начинает менторским тоном рассказывать, как тестировать ну, допустим, граничные значения (а вы это прекрасно знаете). То есть, какие-то азы. Или, бывает, встречаются перцы, которые считают что тестирование это обезьянья работа и я-вам-тут-щас-за-час-все-протестирую. Не спорьте с такими, выслушайте и сделайте, как считаете нужным. А вообще, я никогда не упускаю возможности чему-нибудь незнакомому научиться, и вам советую.

4. Приходится выглядеть идиотом
Да, частенько приходится задавать глупые, а порой совсем тупые вопросы. Просто чтобы выяснить что это действительно так а не иначе. Шаги для воспроизведения ошибки приходится описывать чересчур детально (порой, противоестественно для мозга). Не бойтесь выглядеть идиотом, бойтесь им оказаться.

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

Tools: www.websequencediagrams.com - создание диаграмм последовательностей

Удобный и простой Web-сервис для быстрого создания диаграмм различных последовательностей - www.websequencediagrams.com. Вы пишете текст определенного формата, нажимаете Draw и получаете нечто подобное:
















Можно очень быстро набросать модель для тестирования, например, инсталлятора.

Tools: Интересный сервис для создания макета интерфейса (mockup)

Демо-версию посмотреть можно тут: http://www.balsamiq.com/demos/mockups/Mockups.html
Много различных контролок, есть даже для iPhone. Все интуитивно понятно. В-общем, что тут писать, лучше посмотреть.

Tools: Expression Web SuperPreview от Microsoft

Недавно Microsoft объявила о новом продукте Expression Web SuperPreview , который позволяет через один и тот же интерфейс предпросматривать веб-страницы для любого из браузеров, установленных в системе. Также продукт содержит всяческие полезности, как, например HTML-debugger. Бета-версия уже доступна для скачивания. Однако, в ней пока поддерживается только IE - можно сравнить рендеринг между IE6 и IE7 (или 8). Внутренний билд уже поддерживает Safari и Firefox. Окончательно продукт появится как составная часть MS Expression Web Studio 3, которую обещают релизнуть в конце года.

Мифы и грабли: Что такое программа?

А давайте-ка заглянем в словари (сами-знаете-на-каком-сайте) и посмотрим что такое программа.

Большая советская энциклопедия

Программа (от греч. programma — объявление, распоряжение, указ), Упорядоченная последовательность действий для ЭВМ, реализующая алгоритм решения некоторой задачи.

Экономико-математический словарь

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

ГОСТ 19781-90

Программа - согласно - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.

Да уж, как-то суховато и старомодно. В последнее время стало модно в качестве компетентного источника использовать Википедию. Заглянем и туда:

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

В общем, смысл ясен, программа это сферический конь где-то в компьютере. Примерно этому нас и учили в школе и ВУЗе. Но чем плохи эти определения? Да это же грабли! Они утверждают что программы созданы для компьютера. В современных реалиях это всего лишь частный случай. К чести Википедии, в конце статьи вспоминаются многострадальные пользователи, которым приходится использовать эти программы.

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

Ура-ура!!! Программы для пользователей называются прикладным программным обеспечением. Идем дальше:

Издательский словарь-справочник

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ — совокупность программ, управляющих работой компьютера или автоматизированной системы.

Cловарь по естественным наукам. Глоссарий.ру

Программное обеспечение - комплекс программ:
- обеспечивающих обработку или передачу данных;
- предназначенных для многократного использования и применения разными пользователями.

Википедия

К прикладному программному обеспечению (application software) относятся программы, написанные для пользователей или самими пользователями, для задания компьютеру конкретной работы. Программы обработки заказов или создания списков рассылки — пример прикладного программного обеспечения. Программистов, которые пишут прикладное программное обеспечение, называют прикладными программистами.

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

7 навыков высокоэффективных тестировщиков (часть 2)

Навык 4 - Мыслить Win\Win
Во многих организациях, команды разработчиков и тестировщиков переводят стрелки друг на друга, тем самым создавая напряженность между командами. Это наносит большой вред и существенно влияет на качество. У команд разработчиков и тестировщиков должна быть одна общая цель - обеспечить клиенту поставку продукта высочайшего качества. Если это становится общей целью команды, все начинают помогать и всячески поддерживать друг друга, в результате, когда счастливый клиент получает высококачественный продукт, все в команде счастливы не меньше этого самого клиента. Если вы хотите поспособствовать созданию атмосферы доверия, уважения и развить команду Win\Win, вот несколько советов:

• Делитесь знаниями - не скрывайте свои знания от других, делитесь ими.
  
• Общайтесь - обедайте с различными должностными лицами в вашей компании. Узнавайте больше о них,
  
• Поощряйте труд остальных - хвалите и восхищайтесь великолепной работой коллег. Расскажите об этом своему (и их) начальнику. Расскажите им, как вы цените их работу.
  
• Спасайте утопающих - если вы видите что кто-то погряз в работе, предложите ему свою помощь. Если предложили - помогайте и обеспечьте, чтобы коллега действительно получил ту помощь, которая ему необходима.

Навык 5 - Сначала понять самому, потом искать понимание
Многие из нас имеют плохую привычку переставать слушать то, что говорит собеседник, потому что нам очень сильно хочется высказать свое мнение. Каждый тестировщик или любой другой член команды имеют различный опыт, точки зрения и интересы. Перед решением любой проблемы, очень важно внимательно и взвешенно понять саму проблему. Когда вы почувствуете что обладаете всеми фактами, генерируйте различные идеи для решения проблемы. Наличие нескольких вариантов подразумевает конструктивное обсуждение, а также позволяет команде выработать из начальных решений наиболее внятное и решающее проблему с наименьшими потерями. Если вам не нравится чей-то подход, не нападайте на него. Вместо этого, поясните, основываясь на своем опыте, почему возможен более лучший подход.

Навык 6 - Синергизм
Командное сотрудничество это ключ к синергичной команде. Синергичная команда состоит из людей с различными сильными сторонами, профессиональным уровнем и точками зрения. Всячески поощряйте эти различия и предоставьте команде инструменты, которые позволят вам увеличить их эффективность. В крайне объединенных командах общаются друг с другом путем обмена календарей, публикацией статуса в дискуссионных форумах, чтобы другие могли видеть текущую занятость и выполненные задачи. Такие команды отслеживают все задачи, над которыми они работают каждый день, часы отработанные и оставшиеся, а также следят за расхождением с планом. Они также делятся друг с другом документами, отражающими передовую практику, готовят доклады, чтобы обучить других тому, что они узнали.

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

Об авторе
Стив Миллер является президентом Pragmatic Software. Имея 24 года опыта за спиной, Стив обладает обширными знаниями в областях управления проектами, архитектуры ПО и тест-дизайна. Стив публикует ежемесячный бюллетень для компаний - разработчиков ПО. Вы можете прочесть другие бюллетени по адресу http://www.pragmaticsw.com/Newsletters.asp

7 навыков высокоэффективных тестировщиков (часть 1)

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


Опубликованная в 1989 году книга Стивена Кови "7 навыков высокоэффективных людей" помогла миллионам людей повысить свою эффективность как в жизни, так и в работе. В данной статье обсуждаются 7 навыков, характерных для высокоэффективных тестировщиков. Итак, навыки:

1. Проактивность (упреждение)
2. Видеть результат работы в её начале
3. Начинать с самого главного
4. Мыслить Win\Win
5. Сначала понять самому, потом искать понимание
6. Синергизм
7. Точить пилу

Навык 1 - Проактивность
Цель тестировщика в любом проекте - добиться поставки ПО высокого качества. Когда проекты терпят неудачу из-за их плохого качества, вы либо упреждаете проблемы либо реагируете на последствия после анализа причин. Если вы реагируете, вы будете обвинять в проблемах и препятствиях других людей и обстоятельства. Если вы проактивны, вы берете ответственность на себя и ищете возможность предотвратить такие проблемы в будущем. На завершающей стадии каждого проекта ваша команда проводит "post mortem" или "retrospective" митинги на которых открыто обсуждается что было сделано хорошо а что плохо. Ниже представлены несколько идей, как быть проактивным:

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

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

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

Мифы и грабли: Цель тестирования в проверке соответствия требованиям

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

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


Но глядя со своей колокольни, я не могу считать эту деятельность тестированием. Честно говоря, я даже не интересовался, как все это должно называться. Допустим, валидация. Или верификация. Не важно, речь в заметке пойдет не об этом, а почему проверку соответствия требованиям, т.е проверку качества, я не могу считать тестированием (вы можете оставаться при своем мнении).

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:

1. Возможно ли составить полный список требований?
2. Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
3. Надо ли тестировать то, что в требованиях не описано?
4. Верны ли требования сами по себе?
   
5. Я что, долбаный робот? :) и т.д.

Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

Что по поводу качества, мне нравится высказывание Gerald Weinberg: "Quality is value to some person", т.е. у каждого свои представления о качестве. У разработчика. у менеджера, у тестировщика, у пользователя и т.д. Поэтому тестирование осложняется тем, что тестировщикам приходится часто сталкиваться с проблемами, которые влекут за собой конфликт интересов. Тут уже надо включать голову и здравый смысл. Некоторым конечно проще перевести стрелки на менеджера или лицо более ответственное, но грамотный тестировщик обычно всегда в состоянии предложить решение и донести его до заинтересованных сторон (так называемых stakeholders). Потому что у этого тестировщика сформирована общая картина проекта и он понимает что от него хочет каждая из заинтересованных сторон. Кажется, я уже ударился в проповедование context-driven testing. :)

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

10 практик юзабилити

В свежей заметке на DevelopSense Blog, где Майкл Болтон и Бен Симо совершенно справедливо склоняют глаголы над интерфейсом последней версии Skype, проскакивает несколько, как мне показалось, интересных ссылок. Текст одной из них я сподобился перевести. Многие вещи, несомненно очевидны и стали уже нормой, но пруфлинки и имена дядек на которых можно сослаться, часто бывает полезным аргументом если вы практикуете такую вещь как Bug Advocacy. Также материал может служить неплохим подспорьем для тест-планов по юзабилити. Дисклаймер: я долго сомневался при переводе слова heuristics и решил перевести его как практики. Вы можете понимать как вам удобно или предложить лучший на ваш взгляд вариант.

автор Jakob Nielsen
Оригинал http://www.useit.com/papers/heuristic/heuristic_list.html#

Ниже перечислено 10 основных принципов для проектирования пользовательского интерфейса. Они называются практики потому что они по характеру ближе к практическим методам нежели к каким либо руководствам по юзабилити (guidelines).

Очевидность статуса системы

Система должна постоянно держать пользователя в курсе происходящего путем соответствующих откликов в пределах разумных промежутков времени

Приближенность системы к реальности

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

Контроль и свобода пользовательских действий

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

Согласованность и стандарты

Пользователи не должны удивляться различным словам, состояниям или действиям обозначающим одно и то же. Следуйте стандартизированным соглашениям.

Предупреждение ошибок

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

Распознавание предпочтительнее вспоминания

Минимизируйте загрузку памяти пользователей отображая объекты, действия или опции. Не вынуждайте пользователя запоминать информацию когда он переходит от одной части диалога к другой. Инструкция по использованию системы должна быть доступна постоянно.

Гибкость и эффективность использования

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

Эстетичный и минималистичный дизайн

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

Помогайте пользователям опознавать, выявлять и восстанавливаться после ошибок

Сообщения об ошибках должны быть написаны простым языком (без кода), точно указывать на проблему и предлагать конструктивное решение.

Помощь и документация

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

Первоначально автор разработал эти практики для эвристической оценки в сотрудничестве с Rolf Molich в 1990-м [Molich and Nielsen 1990; Nielsen and Molich 1990]. С тех пор они были усовершенствованы на основе анализа факторов 249 проблем юзабилити [Nielsen 1994a] что породило набор практик с максимальной степенью пояснения, которые воплотились в этом пересмотренном перечне практик [Nielsen 1994b].

Обновленные сведения

Я буду представлять мои новейшие руководства по юзабилити на консультации Fundamental Guidelines for Web Usability в рамках Usability Week 2009 conference в Вашингтоне, Сан-Франциско, Лондоне.

Смотрите также:

• Основные принципы дизайна интерфейса от Bruce "Tog" Tognazzini. Перечень длинноват для эвристической оценки, но служит хорошим чек-листом.
• 10 практик юзабилити для повседневной жизни (типа прикол, на англ.)

Список литературы:

• Molich, R., and Nielsen, J. (1990). Improving a human-computer dialogue, Communications of the ACM 33, 3 (March), 338-348.
• Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), 249-256.
• Nielsen, J. (1994a). Enhancing the explanatory power of usability heuristics. Proc. ACM CHI'94 Conf. (Boston, MA, April 24-28), 152-158.
• Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY.

Copyright © 2005 by Jakob Nielsen. ISSN 1548-5552

Майкрософт изменили гайдлайны для капитализации

Для кого-то это не новость и, возможно, кого-то это развеселит, но на днях я был удивлен тем, что оказывается для Windows Vista стандарты капитализации изменились. Я уже привык к тому, что в названии кнопок, например, все слова пишутся с большой буквы (это грубо говоря, на самом деле там много разных условий). Такой вид капитализации называется title-style capitalization. Когда с большой буквы написано только первое слово, это sentence-style. Так вот, чтобы следовать Windows Vista tone, title-style capitalization должен использоваться только для заголовков окон, все остальные элементы UI должны быть оформлены в стиле sentence. Прочитать об этом и многом другом в оригинале можно тут. К чему этот пост? Да к тому, что все течет, все меняется, не забывайте держать руку на пульсе :)

Мифы и грабли: Вы не обеспечиваете качество тестированием

Наверное многие тестировщики и QA-инженеры думают о себе как о гаранте качества. Вот только вы не привносите это качество, впрочем, как и не убавляете. Возможно, вы говорите "я ломаю программу", но правда в том, что она приходит к вам уже сломанная. Качество обеспечивается теми, кто разрабатывает продукт и, порой, оказывается слишком тяжелой ношей для них. Большая часть вашей миссии состоит в том чтобы помочь бедолагам распределить ношу наиболее эффективно. Вы не сможете справиться с этой задачей достаточно хорошо, если будете думать что вы единственный в команде, кто озабочен выпустить классный продукт.

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

Из книги "Lessons Learned in Software Testing" Kaner, Bach, Pettichord

Tools: Snipping Tool - встроенный в Windows Vista инструмент захвата изображений

Наверняка я не открываю Америку, но тем не менее. Если вы работаете на Windows Vista Home Premium, Business, Enterprise или Ultimate, вы можете использовать встроенное средство для захвата изображений - Snipping Tool (Ножницы в русской локализации).






















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

• Произвольная форма. Обведите требуемый объект произвольной линией, например образующей круг или треугольник.
• Прямоугольник. Заключите объект в прямоугольник, протащив курсор вокруг объекта.
• Окно. Выберите требуемое окно (например, окно обозревателя или диалоговое окно).
• Весь экран. Также можно сделать снимок всего экрана.

Готовый фрагмент автоматически копируется в окно, где доступны такие инструменты как многоцветное перо, маркер и ластик. Сохранить можно в форматах PNG, GIF, JPEG или HTML (MHT). Также есть возможность отправить картинку по почте. Если вам нужно захватить какую-либо нестатичную область, например открытое меню, сделайте следующее:

1. Откройте Snipping Tool.
2. Нажмите ESCAPE и откройте меню.
3. Нажмите CTRL+PRINT SCREEN.
4. Выбирайте тип выделения и хватайте.

Мифы и грабли: Цель тестирования - поиск ошибок

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





То есть, этому мифу будет посвящено несколько заметок. Тем не менее, ниже я не озвучу свое видение вопроса, а приведу вольный перевод отрывка из книги Рекса Блэка Pragmatic Software Testing, который в свою очередь цитирует Бориса Бейзера (мне очень льстит такая вложенность :) ). Мне сегодня случайно попалась эта глава на глаза, показалась весьма в тему и я решил не откладывать в долгий ящик. Это неплохая пища для ума, а свое скромное мнение я напишу как-нибудь потом, тем более что с гуру трудно не согласиться.

-------
Один из трех основателей современного тестирования ПО, Борис Бейзер, определил пять стадий становления тестировщика:

• Стадия 0: Нет никакой разницы между тестированием и отладкой. Цель тестирования - помощь в поиске и исправлении ошибок;
• Стадия 1: Цель тестирования - доказать что ПО работает;
• Стадия 2: Цель тестирования - доказать что ПО не работает;
• Стадия 3: Цель тестирования не в том, чтобы что-то доказать, а в понижении предполагаемых рисков, приводящих к неработающему ПО, до приемлемого уровня;
• Стадия 4: Тестирование это не этап. Это интеллектуальная деятельность которая приводит к получению надежного и стабильного ПО без больших трудоемких затрат на тестирование.

Первые две стадии можно рассматривать как миф людей и организаций с незрелыми практиками и процессами тестирования (для исчерпывающего описания см. книгу Б.Бейзера Software Testing Techniques).

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

Однако вы можете прогрессировать до стадии 3. На этой стадии тестирование является составляющей всеобъемлющей стратегии управления рисками. Тестирование ориентировано на риски. Тестирование предоставляет информацию, имеющую отношение к рискам. Эта книга может научить вас как достичь и этого.

Стадия 4 больше отражает организационное мировоззрение, нежели тестерское. Тестирование - и вовлечение в тестирование - становится широко распространенным в организации, все будут действовать таким образом, чтобы уменьшить количество ошибок до запуска теста.

Итак, на какой стадии вы сейчас находитесь и почему? На какой стадии хотят вас видеть коллеги и начальство и почему? На какой стадии нужно вашей организации чтобы вы находились и почему?
-------

Думаю, в следующих заметках на эту тему я опять обращусь к кому-нибудь из классиков.

Tools: Locky - инструмент блокировки файлов

Некий Evil Tester решил поделиться самописным инструментом, который позволяет блокировать доступ к файлам. Количество заблокированных файлов может достигать 64. Небольшая инструкция по использованию прилагается в архиве, который можно скачать здесь.

Ссылка на источник

Анонс: Мифы и грабли тестирования

Всем известен постулат: "любая программа содержит ошибки". Или "тестирование это бесконечный процесс". А также многие другие. К сожалению, среди этих многих других, часто встречаются заблуждения. Например, что цель тестирования - поиск ошибок или что тестирование обеспечивает качество и так далее. Я читаю об этом на форуме тестировщиков, слышу на собеседованиях (особенно от малоопытных специалистов), припоминаю какие-то свои ошибки или сам их совершаю. В итоге, я решил начать коллекционировать эти мифы и грабли и буду пробовать потихоньку разрушать их в этом блоге. На истину в последней инстанции не претендую, поэтому все возмущения от моей дерзости с удовольствием буду принимать и парировать в комментариях. Следите за блогом.

На фото: Кэри Байрон из телешоу "Разрушители легенд"

Tools: Problem Steps Recorder в Windows 7

Наверное, многие уже знают о распространяемой Microsoft бесплатной бета-версии Windows 7 для тестирования.
Так вот, в данную сборку включена удобная утилита для быстрой и несложной записи последовательности действий пользователя. В результате работы программы получается ZIP-файл, в котором запакован MHTML-отчет о действиях пользователя. Пример такого отчета можно посмотреть здесь. Запускается данная утилита из Панели Управления или Start\Run\psr.exe. Небольшую видеопрезентацию можно скачать отсюда.

Как её оттуда выковырять пока не разбирался.

Update: Не работает с Qt :(

Tools: Om for software testing

Простая и полезная программка для генерации текстовых строк различной длины и содержания.

Om (pronounced as "Oh m") is a free command line tool for generating stressfull text data for field testing as well as Random testing. The data generated can be copied anywhere using Ctrl + v. (e.g. It can be copied to any field of the test Application or as a Test data in Test Case file).

Features

• Om can generate data in three different ways using its three different modes of Operation.

• User can provide an option for generating data consisting of different character types like uppercase, lowercase, numerical, others or any combination of the above four.

• Om comes with User Manual for complete guidance to its users.

• Om is free software. This means that everyone may use it, redistribute it and/or modify it under the terms of the GNU General Public License, as published by the Free Software Foundation.

Downloads:
Click here to download Om1.0 for windows. (Download includes User Manual).

About Author
Sanket Vaidya is a software test engineer at Patni Computer Systems Ltd. , India

Источник: http://omfortesting.110mb.com/

Обнаруживайте серьезные проблемы быстро

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

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

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

Из книги Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord

7 основных принципов Context-Driven школы тестирования.

Disclaimer: все переводы это личная забава автора, являются весьма вольными и ни на что не претендуют. Критика в комментариях приветствуется.

1. Ценность каждого решения зависит от условий его применения.
2. Есть много вариантов решений, но нет лучшего.
   
3. Команда - самая важная составляющая любого проекта.
4. Часто проекты отнимают много времени там, где мы этого не ждем.
5. Продукт - это конечное решение. Если задача не решается, продукт не работает.
6. Грамотное тестирование это сложный интеллектуальный процесс.
7. Только здравый смысл и мастерство, совместно прилагаемые на протяжении всего проекта, позволят нам сделать все правильно и в срок, чтобы эффективно протестировать наши продукты.

Пояснения принципов в действии:

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

Пример:

Рассмотрим два проекта:

1. Разработка системы управления самолетом. Корректное поведение означает высочайшую техническую и математическую точность. Соответствие требованиям Федерального авиационного агентства. Всё, что вы делаете (или не делаете) может стать основанием для суда в течение 20 лет. В команде прививается инженерная культура в которой ценятся такие качества как осторожность, точность, повторяемость и двухсторонний контроль.
2. Разработка текстового процессора для Веба. Корректное поведение в данном случае значит потакать огромному числу пользователей Microsoft Word для их привлечения к вашему продукту. Нет регулярных требований имеющих значение (кроме отвечающих общим потребностям). Через 20 месяцев надо выпустить продукт, хороший либо плохой. Команда не следует инженерной культуре, попытки следовать культуре из первого случая будут приводить к ущербу для окружающих.

• Методы тестирования подходящие для первого проекта обречены на провал во втором.
• Методы подходящие для второго будут выглядеть преступно халатными в первом.
  

Источник: http://www.context-driven-testing.com/