Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.
Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.
Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.
Мне кажется, уместно ответить на сам вопрос, и попробовать разобраться с контекстом данного вопроса.
Если вам проще смотреть видео, чем читать текст, то видео на тему можно посмотреть вот тут:
Начнем с самого вопроса
И для начала стоит определить термины. Что такое тестирование?
Вам на выбор два определения. Определение первое, из сертификации ISQTB:
"The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of a component or system and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects." [1]
Что можно вольно перевести следующим образом:
"Процесс состоящий из всех активностей, статичных и динамичных, имеющих отношение к планированию, подготовке и оценке компонентов или систем а также производных продуктов для определения соответствуют ли они заданным требованиям, для демонстрации пригодности для применения и поиска дефектов"
Второе определение из методологии Rapid Software Testing, которую продвигают Майкл Болтон и Джеймс Бах:
"Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting, which includes to some degree: questioning, study, modeling, observation, inference, etc." [2]
Вольный перевод:
"Тестирование - это процесс оценки продукта посредством изучения через опыт, исследование, постановку экспериментов, которое включает в себя постановку вопросов, изучение, моделирование, наблюдение, деструктивные методы оценки, и так далее."
Что тогда есть автоматизированное тестирование?
Я вижу два варианта. Первый - это тестирование (в полном соответствии с определениями выше), выполняемое автоматически. Как не трудно догадаться, это просто невозможно, потому что:
Проблема останова (теоретически невозможно написать программу достоверно валидирующую другую программу)
Закон Эшби (для надежной автоматизации тестирования, автоматизация должна быть более сложной, чем тестируемый продукт)
Дилемма лица, принимающего решения (кого увольнять\сажать\расстреливать в случае критической ошибки, например как в Боинг МАХ)
Второй вариант будет подразумевать некое подможество тестирования, например подмножество тестирования в виде автоматизированной регрессии. В таком случае ответ очевиден - оно не может заменить тестирование, потому что не является полноценной заменой.
Я считаю следующую аналогию полезной: у вашей машины есть много диагностирующих лампочек (проверь двигатель, долей масла, накачай колеса). Если ни одна из лампочек не горит, значит ли это, что машина исправна, и ее можно не возить на ТО? Нет, не значит. Поэтому если кто-то говорит, что "мы отказались от ручного тестирования" это не значит, что они смогли автоматизировать тестирование. Просто они готовы пойти на риск (и да, это тоже вполне годная стратегия обеспечения качества)
Так что с этим мы разобрались. Автоматизированное тестирование не заменит ручное (или, что звучит более корректно - тестирование невозможно полностью автоматизировать).
Теперь перейдем к контексту вопроса
Почему (зачем) человек задает данный вопрос? Опять таки, несколько вариантов:
это тестировщик, у которого нет навыков разработки\автоматизации, и который хочет убедиться, что его работе ничего не угрожает;
это автоматизатор тестирования, который во всем видит тесты, которые надо автоматизировать;
это менеджер, который пытается сделать стратегические кадровые решения.
Тестировщикам рано расслабляться, потому что тестирование - это всего-лишь один из способов управления рисками, и альтернативные способы развиваются очень быстро. Если хотите, тестировщикам нужно бояться не автоматизации.
Автоматизаторам расслабляться тоже рано, вот тут, например, я достаточно обоснованно показал, почему я не считаю автоматизацию необходимой специализацией, и со мной согласились Alan Page и James Whittaker. Если уж на то пошло, возможно специализация автоматизатора придет в упадок быстрее специализации тестировщика.
Менеджеру, принимающему кадровые решения, я лишь посоветую перестать пытаться сделать из процесса разработки ПО конвейер, где у каждого своя узкая специализация. Разработка ПО (во всяком случае такого ПО, с которым я хотел бы работать) во многом - исследовательская работа, в которой, в отличие от массового производства, количество идентичных операций ничтожно мало. С точки зрения теории управления и технологии, речь идет о мелкосерийном и единичном производстве, в котором специализация только вредит. Будущее за генералистами.
Что же из этого вынести для себя? Мой (субъективный и ничем особо не обоснованный) прогноз:
Спрос на "чистых" тестировщиков будет снижаться, граница между тестировщиками и автоматизаторами продолжит стираться
Спрос на автоматизаторов продолжит расти, но в долгосрочной перспективе (и тут больше моя личная надежда, чем прогноз), начнет снижаться быстрее, чем спрос на тестировщиков
Спрос на "универсалов" и "T-shaped" специалистов продолжит расти.
[1] https://glossary.istqb.org/app/en/search/testing
[2] https://www.satisfice.com/blog/archives/856
Приглашаю вас на мой youtube канал, где мы обсуждаем эту и другие релевантные темы.
