Я очень не люблю вещи, которые делают с серьезным выражением лица. Исключения, конечно, есть, но их мало, а большая часть из них при ближайшем рассмотрении не такие уж и исключения.
Например, я очень не люблю то, что называют буллшит бинго.
Слова из буллшит бинго когда-то обладали глубоким смыслом, подразумевали мысль и наличие души, теперь они - маркеры глупости, лени или лицемерия.
Изначально Я слышу эту фразу так: Я не потрудился рассказать вам об этом раньше
Изучать Я изучал python, я изучал рынок, я изучал линукс, я изучал продукт. А что ты делал? С умным видом ковырял конфиги? Как ты мог изучать язык программирования, не написав при этом ни строчки кода? Что ты, черт возьми делал? Я слышу эту фразу так: Два дня я внимательно смотрел на объект исследования
Я ничего не успеваю Слышу так: Я брался за все, я бегал и метался, но так ничего полезного и не сделал
Можно сделать Слышу так: Будет зашибись, если вы сделаете еще и это, Ваше поделие оскорбляет мои эстетические чувства, переделайте все, ага. пиздеть не мешки ворочать
Надо понимать Слышу так: Странно, вы не умеете читать мои мысли Надо объяснять!
В целом, в общем В зависимости от контекста Я не могу логически объяснить, как я пришел к этому выводу или Вы делаете все неправильно, так как не понимаете (см. выше) глобальной цели(тм)
Анализировать Это вообще волшебно - Я анализировал цифры и статистику, я проанализировал данные... Каждый раз, когда произносится эта фраза - результатов работы нет. Просто нет. Нет выводов, нет обязательного этапа, следующего за анализом - синтеза. Ах, нет. Есть, блядь, графики. На которые все смотрят с умным видом и не принимают никаких решений. Или принимают, но те, которые уже были до графиков. Я слышу это так: Я выгрузил все это в гуглдок, шесть раз отсортировал, сгруппировал, построил семь графиков. И изучил(см. выше) результат.
Анализ - одно из моих любимых слов. Странно, но почти все, кто его произносит, забывают о синтезе. Я даже расскажу историю.
Жила-была проблема. Например - сбои на n-м этапе техпроцесса.
И были приняты тяжелые меры, усилен накал борьбы, изменен процесс, переучены люди, сменены несколько интерфейсов и ряд регламентов. Вообще случилась масса субъективно полезных вещей, связанных не только с этими сбоями.
А затем человеку дали задание - посчитать, как изменилось количество сбоев по сравнению с предыдущими периодами (там, к сожалению, нужно считать руками).
Все правильно? Да, смарт, измеримый результат (еще б заранее определить целевой показатель, но и так сойдет).
Но есть нюанс и вместе с ним вопрос: зачем вообще нужна эта работа?
Вопрос был задан и на него получен резонный ответ: чтоб узнать, были бы меры эффективными, принесли ли результат.
Отлично, а что мы сделаем, если ответ - нет, не были, не принесли мы вернем все обратно?
Если ответом было бы да, то я сочту проделанную работу полезной.
Если бы мне ответили нет, то у нас получится анализ без синтеза, без принятия решения.
Хм.
Да, я сам пользуюсь всем этим булшитом. Надеюсь, что все меньше
пятница, 27 сентября 2013 г.
пятница, 20 сентября 2013 г.
четверг, 19 сентября 2013 г.
Рутина
А боец нашей группы будет вести курсы для будущих тестировщиков. Она волнуется, но старается и молодец.
Вот тут с 40 секунды начинает вещать она:
Меня туда не взяли, потому что ленивый и морда лица не преподавательская.
Не знаю насчет ее студентов, но ей эти курсы точно помогут. Начала читать литературу, есть риск, что добьет недослушанные вебинары по тест-дизайну. Растет над собой. В одном месте своего рассказа даже цитирует меня. Пару лет назад я сюда выкладывал текст лекции по тестированию, пока искали этот шуточно-матерный, жизненный материал, наткнулись на старый пост Как на войне. Оттуда:
Тестировщики. Тестировщики это, конечно, пехота. Танки танками, но очистить местность от врага могут только они и хотят это делать за такой паек – тоже только тестировщики.
Во время атаки следуют за танками (в приличных соединениях – вместе с ними), зачищают местность, работают медленно и скрупулезно. В случае необходимости могут захватить ДОТ(создать фичу), но смогут сделать это самые опытные, делать будут долго и не спеша.
Если часть стоит в обороне(стабилизация и техподдержка), то они продолжают делать свое нелегкое дело – копать окопы (кейсы), которые, как известно, они могут или копать, или не копать. При достаточном количестве этих окопов враг не пройдет даже при полном отсутствии иных родов войск.
Тестировщики – шутники, но очень усталые.
Читать олностью.
Вот тут с 40 секунды начинает вещать она:
Меня туда не взяли, потому что ленивый и морда лица не преподавательская.
Не знаю насчет ее студентов, но ей эти курсы точно помогут. Начала читать литературу, есть риск, что добьет недослушанные вебинары по тест-дизайну. Растет над собой. В одном месте своего рассказа даже цитирует меня. Пару лет назад я сюда выкладывал текст лекции по тестированию, пока искали этот шуточно-матерный, жизненный материал, наткнулись на старый пост Как на войне. Оттуда:
Тестировщики. Тестировщики это, конечно, пехота. Танки танками, но очистить местность от врага могут только они и хотят это делать за такой паек – тоже только тестировщики.
Во время атаки следуют за танками (в приличных соединениях – вместе с ними), зачищают местность, работают медленно и скрупулезно. В случае необходимости могут захватить ДОТ(создать фичу), но смогут сделать это самые опытные, делать будут долго и не спеша.
Если часть стоит в обороне(стабилизация и техподдержка), то они продолжают делать свое нелегкое дело – копать окопы (кейсы), которые, как известно, они могут или копать, или не копать. При достаточном количестве этих окопов враг не пройдет даже при полном отсутствии иных родов войск.
Тестировщики – шутники, но очень усталые.
Читать олностью.
Рутина
Randall Munroe жжот.
Сайт с переводом: http://xkcd.ru/1204/ Оригинал: http://xkcd.com/1204/
А в это время: Схемы зданий на Google Картах приходят в Россию
Гугл, если ты меня слышишь, коллеги просят станцию метро Ботаническую.
вторник, 17 сентября 2013 г.
Ingress Green Night
Неделю назад, в ночь со вторника на среду, мы провели Green Night.
В рамках акции перекрасили в красивый зеленый цвет центр и юго-запад Екатеринбурга, поставив 195 порталов 8 lvl (причем по России и ближнему СНГ их на тот момент было 410, считая наши). Восьмерки продержались до пятницы, к выходным сопротивление зачистило остатки.
Практика совместных действий показала, что в таком серьезном деле, как игра — дисциплина и планирование значат больше, чем на работе. Ну и по Адизесу, демократия возможна только до начала работы, после — только тоталитаризм и единовластие, только хардкор. За последние четыре часа сделали втрое больше, чем за первые четыре.
В самую жару, часа в три ночи, деплоили с размаху, не выходя из транспорта, с вытянутых рук, некоторые по-македонски.
Выглядело это примерно так:
Пирожок с верхней полочки тому, кто первый расскажет, зачем на 10й секунде парень разбегается в стену, хех.
Ну а @Raspberries не останавливается, и проводит еще акции. Вива Enlightened!
В рамках акции перекрасили в красивый зеленый цвет центр и юго-запад Екатеринбурга, поставив 195 порталов 8 lvl (причем по России и ближнему СНГ их на тот момент было 410, считая наши). Восьмерки продержались до пятницы, к выходным сопротивление зачистило остатки.
Практика совместных действий показала, что в таком серьезном деле, как игра — дисциплина и планирование значат больше, чем на работе. Ну и по Адизесу, демократия возможна только до начала работы, после — только тоталитаризм и единовластие, только хардкор. За последние четыре часа сделали втрое больше, чем за первые четыре.
В самую жару, часа в три ночи, деплоили с размаху, не выходя из транспорта, с вытянутых рук, некоторые по-македонски.
Выглядело это примерно так:
Пирожок с верхней полочки тому, кто первый расскажет, зачем на 10й секунде парень разбегается в стену, хех.
Ну а @Raspberries не останавливается, и проводит еще акции. Вива Enlightened!
пятница, 13 сентября 2013 г.
Lesson 293
Это последний урок последней главы книги Lessons Learned in Software Testing Сэма Канера и его товарищей.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.
С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..
Собирать перевод в одну xml'ку или pdf'ку мне лень, я книгу уже прочел, больше мне не интересно.
Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.
Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.
Слово Канеру
Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Вы предоставляете услугу тестирования циклически. Цикл тестирования начинается с новой сборкой и заканчивается одной из двух вещей: новой сборкой или признанием того, что дальнейшее тестирование лишено смысла. Ваша стратегия конкретизирует эти циклы. Планируйте именно их. Чтоб предоставлять самую качественную информацию вашим клиентам. Вот один из способов организации цикла:
1. Возьмите продукт. Убедитесь, что у вас правильный билд.
2. Сконфигурируйте систему тестирования. Очистите ее. Восстановите диск, полностью удалите предыдущую версию продукта.
3. Проверьте тестируемость. Это хороший билд? Он стоит того, чтоб его проверять? Проведите smoke-тесты, демонстрирующие, что основная функциональность работает.
4. Определите, что появилось нового, а что было изменено. Какой код расширял или менял возможности продукта?
5. Выясните, какие ошибки были исправлены. Также, найдите проблемы, которые отклонили и отреагируйте соответствующим образом.
6. Проверьте исправления. Их стоит проверять вначале, так как программисты еще помнят о них. Если ошибка не была исправлена, то программистам нужно быстро об этом узнать.
7. Протестируйте новые или менявшиеся области продукта. Это еще одна тема, которая еще свежа в умах программистов.
8. Протестируйте остальные области (высокие риски в первую очередь). Тестируйте все остальное, пока не кончится время. Выполните автоматизированные регрессионные тесты.
9. Сообщите о результатах. Результаты нужно предоставлять периодически, не реже одного раза в день в ходе цикла тестирования.
вторник, 10 сентября 2013 г.
Lesson 292
В минувшие выходные боец @Raspberries жгла. Результат примерно такой:
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.
 |
