Внезапно, но моего отца охмуряли на поучаствоать в какой-то интернет пирамиде интер континенталь по впариванию всякой херни людям.
Очень надеюсь, что в телефонном разговоре я был более убедителен, чем та "ну вроде солидная знакомая тетка", и отговорил батю от участия.
P.S. Давненько не общался хотя бы со свидетелями Иеговы, подрастерял навыки тролинга сектантов.
четверг, 17 ноября 2011 г.
среда, 16 ноября 2011 г.
Lesson 49
Слово Канеру:
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
вторник, 15 ноября 2011 г.
Рутина
Намедни я научил наш фазер открывать несколько модальных окон. Он радостно заурчал и выплюнул в логи 400 багов этого типа. Я тоже радостно заурчал и заслал это специально обученной тестировщице для разбора и регистрации.
Она, почему-то, радости не показала, зато возразила, что воспроизвести удается пару-тройку. Из четырехсот.
Я почесал репу, нашел прогу и провел исследование - как быстро может кликать человек левой кнопкой мыши. Оказалось:
Ваш покорный слуга выжал 300 мс между кликами, мой падаван примерно так же.
Специально обученная тестировщица показала 500 мс и сказала что устала.
Руководитель отдела разработки три минуты разминался, показал 500 мс, обиделся, разозлился и выдал 150 мс
Заглянувший на ваш аттракцион еще не закрыт? программист показал результат 140 мс.
Но автотестеры не подвели. Боец wursternator, временно приданный группе для усиления, скромно улыбнулся, вспомнил геймерскую молодость и удивил нас 90 мс.
Selenium умеет кликать очень быстро. Примерно 70 мс между щелчками.
Я опять почесал репу и выставил тайм-аут быстрой части фазера в 150 мс. Если что - знаю кого позвать воспроизвести багу.
Она, почему-то, радости не показала, зато возразила, что воспроизвести удается пару-тройку. Из четырехсот.
Я почесал репу, нашел прогу и провел исследование - как быстро может кликать человек левой кнопкой мыши. Оказалось:
Ваш покорный слуга выжал 300 мс между кликами, мой падаван примерно так же.
Специально обученная тестировщица показала 500 мс и сказала что устала.
Руководитель отдела разработки три минуты разминался, показал 500 мс, обиделся, разозлился и выдал 150 мс
Заглянувший на ваш аттракцион еще не закрыт? программист показал результат 140 мс.
Но автотестеры не подвели. Боец wursternator, временно приданный группе для усиления, скромно улыбнулся, вспомнил геймерскую молодость и удивил нас 90 мс.
Selenium умеет кликать очень быстро. Примерно 70 мс между щелчками.
Я опять почесал репу и выставил тайм-аут быстрой части фазера в 150 мс. Если что - знаю кого позвать воспроизвести багу.
 |
| Альбом: randompics4lj |
Есть вопросы
Диалог о системе тестирования:
Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас в системе(тестируемой) есть метаданные и метаклассы, мы запутаемся
Я: - Правильно, запутаемся. У нас демократия поэтому будем пользоваться словом контейнер
Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы
Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?
Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.
И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...
Итак, если вы понимаете, о чем я, то скажите:
- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?
P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...
Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас в системе(тестируемой) есть метаданные и метаклассы, мы запутаемся
Я: - Правильно, запутаемся. У нас демократия поэтому будем пользоваться словом контейнер
Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы
Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?
Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.
И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...
Итак, если вы понимаете, о чем я, то скажите:
- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?
P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...
 |
