Этот вопрос беспокоил меня с тех пор как я посмотрел на пирамиду тестирования, концепт придуманный Mike Kohn в его книге “Succeeding with Agile”. Ее суть состоит в том, что у вас должно быть 70-80% юнит-тестов, затем 10% интеграционных тестов, затем 5% системных тестов и наконец 5% GUI тестов.
Процентный разброс может различаться. Вся суть в том, что у вас должно быть намного больше низкоуровневых юнит-тестов, чем высокоуровневых тестов через GUI.
Если вы взгляните на это немного глубже, это становится возможно только если тестировщик так же обладает программистскими навыками. Просмотром исходного кода он сможет понять роль юнит-тестирования в понижении рисков по отношению к end-to-end (неразрывному) тестированию.
Сейчас команды двигаются по направлению к Acceptance Test Driven Development (ATDD). Где опять же играет роль программирование.
Когда бы я ни услышал историю успеха пирамиды тестирования, в ней всегда есть ключевой фактор успеха. Это либо программисты проводили все тестирование, либо тестировщики научились программированию для того чтобы тестировать.
Люди избавляются от ручной работы как замечено в LeSS queuing theory. В процессе они отходят от роли тестировщика полностью. Это становится достаточно распространенным во многих стартапах в эти дни.
По моему мнению, двигаясь вперед, обе роли обретут возможность к программированию как предпосылку в части развития. Разница будет только в том, что тест-инженеры на первый план поставят тестирование, а разработку на второй. Они будут тратить добрую долю своего времени программируя в форме написания скриптов и кода для автоматизированных сценариев.
Тест-инженерам суждено стать продуктовыми экспертами, советниками по качеству и риск аналитиками.
В заключении:
Ушли в прошлое те времена, когда ручного тестирования было достаточно, и тестовый цикл мог занять месяцы. Тестерам необходимо стать хорошими программистами для того чтобы двигаться вперед. Просто быть знакомым с программированием уже не достаточно. Они должны быть способны изучать и развивать последние фреймворки автоматизации и работать со скриптовыми технологиями чтобы быть конкурентно способными.
Комментарии (64)
kentastik
07.09.2015 08:21+2Ох, сколько раз я видел, что билд даже не запускался, в котором поправили всего 1 букву и разработчик даже не стал проверять. Так и вижу повсеместные краши из-за этого. Это я всё к тому что не умрёт ручное тестирование никогда, если вы хотите хороший продукт. Тупо писать код теста это… я бы не назвал это развитием или качественным рывком вперед.
EuroElessar
07.09.2015 08:52+3Для таких случаев есть CI системы, запускающие тесты для всех изменений, например это можно увидеть в Qt Project. Тестирование UI так же прекрасно автоматизируется с помощью таких проектов как Selenium. Эти подходы позволяют гарантировать, что к пользователям не улетят не протестированные решения.
К тому же уже сейчас ручное тестирование вымирает, многие компании не имеют ни людей занимающихся ручным тестированием, ни отдела тестирования как такого, ярким примером такого подхода является Facebook.
vedenin1980
07.09.2015 10:43+1ни отдела тестирования как такого, ярким примером такого подхода является Facebook
не знаю как насчет отдела тестирования, но в LinkedIn полно QA инженеров Facebook'a. Что-то тут не так…
vedenin1980
07.09.2015 09:12+1Разница будет только в том, что тест-инженеры на первый план поставят тестирование, а разработку на второй. Они будут тратить добрую долю своего времени программируя в форме написания скриптов и кода для автоматизированных сценариев.
А почему все это написано в будущем времени? Все настоящие QA-аналитики, которых я встречал, писали скрипты и код для автоматизированных сценариев.
Люди избавляются от ручной работы как замечено в LeSS queuing theory. В процессе они отходят от роли тестировщика полностью. Это становится достаточно распространенным во многих стартапах в эти дни.
Я один не вижу тут логики? Почему QA-аналитик, который занимается автоматическим тестированием вместо ручного, вдруг перестает быть тестировщиком?
Тест-инженерам суждено стать продуктовыми экспертами, советниками по качеству и риск аналитиками.
Зачем? Нормальный QA-аналитик это человек, который участвует в разработке проекта с самого нуля и создает свою тестовую модель параллельно модели бизнес-аналитиков и программистов. Такая модель позволяет «поймать» даже ошибки бизнес анализа. Никогда программисты настоящего QA-аналитика не заменят.
Это либо программисты проводили все тестирование
Этот миф я встречал ещё 20 лет назад, зачем нам QA если мы программисты? Ни разу не видел, чтобы это действительно прокатывало, теория QA это отдельная и довольно серьезная дисциплина, которое рассказывает как и что тестировать правильно, невозможно одновременно хорошо совмещать обе роли, как невозможно одновременно хорошо совмещать роли юриста, бухгалтера и финансиста, все равно такой человек будет проигрывать специалистам (ну если он не супергений).
Обычно когда отказывались от QA качество продукта резко падало, ну не возможно заменить unit test'ами реального QA специалиста.
либо тестировщики научились программированию для того чтобы тестировать
Да не программированию, а использованию инструментов автоматизированного тестирования и написанию/созданию сценариев. Это две большие разницы, собственно далеко не всегда автоматические тестовые сценарии именно программируются. Но вообще-то, Middle/Senior QA не умеющий использовать такие инструменты это какое-то не совсем Middle/Senior, я всегда считал что только джуниоры могут себе позволить не знать инструменты для автоматического тестирования.
SkvPavel
07.09.2015 09:40Что вы прицепились к QA-аналитикам? Почитайте Блека, QA никогда не пишет автотесты, если у вас есть QA-аналитик, который пишет автотесты, то бодишоп, в котором он работает просто решил продать его дороже. Вот и всё.
vedenin1980
07.09.2015 09:56+1Почитайте Блека
Дайте ссылку или полное имя и название книги/статьи. Кстати автор кто ведущий архитектор Микрософта/гугла и т.п.?
QA никогда не пишет автотесты
Странно, я работал в международной компании одной из крупнейших в мире — там QA писали автотесты. Мы постоянно общались с другими огромными международными компаниями — там QA писали автотесты. Какое-то странное НИКОГДА получается.
А кто тогда умеет грамотно писать автотесты? Программисты? А они этому учились, чтобы тест не просто что-то там проверял, а действительно правильно покрывал все возможные бизнес кейсы?SkvPavel
07.09.2015 10:02-3Дайте ссылку или полное имя
Rex Black. Прямые ссылки не буду давать, не то место.
Странно, я работал в международной компании одной из крупнейших в мире
Действительно странно, но без знания внутреннего устройства команды и проекта сложно о чем-либо судить.vedenin1980
07.09.2015 10:10Возможно у вас просто другое понимание что такое автотесты и вы имеете в виду unit-тесты или интеграционные тесты, которые обычно пишут действительно разработчики. Автотесты QA это специальные системы отправляющие пачки Rest/Soup запросов (с генерацией фейковых данных) и анализирующие правильность ответа, автотесты QA это когда QA записывают макрос вручную проходя тест кейс в браузере, а потом специальные системы автоматически повторяют его и проверяют что на всех шагах ничего не сломалось. Ничем из этого программисты заниматься не будут, тупо потому что это большой стек технологий, сопоставимый с стеком технологий программистов, да и вообще QA это отдельная дисциплина, которой несколько лет учат в Западных университетах.
SkvPavel
07.09.2015 10:14автотесты QA это когда QA записывают макрос вручную проходя тест кейс в браузере, а потом специальные системы повторяют его и проверяют что на всех шагах ничего не сломалось.
Вы про Selenium IDE сейчас? :)
Ой, а расскажите тогда, чем ваш «записанный» тест отличается от интеграционного теста, написанного программистом Васей, который так же открывает браузер и тыкает по UI элементам используя тот же кейс?vedenin1980
07.09.2015 10:19+1Вы про Selenium IDE сейчас
Это не единственная подобная система
расскажите тогда, чем ваш «записанный» тест отличается от интеграционного теста, написанного программистом Васей, который так же открывает браузер и тыкает по UI элементам используя тот же кейс
Тем что кейс не будет тем же, грамотно придумать тест кейсы ничуть не легче чем грамотно придумать архитектуру программы. Это равносильно спросить зачем нужен архитектор, если джуниур-программист тоже умеет рисовать блок-схемы.
Тут два варианта либо у вас будет плохой программист с навыками QA, либо у вас будет отдельно хороший программист и отдельно хороший QA, специализация рулит почти всегда.
vadim_shb
07.09.2015 23:06Вам пытаются дать понять, что вы терминологически запутались. Именно терминологически — описанный вами «автотест QA» является ни чем иным, как интеграционным функциональным тестом. А с применением каких технологий (Selenium / SoapUI / Java NIO / assembler) и кем написанно — не важно.
Этот терминологический нонсенс вообще удручает.
В какой то момент, у QA инжинеров появились инструменты создания автоматических тестов. Они стали называть их «автотестами», чтобы отличать от ручных. Но потом, почему-то..., они начали противопоставлять их unit-тестам, чтобы отличать их от тех, что пишут программисты. А слова нового не придумали. Хотя unit-тесты тоже являлись автоматическими уже тогда… И уже тогда программисты писали не только unit, но и интеграционные тесты.
С тех пор прошло немало времени, а QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать. И нам приходится додумывать, что скорее всего имеются ввиду Selenium тесты (по-моему за ним еще большинство, хотя конкурентов хватает). Называли бы их тогда Selenium тестами, и не запутывали всех вокруг.
Причем разграничивать тесты по тому — кто их написал вообще бессмысленно. Я уловил вашу мысль, что QA-инженер скорее напишет более грамотный тест-кейс, но к классификации тестов, как таковых, это отношения не имеет.vedenin1980
07.09.2015 23:42описанный вами «автотест QA» является ни чем иным, как интеграционным функциональным тестом
Да, является, спасибо, я в курсе. (хотя его можно назвать и Системное тестированием, разница между ними не такая большая). Автотест QA означает лишь автоматический тест, написанный QA инженером. Он может быть интеграционным тестом, может быть GUI-тестированием, но все равно остается автоматическим тестом.
QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать
Я ни разу не QA, а как раз программист. И ни разу не слышал чтобы тесты написанные программистами назывались автотестами. И так понятно что unit и интеграционные тесты, написанные программистами, будут автоматическими, так как программисты ручных тестов не делали никогда, зачем это уточнять?
cкорее всего имеются ввиду Selenium тесты
Это называется GUI-тестирование
классификации тестов
Она может быть разной, в том числе и по тому кто тест написал и каким образом, но это уже споры по понятиям.
говоря «автотест» уверенны, что их все должны понимать
Ну, «автотест» это «Автоматизированное тестирование». По-моему, тут сложно что-то не понять. Почему под автоматизированым тестированием надо обязательно понимать unit тесты (цитата выше «QA никогда не пишет автотесты») мне тоже не очень понятно.vadim_shb
08.09.2015 10:14хотя его можно назвать и Системное тестированием, разница между ними не такая большая
Согласен. Я бы разницы не заметил. Хотя если верить википедии — то она есть
программисты ручных тестов не делали никогда
Программисты постоянно занимаются ручным тестированием, если не пишут автотестов (видимо буду первым, кто назовет их так в вашем присутствии). Запускают написанную программу — и смотрят все ли правильно работает. Они их редко оформляют в виде тестовых сценариев, или проводят ручные регрессы — но тестирование фич проводят.
Это называется GUI-тестирование
Да, тоже можно… Всяко понятнее, чем «автотесты». Но из контекста должно быть понятно, что имеется ввиду не ручное GUI тестирование…
цитата выше «QA никогда не пишет автотесты»
Согласен… Бред полный написан. Не разглядел поначалу.
Вообще посыпаю голову пеплом… С вашей стороны на протяжении этого треда в подавляющем большинстве случаев была корректная терминология.
Просто я неправильно прочитал вот эти строки вещи:
Автотесты и Юнит-тесты это две большие разницы
Возможно у вас просто другое понимание что такое автотесты и вы имеете в виду unit-тесты или интеграционные тесты
А затем вы приправили их вот этим
И ни разу не слышал чтобы тесты написанные программистами назывались автотестами
Вообще у меня вызывает баттхерт, когда люди говоря «автотест» подразумевают именно «автотест написанный QA-инженером», а такое случается постоянно. И это не правильно.
Автотест, согласно присланной вами же ссылке это и unit-тест и интеграционный, вне зависимости от того кем написан. Главное, чтобы его можно было запускать без участия человека.
DrPass
07.09.2015 10:11Юнит-тесты пишут программисты. Это не касается бизнес-кейсов, здесь речь идет о поведении подпрограмм в соответствии с архитектурными спецификациями, и это всё в рамках квалификации программиста. Вот GUI-тестирование или тестирование внешних интерфейсов уже должно проводиться в рамках соответствия бизнес-кейсам. Конечно, никто не мешает тестировщику добавить дополнительных скиллов, и он будет писать юнит-тесты для внутреннего API приложения, но это уже просто делегирование ему части функций программиста, а не его прямая обязанность в рамках специализации.
vedenin1980
07.09.2015 10:15Автотесты и Юнит-тесты это две большие разницы (см. сообщение выше). Юнит-тесты никогда полноценно не заменяют автотесты QA. Ручное тестирование автотесты заменить могут, но Юнит-тесты нет.
DrPass
07.09.2015 11:40Да, я уже понял, что вы под автотестами подразумеваете только функциональное тестирование. Добавлю только, что ручное тестирование оно полностью не может заменить. Ручные тесты предполагают не только контроль соответствия спецификациям, но и usability-контроль, поэтому без живого тестировщика все равно не обойтись.
DigitalSmile
07.09.2015 09:47+1Абсолютно согласен с автором. Из опыта могу сказать, что подход с юнит-тестами + автоматизированным тестированием + немного ручного тестирования дает очень большой качественный эффект. Если это еще стоит и на рельсах CI, то эффект можно смело умножать на два.
Я считаю, роль тестировщика должна быть одной из ключевых в команде, поскольку только он может сказать «продукт готов, можно выпускать».
Krizai
07.09.2015 09:53+1Категорически не согласен с полным вымиранием ручного тестирования. Допускаю что это возможно для систем с низкой энтропией, но для областей где Большей частью системы является ui и десятки ивентов бегают наперегонки — слабо себе представляю. Яркий пример такой области для меня — мобил разработка.
biomaks
07.09.2015 10:09-1А никто не говорит о его вымирании, в статье предрекается его трансформация.
kentastik
07.09.2015 10:20+2Да не будет этого. Я вам с десяток примеров приведу которые вы не заавтоматизируете «на раз-два», но которые проверяются за 1 секунду даже джуниором. А коли есть такие примеры, то и говорить не о чем.
EuroElessar
07.09.2015 10:35А будьте добры такие примеры, вы меня заинтересовали.
kentastik
07.09.2015 10:41+1Если в общем, то по большей части это визуальная составляющая:
- Анимационные и видеоэффекты верстки.
- Удобство использования.
- Отображение картинок, видео.
- «Невлезающие», «поехавшие» элементы верстки.
В целом, есть сильная ограниченность проверки только по запрограммированным прогонами. Как подсказывает мой опыт, какие сценарии не выдумывай пользователь сделает по своему.DigitalSmile
07.09.2015 10:45Вот под это и отводится 5% в общем объеме тестирования.
UPD: даже 10%, на уровне приемочного тестирования это тоже можно выявить, в т.ч. руками.kentastik
07.09.2015 10:58+2Если в вашем приложение 2 кнопки и 1 форма, то да. На проектах, где мне доводилось работать очень большая часть нуждается в живой проверке глазками, я бы обозначил как 50%. А сколько таких проектов как мои? У меня нет статистики, поэтому и сомневаюсь я в 5%, это пальчиков в небо, извините.
EuroElessar
07.09.2015 11:10В части продуктов такие вопросы решаются с помощью так называемого dog fooding, т.е. процесса тестирование продуктов компании сотрудниками в процессе обычного ежедневного использования. К пользователям при этом выкатывается версия, которой пользовались внутри компании последний день/неделю. За счет этого опять же нет необходимости выделять время/людей специально для ручного тестирования.
DigitalSmile
07.09.2015 11:11Здесь может быть в другом проблема и размер тут не при чем — затраты на поддержку автоматизированного тестирования не входит в бюджет (или признаны слишком большими для такого проекта). Возможна также некомпетентность отдельных руководителей.
Давайте разберем Ваши задачи по полочкам:
1) Анимационные эффекты — только ручное, трудоемкость невысокая (на уровне «открыл, посмотрел, зафиксировал»).
2) Удобство использования, по идее, должно быть заложено на этапе проектирования интерфейса и затраты тестирования должны быть отнесены на этот этап.
3) и 4) Отображение картинок, видео и «поехавшая верстка» см. п. 1)
В итоге весь класс задач, можно охарактеризовать, как Вы верно подметили, «визуальной составляющей», т.е. той, что требует людских глаз для оценки. В вашем проекте 50% времени тестировщики выполняют такую работу? Это вполне возможно для определенных категорий проектов (игры, анимационные приложения), но все таки в общей доле проектов это не большинство. А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Что касается проектов с моим участием, то они частенько сложнее двух кнопок и формы. Мы стараемся двигаться в направлении автоматизации по похожей схеме и это дает ощутимый эффект.
vedenin1980
07.09.2015 13:18А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Есть ложь, большая ложь и статистика. (с) На самом деле, я видел огромное кол-во подходов к тестированию.
Интеграционный тест может быть написан программистов, может запускаться QA через инструменты для тестирования SOUP/Rest и т.п. Интеграционный тест может быть заменен функциональным автотестом/макросом (но не всегда наоборот), то есть если макрос работы с UI вдруг сломался результат будет тот же что сломался интеграционный тест. Видел, я когда люди чрезмерно увлекались unit-тестами, так что придумывали совершенно бессмысленные тесты ради покрытия в 200% (и тратили кучу времени на правку unit-test'ов при банальном изменении одной функции) или наоборот все отдавали на откуп отделу QA.
Надо понимать что нет серебряной пули тестирования, есть относительно модные на данный момент технологии, но у каждой компании своя политика тестирования и свои приоритеты между разными видами тестов. И так будет всегда, через лет пять мятник может качнуться в другую сторону и станет модным меньшее кол-во unit-тестов и больше ручного и полуручного тестирования, как стал модным старый забытый nosql после моды на sql. Поэтому говорить о какой-то статистике или правилах не очень-то правильно.DigitalSmile
07.09.2015 13:28Подходов вагон и маленькая тележка, конечно нужно с умом подходить. Если статистика для большинства, это не значит, что подход подойдет именно Вам.
Не согласен по поводу правил. Правила, или если хотите «рецепты» или «подходы», очень нужны и важны. Это обмен опытом, не представляю как можно без него представить ИТ индустрию.vedenin1980
07.09.2015 13:37Если статистика для большинства,
А кто приходил в гугл, оракл или микрософт и мерил эту статистику (которая коммерческая тайна, если что)? Надо понимать что нарисованная пирамида это не статистика для большинства (никто никогда не сможет перемерить бизнес процессы всех компаний в мире, не говоря уже о том что мало кто будет раскрывать свои коммерческие тайны), это числа взятые из головы конкретным автором, как ОН видит правильный подход к тестированию, не более того. Ну максимум статистика для десятка компаний его региона, к статистике которых у него есть доступ.DigitalSmile
07.09.2015 13:54Ну я все таки верю, что человек, который пишет про Agile книги и продает их, не с потолка берет эти сведения, у него наверняка есть аргументы, почему так.
Тем не менее, Вы правы, что это просто взгляд, а не истина, которой следует идти. Повторюсь, своя голова у всех должна быть :)
Кстати оригинал статьи не открывается.
Krizai
07.09.2015 10:22+1Да, с эволюционной трансформацией безусловно согласен. Просто рассматриваю это лишь как небольшой смещение акцента, а не радикальную трансформацию.
tangro
07.09.2015 10:39+1А чем вообще объясняется в этой пирамиде столь большой процент (аж 80%) самых низкоуровневых тестов? Как по мне, значительно лучше иметь больше интеграционных тестов, поскольку один раз написанная функция ломается ну очень редко, а вот связи компонентов при перетасовке архитектуры — достаточно часто.
DigitalSmile
07.09.2015 10:43Архитектуру Вы перетасовываете реже, чем вносите правки в методы.
burjui
07.09.2015 12:35Но это значит, что и юнит-тесты придётся переписывать чаще. Вы же не думаете, что можно один раз написать низкоуровневый юнит-тест, а всё остальное время пытаться впихнуть код в его прокрустово ложе?
DigitalSmile
07.09.2015 12:49Придется (если у Вас не TDD), не вижу противоречий в моем ответе на вопрос про высокий процент низкоуровневых тестов.
tangro
07.09.2015 16:16Ладно, не так выразился. Пуская не при изменении архитектуры, а при включении плагинов или сборке кастомного билда для нового клиента с отдельными дополнительными модулями.
zharikovpro
07.09.2015 12:56Допустим, есть интеграционный тест для проверки функции оформления заказа в магазине. Ввели новый тип продукта и он упал. В чем причина? В контроллере или модели? В неверном расчете баланса пользователя или цены скидки? Интеграционный тест покажет, что большая часть программы не работает. Юнит тесты в данном случае помогут быстро найти юнит, в котором проблема. И если покрыть этот случай тестом, то автоматически будет тестироваться работа юнита в других местах (например, функции расчета скидки или работы с балансом пользователя).
tangro
07.09.2015 16:15Интеграционный тест покажет, что большая часть программы не работает.
Отлично, этого и добиваемся. А 10 юнит-тестов отдельных компонентов покажут что «всё хорошо, компонент рабочий» — абсолютно бестолковая информация.zharikovpro
07.09.2015 17:46Ваш вопрос был о том, почему большой процент низкоуровневых тестов. Потому что на примере данного случая будет 1 интеграционный тест и например десяток юнит-тестов для быстрой и точной локализации проблемы. Отсюда и такое соотношение. Естественно, если интеграционный тест показывает проблему, а юнит-тесты не показывают — что-то забыли протестировать в юнит-тестах и нужно дописать новый юнит тест на данный кейс.
> Отлично, этого и добиваемся.
Добиваемся не только этого, но и быстрой локализации причины проблемы и ее быстрого устранения. И также уверенности в том, что в будущем эта же проблема в этом же модуле не повторится. Юнит тесты очень хорошо в этом помогают.
Итого нужны разные виды тесты для разных задач и хорошо, когда тестирование проводится комплексно.tangro
07.09.2015 17:54+1Я хотел сказать, что юнит-тест неплохо решает задачу «мы знаем, какой может быть баг и вот на него тест» — да, отличная локализация и прекрасно, что он существует. Но в жизни чаще случаются ситуации «мы не знаем, какой может быть баг и надо хотя-бы понять, что он где-то произошел» — и вот с этой задачей интеграционный тест справится лучше. Если юнит-тесты, грубо говоря, прикрывают программиста, то интеграционные (и выше) уже дают понимание руководству как там сейчас поживает продукт — можно его использовать или нет.
zharikovpro
07.09.2015 18:00Все так. Просто интеграционные тесты прогоняются долго и пишутся часто сложнее. Вопрос об оптимальном соотношении одних к другим — открытый, вероятно в каждом проекте свой оптимальный баланс. Не видел каких-то универсальных обоснованных правил на эту тему.
Да, еще момент про юнит-тесты. Вот пишет прогер допустим функцию или модуль. Они используются в разных местах приложения в связке с другими модулями. Как написать приемочный интеграционный тест для этого модуля? Это неправильно в том смысле, что он не покажет результат работы именно этого программиста (будет задевать чужие куски). В этом мне кажется тоже одна из важных причин того, что интеграционных тестов всегда меньше чем юнит. От общего (интеграционные) к частному (юнит) увеличивается количество сущностей. И это нормально вроде как :)
freeAKK
07.09.2015 12:58Мне кажется, что тут есть скрытый эффект. Это заставляет увеличивать процент кода, который можно покрыть unit-тестами, уменьшая процент кода, который сложно тестить.
shuron
07.09.2015 19:13Ответ
чем ниже в пирамиде тем:
— больше изоляция в тестах. Меня маленькую компонентут вы меняете один, малький понятный тест.
— в рыз большая скорость тестирования, скороть тестевого цыкла
Чем выше в пирамиде те:
— выше ваша увереность в правильности функционала
— но приходится править все тесты при каждом чихе.
Представьте вы написали калькулятор простой из двух сервисов…
И решили сначала написать тест UI
shuron
07.09.2015 19:05Спасибо, какраз вот всю неделю размышляю над и какраз каказал сегодня чуть эту книгу не заказал отпугнуло немного что её уже 6 лет.
И тут вы;)
Скажите это не оправданно? Как вам книга?
orcy
07.09.2015 21:32+2— «Пап, а можно ли выпустить качественный продукт без ручного тестирования?»
— «Нет, сынок, это фантастика».
Кстати на продуктах без серьезного UI наверное вполне можно (компиляторы, базы данных, итд). Обычно говорят об автоматизации UI тестирование как о панацеи, однако в этой статье даже не про это, а про какой-то странный посыл что unit-тестами можно заменить тестирование сценариев уровня пользователей, что на мой взгляд вообще не особо реалистично. Не знаю, как будто тут предлагают вместо антибиотиков прописывать витаминки, потому что они дешевле и форма у них круглая. Пользователю у которого сломался сценарий пофиг на 1000 зеленых тест резалалтов в вашей CI.
Насчет автоматизации UI-тестирования: я давно думал о том что надо двигаться в направлении автоматизации UI-тестирования, но я склоняюсь что очень часто это может быть не практично. С одной стороны заманчиво написать UI тест который бы проверял работоспособность автоматически. Однако получается такой парадокс: там где UI часто меняется становится довольно дорого обновлять тесты, а там где UI не меняется, там часто и не нужен объем работ по тестированию. Нужно хорошо понимать когда автоматизация UI-тестирования будет выгодна, а это не просто.
Иногда наличие UI-тестов тормозит развитие продукта. Например, есть хорошая идея для небольшой оптимизации интерфейса, которая ломает много готовых автоматических UI-тестов. В такой ситуации высок соблазн оставить все как есть, т.к. очень жалко потраченных ресурсов на тесты.shuron
13.09.2015 15:59Сорри но иммено об этом и речь что проекты изначальмо ставящие на автоматизацию UI тестов, имеют серьезные проблемы (Мой личный опыт это подтверждает)
Коротко обьясненно тут. Для пример там же даны ссылии на гугл блог.
Но там не догматично как любое правило/паттерн в информатике…
Просто в совремненом состоянии IT (тенденции к микросервисам и CI /CD +Agile)
хорошо
TestingPyramid
korvinriner
08.09.2015 11:29+2ИМХО В любом случае автоматизированное тестирование — лишь инструмент, который используется или не используется в рамках процесса тестирования. Контекст данной статьи звучит для меня приблизительно как: «Скоро все откажутся от лопат в пользу экскаваторов...» Полностью заменить ручное тестирование на что-то возможно лишь в полностью автоматических системах или системах, где роль «пользователь» почти и не нужна. Да и экономический и технический профит должен быть колоссальный от автоматизации, чтобы она «выстрелила». Хотя бы потому что ее надо:
1. Создать.
2. Описать.
3. Регламентировать.
4. Поддерживать.
5. Обновлять.
6. Анализировать результаты ее работы.
Собственно я всегда за, когда количество ручного труда, переложенного на плечи автоматизации, растет, но не питаю иллюзий, что когда-нибудь смогу заниматься только автоматизацией… совсем без ручного тестирования. :)
kurnosova
Тестировщик — это не просто роль в команде, а отдельная специализация, человек который может дать объективную оценку качества программы, потому что понимает как она работает. Такие люди умеют программировать. И в проектах, которых просто необходим высокий контроль качества, без них не обойтись. Другое дело, что сейчас многие тестировщики не обладают такой квалификацией, потому что иногда компании экономят на качестве.
SerafimArts
Боюсь что в подавляющем случае всем тестированием занимаются сами программисты и более того — вымогают у начальства время, чтоб покрыть код оными. Самые ярые сторонники качества придумали даже (если так можно выразиться) контрактное программирование, где сам код берёт на себя процентов ~30% задач юнит-тестирования. А тестеры (при наличии оных в команде) просто пользуются продуктом находя все подводные камни со стороны пользователей. И отрадно и печально, но пока дело в основном, среднем секторе ИТ дело обстоит так.
kurnosova
Я так поняла из комментария, что вы считаете, разрабатывая юнит-тесты, разработчик выполняете часть работы тестировщика. Но разве это не задача разработки кода? Причём тут тестировщики?
Что значит вымогать у начальства время на юнит-тесты? это ведь неотъемлемый процесс разработки. Как можно оценить сколько время надо выклянчить на тесты если ещё код не написан?
Дело обстоит так (и тут я согласна) по вине всех сторон, задействованных в разработке, конкретно тестирование тут не причём.
SerafimArts
Тогда я просто не понял статью. Что тогда подразумевается под этими раритетными «тестировщиками», которым следует учиться писать код? Лично я подразумевал ребят, которые просто тукают в кнопочки, проверяя работоспособность какого-либо функционала. Но тогда в чём смысл им учиться программировать? Чтоб чётко составлять задачи?
VolCh
Юнит-тесты не всегда пишутся до кода.
loz
Согласен, был опыт работы с тестировщиком, который вначале тестировал вручную, постепенно по мере общения заинтересовался программированием именно для автоматизации, все больше въезжал в тему, спрашивал, советовался, и в итоге сильно автоматизировал свою работу, включая генерацию входных данных, прогоны кейсов и тд.
И это в том числе облегчало жизнь программистами, когда они вносили изменения в тесты.
shuron
А разве не клиент которому или под которого (или клиент как целевая группа — Persona пишут софтину являеттся единственным кто оценивает качеств софта? Все остальные занимаются транляцией его ожиданий- что очень субьективно… и это нормально…
Интересно какже софтверные гиганты типа нетфликс умудряются релизить софтину автоматически, если все тесты автоматические тесты прошли. Кто и где у них тестировщик? И на сколько он обьективен? ;))
vedenin1980
Тут?
Были бы необъективны, их бы наверное не держали?
shuron
Ха ха классынй аргумент. В штате есть QA ;)
Однозначно уних есть не один продукт и система которые деплоются по 10 раз за день пройдя автоматические тесты без участия человека (с кнопкой «добро»)
Конечно не везде… это нормально…
Так же они используют активно Canary testing, тоесть тестировщик у них в классическом смысле сам клиент ;)
П.С. мы на фирме тоже имеем никаких тестировщиков, нам конечно далековато до нетфликса, но релизим по разу в день иногда…
Достаточно автоматичеких тестов… для 80% систем… 20% имногда кликаются или тестируются самими девелоперами или ПО если решили что «пока» тестировать автоматичеки будет дороже чем «прокликать»…
Конеч у нас «доменная специфика», но
«Обьективых тестировщиков» нам точно не надо… ;)
VolCh
Оценка клиента как раз очень субъективна именно потому что у него есть неформализованные ожидания, а часто даже не осознанные.
shuron
Дык в том то и дело… Она субьективна и она решает! Все остальное додумки и надстроки…
Важнее клиентская субьективность чем придуманая обьективность…
Если вы считаете что клиент не прав повлияйте не него… А если ваш клиент это 10000 посетителей сайта..?
VolCh
Объективность на то и объективность, что не придуманная :)
Для меня клиент — человек с должностью типа «Директор департамента разработки программного обеспечения генерального департамента информационных технологий ООО „Рога и копыта Лтд.“ :)
shuron
И какой вывод?