Я продолжу раззадоривать любопытство тех, кто еще не читал Рона Патторна, приводя любопытные цитаты из его книжки.
Финальный продукт, который мы отдаем Заказчику, состоит не только сам из себя, как это могло бы показаться
It`s unfortunate, but these components are often overlooked in the testing process. You`ve surely attempted to use a product`s built-in help file and found it to be not so helpful or-worse-just plain wrong. Or, maybe you`ve checked the system requirements on a sticker on the side of software box only to find out after you bought it that the software didn`t work on your PC. These seem like simple things to test, but no one probably even gave them a second look before the product was okayed for release.
К сожалению, про эти компоненты мы часто забываем в процессе тестирования. И вот вы, пользователь, открываете help файл в новом софте, чтобы посмотреть, как его установить и тут оказывается, что он совсем непонятный, или, что еще хуже, просто неправильный. Или, например, вы смотрите на системные требования на стикере на внутренней стороне коробочки для диска только для того, чтобы понять - этот софт на вашем компьютере не установится. Это выглядит так легко - проверить при такие мелочи при тестировании. Но никто, вероятно, просто не обратил на них внимания перед сдачей продукта в релиз.
Посмотрите на свое приложение со стороны пользователя - все ли вам понятно? Сможете ли вы установить приложение самостоятельно, руководствуясь лишь инструкцией?
Вообще, когда вы пишите инструкцию - для кого вы ее пишите, для себя или для пользователя? А ведь последнему порой бывает ой как неочевидно то, что там написано...
Поэтому, обратите внимание на те файлы, про существование которых зачастую просто забывают, увлекшись самим продуктом:
И снова вспомним о том, как сами устанавливали что-то. Например, купили телефон - а как его установить? А тут раз - открыли мануальчик, почитали пошаговую инструкцию и все быстренько сделали!
Ну и потом, даже если вам не нужны пошаговые инструкции, примеры нужны все равно. Во-первых, для наглядности. А во-вторых, чтобы проще было протестировать ваше ПО. Ведь на стороне Заказчика часто есть принимающая сторона, которая должна протестировать ваш продукт, прежде чем согласовать его для поставки в production. И если вы не хотите отвечать на поток писем с вопросами, почему бы заранее не создать примеры?
А уж самим то как удобно! Ушел в отпуск, отдал проект коллеге. Коллега ваш модуль видит впервые, вот что ему за файлы системе на "съедение" отдавать? Какие запросы отправлять через soap чтобы удостовериться хотя бы в том, что этот soap в принципе работает?
А тут раз - и все есть. И все счастливы
И да, отдельное внимание хотелось бы обратить вот на что:
DON`T FORGET TO TEST ERROR MESSAGES!
Подробнее об этом вы можете услышать в Танином докладе "Тестирование юзабилити" на SQA Days 10".
У нас не СПАРТА! Берегите своих пользователей!!
Финальный продукт, который мы отдаем Заказчику, состоит не только сам из себя, как это могло бы показаться
It`s unfortunate, but these components are often overlooked in the testing process. You`ve surely attempted to use a product`s built-in help file and found it to be not so helpful or-worse-just plain wrong. Or, maybe you`ve checked the system requirements on a sticker on the side of software box only to find out after you bought it that the software didn`t work on your PC. These seem like simple things to test, but no one probably even gave them a second look before the product was okayed for release.
К сожалению, про эти компоненты мы часто забываем в процессе тестирования. И вот вы, пользователь, открываете help файл в новом софте, чтобы посмотреть, как его установить и тут оказывается, что он совсем непонятный, или, что еще хуже, просто неправильный. Или, например, вы смотрите на системные требования на стикере на внутренней стороне коробочки для диска только для того, чтобы понять - этот софт на вашем компьютере не установится. Это выглядит так легко - проверить при такие мелочи при тестировании. Но никто, вероятно, просто не обратил на них внимания перед сдачей продукта в релиз.
Посмотрите на свое приложение со стороны пользователя - все ли вам понятно? Сможете ли вы установить приложение самостоятельно, руководствуясь лишь инструкцией?
Вообще, когда вы пишите инструкцию - для кого вы ее пишите, для себя или для пользователя? А ведь последнему порой бывает ой как неочевидно то, что там написано...
Поэтому, обратите внимание на те файлы, про существование которых зачастую просто забывают, увлекшись самим продуктом:
- Help files
- Samples and examples
- Product support info
- Error message
- Setup and installation
- User`s manual
- Labels and stikers
- Icons and art
- Ads and marketing material
- Readme file
И снова вспомним о том, как сами устанавливали что-то. Например, купили телефон - а как его установить? А тут раз - открыли мануальчик, почитали пошаговую инструкцию и все быстренько сделали!
Ну и потом, даже если вам не нужны пошаговые инструкции, примеры нужны все равно. Во-первых, для наглядности. А во-вторых, чтобы проще было протестировать ваше ПО. Ведь на стороне Заказчика часто есть принимающая сторона, которая должна протестировать ваш продукт, прежде чем согласовать его для поставки в production. И если вы не хотите отвечать на поток писем с вопросами, почему бы заранее не создать примеры?
А уж самим то как удобно! Ушел в отпуск, отдал проект коллеге. Коллега ваш модуль видит впервые, вот что ему за файлы системе на "съедение" отдавать? Какие запросы отправлять через soap чтобы удостовериться хотя бы в том, что этот soap в принципе работает?
А тут раз - и все есть. И все счастливы
И да, отдельное внимание хотелось бы обратить вот на что:
DON`T FORGET TO TEST ERROR MESSAGES!
Подробнее об этом вы можете услышать в Танином докладе "Тестирование юзабилити" на SQA Days 10".
У нас не СПАРТА! Берегите своих пользователей!!
Комментариев нет:
Отправить комментарий