| Альбом: randompics4lj |
суббота, 12 ноября 2011 г.
Lesson 48
Уже часть третья.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Рутина.
Пишу фазер "гатлинга". Тот же самый батон-давитель, но делающий все на скорости максимума человеческих возможностей. Самое сложное - идентифицировать багу.
Кстати, на уровне "нутром чую", но начинаю понимать разницу между профессионалом-тестировщиком и джедаем.
Примерно так: профессионал проведет дизайн или нагрузочное быстро, качественно а, может, в срок. Годный профессионал напоследок подскажет, что делать. Отличный - научит вас.
Сделает не так джедай. Джедай тестирования напишет фреймворк и аналитиков научит фреймворку написал который джедай. Или тест бета проведет. А может кликать вручную начнет просветленный. Или бадминтоном с алкоголем команду займет. Да он может не делать ничего. Иначе или так, неизбежно это к решению проблем с качеством приведет. Силу использует джедай.
Не знаю, как это точнее сформулировать, просто читаю третью часть уроков о тестировании и отчетливо понимаю, что Канер - джедай.
Кстати, на уровне "нутром чую", но начинаю понимать разницу между профессионалом-тестировщиком и джедаем.
Примерно так: профессионал проведет дизайн или нагрузочное быстро, качественно а, может, в срок. Годный профессионал напоследок подскажет, что делать. Отличный - научит вас.
Сделает не так джедай. Джедай тестирования напишет фреймворк и аналитиков научит фреймворку написал который джедай. Или тест бета проведет. А может кликать вручную начнет просветленный. Или бадминтоном с алкоголем команду займет. Да он может не делать ничего. Иначе или так, неизбежно это к решению проблем с качеством приведет. Силу использует джедай.
 |
