Comments 13
общаюсь с компаниями за рубежом и часто слышу, что ручного тестирования у них уже нет совсем
Неужели прям сразу пилят фичу и релизят не глядя, просто по результатам прохождения автотестов?
Вопрос же как стоит: как обеспечить нормальную скорость отгрузки, если тестировать по две недели после компоновки релиза? Чтобы настроить такой процесс, нужен тест-менеджер, тестировщики, нужно согласовывать и обновлять тестовые сценарии. На все это заказчик не хочеть тратить время и деньги. Поэтому он покупает автоматизацию тестирования, где ему показывают, что фича была покрыта автотестом, показывают репорты. И на это на все нужен всего один человек, а не целая команда, и тестирование происходит «постоянно». T.e. это скорее компромиссное решение в сторону снижения затрат, а не повышения качества.
Если сравнивать автотест с ручным тестовым сценарием то по моему опыту с автоматизацией ты можешь добиться удаления большего количества ошибок, чем ручной тестировщик. Ты просто можешь например сказать, что автоматизация из-за этого работает медленнее, или сыпется. Или из-за неконсистентного поведения ты не можешь написать вменяемый скрипт. А ручной тестировщик всегда проблему может «обойти». Автомат ничего «обойти» не может и в этом его прелесть. В этом отношении машине больше доверия.
Я на своем старом проекте будучи автоматизатором репортил в несколько раз больше багов чем ручные тестировщики с эксплоративным подходом.
Да и если коснуться вопроса сколько проекту нужно «качества», мы понимаем, что многие клиенты не ракеты в космос запускают, им там супер качество и не нужно. Так, чтобы очевидные вещи не сыпались и уже неплохо. А когда ты закрыл регресс автоматизацией у тебя появляется время/возможность «шерудить шваброй в темных углах» приложения. Смотреть на качество кода, делать QA Achitecture (работать над тем, чтобы встроить качество в архитектуру и процесс разработки)
Подводя итоги скажу:
Автоматизация не замена ручному тестированию, а производственная необходимость. Ее именно так нужно рассматривать. Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
Ого, ты меня опередил) Я тебе респектую от души и согласен с каждым твоим словом)
Вот это вообще топ:
Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
время/возможность «шерудить шваброй в темных углах» приложения
В любом крупном проекте подобных задач набирается столько, что по-факту над ними работает отдельная команда SDET, так сказать, in Manual Testing. Но в вакансиях и резюме все пишут парочку хайповых фреймворков автоматизации, дабы не прослыть ретроградами.
Особенно это забавно на фоне того, что индустрия идёт по пути специализации - ведь уже даже есть отдельные специалисты по мейкфайлам и нажиманию кнопки Build. Но «тестирование у нас делают разработчики», ну да
Часто под разработкой люди понимают разработку своего продукта, но в айти на самом деле гораздо больше контрактной работы. Где ты предоставляешь заказчику работу/команду как сервис. А в контрактной работе тебе нужно предложить заказчику пакет услуг по приемлемой для него цене. И тут договориться об оплате выделеной роли не так просто. Конечно, подрядчик пытается увеличить чек, но конкуренция бешеная и это весьма и весьма сложно. Конкурренты демпингуют жестко, даже не имея необходимых компетенций, лишь бы получить контракт, а там хоть трава не расти. Поэтому работа айтишников сильно зависит от ловкости отдела продаж, смогут они охмурить заказчика или нет.
То, куда идет индустрия в конце концов решает рынок. Поэтому сервисные компании подбирают такой режим работы, чтобы во первых быть дешевле и получить заказ, а во вторых увеличить маржу, например, запихивая в проект джуниоров, и студентов.
А когда компания работает на себя, там другие мотивы. Они конкурируют продуктом.
Так что есть наше профессионально обусловленное представление о том как было бы лучше, и есть рынок, который все эти твои фантазии и мечты о лучшем мире жёстко херачит об асфальт и либо ты идешь на галеры, более или менее устроеные, либо ты идешь ко всем чертям (во фрилансеры).
Собственно о том и речь, что, несмотря на 30 лет обещаний консультантов всё автоматизировать, ни одна компания не обходится без ручного тестирования. И не так уж важно, занимается ли этим разработчик в нагрузку или отдельный человек - по факту затраты на это не уменьшились.
Это касается и крупных компаний из FAANG, где нет выделенной роли тестировщика нет только в Facebook (все знают уровень качества и удобства её продуктов)
Автоматизация процессов - это безусловно необходимость и сильно сокращает время регресса. Только всегда появляются ньюансы
1) Кто пишет автотесты? Встречаю команды, где работают в автоматизаторах разработчики и все тесты, условно, "в лоб" написаны, а чуть влево-вправо отойти от теста и лезут баги.
2) Если гонять только автотесты, можно получить эффект дихлофоса. Вроде все прогоны зеленые, но в саппорте жалобы
3) В процессе разработки нужно уже продумывать сценарии и окружение. Разработчики, хоть и покрывают свой код юниттестами, но часто не знают пользовательских сценариев
Потому что тестирование это борьба с комплексностью. Это решение задачи не как покрыть все (это невозможно на практике), а как с минимальными затратами покрыть наиболее критичные области приложения.
Поэтому хорошая метрика, не количество человекочасов в тестировании, или количество пройденых тесткейсов, а количество задокументированых багов. Нужно увеличивать выхлоп от тестирования, а не расширять тестировочные активности. Я бы еще ввел метрику соотношения найденых недочетов к задокументированым багам. У меня есть основания полагать, что далеко не все найденые недочеты попадают в беклог. Существенная их доля растворяется в дискуссиях. «Оно всегда так работало», «Давай не будем будить спящих собак», «У нас нет спецификации на это» и пр. и пр. Несгибаемых тестировщиков небывает, хоть к этому и надо стремиться.
Всё это компромиссы, компромиссики, которые потом боком выходят. Приведу тут еще раз тут эту поучительную историю:
При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности.— Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»
Вскоре после Рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01
Подобные метрики все таки, либо не работают, либо сложны в понимании, либо слишком много коэффициентов и поправок нужно вводить. Баги бывают сильно разные: приоритеты, затронутые компоненты, а так же заведение бага. Если баг не только был найден и задокументирован (вот баг, надо починить), но и был исследован так, что сразу понятно в какой компоненте или функции проблема, что экономит ресурсы разработчиков?
Скорее, показатель качества продукта - сколько багов (и какой серьезности) нашли пользователи и как сильно саппорт завалило тикетами.
Если коллеги из саппорта не приходят с фразой "как вы это ***** тестировали!?" - значит релиз вышел приемлимым
Вот поэтому из-за того, что они пишутся "в лоб", а если хочется продукт не кривой как ФБ, то отдел QA необходим. Для меня яркий показатель это Тинькофф. Где автотесты пишут разработчики, покрывающие регресс и фичи соотвественно, но пишут тест-кейсы и тестируют фичи – ручные QA. Ибо QA это больше про коммуникацию и процессы, а не тупое тыканье в аппликуху. Поэтому я скорее поверю в подобный коллаб QA/Developer, чем в вымирание ручного тестирования. Насчёт "машину не отманишь", "с человеком можно договориться", такое ощущение мы про госдуму говорим, а не энтерпрайз. Тысячу раз сталкивался с майндсетом разработчика, что для него это работает правильно, ведь под капотом же ок, а на юзкейсы (проще говоря) в ширь он не мыслит. И это правильно, в голове он видит код, а не юзера.
@eroshenkoam Спасибо за статью, уже заплюсовал. Хочу поинтересоваться, а не собираетесь ли вы делать доклад про то кто такой FullStack QA ? Очень хотелось бы услышать именно вашего развернутого мнения поэтому вопросу
Из серии "Меня зовут %username%. Мне нравилось быть тестировщиком и нажимать на кнопки в приложениях, проверять, все ли они работают так, как это задумывалось изначально. Но со временем для качества ПО этого стало не достаточно, и я решил стать кем-то другим, чем-то другим (не "Зеленой стрелой", но "Серебряной пулей")"
Будущее ручного тестирование и главные тренды области: интервью с Артёмом Ерошенко