В первой статье я описал типичные проблемы, которые возникают на проектах по разработке ПО.
В этой части я хочу ответить на вопросы многих, что такое Software Testing 2.0? Чем это отличается от текущего подхода, в котором мы работаем?
Перед тем как говорить о Software Testing 2.0, давайте начнем с упражнения.
Спросите себя:
Теперь задайте себе следующие вопросы:
Запишите ответы в две колонки и проведите аналогию.
Давайте посмотрим на пример, который получился у меня:
| Текущий проект | Предыдущий проект |
| Бизнес сектор: Мультимедийные развлечения | Бизнес сектор: VoIP телефония |
| Методология: Kanban | Методология: Scrum |
| Команда: 7 человек | Команда: 5 человек |
| Технологическое решение: Java Enterprise | Технологическое решение: Web and Android Applications |
Давайте назовем несколько проблем, которые возникают в контекстах этих проектов?
Можем заметить, что каждая из проблем может относиться к любому из контекстов. А вот будет ли какое-то одно решение универсальным для всех?
Цикл решения проблем состоит из следующих шагов:
Сейчас мы находимся на втором шаге. Откуда мы можем черпать информацию для генерации идей?
Давайте рассмотрим, какие могут быть вариант для первой проблемы – «Заказчик находит дефекты после релиза»:
Как вы видите, варианты есть, и их может быть еще больше. Но где гарантии, что все эти идеи подойдут для каждого из проектов, которые мы описали ранее? Вы могли услышать на конференции, как одна из команд решила очередную проблему и теперь рекомендует всем следовать этим подходам. Подумайте, стоит ли воспринимать это утверждение как догму? Быть может, для начала стоит разузнать у человека предметную область и контекст, в котором он находился?
Не нужно ограничивать себя в выборе и слепо следовать чьим-то словам. Включайте мозг и думайте, что применимо именно в вашей ситуации и вашем контексте. Но не забывайте! Все действия должны быть направлены на то, чтобы принести ценность проекту!
Проецируя все выше сказанное на Software Testing 2.0, можно сказать, что это что-то о свободе выбора и конечном результате.
Первые упоминания о Software Testing 2.0 появились еще в 2006 году. Их автором был Jonathan Kohl. В своей статье Джонатан говорит о том, что со временем классическое тестирование трансформируется. От тестировщика требуются все новые и новые знания. Объёмы информации увеличиваются и сделать выбор становится все сложнее. Это требует все новых и новых навыков от тестировщика. Статья заканчивается фразой “The ‘second version’ of software testing has begun to arrive.”
Так что же такое Software Testing 2.0?
Давайте возьмем за основу язык Геркин и опишем определение вот таким сценарием:
Дано – проект в определенном контексте
А так же свобода
Когда есть выбор между различными техниками, методиками или практиками
Тогда стоит принимать решение на основании ожиданий от конечного результата
Теперь подробнее.
Контекст
Когда я искал существующие материалы на тему тестирования в определенном контексте, я наткнулся на идеи Канера и Баха, которые описаны на сайте context-driven-testing.com.
Не существуют лучших практики, есть только хорошие практики в определенном контексте.
Целесообразность использования тех или иных практик зависит от контекста проекта. А что такое контекст мы уже разобрались выше.
Контекст проекта зависит от многих обстоятельств. Ниже несколько примеров:
Какие же практики стоит использовать в определённых контекстах?
Ответ не всегда очевиден. Ведь, если практика заработала в Scrum команде из 5 человек, она может не прижиться в команде из 8 человек, которая работает по методологии Kanban. Вам нужно самостоятельно определить какие практики будут работать в вашем контексте проекта. Вам нужно постоянно пробовать новые подходы, получать от них результат, думать помогло ли это вам в цикле разработки продукта или нет? Если да, внедрять следующую практику, если нет отказаться от нее.
Следующий пункт – свобода!
Вы не должны ограничивать себя в выборе инструментов, методик, практик, подходов. Не ограничивайте себя правилами, которые навязывают современные методологии. Помните, что все зависит от контекста!
Используя этот подход, можно принимать во внимания все существующие области, от которых можно подчерпнуть новые идеи. Было бы шикарно иметь облако идей, набор практик. Все то, что мы сейчас видим в повседневном мире разработки ПО. Представьте, что мы можете зайти на библиотеку живых кейсов внедрения практики в разных контекстах разработки и посмотреть, как уже похожие проблемы решали другие люди. Многие из вас уже делятся такими наработками на своих блогах, конференциях, тематических порталах. Это круто и правильно. Вы создаете новый поток отфильтрованной информации. Ведь только на практике мы можем узнать, как действительно работает та или иная методика.
Последний вопрос. Зачем мы пытаемся решить эти проблемы?
Все это для того, чтобы получить нужный нам результат. Получить требуемое Value. Рекомендую посмотреть запись доклада Джонатана Кола на тему “Am I creating Value With My Testing?”. Задавайте себе этот вопрос как минимум один раз в две недели. И, если вам нечего на него ответить – это проблема, над которой стоит поработать. Задайте этот вопрос вашим коллегам, если сами не можете найти ответ.
Давайте еще раз подведем итог о том, что такое Software Testing 2.0?
Все мы находимся в определенном контексте проекта, где нужно руководствоваться свободой выбора для применения любых доступных техник, методик или практик. Самое главное, что мы должны получить на выходе – это ценность!
P.S. Буду рад обсудить вопросы, которые возникли у вас во время прочтения!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Чем я не люблю эту дихотомию заказчик-исполнитель, так это тем, что если строить по ней какую-то классификацию, то получается два разных мира которым как-то надо друг с другом работать. В “продуктовых лавках” бывает так, что очень трудно (да и не нужно) где заканчивается заказчик и начинается исполнитель. Т.е. все это друг с другом может очень плотно работать, а пилить на “заказчика” и “исполнителя” приходится только для того чтобы с коллегами по цеху общаться.
И предлагаю вещи вроде “Не ограничивайте себя правилами, которые навязывают современные методологии” поменять на “не ограничивайте себя правилами, которые навязывают современные методологии – за вас это сделает контекст”. Потому что контекст, зараза такая, ставит нас на свои рельсы и потом очень сильно ограничивает. По сути задачу можно свести к “получить максимум value из того что имеется в наличии”.