| Альбом: randompics4lj |
Не знаю, как это точнее сформулировать, просто читаю третью часть уроков о тестировании и отчетливо понимаю, что Канер - джедай.
пятница, 11 ноября 2011 г.
ЫЫЫЫ
История отсюда:
http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php
О тестировании, кстати, многобукаф, с подачи SALar
Для начала небольшая ремарка: у каждого сотрудника нашего банка есть 2 почтовых ящика: один - для переписки внутри банка и еще один - внешний.
На тот ящик, который предназначен для общения с окружающим миром, ясен пень, ежедневно валится разнообразный спам.
Понятно, что он тут же отправляется прямиком в корзину.
Но до сегодняшнего дня внутренняя почта была свободна от этой заразы...
Так вот, в связи с некоторыми изменениями, происходящими у нас на работе, первую половину дня я провожу в одном из наших доп. офисов, а вторую - в центральном офисе на своем рабочем месте.
Сегодняшний день не стал исключением.
Приехав, наконец, к себе в контору, я обнаружил, что работа нашего подразделения парализована.
Чтобы вы вполне могли себе представить картину, открывшуюся мне, когда я зашел в комнату - обрисую ситуацию.
В нашем отделе сидят кроме меня еще 4 человека: начальник нашего Управления, его секретарша, девушка-маркетолог и мой напарник.
Необходимо добавить, что площадь помещения, где мы впятером сидим, превышает, причем сильно, 300 кв. метров (эдакий спортзал).
Так вот, открыв дверь я слышу дикий гогот, что, скажем прямо, не очень характерно для моих коллег (особенно для мужской части коллектива), но при этом никого не вижу...
Выйдя на середину нашей комнаты, я, наконец, вижу, что начальник -солидный мужик лет сорока в своем недешевом костюмчике катается по полу и ржет...
Остальные, впрочем, заняты примерно тем же...
Немая сцена...
Минуты через три к ним возвращается дар речи, и я начинаю хотя бы в первом приближении понимать, что случилось...
Оказывается, сегодня по ВНУТРЕННЕЙ почте ВСЕ сотрудники банка получили письмо следующего содержания:
*************************************************************
Суперцена! Такого еще не было!
Профессиональные минеты от 5 у. е.!
Телефон: 775-**-** (круглосуточно).
*************************************************************
Ну, в принципе, таким текстом сегодня, в век высоких технологий и окончательно победившей сексуальной революции никого не удивишь...
Хотя, конечно, обороты вроде "профессиональный минет" - это сильно!...
Особенно интересно, чем профессиональный отличается от любительского и каковы критерии оценки...
Цена, опять же, весьма привлекательная...
Ну, как бы то ни было, факт остается фактом - письмо получено по внутренней почте (правда адрес отправителя не указан).
Самое забавное - телефон...
Дело в том, что все телефоны в центральном офисе выглядят следующим образом: 775-**-**.
Вы уже догадываетесь, что будет дальше?
Реакция всех очевидцев была синхронной: все схватили телефонные справочники и начали выяснять, кто это хочет нажиться на сослуживцах...
Однако, не все так просто: такой телефон в справочнике не указан...
Но разве можно на этом успокоиться?
Сделав вид, что тема закрыта, все (включая меня) разбрелись по своим местам...
Минуты 2 все усиленно лупили по клавиатуре, создавая видимость работы...
Во внезапно наступившей тишине было отчетливо слышно как все (и я тоже)схватились за телефоны и начали куда-то названивать с таким видом, словно у каждо гогорит контракт на несколько миллионов долларов...
Неудивительно, что спустя секунд 15 все с разочарованным видом положили трубки...
Ничего странного, у всех было занято, потому как ВСЕ звонили по номеру из объявления...
Не знаю что уж так заинтересовало девушек в этой объяве... наверное хотели узнать, как стать профессионалом и грести пятидолларовые бумажки лопатой...
Когда минут через 20 кому-то все-таки удалось прозвониться - выяснилось, что "аппарат абонента временно заблокирован"...
Все разочарованно покурили и разбрелись по своим углам.
Но на этом история не закончилась...
Спустя еще минут 20 к нам зашел один из компьютерщиков и по секрету рассказал, что вчера у нас установили новую офисную мега-супер-пупер-АТС.
Нужно было протестировать ее на предмет того, справится ли она с пиковыми нагрузками (короче, если все разом начнут куда-то звонить или принимать звонки, нае*нется АТС или нет)...
Кто-то из наших компьютерных гениев додумался позвонить в отдел по работе с персоналом и сформулировать задачу.
Весь вчерашний день и начало сегодняшнего в стенах кадрового отдела бушевал мозговой шторм (потому что мозговой штУрм не даст столь выдающихся результатов).
В итоге было сочинено то самое письмо, которое и было разослано всем нам...
Напоследок компьютерщик стрельнул у меня сигаретку про запас и совсем уж по секрету сказал, что АТС все-таки нае*нулся - за первые 10 минут поступило больше трех тысяч звонков (всего в банке работает человек 500)... так что когда технику починят, нас ждет продолжение тестирования.
Кот смотрит в будущее с надеждой.
http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php
О тестировании, кстати, многобукаф, с подачи SALar
Для начала небольшая ремарка: у каждого сотрудника нашего банка есть 2 почтовых ящика: один - для переписки внутри банка и еще один - внешний.
На тот ящик, который предназначен для общения с окружающим миром, ясен пень, ежедневно валится разнообразный спам.
Понятно, что он тут же отправляется прямиком в корзину.
Но до сегодняшнего дня внутренняя почта была свободна от этой заразы...
Так вот, в связи с некоторыми изменениями, происходящими у нас на работе, первую половину дня я провожу в одном из наших доп. офисов, а вторую - в центральном офисе на своем рабочем месте.
Сегодняшний день не стал исключением.
Приехав, наконец, к себе в контору, я обнаружил, что работа нашего подразделения парализована.
Чтобы вы вполне могли себе представить картину, открывшуюся мне, когда я зашел в комнату - обрисую ситуацию.
В нашем отделе сидят кроме меня еще 4 человека: начальник нашего Управления, его секретарша, девушка-маркетолог и мой напарник.
Необходимо добавить, что площадь помещения, где мы впятером сидим, превышает, причем сильно, 300 кв. метров (эдакий спортзал).
Так вот, открыв дверь я слышу дикий гогот, что, скажем прямо, не очень характерно для моих коллег (особенно для мужской части коллектива), но при этом никого не вижу...
Выйдя на середину нашей комнаты, я, наконец, вижу, что начальник -солидный мужик лет сорока в своем недешевом костюмчике катается по полу и ржет...
Остальные, впрочем, заняты примерно тем же...
Немая сцена...
Минуты через три к ним возвращается дар речи, и я начинаю хотя бы в первом приближении понимать, что случилось...
Оказывается, сегодня по ВНУТРЕННЕЙ почте ВСЕ сотрудники банка получили письмо следующего содержания:
*************************************************************
Суперцена! Такого еще не было!
Профессиональные минеты от 5 у. е.!
Телефон: 775-**-** (круглосуточно).
*************************************************************
Ну, в принципе, таким текстом сегодня, в век высоких технологий и окончательно победившей сексуальной революции никого не удивишь...
Хотя, конечно, обороты вроде "профессиональный минет" - это сильно!...
Особенно интересно, чем профессиональный отличается от любительского и каковы критерии оценки...
Цена, опять же, весьма привлекательная...
Ну, как бы то ни было, факт остается фактом - письмо получено по внутренней почте (правда адрес отправителя не указан).
Самое забавное - телефон...
Дело в том, что все телефоны в центральном офисе выглядят следующим образом: 775-**-**.
Вы уже догадываетесь, что будет дальше?
Реакция всех очевидцев была синхронной: все схватили телефонные справочники и начали выяснять, кто это хочет нажиться на сослуживцах...
Однако, не все так просто: такой телефон в справочнике не указан...
Но разве можно на этом успокоиться?
Сделав вид, что тема закрыта, все (включая меня) разбрелись по своим местам...
Минуты 2 все усиленно лупили по клавиатуре, создавая видимость работы...
Во внезапно наступившей тишине было отчетливо слышно как все (и я тоже)схватились за телефоны и начали куда-то названивать с таким видом, словно у каждо гогорит контракт на несколько миллионов долларов...
Неудивительно, что спустя секунд 15 все с разочарованным видом положили трубки...
Ничего странного, у всех было занято, потому как ВСЕ звонили по номеру из объявления...
Не знаю что уж так заинтересовало девушек в этой объяве... наверное хотели узнать, как стать профессионалом и грести пятидолларовые бумажки лопатой...
Когда минут через 20 кому-то все-таки удалось прозвониться - выяснилось, что "аппарат абонента временно заблокирован"...
Все разочарованно покурили и разбрелись по своим углам.
Но на этом история не закончилась...
Спустя еще минут 20 к нам зашел один из компьютерщиков и по секрету рассказал, что вчера у нас установили новую офисную мега-супер-пупер-АТС.
Нужно было протестировать ее на предмет того, справится ли она с пиковыми нагрузками (короче, если все разом начнут куда-то звонить или принимать звонки, нае*нется АТС или нет)...
Кто-то из наших компьютерных гениев додумался позвонить в отдел по работе с персоналом и сформулировать задачу.
Весь вчерашний день и начало сегодняшнего в стенах кадрового отдела бушевал мозговой шторм (потому что мозговой штУрм не даст столь выдающихся результатов).
В итоге было сочинено то самое письмо, которое и было разослано всем нам...
Напоследок компьютерщик стрельнул у меня сигаретку про запас и совсем уж по секрету сказал, что АТС все-таки нае*нулся - за первые 10 минут поступило больше трех тысяч звонков (всего в банке работает человек 500)... так что когда технику починят, нас ждет продолжение тестирования.
Кот смотрит в будущее с надеждой.
 |
