Сегодня чинил то, что сломано, проверял то, что еще не сломано, понимал то, что не успел понять.
Слово Канеру:
Ты не гарантируешь качество тестированием.
Очень легко считать себя блюстителем качества. Но ты не создаешь качество, и ты не убавляешь его. Ты можешь сказать, что ты "сломал продукт", но на самом деле он уже был сломан. Качество приходит от людей, которые создают продукт, и они несут тяжелое бремя, чтоб обеспечить это качество. Большая часть твоих задач состоит в том, чтоб помогать им нести это бремя более эффективно. И ты не можешь делать это до тех пор, пока считаешь, что ты единственный, кто заботится о запуске хорошего продукта.
Твоя команда может называться "Обеспечение качества". Не позволяй этому проникнуть в твою голову. Результаты твоих тестов и отчеты предоставляют информацию, которая облегчает обеспечение качества проекта, но само качество является результатом усилий всей команды.
среда, 31 августа 2011 г.
Lesson 10
Ну ничотак, шесть тестов и еще добрейшее начальство утвердило мой особый отпуск. С послезавтра, да.
Слово Канеру:
Опасайтесь "завершения" тестирования.
Некоторые тестировщики, из тех, что согласны, что они не смогут найти все баги продукта говорят, что это означает окончание тестирования в любой момент. Слова "Мне понадобится пять дней на то, чтоб протестировать это" могут быть поняты как то, что вы полностью(!) протестируете часть продукта за пять календарных дней. Это может быть понято, как то, что вы найдете каждый баг за эти пять дней. Полнота чаще подразумевается, нежели указывается. В любом случае, от этого нужно лечиться с большой осторожностью. Подумайте о том, что может означать окончание тестирования:
- Завершение поиска дефектов в продукте.
- Завершение рассмотрения какой-либо части продукта.
- Завершение тестирования, потому что вы верите, что эффективно работали все это время.
- Завершение выполнения целей проекта в меру ваших способностей
- Завершение выполнения согласованных тестов.
- Завершение тестирования того, что способен потестировать человек при данных обстоятельствах.
- Завершение всего того, что вы знали как делать.
- Завершение вашей части тестирования, вне зависимости от остальных частей.
- Завершение широкого, но не глубокого тестирования продукта.
- Завершение одного вида тестирования продукта.
- Завершение времени, отведенного на тестирование.
Если вы заботитесь о ясности и не говорите "завершено", "закончено", "выполнено", то вы, вероятно, в безопасности. Вас реже обвиняют в том, что вы не делаете свою работу и вы лучше защищены от обвинений. Знайте, что определение "завершения" не устоялось окончательно к старту проекта. Оно будет пересмотрено вместе с эволюцией проекта и новые задачи тестирования будут возникать постоянно.
Чтоб справиться с главной проблемой недопонимания критериев завершения, покажите детали процесса тестирования клиентам. Суммируйте то ,что вы тестируете и почему вы это тестируете, и расскажите клиентам о том, что вы делаете. что не делаете и почему.
Слово Канеру:
Опасайтесь "завершения" тестирования.
Некоторые тестировщики, из тех, что согласны, что они не смогут найти все баги продукта говорят, что это означает окончание тестирования в любой момент. Слова "Мне понадобится пять дней на то, чтоб протестировать это" могут быть поняты как то, что вы полностью(!) протестируете часть продукта за пять календарных дней. Это может быть понято, как то, что вы найдете каждый баг за эти пять дней. Полнота чаще подразумевается, нежели указывается. В любом случае, от этого нужно лечиться с большой осторожностью. Подумайте о том, что может означать окончание тестирования:
- Завершение поиска дефектов в продукте.
- Завершение рассмотрения какой-либо части продукта.
- Завершение тестирования, потому что вы верите, что эффективно работали все это время.
- Завершение выполнения целей проекта в меру ваших способностей
- Завершение выполнения согласованных тестов.
- Завершение тестирования того, что способен потестировать человек при данных обстоятельствах.
- Завершение всего того, что вы знали как делать.
- Завершение вашей части тестирования, вне зависимости от остальных частей.
- Завершение широкого, но не глубокого тестирования продукта.
- Завершение одного вида тестирования продукта.
- Завершение времени, отведенного на тестирование.
Если вы заботитесь о ясности и не говорите "завершено", "закончено", "выполнено", то вы, вероятно, в безопасности. Вас реже обвиняют в том, что вы не делаете свою работу и вы лучше защищены от обвинений. Знайте, что определение "завершения" не устоялось окончательно к старту проекта. Оно будет пересмотрено вместе с эволюцией проекта и новые задачи тестирования будут возникать постоянно.
Чтоб справиться с главной проблемой недопонимания критериев завершения, покажите детали процесса тестирования клиентам. Суммируйте то ,что вы тестируете и почему вы это тестируете, и расскажите клиентам о том, что вы делаете. что не делаете и почему.
вторник, 30 августа 2011 г.
Новости нашего городка
В Екатеринбурге рушат старинную усадьбу XIX века.
Розы Люксембург, 65 и 67.
Вот вид на памятник архитектуры.
Пару лет ежедневно ходил мимо. Художественной, архитектурной, иной ценности не видел, впочем я не специалист, возможно она скрыта от посторонних глаз. Зато видел, что на тротуар выпадывают куски памятника.
Надеюсь, что эту кучу кирпичей снесут полностью.
Розы Люксембург, 65 и 67.
Вот вид на памятник архитектуры.
 |
