25 мар. 2009 г.

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

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

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

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

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

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

20 мар. 2009 г.

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

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


Опубликованная в 1989 году книга Стивена Кови "7 навыков высокоэффективных людей" помогла миллионам людей повысить свою эффективность как в жизни, так и в работе. В данной статье обсуждаются 7 навыков, характерных для высокоэффективных тестировщиков. Итак, навыки:
  1. Проактивность (упреждение)
  2. Видеть результат работы в её начале
  3. Начинать с самого главного
  4. Мыслить Win\Win
  5. Сначала понять самому, потом искать понимание
  6. Синергизм
  7. Точить пилу


Навык 1 - Проактивность
Цель тестировщика в любом проекте - добиться поставки ПО высокого качества. Когда проекты терпят неудачу из-за их плохого качества, вы либо упреждаете проблемы либо реагируете на последствия после анализа причин. Если вы реагируете, вы будете обвинять в проблемах и препятствиях других людей и обстоятельства. Если вы проактивны, вы берете ответственность на себя и ищете возможность предотвратить такие проблемы в будущем. На завершающей стадии каждого проекта ваша команда проводит "post mortem" или "retrospective" митинги на которых открыто обсуждается что было сделано хорошо а что плохо. Ниже представлены несколько идей, как быть проактивным:
  • Будь ответственным за требования. Не критикуй других за плохие требования. Вместо этого, работай с командой над полным анализом требований чтобы обеспечить их полноту, точность и тестируемость.
  • Анализируй отслеживаемость (traceability). Создание матрицы отслеживаемости позволит тебе проанализировать тест-кейсы на покрытие, тестируемость и полноту. Обсуждай на общих митингах свои тест-кейсы, чтобы удостовериться в понимании требований и адекватном тестовом покрытии. Отправляй свои тесты на ревью команде разработчиков до начала тестирования, это может сократить количество исправлений и сэкономить время.
  • Общайся эффективно. Во время тестирования, необходимо, чтобы все знали состояние дел в тестировании. Сообщай различными способами свой ежедневный статус. Включай в него метрики, такие как количество дефектов, покрытие требований, количество пройденных кейсов и т.п.
  • Описывай дефекты эффективно. Когда пишешь отчет об ошибке, не жалей времени на составление хорошего описания, шагов воспроизведения и ожидаемых результатов. Добавляй снимки экранов и другую полезную для воспроизведения ошибки информацию.
Навык 2 - Видеть результат работы в её начале
Конечной целью должна быть поставка высококачественного продукта, отвечающего всем требованиям клиента. До начала кодирования необходимо составить список критериев, который позволит судить об успешности продукта. Например, таким критерием может быть то, что продукт выполняет определенные задачи, не содержит известных дефектов (или небольшое количество малокритичных), хорошо задокументирован, прост в использовании и т.д. Определяя критерии успеха наперед, вы сможете объективно оценить, удовлетворяет ли им ваш продукт или нет. Просите помощи в определении критериев у всех членов команды. Выработанные командой критерии будут лучше и более измеримыми и в итоге вы получите неплохой "прикуп" от своей команды.

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

13 мар. 2009 г.

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

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

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


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

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:
  1. Возможно ли составить полный список требований?
  2. Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
  3. Надо ли тестировать то, что в требованиях не описано?
  4. Верны ли требования сами по себе?
  5. Я что, долбаный робот? :) и т.д.
Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

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

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

4 мар. 2009 г.

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 в Вашингтоне, Сан-Франциско, Лондоне.

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

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

  • 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