Показаны сообщения с ярлыком memento. Показать все сообщения
Показаны сообщения с ярлыком memento. Показать все сообщения

18 авг. 2009 г.

51 основное качество успешного проекта


У нас в офисе, над кофе-машиной висит бумажка:
Чтобы стать успешным, проект должен сочетать в себе 51 основное качество (переводить не буду):
1. Accessibility
2. Affordability
3. Beauty
4. Build
5. Caching
6. Code Coverage
7. Compatibility
8. Complexity
9. Consistency
10. Credibility
11. Cyclomatic complexity
12. Discoverability
13. Documentation
14. Efficiency
15. Ethics
16. Extensibility
17. Honesty
18. Integration
19. Licensing
20. Logging and instrumentability
21. Maintainability
22. Marketability
23. Memorability
24. Modularity
25. Open-ness
26. Optimisibility
27. Originality
28. Parallelability
29. Performance
30. Platform versatility
31. Popularity
32. Power
33. Practicality
34. Predictability
35. Purity
36. Readability
37. Reliability
38. Remarkability
39. Responsiveness
40. Reusability
41. Robustness
42. Scalability
43. Scriptability (automatability)
44. Security
45. Simplicity
46. Testability
47. Transparency
48. Trustworthiness
49. Usability
50. User eXperience
51. Versatility

Вы можете позволить себе три.
Два из них - безопасность (44 - security) и удобство использования (49 - usability).
Выберите ещё одно.

Источник http://secretgeek.net/core51.asp

9 авг. 2009 г.

Вы считаете себя экспертом в тестировании?


Тогда проанализируйте следующие утверждения:
1. Я должен составлять тест-план.
2. Важно, чтобы тестирование обладало свойством повторяемости.
3. Каждый тест-кейс должен иметь ожидаемый результат.
4. Автоматизация экономит деньги и время.
5. Все тесты основываются на модели того, что должно быть протестировано.
6. Достаточно хорошее качество (good enough) недостаточно хорошее.
7. Недокументированный тест не может быть улучшен.
8. Лучше использовать термин дефект нежели баг/ошибка.
9. Exploratory testing - полезная практика.
10. Неопределенность и двусмысленность должны быть исключены из требований.

Из доклада J.Bach "Becoming a Software Testing Expert"

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

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

27 февр. 2009 г.

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

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

27 дек. 2008 г.

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

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

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