| Альбом: randompics4lj |
четверг, 10 ноября 2011 г.
Ы!
Я уже перевел 2 чаптера из лессонсов Канера, если кто не заметил, но тут мне сказали, мол мой уютненький зануден. Я исправлюсь. Наверное.
Фор экзампл, давеча мы с коллегами проводили рисерч и обнаружили страшное: Ничего не найдено!. Что ж, будем жить в таком мире.
Ну и вернем кота.
Фор экзампл, давеча мы с коллегами проводили рисерч и обнаружили страшное: Ничего не найдено!. Что ж, будем жить в таком мире.
Ну и вернем кота.
 |
| Альбом: randompics4lj |
среда, 9 ноября 2011 г.
Рутина.
Наш глав-jenkins до сих пор пишет мне письма о том, что та или иная сборка с main view нестабильна или упала.
Единственное объяснение - он по старой памяти жалуется, хотя я уже давно не занимаюсь поддержкой внутренней инфраструктуры.
Вы не думайте, я не идиот. Команда
cat /home/hudson/.hudson/jobs/*/*.xml |grep
не дает ничего.
Еще я столько не коммичу. И мой мейл давно уже не записан в администраторы системы. Давно - это почти год, с тех пор система неоднократно перезагружалась. Единственное объяснение я написал выше - наша система CI жалуется мне.
Помнит, зараза...
Единственное объяснение - он по старой памяти жалуется, хотя я уже давно не занимаюсь поддержкой внутренней инфраструктуры.
Вы не думайте, я не идиот. Команда
cat /home/hudson/.hudson/jobs/*/*.xml |grep
не дает ничего.
Еще я столько не коммичу. И мой мейл давно уже не записан в администраторы системы. Давно - это почти год, с тех пор система неоднократно перезагружалась. Единственное объяснение я написал выше - наша система CI жалуется мне.
Помнит, зараза...
 |