| Альбом: home |
Пару лет ежедневно ходил мимо. Художественной, архитектурной, иной ценности не видел, впочем я не специалист, возможно она скрыта от посторонних глаз. Зато видел, что на тротуар выпадывают куски памятника.
Надеюсь, что эту кучу кирпичей снесут полностью.
Lesson 9
Сегодня вечером написал пару хороших тестов.
Днем наша ведущая программистка прямо на лекции срывала для нас покровы с OSGi.
А утром посчитал статистику наколбашивания методов в модуль. Почти за два года. Выяснил, что я - это примерно два стажера. Или две трети опытного сотрудника.
Слово Канеру:
Ты никогда не найдешь все баги продукта.
Твоя работа - искать и сообщать о значимых багах. Но ты никогда не найдешь все. Для того, чтоб найти их все ты должен посмотреть всюду, где могут скрываться баги, для каждой ситуации, в которой они могут возникнуть, и тебе понадобится надежный способ идентификации каждого вида бага. Если ты думаешь, что ты можешь это сделать, то у тебя или очень простой продукт или очень ограниченное воображение.
Ты должен выбрать, на что тратить свое время, зная. что ты не сможешь сделать все.
Днем наша ведущая программистка прямо на лекции срывала для нас покровы с OSGi.
А утром посчитал статистику наколбашивания методов в модуль. Почти за два года. Выяснил, что я - это примерно два стажера. Или две трети опытного сотрудника.
Слово Канеру:
Ты никогда не найдешь все баги продукта.
Твоя работа - искать и сообщать о значимых багах. Но ты никогда не найдешь все. Для того, чтоб найти их все ты должен посмотреть всюду, где могут скрываться баги, для каждой ситуации, в которой они могут возникнуть, и тебе понадобится надежный способ идентификации каждого вида бага. Если ты думаешь, что ты можешь это сделать, то у тебя или очень простой продукт или очень ограниченное воображение.
Ты должен выбрать, на что тратить свое время, зная. что ты не сможешь сделать все.
Lesson 8
В этот раз получилось особенно ужасно, да...
Слово Канеру:
Фокусируйся на сбоях, как твои клиенты фокусируются на успехе.
Тестировщик - единственная роль в проекте, которая не фокусируется на успехе. Другие что-нибудь создают или описывают то, что создано. Но тестировщики негативны. Это может быть депрессивной работой, почти как в греческом мифе: "На острове тестировщиков, они должны вечно искать доказательства тому, что облака не существуют и не должны существовать, зная, что их успех принесет несчастья Богу".
Было бы ошибкой переопределить вашу цель более позитивно, как кого-то, кто удостоверяется, что программа работает. Даже если "удостовериться что программа работает" будет вашей целью, расскажите вашим ваших клиентов, что такая верификация невозможна. Это отвратительно дорого. Пока вы не запустите все возможные тесты, вы не докажете, что продукт работает. Лучше всего будет, если вы скажете: "Для тестов, которые выполнены, я не могу сказать, что продукт не работает". В противоположность предыдущему высказыванию, это удивительно экономно: С всего лишь одним тестом, ты можешь показать, что продукт не работает.
Тестировщики фокусируются на сбоях, так как это повышает шансы обнаружить их. Смотри в ключ проблем продукта со всей возможной изобретательностью и умением. Если ты не найдешь проблему - ее не исправят. и многие пользователи смогут найди ее для тебя. Поиском всего, что можно найти в продукте, ты помогаешь команде улучшить собственные навыки , узнать больше о рисках продукта, ты помогаешь сделать им продукт лучше, и, возможно, более успешным на рынке.
Слово Канеру:
Фокусируйся на сбоях, как твои клиенты фокусируются на успехе.
Тестировщик - единственная роль в проекте, которая не фокусируется на успехе. Другие что-нибудь создают или описывают то, что создано. Но тестировщики негативны. Это может быть депрессивной работой, почти как в греческом мифе: "На острове тестировщиков, они должны вечно искать доказательства тому, что облака не существуют и не должны существовать, зная, что их успех принесет несчастья Богу".
Было бы ошибкой переопределить вашу цель более позитивно, как кого-то, кто удостоверяется, что программа работает. Даже если "удостовериться что программа работает" будет вашей целью, расскажите вашим ваших клиентов, что такая верификация невозможна. Это отвратительно дорого. Пока вы не запустите все возможные тесты, вы не докажете, что продукт работает. Лучше всего будет, если вы скажете: "Для тестов, которые выполнены, я не могу сказать, что продукт не работает". В противоположность предыдущему высказыванию, это удивительно экономно: С всего лишь одним тестом, ты можешь показать, что продукт не работает.
Тестировщики фокусируются на сбоях, так как это повышает шансы обнаружить их. Смотри в ключ проблем продукта со всей возможной изобретательностью и умением. Если ты не найдешь проблему - ее не исправят. и многие пользователи смогут найди ее для тебя. Поиском всего, что можно найти в продукте, ты помогаешь команде улучшить собственные навыки , узнать больше о рисках продукта, ты помогаешь сделать им продукт лучше, и, возможно, более успешным на рынке.
суббота, 27 августа 2011 г.
Lesson 7
Еще день прошел. Написал один тест. Зато хороший.
А еще интернет подключили, сегодня буду делать из ноутбука раздавалку вайфая для телефона.
Слово Канеру:
Спрашивай постоянно, но не обязательно вслух.
Можно тестировать не задавая вопросы, но нельзя тестировать хорошо. Вопросы - основа твоей роли в проекте. Если ты не задаешь вопросы- ты тестируешь бесцельно и механически. Однако постоянные вопросы могут быть провокационными. Они могут заставить людей защищаться. Вопросы - как сильное лекарство, лучше принимать в низких дозах или с едой (с другими видами коммуникации). К счастью, ценность вопросов не уменьшается, если их задавать не вслух. Некоторые вопросы провоцируют собственный разум мыслить в нужном направлении и дают жизненно важное понимание.
Если вам когда нибудь придется тестировать и у вас не будет вопросов - возьмите перерыв.
А еще интернет подключили, сегодня буду делать из ноутбука раздавалку вайфая для телефона.
Слово Канеру:
Спрашивай постоянно, но не обязательно вслух.
Можно тестировать не задавая вопросы, но нельзя тестировать хорошо. Вопросы - основа твоей роли в проекте. Если ты не задаешь вопросы- ты тестируешь бесцельно и механически. Однако постоянные вопросы могут быть провокационными. Они могут заставить людей защищаться. Вопросы - как сильное лекарство, лучше принимать в низких дозах или с едой (с другими видами коммуникации). К счастью, ценность вопросов не уменьшается, если их задавать не вслух. Некоторые вопросы провоцируют собственный разум мыслить в нужном направлении и дают жизненно важное понимание.
Если вам когда нибудь придется тестировать и у вас не будет вопросов - возьмите перерыв.
Lesson 6
Слово Канеру:
Работай вместе с программистами.
Помощь программистам, вероятнее всего, является твоей ключевой задачей. Если ты тестируешь вещи, которые программисты только что или недавно создали, то твой фидбек и твоя помощь будут более эффективными. Тестируй фичи как только их тебе передают. Если они что-то изменили - протестируй это. Стремись к быстрому тестированию, давай настолько быстрый фидбек, насколько сможешь. Пока программисты разжуют баги, что ты нашел - ты найдешь еще баги. Идеальная ситуация (для тестировщика), в том, что программисты настолько заняты фиксом багов, которые ты нашел , что ты не становишься узким местом проекта.
Работай вместе с программистами.
Помощь программистам, вероятнее всего, является твоей ключевой задачей. Если ты тестируешь вещи, которые программисты только что или недавно создали, то твой фидбек и твоя помощь будут более эффективными. Тестируй фичи как только их тебе передают. Если они что-то изменили - протестируй это. Стремись к быстрому тестированию, давай настолько быстрый фидбек, насколько сможешь. Пока программисты разжуют баги, что ты нашел - ты найдешь еще баги. Идеальная ситуация (для тестировщика), в том, что программисты настолько заняты фиксом багов, которые ты нашел , что ты не становишься узким местом проекта.
пятница, 26 августа 2011 г.
Как-то так
Месарош: Наглядным примером того, как не следует поступать, является тестирование бизнес-логики вместе с пользовательским интерфейсом.
Я знал! Эх..
Я знал! Эх..
Меркантильный пост
Продам гарнитуру за 500. Или обменяю. Или подарю, если красивая девушка.
Екб, да.
Екб, да.
Lesson 5
Я тут заметил, что в моем бложике все больше йети подземелья и все меньше хроник тестировщика.
И, хотя у новых читателей не возникает вопросов о том, что за Канер перманентно появляется у меня последнее время, я все равно отвечу.
Потому что ответы без вопросов это все же лучше, чем вопросы без ответов.
Года два назад я с тэгом лекции начал потихоньку переводить книгу Сэма Канера. Просто для того, чтоб читать что-нибудь по-английски. Тогда меня хватило на две с половиной недели и девять уроков. Книги канера у меня не было. И в интернетах я нашел только ее части у гугла в превьюшках. Перевода на русский не было вообще.
Теперь книжка есть у меня на столе. В мае 2009 перевода не было, и сейчас нет. Если найдете - сообщите, я перестану переводить. Хм. Или не сообщайте.
На амазоне она стоит триста ре, а на озоне почему-то две тыщи...
Кстати, не я один озаботился попытками ее перевести. Вот тут тоже пытались, их хватило аж на 15 заметок! У меня уже 14 (вместе с прошлыми), их я обгоню точно. Но у них перевод получше, да.
А этих ребят хватило всего на 11 уроков. Качество перевода тоже повыше моего. С октября 2008 по январь 2009. Их там аж четверо, кстати, бложик жив все еще.
Картинка для привлечения внимания:
Ах да, сегодня починил семь тестов.
А теперь слово Канеру:
Находи критичные баги быстро.
Вероятно, в твои задачи входит поиск критичных багов (в отличие от незначительных), и этот поиск должен быть быстрым. Если так, то что это значит в контексте тестов, которые ты проводишь?
- Тестируй те вещи, которые менялись перед теми, что не менялись. Исправления и обновления означают свежие риски.
- Тестируй базовые функции перед вспомогательными. Тестируй критичные и популярные функции продукта. Тестируй те функции продукта, которые делают его таким. какой он есть.
- Тестируй возможности перед надежностью. Тестируй работоспособность всего функционала перед глубоким погружением в исследование поведения функций в различных условиях.
- Тестируй стандартные условия перед гипотетическими. Используй популярные данные и сценарии использования.
- Тестируй стандартные угрозы перед экзотическими. Проводи тесты на наиболее вероятные стрессовые и багоопасные ситуации.
- Тестируй проблемы, которые могут нанести больший вред. Тестируй те части продукта, которые могут нанести наибольший вред в случае. если они сломаются.
- Тестируй наиболее используемые области продукта перед невостребованными областями. Тестируй те части и проблемы продукта, которые интересны еще кому-либо в команде.
Такде ты можешь раньше найти важные баги продукта, если ты знаешь больше о продукте, программном и аппаратном обеспечении, о людях, которые его используют. Изучи все это хорошенько.
И, хотя у новых читателей не возникает вопросов о том, что за Канер перманентно появляется у меня последнее время, я все равно отвечу.
Потому что ответы без вопросов это все же лучше, чем вопросы без ответов.
Года два назад я с тэгом лекции начал потихоньку переводить книгу Сэма Канера. Просто для того, чтоб читать что-нибудь по-английски. Тогда меня хватило на две с половиной недели и девять уроков. Книги канера у меня не было. И в интернетах я нашел только ее части у гугла в превьюшках. Перевода на русский не было вообще.
Теперь книжка есть у меня на столе. В мае 2009 перевода не было, и сейчас нет. Если найдете - сообщите, я перестану переводить. Хм. Или не сообщайте.
На амазоне она стоит триста ре, а на озоне почему-то две тыщи...
Кстати, не я один озаботился попытками ее перевести. Вот тут тоже пытались, их хватило аж на 15 заметок! У меня уже 14 (вместе с прошлыми), их я обгоню точно. Но у них перевод получше, да.
А этих ребят хватило всего на 11 уроков. Качество перевода тоже повыше моего. С октября 2008 по январь 2009. Их там аж четверо, кстати, бложик жив все еще.
Картинка для привлечения внимания:
 |