| Альбом: Ingress |
Подробности и фоточки.
И еще история про кота от Александра Селяева.
Слово Канеру
Создайте стратегию тестирования как ответ на особенности и риски проекта
Хорошая стратегия тестирования формируется не только рисками, но и особенностями проекта. Вот несколько принципов формирования стратегий. Основанных на деталях проекта:
- Не теряйте баги в щелях между тестами. Если вы не используете принцип разных полумер или перекрывающихся зон ответственности, то сталкиваетесь с опасностью того, что определенная функциональность не будет проверена, так как окажется на границе ответственности между двумя тестировщиками или командами.
- Тестируйте то, что вас просят тестировать. Вы тестируете от имени большого количества клиентов. Что они считают, что вы должны проверить? Узнайте, и убедитесь в том, что вы удовлетворяете потребности хотя бы некоторых из них.
- Иногда проверяйте то, что вас просили не проверять. Иногда вас просят не тестировать определенные части продукта. Это деликатный вопрос и мы точно не скажем вам, что делать. Однако иногда те вещи, которые вас просили не тестировать являются теми, которые больше всего нуждаются в тестировании.
- Тестируйте путаницу и противоречия. Like coder; like code. Везде, где есть путаница и противоречия, процветают дефекты. Если программист не уверен в том, что делает функция — протестируйте ее. If he's new to the technology, test it. Если два программиста создавали части, взаимодействующие друг с другом — протестируйте их и вы не будете разочарованы.
- Не бейте мертвую фичу. Когда становится ясно, что фича полна ошибок — прекратите тестирование, если только вы не делаете это с разработчиком. Это может быть сломанная сборка, некорректная конфигурация. Кроме того, если компонент настолько плох, что будет заменен, а не пересмотрен, то любые ошибки, что вы найдете, будут закрыты.
- Чем больше изменений, тем больше тестирования. Теоретически, мельчайшее изменение в продукте может повлечь большие нелокальные эффекты. Это значит, что любое изменение потенциально обесценивает все тесты, которые вы когда либо проводили с продуктом. В действительности, большинство изменений имеют довольно ограниченный диапазон влияния. Тем не менее, вы должны следить за изменениями в продукте. Чем больше изменений, тем больше вы должны тестировать. Это становится серьезной работой в конце проекта.
понедельник, 9 сентября 2013 г.
Lesson 291
Пару дней назад в Екатеринбург приезжал Максим cartmendum Дорофеев.
Как обычно, жог.
Из запомнившегося:
Купить книгу: Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь
Это неловкое чувство, когда ты выключаешь сервер по питанию, а он продолжает пинговаться
Эффект козлов: переписка с человеком в три письма — и такое ощущение, что он там козел. Позвонил по телефону — адекватный вроде бы человек. Приехал в командировку и увиделся лично — отличный парень, никаких проблем. Вернулся, три письма в переписке — козел и вообще ничего не понимает.
Бритва Оккама-????(Дорофеева?): Из всех объяснений ситуации наиболее вероятно то, в котором количество мудаков минимально. Первое следствие (Захарова?): Если ситуация объясняется тем, что все вокруг — мудаки, то скорее всего мудак — объясняющий.
При всем при этом с основной мыслью Максима позволю себе не согласиться. Он говорил, что из вариантов Алгоритмы, бизнес-идеи, языки программирования, общение самое важное для IT-специалиста — умение общаться, 50%, остальные три пункта по 15%.
Я считаю - это верно для всех, кроме программистов. Программист должен любить писать код. По поводу и без. Общаться за него должны все остальные — аналитики, тестировщики, саппорты, админы, менеджеры и прочий обслуживающий строчки кода персонал. Потому как без строчек кода все эти люди - предприниматели, ОТК, заведующие складом и вахтеры. Но не IT-специалисты.
З.Ы. Максим, а ты напишешь про меня восторженный твит, когда я закончу перевод Канера? Мне осталось 2 страницы.
Слово Канеру
Два тестировщика, тестируя одно и то же не дублируют работу.
Некоторые тестировщики беспокоятся о дублировании работы. Расслабьтесь. Не волнуйтесь о том, что люди перекрывают одни и те же области или задачи. Дублирование тестирования не то же самое, что дублирование тестов. Есть вероятность, что два тестировщика, тестируя одно и то же, обнаружат разные проблемы. Это потому, что они прогоняют разные тесты. Даже тогда, когда они считают, что работают одинаково, между ними есть различия. Кроме того, один тестировщик заметит проблемы, которые другой просто выпустит из виду.
Дублирование усилий по тестированию никогда не пройдет впустую. Реальный вопрос заключается в том, чтоб решить, какая часть продукта заслуживает того, чтоб ее тестировали несколько раз.
Как обычно, жог.
Из запомнившегося:
Купить книгу: Ментальные ловушки. Глупости, которые делают разумные люди, чтобы испортить себе жизнь
Это неловкое чувство, когда ты выключаешь сервер по питанию, а он продолжает пинговаться
Эффект козлов: переписка с человеком в три письма — и такое ощущение, что он там козел. Позвонил по телефону — адекватный вроде бы человек. Приехал в командировку и увиделся лично — отличный парень, никаких проблем. Вернулся, три письма в переписке — козел и вообще ничего не понимает.
Бритва Оккама-????(Дорофеева?): Из всех объяснений ситуации наиболее вероятно то, в котором количество мудаков минимально. Первое следствие (Захарова?): Если ситуация объясняется тем, что все вокруг — мудаки, то скорее всего мудак — объясняющий.
При всем при этом с основной мыслью Максима позволю себе не согласиться. Он говорил, что из вариантов Алгоритмы, бизнес-идеи, языки программирования, общение самое важное для IT-специалиста — умение общаться, 50%, остальные три пункта по 15%.
Я считаю - это верно для всех, кроме программистов. Программист должен любить писать код. По поводу и без. Общаться за него должны все остальные — аналитики, тестировщики, саппорты, админы, менеджеры и прочий обслуживающий строчки кода персонал. Потому как без строчек кода все эти люди - предприниматели, ОТК, заведующие складом и вахтеры. Но не IT-специалисты.
З.Ы. Максим, а ты напишешь про меня восторженный твит, когда я закончу перевод Канера? Мне осталось 2 страницы.
Слово Канеру
Два тестировщика, тестируя одно и то же не дублируют работу.
Некоторые тестировщики беспокоятся о дублировании работы. Расслабьтесь. Не волнуйтесь о том, что люди перекрывают одни и те же области или задачи. Дублирование тестирования не то же самое, что дублирование тестов. Есть вероятность, что два тестировщика, тестируя одно и то же, обнаружат разные проблемы. Это потому, что они прогоняют разные тесты. Даже тогда, когда они считают, что работают одинаково, между ними есть различия. Кроме того, один тестировщик заметит проблемы, которые другой просто выпустит из виду.
Дублирование усилий по тестированию никогда не пройдет впустую. Реальный вопрос заключается в том, чтоб решить, какая часть продукта заслуживает того, чтоб ее тестировали несколько раз.
среда, 4 сентября 2013 г.
Lesson 290
Слово Канеру
Остерегайтесь поклонения предкам при повторном использовании материалов тестирования.
Переиспользуя материалы тестирования или любые другие, не рассматривайте их как черный ящик. Изучите из. Выясните, почему они созданы именно такими. Во многих случаях архивные материалы для тестирования настолько низкого качества, что лучше их не использовать вообще. Тенденция тестировщиков доверять старым материалам только потому, что они старые загадочна. Мы многократно видели древние тесты, которые выполнялись через много лет после того, как стали неактуальны. Мы видели умных и квалифицированных тестировщиков, беспрекословно следующих тестам, которые писали менее квалифицированные тестировщики. Это темная сторона повторного использования.
В одной тестовой лаборатории было правило «всегда прверяй с Compaq Presario, because they are notoriously incompatible». Это правило было написано в 1996 году. Оно все еще актуально? Кто-нибудь возвращался к этой проблеме? Кто-нибудь подвергал сомнению авторитет Древних, которые писали правила?
Если вас привлекают к написанию тестов, которые будут выполняться повторно, спросите себя: как люди узнают, что вы имели в виду? Почему эти тесты нужны? Когда их нужно отправить на пенсию или переписать заново? Иначе есть отличные шансы, что ваши клиенты будут относиться к вашей работе как к магическому тотему, а не использовать тесты так, как вы бы того хотели.
Остерегайтесь поклонения предкам при повторном использовании материалов тестирования.
Переиспользуя материалы тестирования или любые другие, не рассматривайте их как черный ящик. Изучите из. Выясните, почему они созданы именно такими. Во многих случаях архивные материалы для тестирования настолько низкого качества, что лучше их не использовать вообще. Тенденция тестировщиков доверять старым материалам только потому, что они старые загадочна. Мы многократно видели древние тесты, которые выполнялись через много лет после того, как стали неактуальны. Мы видели умных и квалифицированных тестировщиков, беспрекословно следующих тестам, которые писали менее квалифицированные тестировщики. Это темная сторона повторного использования.
В одной тестовой лаборатории было правило «всегда прверяй с Compaq Presario, because they are notoriously incompatible». Это правило было написано в 1996 году. Оно все еще актуально? Кто-нибудь возвращался к этой проблеме? Кто-нибудь подвергал сомнению авторитет Древних, которые писали правила?
Если вас привлекают к написанию тестов, которые будут выполняться повторно, спросите себя: как люди узнают, что вы имели в виду? Почему эти тесты нужны? Когда их нужно отправить на пенсию или переписать заново? Иначе есть отличные шансы, что ваши клиенты будут относиться к вашей работе как к магическому тотему, а не использовать тесты так, как вы бы того хотели.
вторник, 3 сентября 2013 г.
Lesson 289
Отсортируйте по значимости, от большего к меньшему:
В некой группе людей вас ...
чтят
восхищаются
восторгаются
высоко оценивают
признают
принимают во внимание
ценят
любят
уважают
Слово Канеру
Тестируйте серый ящик
Даже если вы и не располагаете полной информацией о внутреннем устройстве продукта, стратегия тестирования, частично опирающаяся на знания его внутреннего устройства - хорошая идея. Мы называем это тестированием серого ящика. Концепция проста: если вы знаете что-то о том, как продукт работает внутри, то у вас есть возможность лучше проверить его снаружи. Этот способ не следует путать с тестированием белого ящика, при котором тестируется внутренние компоненты продукта. В случае серого ящика, вы тестируете так же, как тестировали бы черный, но выбор тестов, которые вы проводите определяется знанием о особенностях работы и взаимодействия компонент продукта.
Тестирование серого ящика особенно важно для тестирования веб- и интернет-приложений, так как интернет построен вокруг слабо интегрированных компонент, соединяющихся через хорошо определенные интерфейсы. Если вы не понимаете архитектуру сети, то тестирование будет поверхностным. Testing Applications on the Web (2000) Hung Nguyen — хороший пример стратегии тестирования серого ящика, применимой в веб.
В некой группе людей вас ...
чтят
восхищаются
восторгаются
высоко оценивают
признают
принимают во внимание
ценят
любят
уважают
Слово Канеру
Тестируйте серый ящик
Даже если вы и не располагаете полной информацией о внутреннем устройстве продукта, стратегия тестирования, частично опирающаяся на знания его внутреннего устройства - хорошая идея. Мы называем это тестированием серого ящика. Концепция проста: если вы знаете что-то о том, как продукт работает внутри, то у вас есть возможность лучше проверить его снаружи. Этот способ не следует путать с тестированием белого ящика, при котором тестируется внутренние компоненты продукта. В случае серого ящика, вы тестируете так же, как тестировали бы черный, но выбор тестов, которые вы проводите определяется знанием о особенностях работы и взаимодействия компонент продукта.
Тестирование серого ящика особенно важно для тестирования веб- и интернет-приложений, так как интернет построен вокруг слабо интегрированных компонент, соединяющихся через хорошо определенные интерфейсы. Если вы не понимаете архитектуру сети, то тестирование будет поверхностным. Testing Applications on the Web (2000) Hung Nguyen — хороший пример стратегии тестирования серого ящика, применимой в веб.
понедельник, 2 сентября 2013 г.
Подписаться на:
Сообщения (Atom)