Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
Тестировщик — это не просто роль в команде, а отдельная специализация, человек который может дать объективную оценку качества программы, потому что понимает как она работает. Такие люди умеют программировать. И в проектах, которых просто необходим высокий контроль качества, без них не обойтись. Другое дело, что сейчас многие тестировщики не обладают такой квалификацией, потому что иногда компании экономят на качестве.
Боюсь что в подавляющем случае всем тестированием занимаются сами программисты и более того — вымогают у начальства время, чтоб покрыть код оными. Самые ярые сторонники качества придумали даже (если так можно выразиться) контрактное программирование, где сам код берёт на себя процентов ~30% задач юнит-тестирования. А тестеры (при наличии оных в команде) просто пользуются продуктом находя все подводные камни со стороны пользователей. И отрадно и печально, но пока дело в основном, среднем секторе ИТ дело обстоит так.
Я так поняла из комментария, что вы считаете, разрабатывая юнит-тесты, разработчик выполняете часть работы тестировщика. Но разве это не задача разработки кода? Причём тут тестировщики?
Что значит вымогать у начальства время на юнит-тесты? это ведь неотъемлемый процесс разработки. Как можно оценить сколько время надо выклянчить на тесты если ещё код не написан?
Дело обстоит так (и тут я согласна) по вине всех сторон, задействованных в разработке, конкретно тестирование тут не причём.
Что значит вымогать у начальства время на юнит-тесты? это ведь неотъемлемый процесс разработки. Как можно оценить сколько время надо выклянчить на тесты если ещё код не написан?
Дело обстоит так (и тут я согласна) по вине всех сторон, задействованных в разработке, конкретно тестирование тут не причём.
Тогда я просто не понял статью. Что тогда подразумевается под этими раритетными «тестировщиками», которым следует учиться писать код? Лично я подразумевал ребят, которые просто тукают в кнопочки, проверяя работоспособность какого-либо функционала. Но тогда в чём смысл им учиться программировать? Чтоб чётко составлять задачи?
Юнит-тесты не всегда пишутся до кода.
Согласен, был опыт работы с тестировщиком, который вначале тестировал вручную, постепенно по мере общения заинтересовался программированием именно для автоматизации, все больше въезжал в тему, спрашивал, советовался, и в итоге сильно автоматизировал свою работу, включая генерацию входных данных, прогоны кейсов и тд.
И это в том числе облегчало жизнь программистами, когда они вносили изменения в тесты.
И это в том числе облегчало жизнь программистами, когда они вносили изменения в тесты.
Тестировщик — это не просто роль в команде, а отдельная специализация, человек который может дать объективную оценку качества программы, потому что понимает как она работает.
А разве не клиент которому или под которого (или клиент как целевая группа — Persona пишут софтину являеттся единственным кто оценивает качеств софта? Все остальные занимаются транляцией его ожиданий- что очень субьективно… и это нормально…
Интересно какже софтверные гиганты типа нетфликс умудряются релизить софтину автоматически, если все тесты автоматические тесты прошли. Кто и где у них тестировщик? И на сколько он обьективен? ;))
Кто и где у них тестировщик?
Тут?
И на сколько он обьективен?
Были бы необъективны, их бы наверное не держали?
Ха ха классынй аргумент. В штате есть QA ;)
Однозначно уних есть не один продукт и система которые деплоются по 10 раз за день пройдя автоматические тесты без участия человека (с кнопкой «добро»)
Конечно не везде… это нормально…
Так же они используют активно Canary testing, тоесть тестировщик у них в классическом смысле сам клиент ;)
П.С. мы на фирме тоже имеем никаких тестировщиков, нам конечно далековато до нетфликса, но релизим по разу в день иногда…
Достаточно автоматичеких тестов… для 80% систем… 20% имногда кликаются или тестируются самими девелоперами или ПО если решили что «пока» тестировать автоматичеки будет дороже чем «прокликать»…
Конеч у нас «доменная специфика», но
«Обьективых тестировщиков» нам точно не надо… ;)
Однозначно уних есть не один продукт и система которые деплоются по 10 раз за день пройдя автоматические тесты без участия человека (с кнопкой «добро»)
Конечно не везде… это нормально…
Так же они используют активно Canary testing, тоесть тестировщик у них в классическом смысле сам клиент ;)
П.С. мы на фирме тоже имеем никаких тестировщиков, нам конечно далековато до нетфликса, но релизим по разу в день иногда…
Достаточно автоматичеких тестов… для 80% систем… 20% имногда кликаются или тестируются самими девелоперами или ПО если решили что «пока» тестировать автоматичеки будет дороже чем «прокликать»…
Конеч у нас «доменная специфика», но
«Обьективых тестировщиков» нам точно не надо… ;)
Оценка клиента как раз очень субъективна именно потому что у него есть неформализованные ожидания, а часто даже не осознанные.
Ох, сколько раз я видел, что билд даже не запускался, в котором поправили всего 1 букву и разработчик даже не стал проверять. Так и вижу повсеместные краши из-за этого. Это я всё к тому что не умрёт ручное тестирование никогда, если вы хотите хороший продукт. Тупо писать код теста это… я бы не назвал это развитием или качественным рывком вперед.
Для таких случаев есть CI системы, запускающие тесты для всех изменений, например это можно увидеть в Qt Project. Тестирование UI так же прекрасно автоматизируется с помощью таких проектов как Selenium. Эти подходы позволяют гарантировать, что к пользователям не улетят не протестированные решения.
К тому же уже сейчас ручное тестирование вымирает, многие компании не имеют ни людей занимающихся ручным тестированием, ни отдела тестирования как такого, ярким примером такого подхода является Facebook.
К тому же уже сейчас ручное тестирование вымирает, многие компании не имеют ни людей занимающихся ручным тестированием, ни отдела тестирования как такого, ярким примером такого подхода является Facebook.
ни отдела тестирования как такого, ярким примером такого подхода является Facebook
не знаю как насчет отдела тестирования, но в LinkedIn полно QA инженеров Facebook'a. Что-то тут не так…
А сколько раз я видел зеленые тесты, но при этом не работающую фичу.
Разница будет только в том, что тест-инженеры на первый план поставят тестирование, а разработку на второй. Они будут тратить добрую долю своего времени программируя в форме написания скриптов и кода для автоматизированных сценариев.
А почему все это написано в будущем времени? Все настоящие QA-аналитики, которых я встречал, писали скрипты и код для автоматизированных сценариев.
Люди избавляются от ручной работы как замечено в LeSS queuing theory. В процессе они отходят от роли тестировщика полностью. Это становится достаточно распространенным во многих стартапах в эти дни.
Я один не вижу тут логики? Почему QA-аналитик, который занимается автоматическим тестированием вместо ручного, вдруг перестает быть тестировщиком?
Тест-инженерам суждено стать продуктовыми экспертами, советниками по качеству и риск аналитиками.
Зачем? Нормальный QA-аналитик это человек, который участвует в разработке проекта с самого нуля и создает свою тестовую модель параллельно модели бизнес-аналитиков и программистов. Такая модель позволяет «поймать» даже ошибки бизнес анализа. Никогда программисты настоящего QA-аналитика не заменят.
Это либо программисты проводили все тестирование
Этот миф я встречал ещё 20 лет назад, зачем нам QA если мы программисты? Ни разу не видел, чтобы это действительно прокатывало, теория QA это отдельная и довольно серьезная дисциплина, которое рассказывает как и что тестировать правильно, невозможно одновременно хорошо совмещать обе роли, как невозможно одновременно хорошо совмещать роли юриста, бухгалтера и финансиста, все равно такой человек будет проигрывать специалистам (ну если он не супергений).
Обычно когда отказывались от QA качество продукта резко падало, ну не возможно заменить unit test'ами реального QA специалиста.
либо тестировщики научились программированию для того чтобы тестировать
Да не программированию, а использованию инструментов автоматизированного тестирования и написанию/созданию сценариев. Это две большие разницы, собственно далеко не всегда автоматические тестовые сценарии именно программируются. Но вообще-то, Middle/Senior QA не умеющий использовать такие инструменты это какое-то не совсем Middle/Senior, я всегда считал что только джуниоры могут себе позволить не знать инструменты для автоматического тестирования.
Что вы прицепились к QA-аналитикам? Почитайте Блека, QA никогда не пишет автотесты, если у вас есть QA-аналитик, который пишет автотесты, то бодишоп, в котором он работает просто решил продать его дороже. Вот и всё.
Почитайте Блека
Дайте ссылку или полное имя и название книги/статьи. Кстати автор кто ведущий архитектор Микрософта/гугла и т.п.?
QA никогда не пишет автотесты
Странно, я работал в международной компании одной из крупнейших в мире — там QA писали автотесты. Мы постоянно общались с другими огромными международными компаниями — там QA писали автотесты. Какое-то странное НИКОГДА получается.
А кто тогда умеет грамотно писать автотесты? Программисты? А они этому учились, чтобы тест не просто что-то там проверял, а действительно правильно покрывал все возможные бизнес кейсы?
Дайте ссылку или полное имя
Rex Black. Прямые ссылки не буду давать, не то место.
Странно, я работал в международной компании одной из крупнейших в мире
Действительно странно, но без знания внутреннего устройства команды и проекта сложно о чем-либо судить.
Возможно у вас просто другое понимание что такое автотесты и вы имеете в виду unit-тесты или интеграционные тесты, которые обычно пишут действительно разработчики. Автотесты QA это специальные системы отправляющие пачки Rest/Soup запросов (с генерацией фейковых данных) и анализирующие правильность ответа, автотесты QA это когда QA записывают макрос вручную проходя тест кейс в браузере, а потом специальные системы автоматически повторяют его и проверяют что на всех шагах ничего не сломалось. Ничем из этого программисты заниматься не будут, тупо потому что это большой стек технологий, сопоставимый с стеком технологий программистов, да и вообще QA это отдельная дисциплина, которой несколько лет учат в Западных университетах.
автотесты QA это когда QA записывают макрос вручную проходя тест кейс в браузере, а потом специальные системы повторяют его и проверяют что на всех шагах ничего не сломалось.
Вы про Selenium IDE сейчас? :)
Ой, а расскажите тогда, чем ваш «записанный» тест отличается от интеграционного теста, написанного программистом Васей, который так же открывает браузер и тыкает по UI элементам используя тот же кейс?
Вы про Selenium IDE сейчас
Это не единственная подобная система
расскажите тогда, чем ваш «записанный» тест отличается от интеграционного теста, написанного программистом Васей, который так же открывает браузер и тыкает по UI элементам используя тот же кейс
Тем что кейс не будет тем же, грамотно придумать тест кейсы ничуть не легче чем грамотно придумать архитектуру программы. Это равносильно спросить зачем нужен архитектор, если джуниур-программист тоже умеет рисовать блок-схемы.
Тут два варианта либо у вас будет плохой программист с навыками QA, либо у вас будет отдельно хороший программист и отдельно хороший QA, специализация рулит почти всегда.
Вам пытаются дать понять, что вы терминологически запутались. Именно терминологически — описанный вами «автотест QA» является ни чем иным, как интеграционным функциональным тестом. А с применением каких технологий (Selenium / SoapUI / Java NIO / assembler) и кем написанно — не важно.
Этот терминологический нонсенс вообще удручает.
В какой то момент, у QA инжинеров появились инструменты создания автоматических тестов. Они стали называть их «автотестами», чтобы отличать от ручных. Но потом, почему-то..., они начали противопоставлять их unit-тестам, чтобы отличать их от тех, что пишут программисты. А слова нового не придумали. Хотя unit-тесты тоже являлись автоматическими уже тогда… И уже тогда программисты писали не только unit, но и интеграционные тесты.
С тех пор прошло немало времени, а QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать. И нам приходится додумывать, что скорее всего имеются ввиду Selenium тесты (по-моему за ним еще большинство, хотя конкурентов хватает). Называли бы их тогда Selenium тестами, и не запутывали всех вокруг.
Причем разграничивать тесты по тому — кто их написал вообще бессмысленно. Я уловил вашу мысль, что QA-инженер скорее напишет более грамотный тест-кейс, но к классификации тестов, как таковых, это отношения не имеет.
Этот терминологический нонсенс вообще удручает.
В какой то момент, у QA инжинеров появились инструменты создания автоматических тестов. Они стали называть их «автотестами», чтобы отличать от ручных. Но потом, почему-то..., они начали противопоставлять их unit-тестам, чтобы отличать их от тех, что пишут программисты. А слова нового не придумали. Хотя unit-тесты тоже являлись автоматическими уже тогда… И уже тогда программисты писали не только unit, но и интеграционные тесты.
С тех пор прошло немало времени, а QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать. И нам приходится додумывать, что скорее всего имеются ввиду Selenium тесты (по-моему за ним еще большинство, хотя конкурентов хватает). Называли бы их тогда Selenium тестами, и не запутывали всех вокруг.
Причем разграничивать тесты по тому — кто их написал вообще бессмысленно. Я уловил вашу мысль, что QA-инженер скорее напишет более грамотный тест-кейс, но к классификации тестов, как таковых, это отношения не имеет.
описанный вами «автотест QA» является ни чем иным, как интеграционным функциональным тестом
Да, является, спасибо, я в курсе. (хотя его можно назвать и Системное тестированием, разница между ними не такая большая). Автотест QA означает лишь автоматический тест, написанный QA инженером. Он может быть интеграционным тестом, может быть GUI-тестированием, но все равно остается автоматическим тестом.
QA инженеры до сих пор говоря «автотест» уверенны, что их все должны понимать
Я ни разу не QA, а как раз программист. И ни разу не слышал чтобы тесты написанные программистами назывались автотестами. И так понятно что unit и интеграционные тесты, написанные программистами, будут автоматическими, так как программисты ручных тестов не делали никогда, зачем это уточнять?
cкорее всего имеются ввиду Selenium тесты
Это называется GUI-тестирование
классификации тестов
Она может быть разной, в том числе и по тому кто тест написал и каким образом, но это уже споры по понятиям.
говоря «автотест» уверенны, что их все должны понимать
Ну, «автотест» это «Автоматизированное тестирование». По-моему, тут сложно что-то не понять. Почему под автоматизированым тестированием надо обязательно понимать unit тесты (цитата выше «QA никогда не пишет автотесты») мне тоже не очень понятно.
хотя его можно назвать и Системное тестированием, разница между ними не такая большая
Согласен. Я бы разницы не заметил. Хотя если верить википедии — то она есть
программисты ручных тестов не делали никогда
Программисты постоянно занимаются ручным тестированием, если не пишут автотестов (видимо буду первым, кто назовет их так в вашем присутствии). Запускают написанную программу — и смотрят все ли правильно работает. Они их редко оформляют в виде тестовых сценариев, или проводят ручные регрессы — но тестирование фич проводят.
Это называется GUI-тестирование
Да, тоже можно… Всяко понятнее, чем «автотесты». Но из контекста должно быть понятно, что имеется ввиду не ручное GUI тестирование…
цитата выше «QA никогда не пишет автотесты»
Согласен… Бред полный написан. Не разглядел поначалу.
Вообще посыпаю голову пеплом… С вашей стороны на протяжении этого треда в подавляющем большинстве случаев была корректная терминология.
Просто я неправильно прочитал вот эти строки вещи:
Автотесты и Юнит-тесты это две большие разницы
Возможно у вас просто другое понимание что такое автотесты и вы имеете в виду unit-тесты или интеграционные тесты
А затем вы приправили их вот этим
И ни разу не слышал чтобы тесты написанные программистами назывались автотестами
Вообще у меня вызывает баттхерт, когда люди говоря «автотест» подразумевают именно «автотест написанный QA-инженером», а такое случается постоянно. И это не правильно.
Автотест, согласно присланной вами же ссылке это и unit-тест и интеграционный, вне зависимости от того кем написан. Главное, чтобы его можно было запускать без участия человека.
Юнит-тесты пишут программисты. Это не касается бизнес-кейсов, здесь речь идет о поведении подпрограмм в соответствии с архитектурными спецификациями, и это всё в рамках квалификации программиста. Вот GUI-тестирование или тестирование внешних интерфейсов уже должно проводиться в рамках соответствия бизнес-кейсам. Конечно, никто не мешает тестировщику добавить дополнительных скиллов, и он будет писать юнит-тесты для внутреннего API приложения, но это уже просто делегирование ему части функций программиста, а не его прямая обязанность в рамках специализации.
Автотесты и Юнит-тесты это две большие разницы (см. сообщение выше). Юнит-тесты никогда полноценно не заменяют автотесты QA. Ручное тестирование автотесты заменить могут, но Юнит-тесты нет.
Да, я уже понял, что вы под автотестами подразумеваете только функциональное тестирование. Добавлю только, что ручное тестирование оно полностью не может заменить. Ручные тесты предполагают не только контроль соответствия спецификациям, но и usability-контроль, поэтому без живого тестировщика все равно не обойтись.
Абсолютно согласен с автором. Из опыта могу сказать, что подход с юнит-тестами + автоматизированным тестированием + немного ручного тестирования дает очень большой качественный эффект. Если это еще стоит и на рельсах CI, то эффект можно смело умножать на два.
Я считаю, роль тестировщика должна быть одной из ключевых в команде, поскольку только он может сказать «продукт готов, можно выпускать».
Я считаю, роль тестировщика должна быть одной из ключевых в команде, поскольку только он может сказать «продукт готов, можно выпускать».
Категорически не согласен с полным вымиранием ручного тестирования. Допускаю что это возможно для систем с низкой энтропией, но для областей где Большей частью системы является ui и десятки ивентов бегают наперегонки — слабо себе представляю. Яркий пример такой области для меня — мобил разработка.
А никто не говорит о его вымирании, в статье предрекается его трансформация.
Да не будет этого. Я вам с десяток примеров приведу которые вы не заавтоматизируете «на раз-два», но которые проверяются за 1 секунду даже джуниором. А коли есть такие примеры, то и говорить не о чем.
А будьте добры такие примеры, вы меня заинтересовали.
Если в общем, то по большей части это визуальная составляющая:
В целом, есть сильная ограниченность проверки только по запрограммированным прогонами. Как подсказывает мой опыт, какие сценарии не выдумывай пользователь сделает по своему.
- Анимационные и видеоэффекты верстки.
- Удобство использования.
- Отображение картинок, видео.
- «Невлезающие», «поехавшие» элементы верстки.
В целом, есть сильная ограниченность проверки только по запрограммированным прогонами. Как подсказывает мой опыт, какие сценарии не выдумывай пользователь сделает по своему.
Вот под это и отводится 5% в общем объеме тестирования.
UPD: даже 10%, на уровне приемочного тестирования это тоже можно выявить, в т.ч. руками.
UPD: даже 10%, на уровне приемочного тестирования это тоже можно выявить, в т.ч. руками.
Если в вашем приложение 2 кнопки и 1 форма, то да. На проектах, где мне доводилось работать очень большая часть нуждается в живой проверке глазками, я бы обозначил как 50%. А сколько таких проектов как мои? У меня нет статистики, поэтому и сомневаюсь я в 5%, это пальчиков в небо, извините.
В части продуктов такие вопросы решаются с помощью так называемого dog fooding, т.е. процесса тестирование продуктов компании сотрудниками в процессе обычного ежедневного использования. К пользователям при этом выкатывается версия, которой пользовались внутри компании последний день/неделю. За счет этого опять же нет необходимости выделять время/людей специально для ручного тестирования.
Здесь может быть в другом проблема и размер тут не при чем — затраты на поддержку автоматизированного тестирования не входит в бюджет (или признаны слишком большими для такого проекта). Возможна также некомпетентность отдельных руководителей.
Давайте разберем Ваши задачи по полочкам:
1) Анимационные эффекты — только ручное, трудоемкость невысокая (на уровне «открыл, посмотрел, зафиксировал»).
2) Удобство использования, по идее, должно быть заложено на этапе проектирования интерфейса и затраты тестирования должны быть отнесены на этот этап.
3) и 4) Отображение картинок, видео и «поехавшая верстка» см. п. 1)
В итоге весь класс задач, можно охарактеризовать, как Вы верно подметили, «визуальной составляющей», т.е. той, что требует людских глаз для оценки. В вашем проекте 50% времени тестировщики выполняют такую работу? Это вполне возможно для определенных категорий проектов (игры, анимационные приложения), но все таки в общей доле проектов это не большинство. А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Что касается проектов с моим участием, то они частенько сложнее двух кнопок и формы. Мы стараемся двигаться в направлении автоматизации по похожей схеме и это дает ощутимый эффект.
Давайте разберем Ваши задачи по полочкам:
1) Анимационные эффекты — только ручное, трудоемкость невысокая (на уровне «открыл, посмотрел, зафиксировал»).
2) Удобство использования, по идее, должно быть заложено на этапе проектирования интерфейса и затраты тестирования должны быть отнесены на этот этап.
3) и 4) Отображение картинок, видео и «поехавшая верстка» см. п. 1)
В итоге весь класс задач, можно охарактеризовать, как Вы верно подметили, «визуальной составляющей», т.е. той, что требует людских глаз для оценки. В вашем проекте 50% времени тестировщики выполняют такую работу? Это вполне возможно для определенных категорий проектов (игры, анимационные приложения), но все таки в общей доле проектов это не большинство. А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Что касается проектов с моим участием, то они частенько сложнее двух кнопок и формы. Мы стараемся двигаться в направлении автоматизации по похожей схеме и это дает ощутимый эффект.
А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Есть ложь, большая ложь и статистика. (с) На самом деле, я видел огромное кол-во подходов к тестированию.
Интеграционный тест может быть написан программистов, может запускаться QA через инструменты для тестирования SOUP/Rest и т.п. Интеграционный тест может быть заменен функциональным автотестом/макросом (но не всегда наоборот), то есть если макрос работы с UI вдруг сломался результат будет тот же что сломался интеграционный тест. Видел, я когда люди чрезмерно увлекались unit-тестами, так что придумывали совершенно бессмысленные тесты ради покрытия в 200% (и тратили кучу времени на правку unit-test'ов при банальном изменении одной функции) или наоборот все отдавали на откуп отделу QA.
Надо понимать что нет серебряной пули тестирования, есть относительно модные на данный момент технологии, но у каждой компании своя политика тестирования и свои приоритеты между разными видами тестов. И так будет всегда, через лет пять мятник может качнуться в другую сторону и станет модным меньшее кол-во unit-тестов и больше ручного и полуручного тестирования, как стал модным старый забытый nosql после моды на sql. Поэтому говорить о какой-то статистике или правилах не очень-то правильно.
Подходов вагон и маленькая тележка, конечно нужно с умом подходить. Если статистика для большинства, это не значит, что подход подойдет именно Вам.
Не согласен по поводу правил. Правила, или если хотите «рецепты» или «подходы», очень нужны и важны. Это обмен опытом, не представляю как можно без него представить ИТ индустрию.
Не согласен по поводу правил. Правила, или если хотите «рецепты» или «подходы», очень нужны и важны. Это обмен опытом, не представляю как можно без него представить ИТ индустрию.
Если статистика для большинства,
А кто приходил в гугл, оракл или микрософт и мерил эту статистику (которая коммерческая тайна, если что)? Надо понимать что нарисованная пирамида это не статистика для большинства (никто никогда не сможет перемерить бизнес процессы всех компаний в мире, не говоря уже о том что мало кто будет раскрывать свои коммерческие тайны), это числа взятые из головы конкретным автором, как ОН видит правильный подход к тестированию, не более того. Ну максимум статистика для десятка компаний его региона, к статистике которых у него есть доступ.
Ну я все таки верю, что человек, который пишет про Agile книги и продает их, не с потолка берет эти сведения, у него наверняка есть аргументы, почему так.
Тем не менее, Вы правы, что это просто взгляд, а не истина, которой следует идти. Повторюсь, своя голова у всех должна быть :)
Кстати оригинал статьи не открывается.
Тем не менее, Вы правы, что это просто взгляд, а не истина, которой следует идти. Повторюсь, своя голова у всех должна быть :)
Кстати оригинал статьи не открывается.
Да, с эволюционной трансформацией безусловно согласен. Просто рассматриваю это лишь как небольшой смещение акцента, а не радикальную трансформацию.
А чем вообще объясняется в этой пирамиде столь большой процент (аж 80%) самых низкоуровневых тестов? Как по мне, значительно лучше иметь больше интеграционных тестов, поскольку один раз написанная функция ломается ну очень редко, а вот связи компонентов при перетасовке архитектуры — достаточно часто.
Архитектуру Вы перетасовываете реже, чем вносите правки в методы.
Но это значит, что и юнит-тесты придётся переписывать чаще. Вы же не думаете, что можно один раз написать низкоуровневый юнит-тест, а всё остальное время пытаться впихнуть код в его прокрустово ложе?
Ладно, не так выразился. Пуская не при изменении архитектуры, а при включении плагинов или сборке кастомного билда для нового клиента с отдельными дополнительными модулями.
Интеграционный тест покажет, что большая часть программы не работает.
Отлично, этого и добиваемся. А 10 юнит-тестов отдельных компонентов покажут что «всё хорошо, компонент рабочий» — абсолютно бестолковая информация.
Я хотел сказать, что юнит-тест неплохо решает задачу «мы знаем, какой может быть баг и вот на него тест» — да, отличная локализация и прекрасно, что он существует. Но в жизни чаще случаются ситуации «мы не знаем, какой может быть баг и надо хотя-бы понять, что он где-то произошел» — и вот с этой задачей интеграционный тест справится лучше. Если юнит-тесты, грубо говоря, прикрывают программиста, то интеграционные (и выше) уже дают понимание руководству как там сейчас поживает продукт — можно его использовать или нет.
Ответ
чем ниже в пирамиде тем:
— больше изоляция в тестах. Меня маленькую компонентут вы меняете один, малький понятный тест.
— в рыз большая скорость тестирования, скороть тестевого цыкла
Чем выше в пирамиде те:
— выше ваша увереность в правильности функционала
— но приходится править все тесты при каждом чихе.
Представьте вы написали калькулятор простой из двух сервисов…
И решили сначала написать тест UI
чем ниже в пирамиде тем:
— больше изоляция в тестах. Меня маленькую компонентут вы меняете один, малький понятный тест.
— в рыз большая скорость тестирования, скороть тестевого цыкла
Чем выше в пирамиде те:
— выше ваша увереность в правильности функционала
— но приходится править все тесты при каждом чихе.
Представьте вы написали калькулятор простой из двух сервисов…
И решили сначала написать тест UI
Спасибо, какраз вот всю неделю размышляю над и какраз каказал сегодня чуть эту книгу не заказал отпугнуло немного что её уже 6 лет.
И тут вы;)
Скажите это не оправданно? Как вам книга?
И тут вы;)
Скажите это не оправданно? Как вам книга?
— «Пап, а можно ли выпустить качественный продукт без ручного тестирования?»
— «Нет, сынок, это фантастика».
Кстати на продуктах без серьезного UI наверное вполне можно (компиляторы, базы данных, итд). Обычно говорят об автоматизации UI тестирование как о панацеи, однако в этой статье даже не про это, а про какой-то странный посыл что unit-тестами можно заменить тестирование сценариев уровня пользователей, что на мой взгляд вообще не особо реалистично. Не знаю, как будто тут предлагают вместо антибиотиков прописывать витаминки, потому что они дешевле и форма у них круглая. Пользователю у которого сломался сценарий пофиг на 1000 зеленых тест резалалтов в вашей CI.
Насчет автоматизации UI-тестирования: я давно думал о том что надо двигаться в направлении автоматизации UI-тестирования, но я склоняюсь что очень часто это может быть не практично. С одной стороны заманчиво написать UI тест который бы проверял работоспособность автоматически. Однако получается такой парадокс: там где UI часто меняется становится довольно дорого обновлять тесты, а там где UI не меняется, там часто и не нужен объем работ по тестированию. Нужно хорошо понимать когда автоматизация UI-тестирования будет выгодна, а это не просто.
Иногда наличие UI-тестов тормозит развитие продукта. Например, есть хорошая идея для небольшой оптимизации интерфейса, которая ломает много готовых автоматических UI-тестов. В такой ситуации высок соблазн оставить все как есть, т.к. очень жалко потраченных ресурсов на тесты.
— «Нет, сынок, это фантастика».
Кстати на продуктах без серьезного UI наверное вполне можно (компиляторы, базы данных, итд). Обычно говорят об автоматизации UI тестирование как о панацеи, однако в этой статье даже не про это, а про какой-то странный посыл что unit-тестами можно заменить тестирование сценариев уровня пользователей, что на мой взгляд вообще не особо реалистично. Не знаю, как будто тут предлагают вместо антибиотиков прописывать витаминки, потому что они дешевле и форма у них круглая. Пользователю у которого сломался сценарий пофиг на 1000 зеленых тест резалалтов в вашей CI.
Насчет автоматизации UI-тестирования: я давно думал о том что надо двигаться в направлении автоматизации UI-тестирования, но я склоняюсь что очень часто это может быть не практично. С одной стороны заманчиво написать UI тест который бы проверял работоспособность автоматически. Однако получается такой парадокс: там где UI часто меняется становится довольно дорого обновлять тесты, а там где UI не меняется, там часто и не нужен объем работ по тестированию. Нужно хорошо понимать когда автоматизация UI-тестирования будет выгодна, а это не просто.
Иногда наличие UI-тестов тормозит развитие продукта. Например, есть хорошая идея для небольшой оптимизации интерфейса, которая ломает много готовых автоматических UI-тестов. В такой ситуации высок соблазн оставить все как есть, т.к. очень жалко потраченных ресурсов на тесты.
Сорри но иммено об этом и речь что проекты изначальмо ставящие на автоматизацию UI тестов, имеют серьезные проблемы (Мой личный опыт это подтверждает)
Коротко обьясненно тут. Для пример там же даны ссылии на гугл блог.
Но там не догматично как любое правило/паттерн в информатике…
Просто в совремненом состоянии IT (тенденции к микросервисам и CI /CD +Agile)
хорошо
плохо
и рассписано почему
Коротко обьясненно тут. Для пример там же даны ссылии на гугл блог.
Но там не догматично как любое правило/паттерн в информатике…
Просто в совремненом состоянии IT (тенденции к микросервисам и CI /CD +Agile)
хорошо
TestingPyramid
плохо
Ice-cream cone
и рассписано почему
ИМХО В любом случае автоматизированное тестирование — лишь инструмент, который используется или не используется в рамках процесса тестирования. Контекст данной статьи звучит для меня приблизительно как: «Скоро все откажутся от лопат в пользу экскаваторов...» Полностью заменить ручное тестирование на что-то возможно лишь в полностью автоматических системах или системах, где роль «пользователь» почти и не нужна. Да и экономический и технический профит должен быть колоссальный от автоматизации, чтобы она «выстрелила». Хотя бы потому что ее надо:
1. Создать.
2. Описать.
3. Регламентировать.
4. Поддерживать.
5. Обновлять.
6. Анализировать результаты ее работы.
Собственно я всегда за, когда количество ручного труда, переложенного на плечи автоматизации, растет, но не питаю иллюзий, что когда-нибудь смогу заниматься только автоматизацией… совсем без ручного тестирования. :)
1. Создать.
2. Описать.
3. Регламентировать.
4. Поддерживать.
5. Обновлять.
6. Анализировать результаты ее работы.
Собственно я всегда за, когда количество ручного труда, переложенного на плечи автоматизации, растет, но не питаю иллюзий, что когда-нибудь смогу заниматься только автоматизацией… совсем без ручного тестирования. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Традиционное тестирование скоро умрет