| Альбом: cat |
Ах да, сегодня починил семь тестов.
А теперь слово Канеру:
Находи критичные баги быстро.
Вероятно, в твои задачи входит поиск критичных багов (в отличие от незначительных), и этот поиск должен быть быстрым. Если так, то что это значит в контексте тестов, которые ты проводишь?
- Тестируй те вещи, которые менялись перед теми, что не менялись. Исправления и обновления означают свежие риски.
- Тестируй базовые функции перед вспомогательными. Тестируй критичные и популярные функции продукта. Тестируй те функции продукта, которые делают его таким. какой он есть.
- Тестируй возможности перед надежностью. Тестируй работоспособность всего функционала перед глубоким погружением в исследование поведения функций в различных условиях.
- Тестируй стандартные условия перед гипотетическими. Используй популярные данные и сценарии использования.
- Тестируй стандартные угрозы перед экзотическими. Проводи тесты на наиболее вероятные стрессовые и багоопасные ситуации.
- Тестируй проблемы, которые могут нанести больший вред. Тестируй те части продукта, которые могут нанести наибольший вред в случае. если они сломаются.
- Тестируй наиболее используемые области продукта перед невостребованными областями. Тестируй те части и проблемы продукта, которые интересны еще кому-либо в команде.
Такде ты можешь раньше найти важные баги продукта, если ты знаешь больше о продукте, программном и аппаратном обеспечении, о людях, которые его используют. Изучи все это хорошенько.
Lesson 4
Слово Канеру:
То, что ты обнаружил, может быть "багом" по мнению других людей.
Задачи вашей группы включают (или должны включать) информирование клиентов обо всем, что угрожает проекту, в понимании клиентов. Если ты можешь показать, что продукт содержит ошибку, даже если он работает согласно своему предназначению, ты должен сообщить об этом. Если клиенты решат проигнорировать твое сообщение, это их прерогатива.
То, что ты обнаружил, может быть "багом" по мнению других людей.
Задачи вашей группы включают (или должны включать) информирование клиентов обо всем, что угрожает проекту, в понимании клиентов. Если ты можешь показать, что продукт содержит ошибку, даже если он работает согласно своему предназначению, ты должен сообщить об этом. Если клиенты решат проигнорировать твое сообщение, это их прерогатива.
четверг, 25 августа 2011 г.
Lesson 3
Сегодня починил две баги. Или три.
На урале то солнце, то дожди.
Менеджеры провайдера Convex, которым я написал вчера, уже сегодня связались со мной и пообещали выслать монтажников прямо днем.
Монтажники тоже связались со мной, сообщили, что чердак закрыт и они будут только в пятницу. В принципе, нормально.
Внимательно следим за развитием событий и моими отзывами. Конвекс, у меня в уютененьком тысяча уников ;)
Кстати, на тему следующего lesson я как то делал 20-минутный доклад для тестировщиков на нашем демо. У меня было смешнее, у Сэма полнее.
Слово Канеру:
Ты служишь многим клиентам.
Тестирование - это сервис. Прочувствуйте это. Сервис, который ты предоставляешь жизненно важен. Сервис подразумевает наличие клиентов - людей, которым ты служишь. Твой успех измеряется в первую очередь тем, насколько удовлетворены желания и интересы клиентов. Это может не быть трудным, зависит от количества клиентов. Каждый из них имеет свои потребности, но суммарно они сводятся к необходимым:
- Менеджер проекта. ПМ имеет право знать ваш процесс работы и влиять на него. Ты служишь ему тем, что сообщаешь статус работ по его требованию, быстро информируешь о важных проблемах и не являешься узким местом проекта. Прерогатива ПМ'а - управлять проектом. Твоя работа - сказать ему, что ты в состоянии сделать, а что нет, и влиять тестированием на принятие решений в проекте.
- Программист. Ты делаешь работу программиста проще, создавая настолько хорошие багрепорты, насколько это возможно. Старайся знать свое ремесло, знать продукт и не тратить время программиста на ложные или поверхностные багрепорты. Если ты можешь это сделать, то ты заслужишь доверие, получишь поддержку и влияние на программистов.
- Техписатель. Как и ты, люди, которые пишут мануалы и хелпы, имеют неполную информацию о продукте. Ты можешь помочь им понять, как продукт работает на самом деле, ты можешь сообщить им об ошибках в документации. Писатели тоже могут помочь тебе. То, как они исследуют продукт и напишут документ влияет на использование этого продукта людьми, прочитавшими документацию. Если у тебя хорошее отношение с техписателями, то они будут сообщать тебе о новых фичах, новых способах использования, дырах в твоих тест-планах и багах, которые найдут. Некоторые из этих багов никогда не были бы найдены с помощью тест-планов.
- Техсаппорт. Любая проблема в продукте становится бременем техсапорта. Ты сообщаешь группе поддержки о тех аспектах использования продукта, которые могут стать проблемой для пользователей. Если ты взаимодействуешь с ними в процессе разработки, иногда саппорты могут помочь тебе создать хороший кейс. Ты должен также предлагать помощь в исследовании различных проблем продукта, найденных в боевых условиях. Таким образом можно улучшить контакт между техподдержкой и клиентами.
- Маркетинг. Маркетологам нужно знать, является ли что-либо в продукте противоречащим его преимуществам, о которых рассказано клиентам. Баг, который кажется незначительным программистам может оказаться важным для маркетологов. Они могли бы признать этот баг важным для клиентов и выделить его исправление в приоритетную задачу. Также просматривая заявления и документацию маркетологов, ты можешь способствовать точному описанию возможностей продукта.
- Топ менеджмент и акционеры. ты обслуживаешь бизнес. Тут ты должен быть осторожен со словами или действовать как разумный фанат качества. Особенно в конце проекта нужно выполнять работу, учитывая краткосрочные и долгосрочные интересы компании.
- Пользователи. В своем сердце, ты помогаешь тем, кто пользуется продуктом. Их счастье - главная цель проекта, естественно. Но есть и особое удовлетворение в том, чтобы быть главным адвокатом пользователя в команде проекта.
Этот список не отсортирован по приоритету, но в вашем проекте это может быть так как ты это видишь сейчас. Выясни цели своего проекта. Узнай, чему и кому ты служишь. Это первый шаг к отличному тестированию.
На урале то солнце, то дожди.
Менеджеры провайдера Convex, которым я написал вчера, уже сегодня связались со мной и пообещали выслать монтажников прямо днем.
Монтажники тоже связались со мной, сообщили, что чердак закрыт и они будут только в пятницу. В принципе, нормально.
Внимательно следим за развитием событий и моими отзывами. Конвекс, у меня в уютененьком тысяча уников ;)
Кстати, на тему следующего lesson я как то делал 20-минутный доклад для тестировщиков на нашем демо. У меня было смешнее, у Сэма полнее.
Слово Канеру:
Ты служишь многим клиентам.
Тестирование - это сервис. Прочувствуйте это. Сервис, который ты предоставляешь жизненно важен. Сервис подразумевает наличие клиентов - людей, которым ты служишь. Твой успех измеряется в первую очередь тем, насколько удовлетворены желания и интересы клиентов. Это может не быть трудным, зависит от количества клиентов. Каждый из них имеет свои потребности, но суммарно они сводятся к необходимым:
- Менеджер проекта. ПМ имеет право знать ваш процесс работы и влиять на него. Ты служишь ему тем, что сообщаешь статус работ по его требованию, быстро информируешь о важных проблемах и не являешься узким местом проекта. Прерогатива ПМ'а - управлять проектом. Твоя работа - сказать ему, что ты в состоянии сделать, а что нет, и влиять тестированием на принятие решений в проекте.
- Программист. Ты делаешь работу программиста проще, создавая настолько хорошие багрепорты, насколько это возможно. Старайся знать свое ремесло, знать продукт и не тратить время программиста на ложные или поверхностные багрепорты. Если ты можешь это сделать, то ты заслужишь доверие, получишь поддержку и влияние на программистов.
- Техписатель. Как и ты, люди, которые пишут мануалы и хелпы, имеют неполную информацию о продукте. Ты можешь помочь им понять, как продукт работает на самом деле, ты можешь сообщить им об ошибках в документации. Писатели тоже могут помочь тебе. То, как они исследуют продукт и напишут документ влияет на использование этого продукта людьми, прочитавшими документацию. Если у тебя хорошее отношение с техписателями, то они будут сообщать тебе о новых фичах, новых способах использования, дырах в твоих тест-планах и багах, которые найдут. Некоторые из этих багов никогда не были бы найдены с помощью тест-планов.
- Техсаппорт. Любая проблема в продукте становится бременем техсапорта. Ты сообщаешь группе поддержки о тех аспектах использования продукта, которые могут стать проблемой для пользователей. Если ты взаимодействуешь с ними в процессе разработки, иногда саппорты могут помочь тебе создать хороший кейс. Ты должен также предлагать помощь в исследовании различных проблем продукта, найденных в боевых условиях. Таким образом можно улучшить контакт между техподдержкой и клиентами.
- Маркетинг. Маркетологам нужно знать, является ли что-либо в продукте противоречащим его преимуществам, о которых рассказано клиентам. Баг, который кажется незначительным программистам может оказаться важным для маркетологов. Они могли бы признать этот баг важным для клиентов и выделить его исправление в приоритетную задачу. Также просматривая заявления и документацию маркетологов, ты можешь способствовать точному описанию возможностей продукта.
- Топ менеджмент и акционеры. ты обслуживаешь бизнес. Тут ты должен быть осторожен со словами или действовать как разумный фанат качества. Особенно в конце проекта нужно выполнять работу, учитывая краткосрочные и долгосрочные интересы компании.
- Пользователи. В своем сердце, ты помогаешь тем, кто пользуется продуктом. Их счастье - главная цель проекта, естественно. Но есть и особое удовлетворение в том, чтобы быть главным адвокатом пользователя в команде проекта.
Этот список не отсортирован по приоритету, но в вашем проекте это может быть так как ты это видишь сейчас. Выясни цели своего проекта. Узнай, чему и кому ты служишь. Это первый шаг к отличному тестированию.
среда, 24 августа 2011 г.
Пыщ!
Решил я пройтись путем Брейвика. Открыл сейф, взял ствол. Прикрутил глушилку. Взял четыре магазина. И пошел за пивом.
Сначала встретились две девченки, на велосипедах. Красивые. Вот ведь жены кому-то будут, подумал. Потом видел пацанва в футбол гоняет. Бабку с внуком олигофреном видел, помог им через лужу перебраться.
Видел двух таджиков, тяжелый кабель тащили. Ну если их застрелить, кто кабель донесет?
Так я и не выступил по-брейвиковски. Обидно.
Пришел домой, открутил глушитель, и все сложил в сейф.
от, via
Сначала встретились две девченки, на велосипедах. Красивые. Вот ведь жены кому-то будут, подумал. Потом видел пацанва в футбол гоняет. Бабку с внуком олигофреном видел, помог им через лужу перебраться.
Видел двух таджиков, тяжелый кабель тащили. Ну если их застрелить, кто кабель донесет?
Так я и не выступил по-брейвиковски. Обидно.
Пришел домой, открутил глушитель, и все сложил в сейф.
от, via
Lesson 2
А я сегодня написал 5 тестов.
Дальше Канер:
Твои цели управляют тем, что ты делаешь.
Твои цели могут зависеть от отрасли, компании, проекта или состава команды. Тестирование проектов сильно варьируются от места к месту. Проблемой эволюции тестирования как ремесла были трудности создания связей между практиками тестирования, охватывающие культурные и технические различия между ними. Многие из этих различий обусловлены разными целями команд тестирования.
Например, в некоторых организациях тест-план это только инструмент, помогающий тестировщикам. Он может быть написан на салфетке и по-прежнему сохранять эффективность. Другие организации создают тест-план как продукт, который должен быть поставлен вместе с их программным обеспечением. Их тест-план соответствует строгим требованиям и инструкциям.
Некоторые из следующих требований могут определить твою цель. Какие из них ждут от тебя?
- Найти важные дефекты быстро
- Обеспечить оценку качества продукта
- Удостовериться, что продукт отвечает конкретным стандартам
- Помочь клиентам улучшить качество и тестируемость продукта
- Удостовериться, что процесс тестирования соответствует стандартам
- Научить клиентов тестированию и совместной работе с тестировщиками
- Следовать конкретному набору методов и правил
- Помочь предсказывать и контролировать расходы на техподдержку
- Помочь клиентам улучшить их процессы
- Выполнить свою работу с минимальными расходами, за минимальное время или с минимумом негативных последствий
- Делать все, что требует конкретный клиент
Если ты тратишь время и усилия на выполнение требований, которые не волнуют клиентов, вы рискуете быть лишним и контрпродуктивным. Договоритесь о ваших целях с менеджером. Проясните их. Если вы не можете прийти к соглашению касательно ваших целей, то вы не имеете прочного основания для того, что вы будете делать.
Что вы должны делать, когда вы не знаете, что делать? Один вопрос укажет вашу цель. Он идентифицирует суть проблемы, которую вы имеете. Если у вас нет цели тестирования, вы могли бы определить конкретно, что вы будете делать дальше. Также можно объяснить вашу роль окружающим простыми словами. Если вы не можете понять свою цель по каким-то причинам, обсудите этот вопрос с менеджментом сразу.
Что вы должны делать, когда вы не знаете, что делать? Изредка возвращайтесь к вашим целям, чтоб удостовериться, что ваш план не сосредоточен вокруг одной части проблемы, и что вы не забыли о отдыхе.
Дальше Канер:
Твои цели управляют тем, что ты делаешь.
Твои цели могут зависеть от отрасли, компании, проекта или состава команды. Тестирование проектов сильно варьируются от места к месту. Проблемой эволюции тестирования как ремесла были трудности создания связей между практиками тестирования, охватывающие культурные и технические различия между ними. Многие из этих различий обусловлены разными целями команд тестирования.
Например, в некоторых организациях тест-план это только инструмент, помогающий тестировщикам. Он может быть написан на салфетке и по-прежнему сохранять эффективность. Другие организации создают тест-план как продукт, который должен быть поставлен вместе с их программным обеспечением. Их тест-план соответствует строгим требованиям и инструкциям.
Некоторые из следующих требований могут определить твою цель. Какие из них ждут от тебя?
- Найти важные дефекты быстро
- Обеспечить оценку качества продукта
- Удостовериться, что продукт отвечает конкретным стандартам
- Помочь клиентам улучшить качество и тестируемость продукта
- Удостовериться, что процесс тестирования соответствует стандартам
- Научить клиентов тестированию и совместной работе с тестировщиками
- Следовать конкретному набору методов и правил
- Помочь предсказывать и контролировать расходы на техподдержку
- Помочь клиентам улучшить их процессы
- Выполнить свою работу с минимальными расходами, за минимальное время или с минимумом негативных последствий
- Делать все, что требует конкретный клиент
Если ты тратишь время и усилия на выполнение требований, которые не волнуют клиентов, вы рискуете быть лишним и контрпродуктивным. Договоритесь о ваших целях с менеджером. Проясните их. Если вы не можете прийти к соглашению касательно ваших целей, то вы не имеете прочного основания для того, что вы будете делать.
Что вы должны делать, когда вы не знаете, что делать? Один вопрос укажет вашу цель. Он идентифицирует суть проблемы, которую вы имеете. Если у вас нет цели тестирования, вы могли бы определить конкретно, что вы будете делать дальше. Также можно объяснить вашу роль окружающим простыми словами. Если вы не можете понять свою цель по каким-то причинам, обсудите этот вопрос с менеджментом сразу.
Что вы должны делать, когда вы не знаете, что делать? Изредка возвращайтесь к вашим целям, чтоб удостовериться, что ваш план не сосредоточен вокруг одной части проблемы, и что вы не забыли о отдыхе.
вторник, 23 августа 2011 г.
Lesson 1
Контора доставляет в офис книги же!
Ты "свет фар" проекта.
Проект - как дорожное приключение. Некоторые проекты просты и рутинны, как дневная поездка в магазин. Но большинство проектов скорее похожи на вождение внедорожника по горам, ночью. Таким проектам необходим свет фар. Как тестировщик, ты освещаешь путь. Ты освещаешь дорогу перед программистами, менеджерами, может быть они увидят по карте, мимо чего они проезжают и как близко находятся к краю скалы.
Конкретная цель группы тестирования меняется от компании к компании, но за деталями есть общий фактор. Тестируют для поиска информации. Критические решения по проекту или продукту принимают на основе этой информации.
 |
