Продолжаю серию постов-обзоров, на этот раз "внеплановый" доклад от Джеймса Баха "Идем неуклюжим, неровным шагом" (James Bach - A Galumping We Go).
Как я когда-то писал в своем первом обзоре этой серии, этот доклад однозначно нужно хорошо просмотреть-прочитать-прочувствовать-пробовать на себе. И, самое интересное, возможно и вы уже использовали в своей практике, но не задумывались - метод Galumphing. В переводе - неуклюжий, неровный, нелогичный (на первый взгляд), прерывистый шаг.
You all do a galumphing, but probably none of you had a word for it or an explanation, why you do it.
Как часто мы пробуем только простые, линейные тесты на проверку функционала? Да, они находят очевидные и очень важные баги. И только. Можно делать одну и ту же вещь, но по-разному. Первый способ - прямые, отточенные до автоматизма движения, с применением минимально возможного набора сил и средств, как прямая между пунктами A и B - кратчайшее расстояние между двумя точками. Второй - тот же путь из А в B, но "неправильный", на первый взгляд: непонятый, непоследовательный. Вопрос: зачем нужен второй способ, если есть "эффективный" первый? Возможно, при поездке да, но не в тестировании. Джеймс Бах отвечает на этот вопрос определением ниже ( в своих лекциях, заметках, книгах, Бах не раз говорит о том, что тестирование ПО - это не только набор исчерпывающих тестовых процедур как, например, проверка заявленного спецификацией цвета: можно сказать словами Майкла Болтона: Testing Dominates Checking)
Galumphing – A style of test design and execution whereby inert variations in test procedure are used to find unanticipated and potentially important bugs.
(перевод: Galumphing - метод тест-дизайна и выполнения тестов, при котором малые вариации выполнения тестов используются для нахождения непредвиденных и потенциально важных багов)
Доклад - просто must see для тех, кто не только пишет и выполняет тесты, но и исследует свой продукт, находит новые баги в старых кейсах, пробуя сделать что-то "не так".
Видео доклада:
Как я когда-то писал в своем первом обзоре этой серии, этот доклад однозначно нужно хорошо просмотреть-прочитать-прочувствовать-пробовать на себе. И, самое интересное, возможно и вы уже использовали в своей практике, но не задумывались - метод Galumphing. В переводе - неуклюжий, неровный, нелогичный (на первый взгляд), прерывистый шаг.
You all do a galumphing, but probably none of you had a word for it or an explanation, why you do it.
Как часто мы пробуем только простые, линейные тесты на проверку функционала? Да, они находят очевидные и очень важные баги. И только. Можно делать одну и ту же вещь, но по-разному. Первый способ - прямые, отточенные до автоматизма движения, с применением минимально возможного набора сил и средств, как прямая между пунктами A и B - кратчайшее расстояние между двумя точками. Второй - тот же путь из А в B, но "неправильный", на первый взгляд: непонятый, непоследовательный. Вопрос: зачем нужен второй способ, если есть "эффективный" первый? Возможно, при поездке да, но не в тестировании. Джеймс Бах отвечает на этот вопрос определением ниже ( в своих лекциях, заметках, книгах, Бах не раз говорит о том, что тестирование ПО - это не только набор исчерпывающих тестовых процедур как, например, проверка заявленного спецификацией цвета: можно сказать словами Майкла Болтона: Testing Dominates Checking)
Galumphing – A style of test design and execution whereby inert variations in test procedure are used to find unanticipated and potentially important bugs.
(перевод: Galumphing - метод тест-дизайна и выполнения тестов, при котором малые вариации выполнения тестов используются для нахождения непредвиденных и потенциально важных багов)
Доклад - просто must see для тех, кто не только пишет и выполняет тесты, но и исследует свой продукт, находит новые баги в старых кейсах, пробуя сделать что-то "не так".
Видео доклада:
Конспект:
- You all do a galumphing but probably none of you had a word for it or an explanation, why you do it.
- "Only variety can destroy variety" Ashby's law -> for testing purposes "Only variety can explore variety"
- Lack of variety = Lack of control
- Testers are all about exploring the leaky abstractions called specifications
- If you only have a push button you have to introduce complexity some other way
- Ways to insert variety injection: micro-behaviors, randomness, data substitution, platform substitution, time/concurrency varations, scenario variation, state pollution, sensitivities and expectations (18:54)
- The requisite variety that opens up our expressive possibilities comes from practice, play, exercise, exploration, experiment.
- If you are trying to test an actual product of a kind we test, no explicit set of procedures can ever be enough. That's why we must explicit Ashby's law to inject variety not only of intended kind but of unintended kind.
Ссылки на обзоры этого выступления в других блогах:
Комментариев нет:
Отправить комментарий