Делитесь пожалуйста, success stories, "как программисты победили зависимость от кадровой единицы- выделенного QA — и стали чаще релизиться". Какие книжки по QA нужно прочесть, чтобы постичь этот нехитрый скилл.
upd скачал "istqb — foundations of software testing". Наверное, скопирую её на таблет, под подушку.
upd2 чтоб не плодить сущностей shmj — вымирание вида "QA обыкновенный" это данность, от которой нужно плясать. Своё г. пахнет фиалками, это факт. С этим когнитивным искажением должны быть какие-то практики борьбы. Книжки, блоги, советы бывалых и т.д. Когда программиста срели ночи будят звонком про лежащий прод- это тоже стресс.
Здравствуйте, Артём, Вы писали:
Аё>В нынешней атмосфере https://en.m.wikipedia.org/wiki/Shift-left_testing и назовём это так "высоких процентных ставок", тестировщики стали дефицитным ресурсом.
Аё>Делитесь пожалуйста, success stories, "как программисты победили зависимость от кадровой единицы- выделенного QA — и стали чаще релизиться". Какие книжки по QA нужно прочесть, чтобы постичь этот незитрый скилл.
Разработку и тестирование лучше не совмещать и вот почему. Тестировщик это ответственное лицо, он отвечает за подтверждение качества. Он работает со стрессом, этот человек должен возлагать на свои плечи ответственность и стрессовать, переживать что если что-то не так — то виноват он. И основная его функция — снять ответственность с плеч разработчика и водрузить ее на свои плечи. Только это имеет смысл. И причина почему это нужно делать — мозг плохо работает в режиме стресса.
Ну и бред. Делает разраб, а отвечать должен левый чувак? Тогда уж руководитель разрабов, который разрабов и дрюкает. А инфу для этого должны давать тестировщики, да
Здравствуйте, Нomunculus, Вы писали:
Н>Ну и бред. Делает разраб, а отвечать должен левый чувак? Тогда уж руководитель разрабов, который разрабов и дрюкает. А инфу для этого должны давать тестировщики, да
Именно это позволяет снизить стресс — избавить разраба от стресса и обеспечить комфортную безопасную среду, в которой мозг расслабляется и работает в продуктивном режиме. Иначе смысла нет.
Только в случае когда тестер готов взять ответственность — он имеет смысл. И называть лучше отдел качества — кто дает гарантию.
Здравствуйте, Нomunculus, Вы писали:
S>>Именно это позволяет снизить стресс Н>Ну раз такой нежный — иди в дворники. Да и там стресс будет. Это неизбежно. И это правильно. Кто делает — тот и отвечает
Есть два разных качества:
1. Способность разрабатывать софт.
2. Стрессоустойчивость.
Эти качества могут быть как совмещены в одном человеке так и не совмещены. Очевидно что когда два в одном — встречается реже, по этому очевидное решение — разнести по двум разным ролям а лучше даже отделам. И когда что-то в продакшене не так — то все косяки не тестеров — и даже разраб скажет какие же они идиоты, как могли допустить (а я то тестирую только благоприятный сценарий). И легче на душе.
Здравствуйте, Shmj, Вы писали:
S>Разработку и тестирование лучше не совмещать и вот почему. Тестировщик это ответственное лицо, он отвечает за подтверждение качества. Он работает со стрессом, этот человек должен возлагать на свои плечи ответственность и стрессовать, переживать что если что-то не так — то виноват он. И основная его функция — снять ответственность с плеч разработчика и водрузить ее на свои плечи. Только это имеет смысл. И причина почему это нужно делать — мозг плохо работает в режиме стресса.
Про ответственность соглашусь, но делится она тут пополам.
Здравствуйте, Sharov, Вы писали:
S>>Разработку и тестирование лучше не совмещать и вот почему. Тестировщик это ответственное лицо, он отвечает за подтверждение качества. Он работает со стрессом, этот человек должен возлагать на свои плечи ответственность и стрессовать, переживать что если что-то не так — то виноват он. И основная его функция — снять ответственность с плеч разработчика и водрузить ее на свои плечи. Только это имеет смысл. И причина почему это нужно делать — мозг плохо работает в режиме стресса.
S>Про ответственность соглашусь, но делится она тут пополам.
Ну можно так — что разработчика дрючит тестер — но не сильно. Если уж совсем много косяков будет — то это будет видно по багтрекеру и может как-то привести к задержке повышения по должности. Неприятно, но без стресса. Исключение составляет разве что намеренный вред.
А тестировщика дрючит сама реальность и если он допустил в прод. и потерпели убытки — то вплоть штрафов и увольнения. Т.е. берет всю ответственность на себя.
S>Разработку и тестирование лучше не совмещать и вот почему. ... И причина почему это нужно делать — мозг плохо работает в режиме стресса.
Это у кого как.
Вполне себе бывает, что в стрессе мозг работает как машина — быстро и четко.
Видимо, зависит от уровня стресса.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Это у кого как. LVV>Вполне себе бывает, что в стрессе мозг работает как машина — быстро и четко. LVV>Видимо, зависит от уровня стресса.
Но не постоянно же держать мозг в стрессе. Разово — возможно.
По этому функция тестировщиков — как раз избавлять от стресса. Если они не готовы взять на себя такую роль — то смысла ноль.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>>Разработку и тестирование лучше не совмещать и вот почему. Тестировщик это ответственное лицо, он отвечает за подтверждение качества. Он работает со стрессом, этот человек должен возлагать на свои плечи ответственность и стрессовать, переживать что если что-то не так — то виноват он. И основная его функция — снять ответственность с плеч разработчика и водрузить ее на свои плечи. Только это имеет смысл. И причина почему это нужно делать — мозг плохо работает в режиме стресса. S>>Про ответственность соглашусь, но делится она тут пополам. S>Ну можно так — что разработчика дрючит тестер — но не сильно. Если уж совсем много косяков будет — то это будет видно по багтрекеру и может как-то привести к задержке повышения по должности. Неприятно, но без стресса. Исключение составляет разве что намеренный вред. S>А тестировщика дрючит сама реальность и если он допустил в прод. и потерпели убытки — то вплоть штрафов и увольнения. Т.е. берет всю ответственность на себя.
Ответственность пополам. Программист тоже не должен лажать и проверять свои решения. В конце концов, зп у разработчиков обычно
больше, поэтому будь любезен. Но чтобы как-то помочь и разгрузить программиста, есть тестировщики. Ну и 100% покрытый кода тестами
не дает гарантии отсутствия багов.
Здравствуйте, Shmj, Вы писали:
LVV>>Это у кого как. LVV>>Вполне себе бывает, что в стрессе мозг работает как машина — быстро и четко. LVV>>Видимо, зависит от уровня стресса. S>Но не постоянно же держать мозг в стрессе. Разово — возможно.
Здравствуйте, Нomunculus, Вы писали:
Н>Легкость твоей души никому не интересна. Ты или в рынке или нет. Твой комфорт — твое дело.
Вообще выгодно было бы иметь человека-оркестра, который все умеет, все знает, максимально быстро и безропотно работает, не подвержен стрессу и выгоранию и стоит пол копейки — готов с утра до ночи работать за 100 тыр. Только вот не таких людей. Просто нет.
По этому и приходится свои хотелки соотносить с реальностью — разграничивать ответственность.
LVV>Вполне себе бывает, что в стрессе мозг работает как машина — быстро и четко.
Если не достигнут отказ в обслуживании, значит это ещё не стресс.
"Стрессоустойчивость" — это корректное восстановление работы после возврата нагрузки в допустимый предел, а не работать нахаляву в разы больше.
Здравствуйте, Нomunculus, Вы писали:
S>>По этому и приходится свои хотелки соотносить с реальностью — разграничивать ответственность. Н>Ну и как, ты нашел тестера, который согласен принимать на себя все удары вместо тебя? Нет, и не найдешь. Это вои мечты.
За деньги — да. Удавалось находить, пусть это и дороже стоило. За ответственность нужно платить, но это не значит что нет желающих на это.
Здравствуйте, Shmj, Вы писали:
S>За деньги — да. Удавалось находить, пусть это и дороже стоило. За ответственность нужно платить, но это не значит что нет желающих на это.
То есть ты ему сказал чтоб он общался с заказчиком, а ты просто не стрессовал?
Так это ты не тестера себе нашел, а начальника
Здравствуйте, Нomunculus, Вы писали:
S>>За деньги — да. Удавалось находить, пусть это и дороже стоило. За ответственность нужно платить, но это не значит что нет желающих на это.
Н>То есть ты ему сказал чтоб он общался с заказчиком, а ты просто не стрессовал? Н>Так это ты не тестера себе нашел, а начальника
У нас это была команда тестеров — которые за определенную сумму денег согласились взять на себя ответственность. Т.е. тестовая среда, полное тестирование (включая и авто-тесты — по их выбору), ответственность за публикацию.
А в чем проблема такого варианта?
Проверять свой софт — все равно что играть в шахматы с самим собой. Как бы постоянно нужно изменять роль, а это утомляет.
Здравствуйте, Нomunculus, Вы писали:
S>>А в чем проблема такого варианта? Н>В терминах. Как и всегда у тебя
А конкретно?
То что вы заставите все делать одного человека (или одну группу людей) — не уменьшит количество работы. Работа та же самая. Просто команде разработчиков придется как бы постоянно переключаться с одной роли на другую — играть в шахматы с самими собой. Это и сложно и скучно.
Когда же роли разные и люди разные — как бы интерес появляется. Тестеровщики стремятся доказать что вот они молодцы, нашли. И им интересно это, как бы почувствовать себя умнее разрабочиков. Ну и разработчики знают что за ними все сопли вытрут и если где что пропустил — ну не страшно, катастрофы не будет.
Здравствуйте, AWSVladimir, Вы писали:
S>>У нас 100% покрытие кода тремя типами тестов S>>Утомился AWS>Что за 3 типа тестов?
Вечнозелёные, вечнокрасные и ручные.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, AWSVladimir, Вы писали:
AWS>>>Что за 3 типа тестов? AWS>·>Вечнозелёные, вечнокрасные и ручные. AWS>Хмм, думал что то интереснне будет, т.к. ручные тоже Вечнозелёные и вечнокрасные.
Да я пошутить пытался. Не знаю как и зачем 100% тремя типами покрывать.
AWS>TDD тогда куда?
В моём понимании
юнит-тесты (мелкие детали логики каждого кусочка кода)
интеграционные (совмещение кода с внешними системами такие как субд-файлы-сеть-етс)
приёмочные (e2e-тесты развёрнутой системы)
Но как тут сделать 100% на каждом типе — неясно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Нomunculus, Вы писали:
Н> Кто делает — тот и отвечает
Отвечает тот, кто заппрувил "QC Pass" функциональные требования.
Топик о том, что раз линия партии пошла на жёсткий under-stuffing тестировщиков, то либо проекты в pipeline будут срывать deadline-ы по причине "прогоаммист сделал, но релизить не можем", либо программист возьмёт на себя ответственность за "QC Pass". Учитывая, как "идеально работает на компьютере программиста" тестировщик ломает за пару минут- этот скилл нужно освоить.
·>Но как тут сделать 100% на каждом типе — неясно.
Скорее всего, 100% — только по строчкам, и то в сумме. Ну, 50% покрыто юнит-тестами, 25% интеграционными и 25% е2е. Потом мы складываем 50+25+25 и получаем 100 (по строкам кода). И удивляемся, как так, покрытие 100%, но юзеры постоянно рапортуют новые баги
Ты как-то по-своему понял этот shift left. Это всего лишь новое название для ну очень старой идеи "поймать как можно больше ошибок на стадии компиляции и статического анализа (линтеров)". Тестировщики не при чем. А то, что "мануальщики" есть дефицитный ресурс, оно и понятно, это ж очень дорогой ресурс, при этом крайне медленный, по сравнению с автотестами.
Здравствуйте, Shmj, Вы писали:
S>Разработку и тестирование лучше не совмещать и вот почему. Тестировщик это ответственное лицо, он отвечает за подтверждение качества.
Тут 100% да.
S> Он работает со стрессом,
А тут уже нет. Стресс зависит от методов администрирования и особенно от неадекватных требований, по срокам или ещё по чему-то.
Тестировщик может быть холоден как мёртвая рыба на леднике, а программист — психовать по каждому чиху. И от этого не будет существенно меняться качество, это не критерий.
Здравствуйте, SkyDance, Вы писали:
Аё>>В нынешней атмосфере https://en.m.wikipedia.org/wiki/Shift-left_testing и назовём это так "высоких процентных ставок", тестировщики стали дефицитным ресурсом.
SD>Ты как-то по-своему понял этот shift left. Это всего лишь новое название для ну очень старой идеи "поймать как можно больше ошибок на стадии компиляции и статического анализа (линтеров)".
Это не он так понял, это та огромная часть индустрии, которая сократила бо́льшую часть QA и перешла по сути к двум видам тестирования — у программиста и на пользователях, без промежуточного звена.
Приход статического анализа тут очень "помог" — экономы от программирования, в основном на уровне менеджеров среднего звена, взяли это предлогом сократить QA.
SD> Тестировщики не при чем. А то, что "мануальщики" есть дефицитный ресурс, оно и понятно, это ж очень дорогой ресурс, при этом крайне медленный, по сравнению с автотестами.
Переход от тестировщиков вообще к мануальщикам — уже твой домысел в этой дискуссии. В оригинале такого не было.
Тестировщик вполне может быть тем, кто строит автотесты, но свои автотесты, независимые от автора кода. Я долго работал в месте, где это принципиально поддерживают.
N>Это не он так понял, это та огромная часть индустрии, которая сократила бо́льшую часть QA и перешла по сути к двум видам тестирования — у программиста и на пользователях, без промежуточного звена.
Разумно. Если такой подход дешевле и "пипл хавает", такое развитие попросту неизбежно.
N>Переход от тестировщиков вообще к мануальщикам — уже твой домысел в этой дискуссии. В оригинале такого не было.
Не-мануальные тестировщики (те, что пишут автотесты) — это точно такие же программисты. Более того, я и на своем опыте прекрасно вижу, что во многих случаях тесты написать сложнее, чем код, который эти тесты должны тестировать.
N>Тестировщик вполне может быть тем, кто строит автотесты, но свои автотесты, независимые от автора кода. Я долго работал в месте, где это принципиально поддерживают.
Такая техника имеет право на жизнь, но область применения весьма лимитирована. Просто потому, что дороже. Как, например, предлагается использовать TDD в таком подходе? А как налаживать взаимодействие программистов тестов, и программистов не-тестов? А одним коммитом можно и тесты, и не-тесты? В общем, это слишком сложно, поэтому и не массово.
Здравствуйте, SkyDance, Вы писали:
SD>Не-мануальные тестировщики (те, что пишут автотесты) — это точно такие же программисты.
Необязательно это те же люди с тем же набором скиллов- это SDET.
Программист может написать и юнит тесты, и интеграционные- засада очень часто заключается в том, что тестирует не то и не там. Формально можно получить и 90% покрытие по строкам кода, а регрессии не будут ловиться такими тестами.
Аё>Программист может написать и юнит тесты, и интеграционные- засада очень часто заключается в том, что тестирует не то и не там. Формально можно получить и 90% покрытие по строкам кода, а регрессии не будут ловиться такими тестами.
Засада обычно в том, что программист тесты писать не умеет.
Потому что этому не так легко научиться, это, в общем-то, следующий уровень скилла. Поэтому чатГПТ код-то пишет, но вот тесты под него пока адекватно сделать не может.
N>>Переход от тестировщиков вообще к мануальщикам — уже твой домысел в этой дискуссии. В оригинале такого не было.
SD>Не-мануальные тестировщики (те, что пишут автотесты) — это точно такие же программисты. Более того, я и на своем опыте прекрасно вижу, что во многих случаях тесты написать сложнее, чем код, который эти тесты должны тестировать.
Не, это совсем другие программисты (если можно их так вообще назвать). У нас тестировщики вовсю писали интеграционные тесты.
Но требования к их коду кратно ниже, поскольку это продукт для внутреннего использования.
Единственное с чем соглашусь, что налаживание работы автотестов в целом это весьма комплексная задача.
N>>Тестировщик вполне может быть тем, кто строит автотесты, но свои автотесты, независимые от автора кода. Я долго работал в месте, где это принципиально поддерживают.
SD>Такая техника имеет право на жизнь, но область применения весьма лимитирована. Просто потому, что дороже.
Почему дороже? Автоматизированное тестирование заметно ускоряет разработку.
QA/SDET дешевле чем программист. И его проще найти/заменить/обучить внутри компании.
SD>Как, например, предлагается использовать TDD в таком подходе?
SD> А как налаживать взаимодействие программистов тестов, и программистов не-тестов?
Также как взаимодействие QA и программистов. SDET это QA.
SD> А одним коммитом можно и тесты, и не-тесты? В общем, это слишком сложно, поэтому и не массово.
вообще не пересекаются (кодовая база)
Разработка интеграционного автотеста идет от фичей (и bug`ов) и применительно к уже более-менее готовому продукту.
Здравствуйте, SkyDance, Вы писали:
SD>Не-мануальные тестировщики (те, что пишут автотесты) — это точно такие же программисты.
Не такие же.
Даже то, что они не разрабатывают этот код, уже достаточно, чтобы они имели время и возможность думать иначе, чем автор кода.
А в нормальных местах они и вообще изначально другие, они могут не иметь каких-то высоких алгоритмических скиллов, или знать языки и фреймворки, но при этом понимать и реализовывать, что нужно писать для теста.
У меня в voip компании так было и есть. Авторы автотестов знают, грубо говоря, шелл и питон. В питоне — пару-тройку конкретных средств (эмулятор телефона, управлялку конфигурации и эмулятор браузера, что-то вроде знаменитого Selenium). Они не хотят знать, как парсить SIP или как устроен конкретный кодек. Не их это дело. А вот, например, описать тест-план — к ним. Найти рассогласования в спецификациях — тоже, достаточно часто они стопят разработку в ситуациях типа "тут у вас полная фигня, с этой стороны вылетает массив строк, а с приёмной хотят две хэш-мапы флоатов".
90% времени они пишут автотесты и девопят свои установки. 10% (навскидку) — прогоняют ручные тесты. Регулярно ругаемся с ними в вопросе методики нагрузочных тестов
SD> Более того, я и на своем опыте прекрасно вижу, что во многих случаях тесты написать сложнее, чем код, который эти тесты должны тестировать.
Это тогда уже неадекватная организация кода. Как раз вот тут надо включать банхаммер, вспоминать страшные аббревиатуры вроде GRASP или SRP и выяснять, в чём дело.
N>>Тестировщик вполне может быть тем, кто строит автотесты, но свои автотесты, независимые от автора кода. Я долго работал в месте, где это принципиально поддерживают. SD>Такая техника имеет право на жизнь, но область применения весьма лимитирована. Просто потому, что дороже.
С чего бы это вдруг?
SD> Как, например, предлагается использовать TDD в таком подходе?
Если про TDD, которое написание тестов до кода, то никак, и это правильно. Эта методика не соответствует ни одному реальному процессу создания чего-то нового и посему является чистейшей фантастикой.
SD> А как налаживать взаимодействие программистов тестов, и программистов не-тестов? А одним коммитом можно и тесты, и не-тесты?
Нет, раздельно. Сначала коммитится фича и тесты в репах разработчиков. Потом (или одновременно, но не активировано) — её проверка у тестеров. В код друг другу они лезть не должны, за исключением самых очевидных случаев; а собственно нажимать submit, merge или как там зовётся — имеет право только представитель одной стороны. Не забыть потом активировать. Иногда — деактивировать, но если это не плановое удаление фичи, должен висеть тикет на вернуть на место.
SD> В общем, это слишком сложно, поэтому и не массово.
Ничего сложного. Просто нормальный процесс с нормальным разделением ответственности.
Где "не массово", значит, или песочница, или всем пофиг.
M>Но требования к их коду кратно ниже, поскольку это продукт для внутреннего использования.
Это ошибка. И в целом, рассуждения на тему "раз для внутреннего использования, то будут жрать что дадут", ведет к неэффективному бизнесу. Если такой бизнес вырастает до размеров монополистов (гуглы и всякие там фейсбуки), оно может и не иметь существенного значения.
M>Единственное с чем соглашусь, что налаживание работы автотестов в целом это весьма комплексная задача.
M>Почему дороже? Автоматизированное тестирование заметно ускоряет разработку.
Я ровно это и пишу. Автотесты очень важны и нужны. Спорю я со следующим утверждением:
M>QA/SDET дешевле чем программист. И его проще найти/заменить/обучить внутри компании.
Это заблуждание, причем ноги его растут понятно откуда. Из "мануальщиков", которых по сути считали за обезьянок, исполняющих скрипты тестирования.
Но дело в том, что толковые SDET не будут дешевле "обычных программистов". Я очень хорошо помню, когда писал автотест (property-based test) для Process Groups, и — это была намного более сложная работа. И на тест я потратил больше сил и времени, чем на собственно код.
И так — почти всегда: написать хороший тест сложнее, чем код. Особенно когда код, который пишешь, совершенно новый, то есть нет уже готовой спецификации (а значит и референс-имплементации).
M>Также как взаимодействие QA и программистов. SDET это QA.
Ха, раз SDET пишут код, взаимодействуют, и делают все то же, что и программисты, то чего б им не дать и код писать? Они ж все равно его пишут.
M>Разработка интеграционного автотеста идет от фичей (и bug`ов) и применительно к уже более-менее готовому продукту.
Это проигрышная стратегия, "покрывать уже работающий код автотестами". Когда код пишут без оглядки на последующее тестирование, код получается нетестируемый. Проходили многократно.
N>А в нормальных местах они и вообще изначально другие, они могут не иметь каких-то высоких алгоритмических скиллов, или знать языки и фреймворки, но при этом понимать и реализовывать, что нужно писать для теста.
То есть это обычные программисты. Просто не задрочившие leetcode до одури. Ну или подзабывшие, ибо высокие алгоритмические скиллы без постоянных тренировок не работают.
N> А вот, например, описать тест-план — к ним. Найти рассогласования в спецификациях — тоже
То есть у вас все написано в трех экземплярах: спецификация, код и тесты. Как я уже обозначил, это намного дороже.
N>90% времени они пишут автотесты и девопят свои установки. 10% (навскидку) — прогоняют ручные тесты. Регулярно ругаемся с ними в вопросе методики нагрузочных тестов
Это применимо к тем случая, когда все спеки заранее известны. Зачастую еще и есть референс-имплементация, то есть в случае чего можно сравнить с тем, что возвращает референс.
N>Это тогда уже неадекватная организация кода. Как раз вот тут надо включать банхаммер, вспоминать страшные аббревиатуры вроде GRASP или SRP и выяснять, в чём дело.
Классные слова, отличные аббревиатуры. Хорошо годятся для надувания щек, написания книг и прочего. Но в реальной корпоративной обстановке попытка объяснить, как нужно работать, приведет к тому, что тебя запишут во враги. Потом будут вызовы к начальнику "а на тебя вот жалуются, что ты требуешь слишком многого от соседней команды", и закончится все это "ну ты да, крутой программист и вообще академик, но нам тут важнее чтоб люди очень хотели работать друг с другом".
Охотно допускаю, что вне корпоративного мира еще сохранились остатки грамотного программирования. Но это скорее исчезающий вид, ибо в среднем тестирование на юзерах обходится дешевле.
N>Если про TDD, которое написание тестов до кода, то никак, и это правильно. Эта методика не соответствует ни одному реальному процессу создания чего-то нового и посему является чистейшей фантастикой.
Как это "не соответствует"? Да даже в твоем сообщении было — тесты пишутся по спекам (кода может вовсе не быть).
В моем понимании TDD это инкрементальный процесс, которому я неуклонно следую. Я действительно пишу тест до того, как написан код. Просто потому, что так быстрее, чем если сначала написать код, потом пытаться писать тест, а потом осознать — код нетестируем, нужно сначала его переписать так, чтобы было удобно тестировать. В итоге все равно получается, что тесты пишутся до кода.
N>Нет, раздельно. Сначала коммитится фича и тесты в репах разработчиков.
Получаешь нетестируемый код. Под такой код писать тесты — вообще жесть, я бы за такую работу QA денег требовал больше, чем за работу "программистов".
N>Где "не массово", значит, или песочница, или всем пофиг.
Сильное утверждение. Не вижу, чтобы оно соответствовало реальности.
Ну пусть будет "всем пофиг". Потому как на самом деле пофиг, ведь цель всех этих телодвижений — деньги. На примере эволюции наблюдаем, что QA вымирают как вид, в силу финансовой неэффективности вне определенных песочниц.
Здравствуйте, netch80, Вы писали:
N>сократила бо?льшую часть QA и перешла по сути к двум видам тестирования — у программиста и на пользователях, без промежуточного звена.
И назвали это left shift, хотя на самом деле это right shift.
Здравствуйте, SkyDance, Вы писали:
SD>Скорее всего, 100% — только по строчкам, и то в сумме. Ну, 50% покрыто юнит-тестами, 25% интеграционными и 25% е2е. Потом мы складываем 50+25+25 и получаем 100 (по строкам кода). И удивляемся, как так, покрытие 100%, но юзеры постоянно рапортуют новые баги
100 % покрытие юнитестами
Добавляешь одну строчку показывает покрытие 99.999 и блокирует сборку и обновление main бранча
harness test and benchmark test проверяться отдельно и так же блокируют code mergeing в main
Возможно вы пишите кликой софт и судите по своему Тиму
У нас за полтора года что я там работаю был только один реальный баг репорт — нарушалось центрирование текста в message box на работу камеры это не как не влияет
Здравствуйте, sergey2b, Вы писали:
S>У нас за полтора года что я там работаю был только один реальный баг репорт — нарушалось центрирование текста в message box на работу камеры это не как не влияет
Не знаю как и зачем 100% тремя типами покрывать.
Вот это серьёзно. Муха не пролетит.
