Здравствуйте, 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.
Не знаю как и зачем 100% тремя типами покрывать.