| Альбом: randompics4lj |
Lesson 47
Днем услышал фразу, что то типа: "Инициализирует инстанс экземпляра класса объекта". Не дословно, но примерно так. Сперва долго пытался понять смысл фразы. Раз пять переспрашивал: Так все-таки что оно делает-то? Делает-то оно что?
Потом мне, вроде бы, объяснили, чего оно делает. Оставшийся час я выяснял, почему оно ТАК называется. Есть же хорошие простые добрые слова...
Слово Канеру:
Ты не освоишь тестирование пока, ты не изобретешь его.
Не изобретай колеса. Подождите-ка. Разве не изобретение колеса снова и снова чаще всего просходит в истории? Разве это плохо? В конце концов, мы ездим на пневматических шинах, а не на гранитных дисках. Есть тысячи, если не миллионы вариаций на тему колеса. Может быть это урок? Кажется, существует как минимум две причины изобрести что-то снова: адаптировать это к новой ситуации, и изучить как это работает. Мастерство требует и того и другого.
У нас есть коллеги, советующие студентам избегать повторного изобретения тестов или придумывания уже существующих идей по тестированию. Это все равно что наука без экспериментов. Учиться у других – это нормально. Мы считаем, что именно так и важно учиться – если не верите, проверьте название этой книги.
Но если это единственный способ изучения – вы никогда не станете мастером в ремесле тестировщика. Вы будете подмастерьем, не более. Следование инструкциям заведет вас не дальше, чем следование по трассе в направлении Марса. Мы призываем вас изучать тестирование в духе великих механиков и великих программистов: разбирайте все до винтиков, задумывайтесь как они работают, и собирайте обратно подругому. Не ограничивайтесь чужой мудростью, будьте автором своей.
Сначала, ваши тесты, идеи, методы, или документы будут так себе. Это нормально. Просто держите свой мозг включенным, наблюдайте за другими тестировщиками, изучайте, и постоянно оценивайте выхлоп от ваших идей. Если вы хотите преуспеть, практикуйтесь.
Мы годами занимаемся тестированием и мы все еще изобретаем, все еще модифицируем старые идеи. Все коллеги, которых мы уважаем, идут тем же путем.
Потом мне, вроде бы, объяснили, чего оно делает. Оставшийся час я выяснял, почему оно ТАК называется. Есть же хорошие простые добрые слова...
Слово Канеру:
Ты не освоишь тестирование пока, ты не изобретешь его.
Не изобретай колеса. Подождите-ка. Разве не изобретение колеса снова и снова чаще всего просходит в истории? Разве это плохо? В конце концов, мы ездим на пневматических шинах, а не на гранитных дисках. Есть тысячи, если не миллионы вариаций на тему колеса. Может быть это урок? Кажется, существует как минимум две причины изобрести что-то снова: адаптировать это к новой ситуации, и изучить как это работает. Мастерство требует и того и другого.
У нас есть коллеги, советующие студентам избегать повторного изобретения тестов или придумывания уже существующих идей по тестированию. Это все равно что наука без экспериментов. Учиться у других – это нормально. Мы считаем, что именно так и важно учиться – если не верите, проверьте название этой книги.
Но если это единственный способ изучения – вы никогда не станете мастером в ремесле тестировщика. Вы будете подмастерьем, не более. Следование инструкциям заведет вас не дальше, чем следование по трассе в направлении Марса. Мы призываем вас изучать тестирование в духе великих механиков и великих программистов: разбирайте все до винтиков, задумывайтесь как они работают, и собирайте обратно подругому. Не ограничивайтесь чужой мудростью, будьте автором своей.
Сначала, ваши тесты, идеи, методы, или документы будут так себе. Это нормально. Просто держите свой мозг включенным, наблюдайте за другими тестировщиками, изучайте, и постоянно оценивайте выхлоп от ваших идей. Если вы хотите преуспеть, практикуйтесь.
Мы годами занимаемся тестированием и мы все еще изобретаем, все еще модифицируем старые идеи. Все коллеги, которых мы уважаем, идут тем же путем.
вторник, 8 ноября 2011 г.
Lesson 46
Интересный способ оценки проекта. Один из.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
пятница, 4 ноября 2011 г.
Lesson 45
Слово Канеру:
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
четверг, 3 ноября 2011 г.
Lesson 44
Сегодня ничего не понимаю.
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
 |