| Альбом: office |
Ты "свет фар" проекта.
Проект - как дорожное приключение. Некоторые проекты просты и рутинны, как дневная поездка в магазин. Но большинство проектов скорее похожи на вождение внедорожника по горам, ночью. Таким проектам необходим свет фар. Как тестировщик, ты освещаешь путь. Ты освещаешь дорогу перед программистами, менеджерами, может быть они увидят по карте, мимо чего они проезжают и как близко находятся к краю скалы.
Конкретная цель группы тестирования меняется от компании к компании, но за деталями есть общий фактор. Тестируют для поиска информации. Критические решения по проекту или продукту принимают на основе этой информации.
понедельник, 22 августа 2011 г.
среда, 17 августа 2011 г.
пятница, 12 августа 2011 г.
А как вам такая музыка?
The Blood Of Cu Chulainn
Vilona - Irish Dance
Это видео для отвлечения внимания. А на самом деле я посылаю лучи уважения live-in-felix который опщемта говорит достаточно простые вещи, которые натолкнут на достаточно непростые мысли.
Vilona - Irish Dance
Это видео для отвлечения внимания. А на самом деле я посылаю лучи уважения live-in-felix который опщемта говорит достаточно простые вещи, которые натолкнут на достаточно непростые мысли.
вторник, 9 августа 2011 г.
пятница, 5 августа 2011 г.
Пыщ!
Многие девушки не понимают, что идеал - это не рыцарь на белом коне, а как раз тот самый дракон
Подписаться на:
Сообщения (Atom)