Вы неправы. Колет именно медсестра. Врач делает это только в исключительных случаях. А строгая специализация — это большое зло в IT. Есть DBA. Если он заболел или уволился, то проекту труба, потому что только он работал с базой. То же самое для тестировщика, дизайнера и прочих. Если все делят обязанности, то за результат отвечают вместе и риски сильно уменьшаются.
Software Engineer in Test — это как раз та интеллектуальная роль тестировщика, которую не всегда сможет выполнить кто-то другой. Но при этом квалификация таких людей на порядок выше чем у рядовых тестировщиков на просторах нашей необъятной…
Вы утрируете. Даже в вашем примере укол пациенту могут сделать все из них. Просто у каждого есть область, в которой он разбирается лучше других. В моей статье ручное тестирование выступает в роли укола — его могут сделать и тестировщики и разработчики и заказчик. Я не предлагаю заказчику разрабатывать код, а разработчику продавать продукт.
Речь идет о TDD на уровне продукта. До того как все обсудили и поняли задачу, сформулировав свои знания в виде приемочных тестов, примеров поведения и просто примеров использования, браться за разработку бессмысленно. А TDD на уровне кода естественно решает те же задачи, но на низком уровне.
Первые две вообще состоят только из разработчиков и менеджеров продуктов. И да, A/B тестирование активно применяется, но не для того, чтобы совершенно бажный продукт отдать на тестирование. Цель — понять нужна ли фича и в каком виде. Это скорее бизнес цель.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Именно в этом и помогает TDD — сначала думаем как должно работать, а уже потом делаем. И не наоборот.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Неверное понимание требований — не ошибка. И над этой проблемой надо работать отдельно. Именно для этого придумали Agile планирование с приемочными тестами и критериями, вовлеченность заказчика, прототипы и прочие вещи.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Это очень легко автоматизируется с помощью screnshot-based подходов и специализированных инструментов. Было бы желание. Вот видео моего доклада на эту тему.
Что дешевле, время заказчика или время тестировщика?
Вопрос не в том, что это должен быть именно сам заказчик (тот человек или компания, которые заказали разработку продукта). Часто нанимают специального менеджера продукта и его время не так уж и дорого по сравнению с временем тестировщика. Зато он может сделать настоящую приемку.
Ну а программисты чаще всего нужны при задачах не копирования готового продукта, а созданиии нового. А этот процесс «с первого раза и без ошибок» невозможен в принципе.
Речь идет о том, что когда разработчик говорит «ГОТОВО», оно должно быть действительно готово. Речь не идет об ошибках продуктового типа, когда просто не туда пошли или не ожидали такого масштабирования. Все гораздо банальнее…
Tumblr, Instagram, Google (там Software Engineer in Test — тот же разработчик), Twitter. По крайней мере докладчики с этих компаний так утверждают и я склонен им верить.
Обновил пост ссылкой на статью сегодняшнюю про облачные провайдеры для запуска тестов. Вполне себе вменяемые цены и неплохой вариант для многих проектов.
Видимо невнимательно смотрели. Сравнивалка картинок с регионами самописная. Это самая простая часть, любой адекватный разработчик пишет за пару часов. :) В интернете пробегала публичная версия на питоне, но ссылку не помню. У нас на Java.
Да вроде как удобных инструментов во всех языках предостаточно. Обычно они касаются BDD: Cucumber, SpecFlow, JBehave и т.д. А есть еще и куча платных с более удобным интерфейсом для ведения тестов представителями заказчика. Так что было бы желание… :)
Модульными тестами хороший разработчик покрывает код, чтобы убедиться, что его точечная идея для класса, функции, метода или их связки работает правильно. К сожалению, модульные тесты не способны обеспечить проверку даже возможности запуска приложения, не говоря уже о его функциях. Плюс, приемочные тесты написаны на языке, понятном заказчику, в отличии от модульных тестов. Если искать связь, то модульные тесты рождаются из приемочных, в то же время играя роль приемочных тестов на уровне кода.
А вы ему объясните, что в противном случае он будет платить каждый раз за ручное регрессионное тестирование либо просто завалится списком дефектов. И не надо иметь четко сформулированные требования для всего продукта, надо всего лишь на итерацию. Или это тоже нереально из вашего опыта?
Ну если за деньги говорить, то может лучше тогда просто «киданием» заниматься? :)
А по поводу ограничений, решений и т.д. я полностью согласен. Большая часть этого входит в нефункциональные требования. Они не выражаются в приемочных тестах, а переходят в более специфические виды тестов (нагрузочные, производительности, безопасности, юзабилити, доступности). Но если они останутся только на бумаге, то контролировать через некоторое время будет просто нереально…
Приезжайте на SeleniumCamp 2013. Там будет автор Selenium Grid из eBay и много докладчиков из больших продуктовых компаний: Google, Groupon, Amazon, eBay, Яндекс, Одноклассники, 2ГИС и т.д. А у них фермы машин стоят достаточно большие.
На этапе сопровождения часто меняется только часть функциональности (то есть большая часть действительно превращается в реку, в которую нельзя войти дважды). И вот тогда польза от приемочных тестов колоссальная. Мало того, по ним можно понять как должна была работать та или иная часть приложения. Потому что доменные знания теряются за документами, в которых устаревают практически моментально.
Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). На эту тему советую посмотреть мое выступление: www.youtube.com/watch?v=cUoSTBkeFy4. А тут есть еще много всего полезного на эту тему: xpinjection.com/resources/.
Именно в этом и помогает TDD — сначала думаем как должно работать, а уже потом делаем. И не наоборот.
Неверное понимание требований — не ошибка. И над этой проблемой надо работать отдельно. Именно для этого придумали Agile планирование с приемочными тестами и критериями, вовлеченность заказчика, прототипы и прочие вещи.
Это очень легко автоматизируется с помощью screnshot-based подходов и специализированных инструментов. Было бы желание. Вот видео моего доклада на эту тему.
Вопрос не в том, что это должен быть именно сам заказчик (тот человек или компания, которые заказали разработку продукта). Часто нанимают специального менеджера продукта и его время не так уж и дорого по сравнению с временем тестировщика. Зато он может сделать настоящую приемку.
Речь идет о том, что когда разработчик говорит «ГОТОВО», оно должно быть действительно готово. Речь не идет об ошибках продуктового типа, когда просто не туда пошли или не ожидали такого масштабирования. Все гораздо банальнее…
А по поводу ограничений, решений и т.д. я полностью согласен. Большая часть этого входит в нефункциональные требования. Они не выражаются в приемочных тестах, а переходят в более специфические виды тестов (нагрузочные, производительности, безопасности, юзабилити, доступности). Но если они останутся только на бумаге, то контролировать через некоторое время будет просто нереально…