| Альбом: randompics4lj |
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
среда, 2 ноября 2011 г.
Lesson 43
Примерно с 2.9 релиза selenium начал нормально отрабатывать MoveTargetOutOfBoundsException — это когда нельзя пецкнуть элемент, находящийся вне рабочей области браузера. Cегодня обновил pom.xml и на тебе: наш «боевой фазер» находит четверть сотни такой хрени — и это на чистой базе.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
 |
| Альбом: randompics4lj |
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
понедельник, 31 октября 2011 г.
Хорошо.
Помните, как-то весной я рассказывал, что у нас в городе побывала Наталья Руколь?
У меня еще появился прикольный календарик с автографом.
На днях она еще раз приезжала к нам рассказать о планированиии и проектировании тестов.
Меня, как водится, там не было, но начальство, которое там, как водится, было, еще раз передало мне приятный ништячок от Натальи.
Раз:
А унутре у неенеонка автограф, ага.
P.S. Ну и еще руководство всяко хвалило сей тренинг, да.
У меня еще появился прикольный календарик с автографом.
На днях она еще раз приезжала к нам рассказать о планированиии и проектировании тестов.
Меня, как водится, там не было, но начальство, которое там, как водится, было, еще раз передало мне приятный ништячок от Натальи.
Раз:
 |
| Альбом: office |
А унутре у нее
 |
| Альбом: office |
P.S. Ну и еще руководство всяко хвалило сей тренинг, да.
суббота, 29 октября 2011 г.
Lesson 42
Рисовали мы тут диаграммы - кто как работает, что на входе, какой продукт на выходе и так далее. Для всех. Чтоб выяснить, на каких печеньках сэкономить и вообще понять, что происходит.
Примерно так выглядит небольшая часть диаграммы работ у программистов:
Оно же ИРЛ:
А вот так - у автотестеров:
Оно же ИРЛ:
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
Примерно так выглядит небольшая часть диаграммы работ у программистов:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
А вот так - у автотестеров:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
пятница, 28 октября 2011 г.
Так
Переводить текст с английского не могу под музыку со словами.
Писать сценарии для тестирования не могу под музыку с русскими словами.
Писать код тестов можно не только под русскоязычную музыку, но и - сняв наушники - под диалоги коллег.
Как-то так.
Писать сценарии для тестирования не могу под музыку с русскими словами.
Писать код тестов можно не только под русскоязычную музыку, но и - сняв наушники - под диалоги коллег.
Как-то так.
четверг, 27 октября 2011 г.
ЗВ
Смотрю возвращение джедая.
Не понимаю: Вейдер хотел увидеть Люка, чтоб убедить перейти на темную сторону силы - то есть донести свои убеждения, попытаться договориться.
Люк в разговоре с Кеноби понимает "встретиться" только как "убить".
И кто на темной стороне?
Не понимаю: Вейдер хотел увидеть Люка, чтоб убедить перейти на темную сторону силы - то есть донести свои убеждения, попытаться договориться.
Люк в разговоре с Кеноби понимает "встретиться" только как "убить".
И кто на темной стороне?
среда, 26 октября 2011 г.
Lesson 41
Слово Канеру:
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
Подписаться на:
Сообщения (Atom)