Більшість команд розробки не потребують окремо виділених тестувальників

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

В тестувальницьких колах західного світу зараз «горить» від статті Алана Пейджа.

У цій статті він, як тестувальник з дуже великим досвідом (в роках та проєктах) дозволив собі сказати дуже страшну річ:

Most software teams do not need dedicated testers anymore.

Причому це не просто клікбейтна назва заради назви.

У статті Алан наводить дуже багато пояснень своєму твердженню.

Наприклад:

  • як би тестувальник не старався бути «адвокатом замовника», тільки сам замовник знає, що йому потрібно (та може сказати чи якісний софт чи ні)
  • розробник повинен бути відповідальним за те, чим працює фіча чи продукт з функціональної точки зору
  • розробники можуть гарно тестувати (особливо, якщо їх навчити це робити та давати час на це)

Та найголовніше:

Take a moment and answer this: If the developers on your team wrote the vast majority of test automation and if you had a way to know if your software was solving customer problems, would your team need dedicated testers?

А що думаєте з цього приводу ви?

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному5
LinkedIn

Найкращі коментарі пропустити

Як на мене проблема не в тому, що деви не можуть функціонально протестувати власний код, а в тому, що іноді не розуміють бізнес-логіки і процесів, не можуть коректно налаштувати необхідне тестове оточення (знамените «на моїй машині все працює»), не мають розуміння та уявлення про кінцевий продукт для юзера, тобто погано оріентуються в продукті в цілому.

Десятки разів чула про те, як дев здивовано відкриває для себе елементарний функціонал продукту, який він навіть не дивився, бо працював з вузькими фічами і не має в голові повної картини. Власне, продакт овнери і менеджери, тестувальники — це і є та необхідна проксі меж девом і кліентом, щоб вчасно виявити розбіжності у баченні і пофіксити їх. Бо навіть якщо код працює, кліент може не заапрувити бізнес-рішення через його незручніть або неактуальність для користувачів, поламану логіку роботи аппки в цілому. Якщо ж на проекті немає хорошого бізнес аналітика, який збирає вимоги, то роль QA взагалі стає критичною, бо це фактично єдина людина, яка продукт може оцінити з точки зору юзера.
Теоретично звісно дев може тестити, та хіба це буде доцільно, якщо тестери це роблять дешевше і якісніше, зі складанням метрик і відповідальністю за результат? Вже років 5 всі кричать що скоро мануальні тестувальники вимруть, і це вже тупо, якщо чесно. Ні, не вимруть, так само як і скрам-майстри і продакт овнери.

Кидати девелоперів робити qa — все одно що посадити хірурга в аптеку вітаміни продавати

Чому б архітекторам і сто теж тестплани не поганять раз такий кампот. В команду з 5 сіньор архітектів тестувальники теж не потрібні, тільки хто таку вечірку оплачуватиме?

Ну хіба напевно якщо потенційний qa хоче як дев, то краще взяти в команду дева який і буде й тестувати, але хто притомний дев на таке підпишеться?

1. Статью не читал
2. В статье написан бред
3. Девелопер НИКОГДА не будет нормальным тестером. «так себе тестером» — ну, в редких случаях. НОРМАЛЬНЫМ ПРОФИ — ни в жисть. Тестер — это совершенно другой, особый склад ума, гораздо более организованный и научно устроеный.
4. Заказчик НИКОГДА не сможет протестировать приложение.и заказчик в крайне редких случаях знает — что ему нужно.
5. «Девелоперы могут написать автотесты». Бред. «Автотест» — это просто ВСПОМОГАТЕЛЬНЫЙ ИНСТРУМЕНТ тестера, а не его замена. И т.к. (выше сказано) девелопер НИКОГДА не будет нормальным тестером — его автотесты никогда не будут нормальными, а значит — они не нужны и ничего не тестируют.

У топі коментарі, які показують, що люди уявлення не мають про продуктові компанії, в яких працює 30 або 100 інженерів, фічі в тому числі пропонують розробники, а код і тести пишуть усі розробники до СТО включно. Момент відкриттів на ДОУ.

На одній із робіт тестувальники приходили до розробників, щоб дізнатися, як працює фіча, як сконфігурувати фічу і як її правильно тестувати.

касательно моего заявления «девы по определению не умеют в тестирование»
Основная мулька дева — это правильно реализовать поставленную задачу
основная мулька тестера — это найти способ, как заставить написаный код работать неправильно.
как всем давно известно из основ научных исследований — никакого количества положительных результатов недостаточно для подтверждения теории. Но достаточно одного отрицательного результата чтобы теорию опровергнуть.
Так и с тестированием. Тестеры — это специально обученые люди, которые професионально умеют «делать не так».
Дев инстиктивно избегает «неправильных действий». Куа — професионально обучен научным образом генерировать «неправильные действия»

Это дуэль «непробиваемой брони» и «непобедимого копья», тут нужны разные навыки, разный менталитет, разный темперамент.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нормально работаю уже 3й год в крайне успешном стартапе, тестировщиков нет, ну вернее есть команда которая делает инфраструктуру для лоад тестов. Физически тестят продукт овнеры или сами девы если что-то сугубо техническое. Вообде в Европе так часто, иногда могут быть автотестеры, но даже их чаще нет.
Обязательный тестеовщик это видимо что-то из аутстафа когда очень хочется продать клиенту личную голову

Що краще автомобіль з причепом чи без?

Тест кейсы по бизнес логике тоже девам писать?
Или может продактов попросим? (Удачи с этим)
Или будем на слово верить, что весь функционал покрыт?
И вся ответственность, конечно, на девах. Они должны обеспечить покрытие функционала тестами для всех кейсов по подходу TDD, чтобы не было багов, так ещё и в срок успеть в условиях ограниченного ресурса команды, так ещё и безошибочно разобраться в хотелках продукта. Человек-оркестр, а не разработчик получается

Должен быть человек, проверяющий, что новый функционал соответствует требованиям и обеспечивающий, чтобы так и было во время регрессии

розробник повинен бути відповідальним за те, чим працює фіча чи продукт з функціональної точки зору

Ну це справді брєд.
Це і є головне завдання тустувальника.
Як що це будуть розробники робити, то навіщо тестувальникт взагалі потрібні.

Не читав орігінал, але з 3 приведених тез, 1 обсиралово в бік замовника, 2 обсиралова в бік розробників.

тестери не потрібні? млять, це ж очевидно. я про це давно так казав. тестери потрібні тільки в деяких дуже специфічних нішах (UI?), у всіх інших випадках потреба в тестері це некомпетентність девелоперів чи лідів (які не можуть організувати процес коли деви пишуть адекватні юніт/інтегрейшен тести)

Функціональні тести не потрібні ?

Намагався я на днях змінити пароль у одному сервісі.
Я: обираю пароль, згенерований браузером.
Сервіс: символ ’-’ не можна!
Я: клац-клац-клац...
Сервіс: треба пароль складніше, додайте спец-символи!
Я: клац-клац-клац (багато разів) ...
Сервіс: пароль занадто довгий!
Я: клац-клац-клац...
Сервіс: з underscore не можна!
Я: клац-клац-клац...
Сервіс: з ’+’ не можна!
Я: набираю дуже простий буквено-цифровий пароль із знаком оклику в кінці.
Сервіс: Гаразд!
Імейл активації: не приходить.
Завіса.

Але код працює правильно та без тестів. То ви не те робили.

Ща накину на вентилятор. Навіть не на вентилятор, а на турбіну літака...

Якщо вам потрібні тести або тестувальник, то у вас явно проблеми як мінімум з архітектурою, як максимум з кодом. Тест — це визнання безсилля та остраху перед майбутнім. Ви перестали контролювати систему та розуміти її. Мозок не любить такі стани невизначеності та зазвичай пропонує знизити тривожність за допомогою ... тестів. А про цей підхід він дізнався від оточуючих, бо всі так роблять.

Парадоксально звучить, але тести не призводять до зниження рівня помилок, тому що тести або не покривають всі ситуації, або мають помилку. Колись я пожартував, що на тести треба тести, щоб переконатися, що тести дійсно тестують те, що треба, так як треба. Тобто, щоб дійсно знизити кількість помилок, треба щоб кількість тестів наближалася до нескінченності. Тоді можна дати 99.9(9)% гарантію, що все добре.

З економічної точки зору тести — суто витратна частина проекту. Інвестування в тестування має негативний ROI. Завжди. Хочете знизити витрати на проект? Перестаньте інвестувати час та ресурси в тестування. Принаймні в тому розумінні, що зараз популярно насаджувати крізь.

Адепти церкви свідків успішного використання тестів будуть казати, що без тестів ну просто ніяк. Тривожність без тестів тільки зростає, долоні пітніють при кожному деплої в продакшин, кількість сивого волосся додається по експоненті та все таке. Але ніхто не замислюється над простим запитанням. Чи існує світ без тестів? Або світ, в якому тести майже не потрібні...

Існує.

Давайте розбирати причини, чому саме виникає стійке бажання писати тести та що можна робити в кожному з випадків.

Новачки можуть зломати код та не знати наслідків своїх дій

Який код новачки не можуть поламати? Найпростіший. a + b = c. Тут немає шансів для помилки та все очевидно. Якщо мова, якою ви пишете код, абстрактна настільки, що не дозволяє помилятися, то ви й не помилитеся.

Тепер розберемося з «наслідками дій». В сильнопов’язаних архітектурах це дійсно проблема. А в слабопов’язаних або ізольованих — ні. Висновок — найпростіший код написаний новачком мусить виконуватися тільки в ізольованому середовищі та не мати залежності з іншим кодом.

Тести потрібні, щоб не боятися рефакторити

Камон! Я знаю як мінімум декілька підходів, при яких рефакторити можна скільки завгодно

Немодифікуємі функції/методи/класи/процедури
Якщо ти не зможеш внести модифікації в наявні функції, то ти не зможеш нічого зламати. Хочеш внести зміни — клонуй код та переконфігуруй процедуру його виконання. З таким підходом в системі може жити декілька версій або реалізацій водночас.

Статичний протокол обміну інформацією між системами
Якщо протокол обміну даними статичний, незмінний, може бути з валідаціями на вході, то цей тип стандартизації унеможливить багато помилок вже на етапі проектування. Приклад такої системи — пайплайнінг в *nix системах. Або HTTP, якщо не подобається попередній приклад. Ти, як розробник, мусиш виконати вимоги протоколу, інакше нічого не заведеться.

Fail-safe та fault-tolerant архітектури
Оце саме смачне. Тут можна годинами розповідати. В таких архітектурах помилки є частиною нормальної роботи системи. А якщо помилка — це нормально, то сенс в тестуванні відпадає повністю. Рефакторінг теж не призводить до деградації, бо деградація в таких системах зазвичай призводить до ... відновлення функціональності.

Тести потрібні, щоб переконатися, що код виконує те, що хоче замовник, а не розробник

Якщо трохи пошукати екстремуми, то з’ясується наступне. Найкращий варіант, коли замовник сам собі «реалізує» функціональність, яку він хоче, в тому об’ємі, що йому потрібно та в рамках його розуміння «правильного». Це прямо ідеальний варіант. Але він не завжди можливий. Варіант простіше описаний в першому прикладі. Простий код, з високим рівнем абстракції, вирішує проблему. Ідеально, коли слова замовника співпадають з кодом.

Тести потрібні, щоб переконатися, що всі підсистеми працюють правильно

А тут нам на допомогу приходить ... біологія! Коли ви прокидаєтеся вранці, то ви не проводите тестування сечового міхура, кількості кінцівок чи рівня кисню в крові, щоб переконатися, що ви можете функціонувати далі. Вам не потрібно це, бо мозку, в принципі, чхати на наявність у вас однієї руки, чи двох, чи навіть трьох. Якщо ви пошкодите палець, то ви не випадете в kernel panic. Ні, ви замотаєте його та прилаштуєтеся виконувати поточні операції з урахуванням того факту, що ваш палець в бінтах, болить, не згинається та щось там не відчуває.

Щось я втомився вже писати, так й до книги недалеко...

Підсумки сказаного. Погано, коли людям нав’язують стереотипне мислення. Воно вбиває критичне мислення та іновації. Люди почали удосконалювати процес тестування замість того, щоб йти в іншу сторону, намагатися підвищувати якість не використовуючи тести. Прикро...

Немодифікуємі функції/методи/класи/процедури
Якщо ти не зможеш внести модифікації в наявні функції, то ти не зможеш нічого зламати. Хочеш внести зміни — клонуй код та переконфігуруй процедуру його виконання. З таким підходом в системі може жити декілька версій або реалізацій водночас.

дуже крутий підхід, наплодити гамна

Стереотипне мислення в дії. Немає такої проблеми, яку не можна було б вирішити. Так, цей підхід вимагає додаткових зусиль для того, щоб тримати всю систему в чистоті. Але це можна вирішувати не технічно, а адміністративно.

Ти не побачив переваг цього підходу, тільки недоліки. А перевага в тому, що для кінцевого споживача, а це може бути великий та кволий на рухи бізнес, процес зміни курсу буде без зайвих стресів та ризиків все зупинити під час оновлення.

Хочеш приклад такого підходу? npm.

А перевага в тому, що для кінцевого споживача, а це може бути великий та кволий на рухи бізнес, процес зміни курсу буде без зайвих стресів та ризиків все зупинити під час оновлення.

Вообще говоря — нет. если «бизнес большой», то процесс «отката изменений» представляет из себя огромную проблему и целое мероприятие, которое нужно заранее девелопить и, что смешнее всего — тестировать.

У великих бізнесах відкату змін не буває. Їм простіше тримати дві-три паралельні системи та вбивати щось при нефункціональності, або фіксити наявну, ніж відкатуватися.

дві-три паралельні системи

?
Когда у вас одни часы — вы всегда знаете который час, когда у вас трое часов — вы никогда ни в чем не уверены.

Великий бізнес так не працює. Ніхто не кладе всі яйця в один кошик.

я к тому, что никто не держит «2-3 параллельные системы»

Тримають. Прикладів знаю масу. В банках, в бізнесах поменше.

Це ж Open — Closed принцип (один з SOLID)!
Код, який написаний та перевірений — ЗАКРИТО для змін! Це — база не тільки в ІТ. Якщо деталь зламалася — її заміняють на нову. Це тільки «кулібіни» у гаражах виточать тобі поршень з капу. Але це і є різниця між виробництвом і ремісництвом!

Я сейчас поменял один из нелитералов в грамматике. Вы себе и представить не можете, сколько написанного, проверенного и оттестированного кода поломалось :(
И если бы не юнит-тесты — хрен бы я об этом (сразу) узнал.

Ви розумієте, що у вас в розробці є катастрофічна проблема, що у вас як мінімум розробник лізе міняти щось в ядрі проекта, а як максимум, вам необхідно міняти ядро системи?

ну, если вы можете подсказать, как можно менять грамматику так, чтобы она а) оставалась актуальной б) оставалась простой в) оставалась эффективной и при этом — не ломала уже существующий код — то милости просим — делитесь, с удовольствием послушаю.
зы и если несложно, то подскажите — как проверить, что после обновления генератора парсера — всё по прежнему работает корректно, правильно парсится и так далее. а то, понимаете-ли, за грамматику отвечаю я — я ответсвееный человек и пишу правильно. а вот создатели парсер-генератора — полные рукожопы, и ожидать от них правильного кода — не приходится, нужно постоянно проверять и перепроверять :(

Вам необхідно міняти граматику постійно. Значить проектування на ранніх стадіях пішло неправильним шляхом. Люди не просто так придумали версії мов програмування, протоколів, API. Щоб не допускати постійної зміни та необхідності підтримувати старі версії. Перегляньте політику внесення змін спочатку, щоб не ускладнювати собі життя в майбутньому.

Увы, я не могу приказать, скажем, майкрософту или группе разработки постгре «прекратите менять грамматику!». Поэтому — грамматика будет менятся постоянно.

Який код новачки не можуть поламати? Найпростіший. a + b = c. Тут немає шансів для помилки та все очевидно.

что будет, если одна из переменных — null?

Або HTTP, якщо не подобається попередній приклад. Ти, як розробник, мусиш виконати вимоги протоколу, інакше нічого не заведеться.

также нужно быть уверенным в том, что люди «с той стороны» тоже «выполняют условия протокола», иначе нам нужны тесты чтобы убедится, что наши «правильные запросы» правильно обрабатываются «той стороной»

Коли ви прокидаєтеся вранці, то ви не проводите тестування сечового міхура, кількості кінцівок чи рівня кисню в крові, щоб переконатися, що ви можете функціонувати далі.

Цвет мочи, уровень сахара в крови, уровень кислорода — проверяет множество людей.

Якщо ви пошкодите палець, то ви не випадете в kernel panic.

Если у вас нет проблем со свёртываемостью крови или убитый иммунитет — то нет, не впадаем

Підсумки сказаного.

«если у вас всё нормально — то ввам и не надо ничего. А если у вас что-то не так — то вы сами виноваты, что делаете ошибки» ©

намагатися підвищувати якість не використовуючи тести

После «пусть клиент сам себе программирует что ему нужно» — это уже не должно удивлять.

іновації

95% «инноваций» — это PoC, который только после очень долгих усилий, доработок, тестов и так далее становится «продуктом».

что будет, если одна из переменных — null?

Буде те, що ви закладете в оператори «+» та «=»

также нужно быть уверенным в том, что люди «с той стороны» тоже «выполняют условия протокола»

Пофігу на ту сторону. Це їх проблеми. Простий приклад. Банкомат видає тільки гроші або не видає нічого. Ви приходите до нього та вимагаєте ковбасу. Розробники ПО для банкомата такі «Ну блін, нам тепер треба ще й враховувати поведінку довбнів, які замість грошей в банкомата ковбасу вимагають...» Ніт, або гроші, або нічого.

Цвет мочи, уровень сахара в крови, уровень кислорода — проверяет множество людей.

Це робота вищих функцій. Якщо вас ввести в штучну кому, то ви перестанете це робити.

Если у вас нет проблем со свёртываемостью крови или убитый иммунитет — то нет, не впадаем

Ваш організм працює деякий час навіть після смерті головного мозку. Якщо його підтримувати, то так можно прожити все життя. Овочем, але прожити. Нульпойнтерексепшин не трапляється.

После «пусть клиент сам себе программирует что ему нужно» — это уже не должно удивлять.

Це верхівка еволюції розробки ПЗ. Коли вам треба пересунути іконку на робочому столі, то ви не робите заявку в компанію розробник ОС, щоб вони вам щось там напрограмували та прислали апдейт, а просто берете та пересовуєте її. Самостійно. Не запускаючи при цьому триста тестів. Просто вжух та все. Магія!

95% «инноваций» — это PoC, который только после очень долгих усилий, доработок, тестов и так далее становится «продуктом».

Яке дивакувате розуміння терміну «іновація»...

Пофігу на ту сторону. Це їх проблеми.

Когда ВАША система не работает по причине того, что вы НЕ ТЕСТИЛИ как ваша система работает со сторонней системой — то это ВАША система не работает и это ВАША проблема.

Це робота вищих функцій. Якщо вас ввести в штучну кому, то ви перестанете це робити.

А если отрубить мне голову — то и сами тесты потеряют смысл. но мы то говорим не о «системе в коме», а о системе, которая живёт и которую надо поддерживать в актуальном состоянии. (по секрету вам скажу — организм постоянно следит за собой и уведомляет вас о сбоях)

Ваш організм працює деякий час навіть після смерті головного мозку. Якщо його підтримувати, то так можно прожити все життя. Овочем, але прожити. Нульпойнтерексепшин не трапляється.

Не думаю что заказчик захочет платить за систему-«зомби»

Це верхівка еволюції розробки ПЗ. Коли вам треба пересунути іконку на робочому столі, то ви не робите заявку в компанію розробник ОС,

Ну, если для вас «разработка по» это «передвинуть кнопку»..... (и по секрету — да, делают заявку чтобы «передивнули». Достаточно часто это обосновано)

Яке дивакувате розуміння терміну «іновація»...

Основано на практических наблюдениях.

Когда ВАША система не работает по причине того, что вы НЕ ТЕСТИЛИ как ваша система работает со сторонней системой — то это ВАША система не работает и это ВАША проблема.

Ви майже весь час пишете код під чужі API, вигадані не вами, реалізовані не вами. Ви ж не вимагаєте в інших розробників, щоб вони щось там тестували в себе, коли ви щось змінюєте в своєму коді? Але ваша система не буде працювати, якщо ви не дотримуєтеся вимог з боку інших систем. Не важливо, тестуєте ви при цьому, чи ні, логіка тут бінарна. Або працює, або ніт.

а о системе, которая живёт и которую надо поддерживать в актуальном состоянии

Ви не контролюєте систему, наприклад, травлення. Ви гадки не маєте, що саме відбувається у вас всередині, можете тільки в сильному наближенні пояснити все. В цілому, без деталей. На вищому рівні абстракції. Але система працює, бездоганно майже, все ваше життя. Ніхто її не покриває тестами. По-перше в цьому немає необхідності, по-друге, це неможливо в принципі. Тому мозок й не заморочується. Йому байдуже, жували ви брокколі самотужки, вводили пюре ректально чи внутрішьно через вену всі необхідні речовини вже в денатуралізованому вигляді. Все підійде. Код може бути написаний аналогічно. Коли ви гадки не маєте, що у вас відбувається всередині, то вам потрібно що? Правильно, моніторинг та зворотній зв’язок. Не тести.

Не думаю что заказчик захочет платить за систему-«зомби»

Система зомбі — це щось, що покрите з ніг до голови тестами, але все одне не функціонує як треба. Бо тести не тести та треба тести на тести...

Ну, если для вас «разработка по» это «передвинуть кнопку»..... (и по секрету — да, делают заявку чтобы «передивнули». Достаточно часто это обосновано)

Ви не вловили сутність аналогії. У вашому світі всю роботу мусять робити програмісти, бо їм треба сім’ю годувати та щоб вистачало не тільки на хлібчик, а ще й на смузі з різотто. А бізнесу треба швидше, якісніше, бажано безкоштовно, та на позавчора. Спробуйте таке рівняння вирішити тепер.

Основано на практических наблюдениях.

Людина в колодязі бачить світ через призму отвору.

Ви не вловили сутність аналогії. У вашому світі всю роботу мусять робити програмісти, бо їм треба сім’ю годувати та щоб вистачало не тільки на хлібчик, а ще й на смузі з різотто. А бізнесу треба швидше, якісніше, бажано безкоштовно, та на позавчора. Спробуйте таке рівняння вирішити тепер.

Само по себе наличие программистов и тот факт, что бизнес пользуется услугами программистов говорит о том, что модель «бизнес делает себе всё сам» — является нежизнеспособной.
Точно так же, как я не меняю сам масло в своём корыте — бизнес не будет «сам» что -то там девелопить.

Але система працює, бездоганно майже, все ваше життя.

хотя пример «так себе», но уж позвольте с вами не согласится :)

Йому байдуже, жували ви брокколі самотужки, вводили пюре ректально чи внутрішьно через вену всі необхідні речовини вже в денатуралізованому вигляді. Все підійде. Код може бути написаний аналогічно.

Вы знаете, я бы не хотел чтобы код в систему, которую я заказываю, «вводили в систему ректально». Я не за это плачу деньги. По крайней мере не за то чтобы какие-то девы мне заявляли «ой, да какая вам разница, как мы это всё проверяли, работает? работает! чо ты паришься!». Такие девелоперы сразу идут получать расторжение контракта.

З таким підходом в системі може жити декілька версій або реалізацій водночас.

Welcome to DLL (library) hell! ©

І що, відмовилися від DLL? :D

ор вище гор. А потім тобі буде потрібна 100 розробників кожен з яких буде підтримувати открему версію

Ви завжди можете створити нову. ;) Стару просто викиньте.

Спасибо, посмеялся. Для пущей радости нужно сделать еще так, чтобы новая система максимально отличалась от старой — и минимально работала с уже существующим оборудованием.

ор вище гор. А потім тобі буде потрібна 100 розробників кожен з яких буде підтримувати открему версію

Нет, но не зря назвали это «адом», а не «ой, какая удобная классная фича»

Проблема ж не в підході, а як його використовували. Ніж можна використовувати на кухні, а можна людей різати. Ніж від цього не стає гірше або краще. Він є.

Ця проблема хрестоматійна. У вас є щось, що імутабельне через ряд причин. Ви обійшли проблему імутабельності через версійність, та вважаєте, що у вас вже дві проблеми. Але є одне але. Ніхто не задається резонним запитанням, як зменшити проблеми від імутабельності та що є в наявності прямо зараз з успішних реалізацій. Розкладемо проблему на різні частини та спробуємо швидкоруч накидати варіанти реалізації

1. Кожна нова версія коду збільшує ентропію. Проблему ентропії можна вирішувати з двох сторін: боротися з нею або навпаки, зробити її частиною системи.

Боротися можна, знову ж таки, в двох напрямках, або адміністративно, примушувати розробника вичищати всі застарілі версії та слідкувати за дублюванням функціональності (безперспективно, на мою думку), або використати робочі механізми реального світу — ввести термін життя для компонентів системи. Не треба тільки вигадувати нереальні історії про те, що у клієнта щось зламається під час роботи системи, бо прийшов час компоненту померти та він самовипилявся. ;)

Про ентропію, як частину системи, тут цікавіше. В мене немає зараз гарного прикладу, як це можна вирішити.

2. Новий код може використовуватися лише один раз, мати невелику відмінність від іншого та містити помилки. Фікс тисячі класів гірше ніж фікс одного.

Тут ключовою інформацією є дублювання функціональності. Вже є система, де це десятиріччями все працює ідеально. Це утиліти *nix систем. Якщо відійти від цілого до загального, то можна легко побачити, що будь-яка система — це набір правил та функцій, а не класів та структур даних. Утилітарна модель дозволяє швидко побудувати вам необхідну, більш складну функціональність, використовуючи прості компоненти. Утиліти працюють незмінно роками. А от їх спосіб використання може змінюватися.

Продовжувати можно довго ще... Всі рішення лежать на поверхні

Знову дискусія на рівні Арестовича. Порівнювати утиліти юнікса, які теж намагаються використовувати у преносимий спосіб, що по суті означає використовувати фіксований кілька десятків років тому функціонал; з системою, до якої змінюються вимоги і змінюється середовище використання й виконання. Мобільні додатки тре оновлювати з оновленням системи. Бібліотеки тре оновлювати, бо виправили помилки і знайдені вразливості. Де тут статичність?

«Треба кожного разу, коли треба вносити зміни — створювати нову.» Шо тут не зрозуміло)

Треба бібліотеки оновлювати, чи бізнес-логіку?

Які ще тести коли у тебе 30річний проект на мільйони строк коду а замовник хоче фічу на вчора. Думав у казку попав ?

Тривожність, вона така... Підступна річ...

Погано, коли в моді популісти й демагоги, які граються словами й маніпулюють поняттями.
Архітектура перпендикулярна до тестів. Тестується реалізація, яких може бути мільйон для даної архітектури.
Тести — як і програму — потрібно вміти писати. А для цього має бути розуміння, як має працювати тестоване і вміти то перевірити. Якщо не знаєш чогось із цього, то тести на тести не допоможуть.
Зміни в існуючу систему можуть її зламати, тобто змінити її властивості до неприйнятних. І способи рефакторинга тут перпендикулярні. Наприклад зміни призвели до збільшення затримки в одному зі сценаріїв на порядок. Не вимірюючи час виконання — тобто, не тестуючи — цього не знатимеш.
Валідація, протоколи, стандартизація — треба переконатися, що працює і відповідає специфікації або стандарту. Для цього мають проходити набір тестів на відповідність. Те, що модуль приймає й видає дані згідно протоколу, не означає, що він правильно обробляє дані у потрібних сценаріях.
Підсумки сказаного: якщо інженер починає говорити, як політик, на проекті буде біда.

Вимога тестування — наслідок специфічної архітектури. Якщо ви закладаєте в архітектуру ті речі, які роблять тести безглуздими, то вам не треба більше вміти тестувати.

Зміни в існуючу систему можуть її зламати

Зміни в крихку систему можуть її зламати. Це не стосується fault-tolerant та fail-safe систем. Там помилка — частина нормального процесу.

Наприклад зміни призвели до збільшення затримки в одному зі сценаріїв на порядок.

Це видно на моніторингу, якщо він ведеться. Знову ж таки, хто сказав, що це погано? Який SLA примінявся для даного коду?

Валідація, протоколи, стандартизація — треба переконатися, що працює і відповідає специфікації або стандарту.

Тести тут до чого? Ні, ви, звісно ж, можете обкластися ними, щоб знизити тривожність. Але є й альтернативні шляхи, які, чомусь, принципово не розглядаються розробниками.

Підсумки сказаного: якщо інженер починає говорити, як політик, на проекті буде біда.

На моїх проектах біди нема. Все працює роками, без тестів, без мажорних багів (мінорні інколи трапляються, але там більше корнеркейси), з великою кількістю змін та не один я в команді.
Якщо інженер вперто повторює мантру, що тільки тести знімають тривожність, то шкода мені такого інженера, стереотипне мислення призводить до більших проблем.

Тест — це визнання безсилля та остраху перед майбутнім. Ви перестали контролювати систему та розуміти її.

1. Сучасні програми не складаються із декількох сотень рядків, які можна осягнути швидко та швидко змінити.
2. Сучасна розробка дуже динамічна — сьогодні шматок коду пишете Ви, а далі у ньому копирсається джун.
3. Розуміння контексту та його глибини у кожного інженера різна.
4. До того ж, сучасні системи складаються з інших систем, які теж писалися не ідеальними людьми та мають у собі баги.

Парадоксально звучить, але тести не призводять до зниження рівня помилок, тому що тести або не покривають всі ситуації, або мають помилку.

Тести допомагають зрозуміти, чи виконує ваш код функціонально те, що Ви написали. Бо навіть запуск коду та перевірка руками — це також тест. Як інакше ви зрозумієте, чи працює ваша частина правильно?
В системах типу system of systems та наприклад із мікросервісами, навіть Ваш гарно написаний код, разом може не працювати із безліччі причин.

З економічної точки зору тести — суто витратна частина проекту. Інвестування в тестування має негативний ROI.

Чому тоді, наприклад, існує професійний тест-драйв нових моделей авто, їхньої безпеки? Вони працюють в мінус?

Який код новачки не можуть поламати? Найпростіший. a + b = c.

1. Що буде, коли вхідні параметри рівні нулю або менше нуля, різного формату?
2. Що буде, коли a + b != c, але дорівнює d? Чи це проблема? Як Ви будете впевнені в цьому?
3. Крім того, зараз немає таких простих програм. Навіть, якщо у Вас одна функція — вона буде мати добрий десяток шарів абстракцій перш ніж юзер буде з нею взаємодіяти. А за ці шари Ви не можете бути впевненими.

А в слабопов’язаних або ізольованих — ні. Висновок — найпростіший код написаний новачком мусить виконуватися тільки в ізольованому середовищі та не мати залежності з іншим кодом.

Єдиний момент, коли код джуніора буде ізольйований від зовнішнього світу — це коли він буде писати код без інтернету, в окремій кімнаті на закритому режимному об’єті. В усьому іншому — взаємодія коду з іншими частинами буде — так чи інакше.
Unix пайплайни команд якраз і побудовані, щоб взаємодіяти одна з одною.

Немодифікуємі функції/методи/класи/процедури

Сучасна розробка систем не працює в парадигмі «write once, run always». Вимоги змінюються, уточнюються, доповнюються.
З такою логікою, на кожну окрему вимогу потрібно писати окрему велику апплікацію

Або HTTP, якщо не подобається попередній приклад.

Спробуйте написати валідацію на усі типи помилок кейсів, які можливі у веб аплікацію середнього розміру. Їх безліч і одна людина всі не згадає.

Fail-safe та fault-tolerant архітектури

Частково згоден. До того ж у великих розподілених системах дизайн та імплементацію будь-якої частини починають із формальної специфікації. Наприклад на TLA+. Далі, за допомогою інструментів, ця специфікація тестується (автоматично) на безліччі варіантів. І тільки потім пишеться код. Так, наприклад, працюють деякі команди в Amazon.
Але не дивлячись на це, баги знаходять і в таких тестованих системах написаних далеко не найтупішими людьми.

Тести потрібні, щоб переконатися, що код виконує те, що хоче замовник, а не розробник

Функціональні тести (юніт, інтеграційні) потрібні розробнику, щоб переконатися, що його код функціонально робить те, що треба. Замовник на ці тести глибоко пофіг.
Acceptance тести вже перевіряють сценарії, які буде використовувати сам замовник

Тести потрібні, щоб переконатися, що всі підсистеми працюють правильно

Цей аргумент нагадує щось із часів waterfall. Давайте 100 девелоперів будуть тихенько в кутку писати свій код (без тестів), а потім перед релізом ми почнемо ЗБИРАТИ його докупи! Та мерджити (що займає час). А потім перевіряти, чи воно працює взагалі.
На цьому етапі може статися, що вимоги різні команди зрозуміли та виконали по різному, ці самі інтерфейси не підходять один до одного, частини аплікації взагалі не працюють. А хто в цьому винен (чий коміт зламав) — невідомо.
В такому випадку треба багато фіксити, мерджити кожен коміт окремо та й взагалі — такий підхід приведе ліда до самогубства. Та растягне реліз на невизначений час.

А тут нам на допомогу приходить ... біологія!

Якщо це звичайна людина (статичний сайт, який нікому не потрібен), то так — щоденні перевірки непотрібні. Якщо ж професійний спортсмен, який готується до Олімпіади чи просто зірка, то Ваш стан здоров’я будуть відстажувати багато спеціалістів. Тому що на кону грошенята.

Люди почали удосконалювати процес тестування замість того, щоб йти в іншу сторону, намагатися підвищувати якість не використовуючи тести.

Які Ваші варіанти підвищення якості без тестів?
Доречі, алерти на продакшені — це теж свого роду тести, їх напевне також треба прибрати.
А потім сидіти годинами, та бачити, як Ваш ідеальний код втрачає мільйони баксів кожної хвилини через багу у алгоритму трейдингу.

Тести допомагають зрозуміти, чи виконує ваш код функціонально те, що Ви написали

Звучить як «Я дебіл, я не розумію, що я роблю».. Вибачте за грубість.

Як інакше ви зрозумієте, чи працює ваша частина правильно?

Запуск коду не є тестом в класичному розумінні, бо необхідно мати сам тест як окрему сутність. Хоча так, запуск коду програмістом з метою перевірки на роботоспроможність можна вважати тестуванням. Я не розглядаю цей варіант взагалі. Тут й моніторинг тоді можна називати тестуванням, бо присутнє виявлення відхилень від нормальної поведінки системи.

В системах типу system of systems та наприклад із мікросервісами, навіть Ваш гарно написаний код, разом може не працювати із безліччі причин.

До чого тут тести? Вони вам допоможуть зрозуміти, що система не працює через помилку в протоколі обміну даними, яку писали не ви, а розробники ОС, наприклад?

1. Що буде, коли вхідні параметри рівні нулю або менше нуля, різного формату?

Ви, як справжній програміст сучасності, почали лізти в реалізацію. В деталі, ви звикли до цього. Звичка, вона така. Подивіться на це з іншого боку. Є рівняння. Воно просте що двері, однозначне та абстрактне настільки, наскільки може бути абстрактною математика та логіка. Ви автоматично почали перекладати цю формулу на мову програмування, яку ви використовуєте, додавати зайві умови, які не стосуються суті. Але за деревами лісу не бачите.

У вас є три невідомі, дві операції. Не важливо взагалі, що саме будуть містити невідомі, формула звучить так, при складанні двох значень ми отримаємо третє. Це верхівка абстракції. Pure logic. Що саме ви збираєтеся тестувати тут? Різні варіанти значень? А хто вам сказав, що вони важливі? А хто вам сказав, що не можна складати пойнтери та undefined, та отримати в результаті щось інше? Рівняння при цьому залишиться вірним та незмінним. Ваша система може приймати на вхід що завгодно та повертати в результаті обробки що завгодно. Ви збираєтеся тестувати всю нескінченну кількість варіантів? Серйозно?

З такою логікою, на кожну окрему вимогу потрібно писати окрему велику апплікацію

Подивіться на npm ;)

Спробуйте написати валідацію на усі типи помилок кейсів, які можливі у веб аплікацію середнього розміру. Їх безліч і одна людина всі не згадає.

Вони всі класифікуються в коротенький перелік помилок. Ні?

Які Ваші варіанти підвищення якості без тестів?

1. Архітектурні. Як тільки у вас з’явиться вимога мінімізувати кількість тестів без втрати якості, у вас з’являться відповідні архітектурні рішення, наприклад перехід на fault-tolerant підхід.
2. Менеджерські. Перебудова архітектури буде вимагати трохи інших процесів розробки. Не буду заглиблюватися сильно в деталі, самою очевидною річчю буде підвищення рівня команди до більшого через постійні тренінги, сесії передачі знань, тощо.
3. Інструментальні. Більше моніторингів, хелс-чеків, альортів.

Доречі, алерти на продакшені — це теж свого роду тести, їх напевне також треба прибрати.

Так можна дійти до «Написання коду — тест бізнес ідеї на життєздатність» ;)

Звучить як «Я дебіл, я не розумію, що я роблю».

Ви написали додаткову логіку обробки фінансової транзакції у великій багатошаровій аплікації.
Ваша частина, Ви впевнені, працює. Тестів немає. Ви зробили деплой. Отримали N багів. Причому N — 1 багів «не Ваші», а отого Васька з сусіднього відділу. (Але їх можна побачити при базовому тесті). Але його не було зроблено. Клієнт використовуючі Ваші фічу втратив гроші. Хто винен? Зате система fault-tolerant по усім правилам.

Запуск коду не є тестом в класичному розумінні, бо необхідно мати сам тест як окрему сутність.

Тестування — це процес. Процес згідно якого ви перевіряєте чи задовольняє той код (програма), що Ви зробили — специфікації. А чи виділений для цього «окремий тест», чи це просто дослідницьке тестування, чи кричали при цьому на весь голос «Увага буде тестування» — не суттєво.

До чого тут тести? Вони вам допоможуть зрозуміти, що система не працює через помилку в протоколі обміну даними, яку писали не ви, а розробники ОС, наприклад?

Інтеграційні тести допоможуть зрозуміти, чи буде працювати Ваш компонент у зв’язці з сусідним. End-to-end тести допоможуть зрозуміти, чи виконують усі Ваші 1000+ мікросервісів зв’язаних неперевершеною архітектурою — те, що потрібно кастомеру. Тобто чи кастомер може зайти і подивитись відосик про котиків. А умовна фіча відео процессінгу може працювати стабільно та ідеально при цьому. Але інша частина Вашого аплікейшену не працює. Навіть, якщо її писали не Ви. (Про ОС та низькорівневі штуки не говоримо — Ви скоріш за все не пишете ОС у компанії. Якщо б писали — були відповідальні і за це. У сенсі шоб піти, та створити тікети на відповідних розробників).

Вони всі класифікуються в коротенький перелік помилок. Ні?

Не коротенький. І до того ж — якщо Ви написали на уце все error-handling код — як ви перевірете, що він працює в усіх випадках так, як треба. Тестів та тестувальників немає. Юзерам одразу дамо? В такому випадку, юзер отримає 1-2 помилки, заб’є на Ваш софт та піде до конкурента.

Подивіться на npm ;)

npm це не дуже гарний приклад. Я думаю небагато розробників «раді» викачувати оці сотні та тисячі пакетів кожного разу. А потім ще й перевіряти, чи немає breaking changes в одному із цих пакетів.

У вас є три невідомі, дві операції. Не важливо взагалі, що саме будуть містити невідомі, формула звучить так, при складанні двох значень ми отримаємо третє. Це верхівка абстракції. Pure logic. Що саме ви збираєтеся тестувати тут? Різні варіанти значень? А хто вам сказав, що вони важливі? А хто вам сказав, що не можна складати пойнтери та undefined, та отримати в результаті щось інше? Рівняння при цьому залишиться вірним та незмінним. Ваша система може приймати на вхід що завгодно та повертати в результаті обробки що завгодно. Ви збираєтеся тестувати всю нескінченну кількість варіантів? Серйозно?

Ви серйозно можете формально та формулами описати кожну Вашу програму (усі разом, не окреме рівняння)?
Програма — це не одне рівняння. Це взаємодія багатьох систем із тисячами можливих станів.
Задача тестування не покрити усі можливі кейси. Згоден, це неможливо. Але задача тестування перевірити найбільш критичні — які з більшою ймовірністю призведуть до великих помилок.

Ви написали додаткову логіку обробки фінансової транзакції у великій багатошаровій аплікації.

У вас тут в умовах вже є помилка, якщо ви фінансовими транзакціями керуєте з коду.

А чи виділений для цього «окремий тест», чи це просто дослідницьке тестування, чи кричали при цьому на весь голос «Увага буде тестування» — не суттєво.

Суттєво. Ви десь бачили практики або книжки на кшталт «Як правильно кричати про початок процесу тестування»? Ні, всі книжки описують типи тестів, коли їми займається переважно не автор коду.

Інтеграційні тести допоможуть зрозуміти, чи буде працювати Ваш компонент у зв’язці з сусідним.

Інтеграційний тест покаже один випадок з мільйону інших причин. Ви запускаєте тест на якомусь енвайронменті. Але енв може бути мертвим. Ви ж не пишете тест на роботоспроможність енва, на якому запускаються інтеграційні тести? Чи пишете?

А умовна фіча відео процессінгу може працювати стабільно та ідеально при цьому. Але інша частина Вашого аплікейшену не працює.

Вона може не працювати навіть при наявності мільйона end-to-end тестів. У вас немає ніяких гарантій, що при правильній роботі комбінацій AB, BC та CD, комбінація ABCD буде працювати. Чим довше ланцюг, тим менше шансів.

Не коротенький

Вітаю, ви створили неправильну архітектуру. Раджу вам переглянути підходи та почати об’єднувати ваші всі варіанти в кластери, щоб зменшити варіативність валідатора. Або перейти на інший рівень абстракції, щоб зменшити гранулярність. Серйозно, для мене це виглядає так, наче ви помилки архітектури намагаєтеся закрити тестуванням. Не пробували архітектуру міняти?

як ви перевірете, що він працює в усіх випадках так, як треба

У вас дійсно немає жодного іншого рішення в голові, окрім тестування? Серйозно? Про це я й казав вище, типове стереотипне мислення.

Давайте на прикладах, якщо так простіше. На вхід системи подається динамічна структура даних. Будь-що. Необхідно перевирити її за якимось правилами. Невідомими заздалегідь. Ви думаєте, що цю систему треба тестувати? А я вам скажу, що її реалізація буде настільки примітивною, що писати тести для неї буде марною тратою часу. Вам необхідно розробити набір простих правил, яких ваш код мусить дотримуватися. Наприклад, схема валідації вважається нормальною, якщо там є хоч одна декларація, яка схожа на таку. Решту можна ігнорувати. Якщо декларація не містить жодного правила, вважаємо вхідні дані валідними. Ми завжди повертаємо бінарний стан проведення валідації — пройшла або ні. Ніколи валідація не мусить падати з жодним з ексепшенів, всі незрозумілі ситуації трактуються як пройдена валідація. Одному типу валідації — один обробник. Обробники працюють за правилами валідатора.

Якщо пропустити загальні обгортки та перейти до коду обробника, який валідує якісь дані за якимись правилами, то його код буде настільки простим, що його тест буде більшим за об’єкт тестування. Не просто великим, а ще й безглуздим. Ви будете тестувати те, що майже ніколи не зламається. Та ніколи не буде модифікуватися з часів народження.

Ви серйозно можете формально та формулами описати кожну Вашу програму (усі разом, не окреме рівняння)?

Ви за деревами лісу не бачите. На вищому рівні всі програми однакові. Вони виконують кінцевий перелік високорівневих функцій: отримати вхідні дані, обробити, зберігти, показати, видити назовні. Я не сильно заглиблювався в деталі, перелік не остаточний може бути, але для розуміння ідеї достатній. Ви можете лізти в деталі реалізації, занурюватися глибше й глибше до систем, компонентів, класів, але всі вони працюють за цима простими правилами. Метод класу отримує вхідні дані, обробляє, передає іншій системі. На всіх рівнях є таке.

Але задача тестування перевірити найбільш критичні — які з більшою ймовірністю призведуть до великих помилок.

Найбільш критичні стають неможливими, якщо приміняти інші підходи ніж класична імперативщину. Світ живе заручником своїх звичок та стереотипів.

вибачте, але це софістика чистої води. ви робите заздалегідь хибні твердження і на основі їх розвиваєте свої думки як вам здається «логічно». тут навіть розвивати і критикувати немає сенсу такі коменти :D
це все одно що сказати — програмісти не треба бо ШІ все напише сам просто треба вірно загуглити запити. ну і далі ці думки розвивати по аналогії з вашими :D
розробники не потрібні, тестувальники не потрібні. треба тільки ШІ

вибачте, але це софістика чистої води

Я практик. Останні 15 років я використовую event-structure-based підхід, який асинхронний, реактивний, з ситуативним execution flow, та ще й fault-tolerant. За всі ці роки написано та продовжують розвиватися багато систем, які містять мінімальну кількість багів в частині, де відповідальна моя команда. Як ви думаєте, скільки тестів в нас написано? Нуль.

event-structure-based підхід

Гугл щось не знаходить за цими словами нічого релевантного

Може тому, що я його автор? :D Там тупняк. Розповсюдження подій відбувається в рамках певної структури даних тільки для певної зони видимості. Для різних частин однієї структури можуть бути різні зони видимості, різна кількість елементів, на які розповсюджуються події. При запуску події заздалегідь невідомо, скільки елементів попадуть в зону видимості, а також невідомо, що саме вони будуть робити, як реагувати на подію. Контроль можна робити через збільшення або зменшення зони видимості події, або через зміну структури.

Ще простіше можна описати так. Вам треба погодувати всіх в хаті, вам не важливо, хто зараз в ній знаходиться, кіт, свиня, сусідський кіт чи сама сусідка. Ви кричите «Їсти!» всім, а хто вже відгукнеться, то їх персональна справа. Якщо ви зайдете в сусідський будинок та скажете «Їсти» там, то у вас не факт, що хтось інший, окрім сусідки, відгукнеться, бо всі інші реагують на слово «Жерти, скотиняки!». Щоб кликати всіх водночас, вам треба виходити на вулицю та вже там горлопанити, щоб охопити більшу аудиторію. Але треба бути готовим, що збігтися на ваш призов може пів села.

Не обов’язково, щоб на ваш клич постійно прибігала одна й та сама кількість «абонентів», сусідка може вже покинути вашу оселю, а коти десь вештатися. Структура змінилася, змінилася й реакція на події.

Тому execution flow ситуативний. Може не повторюватися реакція на одні й ті самі події в різні періоди часу. Або реакція різна в різному оточенні.

Мозок не любить такі стани невизначеності та зазвичай пропонує знизити тривожність за допомогою ... тестів.

сказано так, наче це погано. Але ніт.

А у вас не росте тривожність, коли всі тести зелені, а прод валиться?

трапляється. а потім я прокидаюсь.

А потом Боинги падают..

Ну, насчет боингов не знаю, а вот ракеты — падали.
причем «странно, всё раньше работало, мы код не меняли, а значит не поломали!» (где-то тут было утверждение, мол «если код не меняли — то он не испортился и нечего его тестировать»)

Підсумую: одним тестувальники потрібні, а інші кажуть що й самі можуть впоратися.
Обидві сторони праві, бо різні обставини у них мабуть. Різні умови, різні контексти.
Чи може одна і та ж сама функція виконуватися у різніх контекстах?

Десь я дуже довго писав як ми працювали над продуктом і в нас не було тестувальника, довго і чього нам це коштувало. Так от — твердження із статті, повне лайно. Звісно дуже добре якщо QA інженер має ще навички автоматизованого тестування,перевірки навантаження тощо, та навіть просто третя людина яка навіть в теорію тестування ще не вміє — всеодно набагато краще ніж нікого. Іноді звісно буває занадто за бюрократизований процесс, коли неможливо толком зарелізити зміну коми в якомусь надписі, по це влече за собою регресію на тиждень чи фікси авто-тестів на два тижні, тому що енв не витримує навантаження які генерують авто-тести. Та це питання не до наявності чи відсутності тестувальників, а безпосередньо до кваліфікації техлідів і менеджменту. Іноді просто знати скрам теж недостатньо, скрам це інструмент. 2. ІМХО твердження всеж клікбейт, дядька із статті суровий.

Наприклад:

як би тестувальник не старався бути «адвокатом замовника», тільки сам замовник знає, що йому потрібно (та може сказати чи якісний софт чи ні)

В оригинальном тексте — совершенно не тот смысл. там нет про «кастомер знает, что ему нужно». там про «только кастомер может сказать — устраивает ли его предлагаемое решение»

«only the customer knows if the software you’ve given them solves a problem that they have in a way that is satisfactory (or enjoyable) to them. »

1. Я всё таки прочитал статью (точнее статью и разъяснения к статье)
2. Умный дядька, который всю жизнь занимался тестированием, обучением тестированию, разработкой и налаживанием процессов тестирования говорит «ой, да в большинстве случаев тестеры не нужны» (если у вас в конторе есть такой вот умный дядька, который всё разработает, настроит, обучит)
3. Практически в каждой главе этот дядька говорит что а) тестирование нужно б) тестрованию нужно учить в) качество кода получается значительно выше, если девелоперы владеют основами тестирования
4. «только кастомер может сказать, хорошо это получилось или плохо». Суть не в том, чтобы кастомер тести, суть в том, что если вы говорите «да нормально оно работает!», а кастомер говорит «что за херню вы мне тут впарили!» — то кастомер прав. Не кастомер отвечает за качество, но кастомер может сказать где ему что не нравится. Это не про тестирование совершенно.
5. «я имею в виду ВЫДЕЛЕННЫХ тестеров» ©. «для небольший компаний/проектов во многих случаем девелеры могут совмещаться с тестерами». Ну ок, никто не спорит, если это экономически целесообразно — то почему бы и нет? Хотя при этом умный дядька говорит что «должен быть кто-то, кто научит, расскажет, покажет». Т.е. хотя бы один НОРМАЛЬНЫЙ тестер должен быть.

В целом статья — откровенная провокация (о чем умный дядька в самой статье писал раза 3 или 4), и напоминает «ошибку выжившего»: «Не нужно вызывать сантехника! Вы сами можете починить.....». Может быть да, может быть нет. Может вы затопите все 18 этажей вниз :)

Після прочитаних коментарів хочу зазанчити, якість коду (не продукту) це відповідальність двелопера — розширюваність коду, підртимка, легкість читання, масштабування...

Якість продукту це вже інегральник показник і відповідальність усієї команди, але найбільше сконцетровані на ньому саме QA інженери.

Ще одна штука як секьюріті котру тут ніхто не згадує, відповідальність несе уся команда і впершу чергу керівництво, але в першу чергу займається нею секьюрщіки і навіть не QA, бо программісти не хакери, хоч і мають знати основи, а ще секьюріті це не лише код, але і вся інфраструктура компанії. Тобто ваш проект це не лише код.

Так само і КУА, програміст може знати основи і це навіть корисно, але проти окремого спеціаліста його єкспертиза ніяк не потяне.

Насправді «якість коду», тобто структурна якість ПЗ це витримування загальних архітектурних принципів, загального дизайну і концепції обробки інформації і описання предметної області задачі автоматизації (business process flow), вдалий вибір алгоритмів їх обробки, усі принципи SOLID, уникання анти-патернів і навпаки слідування найкращім практикам, покриття модульними тестами тощо — це зона відповідальності технічного керівника програмного проекту (головного програміста, техліда, solution architect, fellow, CTO тощо). Як людей більше двох на проекті, це вже дуже велика робота. Зазвичай завдання архітектора ПЗ — саме координація і керування роботою команди над цим. QA інженери мають дещо іньший профіль, зокрема валідація і верифікація. Тобто створене ПЗ відповідає технічному завданні на нього і робить це відповідно до закладених алгоритмів. Оскільки ми не можемо математично доказати вірність створених нами програм — то використовуєм для цього саме науковий метод, тобто підтверджуєм це відповідними процедурами іспитами — тестами. Тестувальник частіше за усе починають тестування на сам перед із формалізації вимог, тобто технічного завдання оскільки на данний момент найбільшу складність в розробці ПЗ несе не кодування чи розробка архітектури — а саме вивчення вимог до ПЗ. Для програмних продуктів сучасної складності на 100% не можливо зібрати вимоги до них, замовник просто не може описати процесс який автоматизуєттся — бо його ще і не існує, доводиться діяти ітеративними методами проб та помилок тобто — експериментальними. Формалізація вимог один з методів суттєвого скорочення використання експериментального методу. Чому добрий QA та BA на проекті можуть коштувати цілої команди добрих программістів. Вони можуть прискорити розробку на 70-80%, тим що одна видає умови іньша їх перевіряє, формалізує та прибирає несумісності — які потім прояснює с тим самим замовником, техлідом тощо.

Я про це і писав але дуже спрощено.

Бачу кілька нюансів
1. Є компанії де QA це окремий департмент, і тестери репортять своїм лідам, а є — де тестери розподілені по командам розробки, і репортять лідам розробки.
2. Якщо на ринку праці є дефіцит розробників, то є багато сенсу наймати тестерів — легше знайти, меньше ЗП. Якщо ситуація зворотня, то має сенс наймати розробників і скидувати на них QA

має сенс наймати розробників і скидувати на них QA

Ще треба знайти ідіотів, котрі на це погодяться.

Вибачте кого образила, але покажіть мені, хто з девелоперів читав хоча б одну книжку про тестування (Сема Канера наприклад)? Чи має якийсь системний до цього підхід, а не просто «тут трошки поклікав» та «отам зробив два http запроси, кажись працює». Я вам скажу це дуже малий процент, і нерідко трапляється ситуація, коли навіть юніт тести написані неякісно. Ситуацію рятує те, що багато проектів — це то стартапи, то mvp де дуже гарної якості і не треба.

Нема сенсу читати бо — є QA. Тому й не читають.

А для того щоб «читали» і тести були добрі — звісно треба відповідальний за якість, який читав :) так само як тех лід відповідальний за продукт, або модуль — в цілому. Хоча ж програмісти кгижкі читали, навіщо лід?

Навіщо відповідати за проєкт коли через рік він або сам закрється, або сам підешь на +500? )))
Тут же ще ось як воно працює, відповідальність та якість дійсно ідуть оде коло іншого, але стартапи то про виживання, а не про якість, а там де замовник жучить галеру за якість, там і куа, і автоматизатори, і перформанс куа, і ще й навіть у шедоу галера закидує...Звісно це на ринку ще багато ріних випадків.

та Канера навіть не всі тестувальники читали :D :D :D

А нащо читати. Краще вивчити Playwright та піти на +500.

Синьор, який не знає що таке юніт-тести, інтегрейшин-тести, перфоманс-тести, стрес-тести і UI-тести і ніколи їх не писав — не справжній синьор!
І взагалі: хто краще знає як написати перфоманс-тести і що перевіряти — QA, який не бачив коду, чи девелопер, який його писав?
Що знає QA про інтегрейшин-тести, якщо перевіряється протокол взаємодії двох мікросервисів, які писали 2 девелопери?
Чи зможе QA взагалі вірно зробити стрес-тест, якщо у нього немає досвіду девопса і розуміння мережевих протоколів?

Давно згоден з ціми тезами.
Може тому що починав коли тестували — самі програмісти, і ми отримували від користувача люлєй особисто, а не через буфер служби підтримки

Додам вже з постережень за собою, коли є класний QA відділ — і чіткий флоу у розробці:
— стає лєньки думати про нюанси. Навіть коли пишеш тести — happy way працює? ну і ок. (іншими словами і ТЗ на тести повинен видавати QA, якщо вже перебрав тестування на себе)
— стає невігидно витрачати час дивидися очами користувача, тобто напрацювати product oriented mindset. Ця експертиза у QA, а тобі — таскі треба закривати, показувати продуктивність, а не «якість».
— ***к, ***к і в продакшн — QA відловить!
— а без «product oriented mindset» архитектурити і проектувати неможливо. Неможливо виділити абстракції домену і узагальнити декомпозицію, тому — копіпаста, кожен пише «своє сортування» (бо як залізе у підмодуль — «а-а-а, це потребує регрісійного тестування»). Тобто — писати треба — індуський код. я мав з ним справу, і не скажу що він поганий. Він — інший, заточений під отакі процеси розробки, які є наслідком — критеріїв оцінки результату роботи програміста.

розробники можуть гарно тестувати

можуть. тільки бізснес розробки рахує гроші інакше. Глобально виходить — збиткі у розробці перекриваються прибутками на інших етапах

касательно моего заявления «девы по определению не умеют в тестирование»
Основная мулька дева — это правильно реализовать поставленную задачу
основная мулька тестера — это найти способ, как заставить написаный код работать неправильно.
как всем давно известно из основ научных исследований — никакого количества положительных результатов недостаточно для подтверждения теории. Но достаточно одного отрицательного результата чтобы теорию опровергнуть.
Так и с тестированием. Тестеры — это специально обученые люди, которые професионально умеют «делать не так».
Дев инстиктивно избегает «неправильных действий». Куа — професионально обучен научным образом генерировать «неправильные действия»

Это дуэль «непробиваемой брони» и «непобедимого копья», тут нужны разные навыки, разный менталитет, разный темперамент.

А еще качесво кода от программиста, это в первую очредь его расширяемость, масштабируемость, читаемость и количество часов поддержки на этот код.

У старі добрі часи до поняття якості коду також відносилася так звана robustness — це властивість коду максимально коректно відпрацьовувати принаймні типові нестандартні ситуації.

девы по определению не умеют в тестирование

А навпаки: QA автоматично не вміють в девелопмент. Вже не виглядає так дивно? Звісно що деви рідко коли вміють професійно виконувати НЕ свою роботу. І це очікувано. Бо мають натомість величезний стек задач у голові, конвертнути юзеркейси в реквайрменти, потім в дизайн, не забути про маштабування, абстрактність, зв’язок з низьким рівнем та інтерфейси з абстракціями високого. Часом просто кеш-пам’ яті на побутові задачі не лишається, і люди так роками живуть. Не просіть їх бути ще й куєй

Бо мають натомість величезний стек задач у голові, конвертнути юзеркейси в реквайрменти, потім в дизайн, не забути про маштабування, абстрактність, зв’язок з низьким рівнем та інтерфейси з абстракціями високого.

Этого девы в 80% примерно случаев тоже не умеют :)
(а некоторые вещи не должны делать, хотя как и с тестированием — сильно помогает работе, когда они понимают основы всего этого)

Тестеры — это специально обученые люди, которые професионально умеют «делать не так».

Тобто більшість часу клієнт платить QA за те, щоб вони перевіряли те, що більшість юзерів ніколи не буде робити! Хіба це не марно витрачені кошти?
А якщо справді юзер зробить «не те» — наскільки катастрофічними можуть бути наслідки? Навіть якщо у банкоматі трапляється помилка і можна вкрасти гроші — усе одно це згодом відстежать. Але у 90% випадків юзер просто отримає повідомлення про помилку — жодних збитків.
То чи варто платити QA тисячі доларів за пошук МОЖЛИВИХ помилок, а тим більше за пошук «неможливих»?

Є системи, в яких помилку взагалі неможливо відшукати. Бо ситуація трапляється в єдиному екземплярі та не повторюється ніколи

Але у 90% випадків юзер просто отримає повідомлення про помилку

От хоча б це й повинен перевірити тестувальник. Що буде якась зрозуміла помилка, а не увесь додаток закрешиться, наприклад.

У топі коментарі, які показують, що люди уявлення не мають про продуктові компанії, в яких працює 30 або 100 інженерів, фічі в тому числі пропонують розробники, а код і тести пишуть усі розробники до СТО включно. Момент відкриттів на ДОУ.

На одній із робіт тестувальники приходили до розробників, щоб дізнатися, як працює фіча, як сконфігурувати фічу і як її правильно тестувати.

На одній із робіт тестувальники приходили до розробників, щоб дізнатися, як працює фіча, як сконфігурувати фічу і як її правильно тестувати.

З мого досвіду усі індуськи тестувальники працюють саме так. На нього приходить таска на тест — він дзвонить розробнику аби той показав йому як перевірити. Після цього тестувальник закриває таску як перевірену! (ну може повторить сам один раз заради відео).
Справа у тому, що якщо тестувальник розбирається не гірше за девелопера — то і платити йому треба стільки ж. Тобто маємо 2 однаково цінних інженерів на одну таску: один робить — іньший перевіряє. Для якості це, звичайно, добре.
Але питання — якщо одна людина буде і робити і перевіряти — на скільки впаде якість і яка буде економія?

Оу, цілих сто інженерів. Моя повага. :)

На рахунок питати у розробника — цілком очевидно що про фічу яку написав конкретний розробник треба питати саме у нього, або у когось з його команди. І не тільки тому що він найбільше в темі, а ще й тому що він міг випадково або свідомо скіпнучи частину спеки, або змінити поведінку відносно спеки.
Мова йде про всі інші фічі, особливо у випадку коли більшість девелоперів досить спеціалізовані. При наявності документації, спеки, та у випадку девелопера сорців кожен інженер може допетрити як працює та чи інша частина продукту. Питання тільки в часі який це відніме людини яка працює з цим регулярно кожен реліз, або взагалі щоденно, і у людини яка полізла в ту фічу вперше, хай навіть і з допомогою сорців. І що як таких фіч у продукті вагон і маленький возик? Змусити більш високооплачуваного інженера витрачати час впусту, щоб що? Запостити на ДОУ топік про те як у вас немає більш спеціалізованих тестувальників? Ну ок :)

розробники до СТО включно

Реву, це в якій компанії де 100 розробників, СТО має час писати тести й код і вважається розробником?

Смысл отказа от тестировщиков, он в экономии средств. Разраб может протестировать свой же код, но он будет смотреть с позиций что код на 100% написан правильно, и ошибок нет. То, как им написанный функционал взаимодействует с другим функционалом он тестировать конечно не будет, главное что его код как-то работает да и некогда ему что-то там тестировать. Далее все это выкатывается в прод и уже в отзывах всплывает куча багов, которые потом ему передает ТП. Ну и так по кругу. Есть компании которые придерживаются такой стратегии, продукт забагованный, но как-то работает, зато можно с улыбкой говорить что QA не нужны и немного экономить

Хороший девелопер — вільний девелопер © Ілон Еролович Маск

Так звичайно, девів у нас тут як собак нерізаних, хоча б з 5 роками досвіду

Вони стільки за останні два роки найняли, що ці звільнення просто смішні. Можете загуглити графік найму в твіттері і як виглядали поточні звільнення. Капля в морі.

Разраб может протестировать свой же код, но он будет смотреть с позиций что код на 100% написан правильно, и ошибок нет. То, как им написанный функционал взаимодействует с другим функционалом он тестировать конечно не будет,

а это — зависит от культуры разработки в команде, компании.

Если тех лид имеет право завернуть пул реквест потому что видит описанный подход — то такой подход и исчезнет, или разраб пойдет искать другую команду.
там где тех лид — не имеет права заворачивать пул реквест по указаным признакам, такое таскозакрывательство и будет процветать. И цвести и пахнуть «индусским кодом».

Далее все это выкатывается в прод и уже в отзывах всплывает куча багов, которые потом ему передает ТП. Ну и так по кругу.

да, именно так. Как в компании принято — так и делают. И так и разрабы подстраиваются. Или меняют компанию :)

В реальності дев таки може непогано протестувати, за наявності зацікавлення та вільного на це часу. В реальних комерційних проектах сучасного айті, часу немає завжди. Тому нема варіантів, куєй потрібен, бо дозволяє пришвидшити вихід продукти та розгрузити девелопера, зробивши частину роботи паралельно та більш якісно

кстати, о тестировании, фидбеке, «кастомер лучше знает, протестирует и зарепортит баг» и всём таком прочем
Если кто помнит — именно так умер Netscape Navigator (ой, а что это? Вот именно...) 4й, если не ошибаюсь, версии
Продукт был «пушнут на проде» без даже минимального тестирования, в расчете на «юзера зарепортят ошибки». И таки да, юзера зарепортили. МИЛЛИОНЫ однотипных ошибок, которые могли бы быть найдены и пофикшены при банальных смоук-тестах и минимальном тестировании. но тестирования не было — и компания тупо умерла под лавиной этих репортов.
А навигатор то был крут, как никто....

Якщо в твоїй команді немає тестувальників то можливо тестувальник це ти.

десь в 50% команд де я працював не було тестувальників.
і зараз не має і не відчуваю таку потребу

всё зависит от задач, решаемых командой. Ну и, может быть, от штрафных санкций, накладываемых заказчиком на исполнителя в случае, если заказчик понесёт потери в результате ошибок в ПО.

Працюю у стартапі, тестувальників у мене в команді немає.
Якщо девлопер звик тестувати те що він робить, то в більшості випадків qa не потрібні.
Тим паче те що я роблю досить важко протестувати manual qa без підтримки делопера.
Треба, щоб він/вона могли стартувати EMR кластери в AWS, сабмітити спарк джоби, кверяти S3, писати спарк квері в zeppelin etc.
Витрачаю приблизно 30-40% часу на тестування свого кода (автотести + мануал тестування)
Тестувальнику на те ж саме потрібно було б в 2-3 рази більше часу.
У стартапі і так часу не вистачає...
P.S. В мене дуже рідко вилазять баги на продакшені.
P.P.S. Часто також приходиться займатися девопсом.

т.е. другими словами «я, квалифицированный девелопер, могу запускать тесты и проверять свой код. Однако я не верю в то, что квалифицированный специалист по тестированию кода сможет запускать тесты и проверять мой код.»
В данном случае я бы посоветовал нанимать квалифицированный тестеров.
хотя для стартапа — вполне подходит модель PoC, когда нужно как можно скорее выпустить версию v0.1, чтобы привлечь инвесторов. В дальнейшем же можно будет уже вести разработку и тестирование нормальным способом.

Витрачаю приблизно 30-40% часу на тестування свого кода (автотести + мануал тестування)

Якось дуже мало. Деколи придумати і накидати юніттести займає більше часу ніж писати код. А ще інтеграційних би і е2е. Так що 30-40% то якась явно занижена оцінка

«Написати тести довше, ніж код».
Якщо я чую щось таке на співбесіді — я відразу розумію що девелопер не звик писати тести! І тому вин пише «монолітний» код який потім, звичайно, дуже важко тестувати у ізоляції.
Коли звик писати код з тестами — то просто незрозуміло: а як можна інакше? Я добав метод — як я перевірю що він працює? Мені потрібно викликати його тут і зараз — а не чекати поки увесь API буде готов чи навіть UI.
Як фіксити баг, якщо щоб його зарепродюсити через UI треба пройти увесь чекаут поцесс? Робити це кожного разу? Звичайно швидше написати тест, який буде падати — і потім зробити фікс.
Тести — це такий же інструмент девелопера, як «тестер» для електрика. Якщо електрик не знає як «продзвонити» лампочку — то це поганий електрик. Так само і девелопер, якій не вміє в тести.

О, сильно розумний підкотив. Порахуй стрічками коду. На тест іде більше стрічок ніж сам метод якшо всі кейси потестувати. А ше замокати купу лабуди. То яким чином на тест піде менше часу?

Е2е тести писав колись? Давай напиши його без робочої апішки.
А ще дані за собою би почистити.
Купа часу йде на різні дрібниці.

«Написати тести довше, ніж код».
Якщо я чую щось таке на співбесіді — я відразу розумію що девелопер не звик писати тести!

ну вообще говоря, да
Я сейчас работаю над проектом одним, относительно несложным
И вот сам код — это, ну пусть, 50 строк кода.
А вот тестовые данные для него — это как правило 200-500 строк уже, потому что нужно проверрить не только то, что код ожидаемо работает в ожидаемых случаях, но и что код нормально прохавывает неожидаемы случаи, проверить не только положительные, но и ложно-положительные случаи, точно так же как отрицательные и ложно-отрицательные и так далее.
и это еще нужно учитывать, что мне нужно просто набор тестовых данных подготовить, фреймворк тестирования то уже готов. а всё равно занимает просто охренеть сколько времени....

Якщо я чую щось таке на співбесіді — я відразу розумію що девелопер не звик писати тести!

щось ви не так тоді розумієте.

Вже порекомендували, додам.
Рядків коду у тесті буде більше, ніж сам код, бо код — то узагальнений запис якось алгоритму, дій, а тест повинен запустити той алгоритм з різними данними.
Так, в ідеалі, коли код відразу по TDD, коду тесту буде більше, але він буде простий, однотипний, тому можна й джуна посадити — копіпастити.

для перевірки
var c = a / b

скільки в вас мініально вийде рядків коду?

а потім, скільки часу займе впавший тест, після:
var c = a / b + someFunc(x)
замокати someFunc — буде просто. чи ні, на вашому ЯП?
бо добрий тест не повинен її викликати, щоб протестувати a / b + someFunc(x), чи не так?

чи, як джуни роблять частенько, у результаті тестами обкладені і ліби, і фреймворк, тільки — не наш код :)

І то, я зтикався з — рефакторингом тестів, бо їх складність вже не давала нормально додавати ще тести, без бігання по третині впавших тестів. На Java. І команду ту згадую як фахову.

Ну а з тестами UI то без
isRunningWithJest() - у коді, інколи і не уявляю як.
у тестовому середовищі ж — не повноцінний браузер, купу речей він просто не відпрацьовує, як от ререндерінг зі змінами які в CSS

так, причина часто у тому що самі компоненти занадто жирнючі, і якщо їх порозбивати до малюсеньких... то в залежності від мови, але матимимо конструктори та функції які приймають 10+ арументів.
тобто заради зручності тестів — зменшуємо readability коду

так, причина часто у тому що самі компоненти занадто жирнючі, і якщо їх порозбивати до малюсеньких... то в залежності від мови, але матимимо конструктори та функції які приймають 10+ арументів. тобто заради зручності тестів — зменшуємо readability коду

Оце не зрозумів — як декомпозиція на прості компоненти зменшує readability коду?! Хіба декілька простих класів не краще, ніж один жирнючий?
Так — можливо конструктор буде мати багато параметрів. Але якщо не подобається — то є багато інших способів інжекшину.

Рядків коду у тесті буде більше, ніж сам код, бо код — то узагальнений запис якось алгоритму, дій, а тест повинен запустити той алгоритм з різними данними.

Data Driven test на допомогу!

І то, я зтикався з — рефакторингом тестів, бо їх складність вже не давала нормально додавати ще тести, без бігання по третині впавших тестів.

Це — прямий результат порушення Open-Closed принципу! Пригадуємо: один раз написаний та покритий тестами код вже ЗАКРИТИЙ для змін!
Ніякого «міняємо A+B на A+B+C і правимо тести» не має бути. Нова імплементація з A+B+C і нові юніт-тести на неї. Це-база!

У вашому випадку професійний тестувальник міг би бути корисним на етапі test design, щоб забезпечити достатнє покриття логіки, оптимізувати кількисть тестів з точки зору класів еквівалентності та таке інше.

А саме виконання тест кейсів дійсно має сенс доручити тому, хто знається на специфіці технологічного стеку.

1. Статью не читал
2. В статье написан бред
3. Девелопер НИКОГДА не будет нормальным тестером. «так себе тестером» — ну, в редких случаях. НОРМАЛЬНЫМ ПРОФИ — ни в жисть. Тестер — это совершенно другой, особый склад ума, гораздо более организованный и научно устроеный.
4. Заказчик НИКОГДА не сможет протестировать приложение.и заказчик в крайне редких случаях знает — что ему нужно.
5. «Девелоперы могут написать автотесты». Бред. «Автотест» — это просто ВСПОМОГАТЕЛЬНЫЙ ИНСТРУМЕНТ тестера, а не его замена. И т.к. (выше сказано) девелопер НИКОГДА не будет нормальным тестером — его автотесты никогда не будут нормальными, а значит — они не нужны и ничего не тестируют.

Якщо перед тим, як імплементувати ту чи іншу фічу, розробник сяде разом із тестувальником та вони разом розпишуть, що треба «як мінімум» протестувати після завершення задачі — то розробник це зможе зробити сам.
Плюс розробник же пише юніт та інтеграційні тести. Чи не так?

Не так, сорри.
Почему-то считается что тестировать — это простая задача. «ты просто пишешь тесты, тестовые случаи, запускаешь — если тест зелёный — всё нормально». Одновременно с этим 95% разработчиков не в состоянии самостоятельно правильно написать тест простой функции f(x). И 99% разработчиков понятия не имеют, причем тут вообще survivorship bias к их тестам?
это как бы раз
Два. если «разработчик сядет рядом с тестировщиком, и тестировщик даст описание, достаточно подробное и полное, чтобы разработчик сумел написать тесты» — то поздравляю, вы только что приняли в штат лида тестеров, который в одно лиТцо рулит целой сворой недо-джунов тестеров/девов.
Но она всё таки есть — этот тестер! И без него — никак.
Кстати, у меня еще замечательная идея. Можно избавится от верстальщиков. Нехитрое дело — вёрстка. Да и пейнтом пользоваться и рисовать там всякие иконки и прочее — невелика мудрость. Дизайнеров нафиг. Ну и английский/испанский/арабский/французский/немецкий для дева — это маст хев, если он работает на этот рынок. Уволить теч райтеров.
Системщики опять же. Ну что ты за дев, если не знашь бо-о-бз-с-бс-з-бк-к и как отрубить icmp echo. Еще можно спецов по БД гнать в шею — есть же linq2sql, code first и прочее — зачем нужны эти бездельники? :)

зы если хотите — можете проверить. Возьмите своих девов, дайте им задачу: есть черный ящик функция f(x). нужно протестировать её на предмет выпадения их неё исключений. какие значения x следует подать на вход? для простоты будем считать что это — float

Усе як завжди залежить від контексту — компанії, її культури розробки та продукту (процесів).

Почему-то считается что тестировать — это простая задача. «ты просто пишешь тесты, тестовые случаи, запускаешь — если тест зелёный — всё нормально». Одновременно с этим 95% разработчиков не в состоянии самостоятельно правильно написать тест простой функции f(x). И 99% разработчиков понятия не имеют, причем тут вообще survivorship bias к их тестам?

Виникає тоді питання — чому, якщо тестувати непросто (а це так і є), ЗП у тестувальників нижче та відношення до них як до «клікерів»?

Виникає тоді питання — чому, якщо тестувати непросто (а це так і є), ЗП у тестувальників нижче та відношення до них як до «клікерів»?

как вы сами уже неоднократно ниже писали — это результат непрофессиональности менеджеров и девелоперов. но по большей части, конечно — это вина манагеров.

Нагадаю визначення бага: не відповідність специфікації. Тобто, якщо у якомусь вигляді в т.ч. у вигляді написаного розробником документу у вас є вимоги — а як інакше можна фічу реалізувати — то і тести зрозуміло, як писати.

Баг — це невідповідність реальної поведінки очікуваній. Тобто значно ширше за те, що є в специфікації. Багато речей там неописані, але очікуються. Щодо розуміння написання тестів ... Тут тестувальники, які роками працюють, читають і вчаться це робити, хиблять, а ви кажете про розробників.

Тестер — это совершенно другой, особый склад ума, гораздо более организованный и научно устроеный.

Дякую, поржав)

Всегда приятно встретить человека с чуйством йумора.

У нас в databand.ai не було виділених тестувальників за весь час існування компанії. Частина речей покривалась тестами, частина — активним моніторингом. Можливо специфіка продукту дається взнаки, але не пригадую, щоб це завадило бізнесу. Стартап успішно зробив exit.

Це абсолютно нормально. Якщо забезпечення якості розподілене між інженерами та вбудоване у процеси — можна жити без тестувальників досить довго.

Лише питання, як рахується заробітна плата, коли на таких проектах інженер це 5в1.

Написал код — проверь.
Тестировать разное поведение и узкие кейсы — работа тестера.
Разраб должен писать код... если отвлекаться на все другое... то не останется времени на первое :)

Що перевіряти та «як глибоко» кожен розробник для себе вирішує сам. В залежності від бажання та наявного часу.

Тільки замість «бажання» я би поставив вимоги до розробки, що здебільшого переводиться в час та гроші.

Тестировать разное поведение и узкие кейсы — работа тестера.

Але виявляється що для більшості продуктів цілком достатньо перевірити тільки happy path !
Який сенс витрачати час і гроші на усякі «вузькі кейси». Ніхто не буде платити зайвих грошей за продукт який «ніколи не падає» — це ж не космічні технології!
Один з 10 юзерів тицне не туда — побачить помилку. Наступного разу тицне куди треба чи подзвонить в сапорт і йому підкажуть. Усе — не треба платити фул-тайм тестеру який буде шукати «корнер кейси».

Один з 10 юзерів

— это примерно 12 тысяч юзеров — и 12 тысяч звонков в саппорт. одновременно.....

Можна зробити чат-бота. Чи ШІ з розпізнаванням голосу. Якщо це проблема, яка виникає у багатьох юзерів — то ШІ зможе зрозуміти що людина питає про це і надати інструкції.

Можна зробити чат-бота. Чи ШІ з розпізнаванням голосу.

То есть вместо тестировщика нанять двух — трех разработчиков, копирайтера который вопросы ответы для бота придумает, перводчиков, если это интернациональное приложение и менеджера который этим всем будет управлять? И все это вместо того что бы иметь тестировщика?

А є ще комплаєнс, безпека, перформанс. Ті кейси може і вузькі, але можуть дорого коштувати. Он Google тільки у Франції виплатив у минулому році 57 млн. євро за порушення GDPR. Ризики теж розробники будуть прораховувати?

тільки сам замовник знає, що йому потрібно

Ревів як локомотив :))))))))))))

Ну якщо подивитися, то поняття якості — це суто індивідуальна штука та залежить від конкретної людини. Комусь більш за все важливо, щоб базовий функціонал працював, а на всі інші легкі косметичні проблеми можна закрити очі.
Інший кастомер — може навіть не дійти до реєстрації чи оплати — бо зачепиться за якісь невеличкі проблеми в UI/UX та з выдразою видалить аппку, замінивши її на конкурента.

Саме тому існує таке поняття, як quality calibration, тобто прояснення очікуваного рівня якості щодо UI/UX, обробки помилок, стабільності роботи у нетипичних умовах тощо.

Є такий цікавий чувак у сфері тестування на прізвище Уіттакер. Написав цілу книжку років 15 тому, де говорив схожі речі. Але якщо трохи пошкрябати пальцем, то виявиться, що він менеджер, а не тестувальник, і як експерта у сфері його сприймають з великою натяжкою, а деякі інші експерти відверто ржуть. З цим тіпом з МС, як мені здається, ситуація досить схожа. Багато вже написали в коментарях, чому це все шляпа, але нижче розберу штуки, які, на мою думку, недостатньо висвітлили:
1. Тостери за 5$, нічого не вміють, тільки проблеми створюють, кококо, справжні QA давно звалили в дев/менеджмент/аналітику.
Я не застав часи, коли таке могло б бути, але зараз якщо тестувальник не вміє писати докладні баг репорти, грепати логи, лазити в базу, не знає інспектор і як стукатися по http, то він пролітає, як фанера над парижем, а ти просто розглядаєш наступного зі 100500 кандидатів. Це, якшо шо, на джуніор (не трейні) рівень.
2. Автотести топ — швидкі, запускаєш скільки хочеш, немає людського фактору, а автотести — це код, значить деви можуть його писати (і так же юніти пишемо).
Може це й діє на маленьких проектах, але десь на доу я бачив влучну фразу: «автоматизуй, не автоматизуй, все одно отримаєш ... багатогодинні джоби з тестами, які треба постійно фіксити, і все одно перезапускати, бо шось там нестабільне впало». Згадайте, які срачі точаться з приводу юнітів, які треба переписувати на кожен рефакторинг, а тепер уявіть, скільки тестів доведеться писати на одну задачу, а потім на її фікс/доробку. Вже день очікування на qa не здається таким жахливим?)
3. (МС стайл) Юзери потестять.
Ні, юзерам абсолютно похєр на вас, якщо вони натикаються на баги, вони підуть шукати альтернативу вашому продукту, а зарепортять вам шось, тільки якщо це буде неможливо, і то, якшо їм буде не впадлу. І те, шо вони вам зарепортять, буде шось в стилі «у мене кнопка не працює», без уточнення того, яка саме кнопка, і за яких умов вона не працює. І так, мене дуже бісить якість сучасного пз.
4. Деви знають код, тому можуть ефективно тестувати, тільки покажіть їм як.
Я свічнувся з qa в дев з 3 роками hands on досвіду, і якось усі тестувальники (їх 2) одночасно пішли у відпустку, тому тестувати довелося мені. Так от, після мене в моїй задачі якийсь нещасний джун знайшов ще 2 бага. Ну що ж, може свої таски тестувати і справді погана ідея, може хай деви тестять таски одне одного? З чужими і справді спрацювало, але їх код я навіть не відкривав, а керувався чисто якимись поверхневими уявленнями про архітектуру тих компонентів. Отже, при тестуванні ніяких переваг від того, що я дев, я не відчув. Але хто слухає рандомних тіпів з доу, у ВАС точно все вийде)))))).
5. Універсальність — топ, якщо ти хочеш, щоб у тебе був якісний продукт/тебе не вигнали з роботи, ти маєш сам за всім слідкувати.
Якраз тестувальники — це найуніверсальніші люди на проекті. Не на всіх проектах є повний набір ролей, тому тестувальник-менеджер, тестувальник-скрам майстер, тестувальник-саппорт, тестувальник-БА — це поширено і дуже зручно. Мені, наприклад, набагато краще працюється, коли я знаю, шо вимоги до моєї таски відтестовані, і всі зауваження або прийняті до уваги, або принаймні, про них знають, а мені для цього не треба й пальцем ворушити.
And so on, може якщо буде цікавий срач в коментарях, то статтю напишу

Я не застав часи, коли таке могло б бути, але зараз якщо тестувальник не вміє писати докладні баг репорти, грепати логи, лазити в базу, не знає інспектор і як стукатися по http, то він пролітає, як фанера над парижем, а ти просто розглядаєш наступного зі 100500 кандидатів. Це, якшо шо, на джуніор (не трейні) рівень.

Якщо тест інженери вміють та знають так багато, чому ж до сих пір до них відношення як до «мануальних макак»? Не скрізь, але бачу таке у незрілих інженерів та менеджерів. (Що виражається також і в ЗП).

Згадайте, які срачі точаться з приводу юнітів, які треба переписувати на кожен рефакторинг, а тепер уявіть, скільки тестів доведеться писати на одну задачу, а потім на її фікс/доробку. Вже день очікування на qa не здається таким жахливим?)

Згоден. Але все залежить від зрілості інженера. Нормальному сіньйору не треба пояснювати, чому наприклад юніт тести треба оновлювати.

Отже, при тестуванні ніяких переваг від того, що я дев, я не відчув. Але хто слухає рандомних тіпів з доу, у ВАС точно все вийде)))))).

Ніхто ж не каже про те, шоб просто кинути таскою в розробника та наказати «а ну давай тестуй!». Для цього їх треба вчити. Та допомагати.

Не скрізь, але бачу таке у незрілих інженерів та менеджерів. (Що виражається також і в ЗП).
Але все залежить від зрілості інженера. Нормальному сіньйору не треба пояснювати, чому наприклад юніт тести треба оновлювати

Вот вы сами и указали ключевой момент — зрелость специалиста, руководителя. И зачастую такая зрелость наступает после некоторого количества «бочек съеденного говна». Тут только проблема в том, сколько кому будет достаточно, чтобы понять, что нужно как-то по-другому

Якщо тест інженери вміють та знають так багато, чому ж до сих пір до них відношення як до «мануальних макак»? Не скрізь, але бачу таке у незрілих інженерів та менеджерів. (Що виражається також і в ЗП).

ну так вы сами ответили на свой вопрос — «непрофессиональные инженеры и менеджеры не в состоянии правильно оценнить необходимость наличия профессиональных тестеров».
кстати, «мануальные макаки» — далеко не «макаки» (если, конечно, вы не использует джун куа как ранеров для тестов). Кто-то же пишет манулаьные тесты? и кто их пишет? те же мануал куа. И дело это совсем не простое.

Тобто уся наша індустрія (окрім одиничних винятків) — є незрілою? Бо ЗП тестувальників все одно нижче ніж в девелоперів)

Тобто уся наша індустрія (окрім одиничних винятків) — є незрілою?

Да. Доказательством тому может косвенно служить тот факт, что у нас нигде не учат на Software Engineer, максимум — «прикладная математика».
А если нет школы, нет обучения — о какой зрелости индустрии может идти речь? Так, кучка любителей-самоучек собрались и лабают на коленке. «Индустрии» в индустриальном понятии — нет.

Є поняття рівня зрілості компанії, а точніше процесів. Які б не біли досвідчені та зрілі розробники, якщо вони дотримуються певних процесів, то і результат буде відповідний.

Без зрелого мененджемента и спецов — не бывает зрелих компаний и зрелих процессов.
Повторюсь — у нас в стране НЕТ обучение на софтвер энжинира. все, у кого такое образование есть (и их безумно мало) — получали образование за рубежом.

Я правильно розумію, що в Україні немає софтверних компаній із хорошими — щоб це не означало — процесами?

Наверняка есть хотя бы одна. Но сказать что это «загальна практика» — я бы сильно поостерёгся.

Там впливає ще попит і пропозиція. Тестувальників потрібно значно менше ніж розробників.

Щодо мануальних макак, то це точно узагальнення. Статистично це довести не вийде

Я свічнувся з qa в дев з 3 роками hands on досвіду

я теж, але я куашив 2 роки мануал+автоматизатор.
куашив ось це саме

багатогодинні джоби з тестами, які треба постійно фіксити, і все одно перезапускати, бо шось там нестабільне впало

потім зрозумів що ні грошей тут ні цікавих тасків (ну хоть іноді) не світить и свічнувся із цього «дня бабака» у прогери.

Усе залежить від конкретної роботи в конкретній компанії.
Буває так, шо девелопер займається створенням однотипних мікросервісів з базового темплейту (із мінімальною кастомізацію).
У той час коли в тест інженера (SDET) задачі на створення нових нінащо не схожих сервісів, скриптів, іще купи усього.

Бінго! Якщо людина може працювати прогером за більші гроші — який сенс залишатися тестером?
Якщо тестер то «як прогер — тільки тупіше» (тому дешевше коштує), то хіба він може перевірити краще за розумнішого прогера?
Якщо тестер і прогер однаково розумні — то обидва можуть виконувати і тестування і програмування.

Якщо людина може працювати прогером за більші гроші — який сенс залишатися тестером?

Вірно.

Якщо тестер і прогер однаково розумні

Рівень зарплати нажаль дуже слабо корелює з розумом, попит на програміста чи інжинера та вміння проходити інтервью вирішюють. І от попит на програмістів значно більше, отже тому і зп вище.

А чому попит на тестувальників меньше я писав вище\нижче — якість дуже мало де цінується, зірвав ІРО або другий раунт інвестиці, а потім в закат з грошима, все одно через час вас викуплять або роздавлять гіганти.

Почитала: як завжди кожна жаба хвалить своє болото. Нічого нового)

Так, яле є нюанс. Команди і цілі компанії без тестерів — реальність. Команди з тестерами без прогерів ... а хто зробить продукт?!

давайте говорить правильно, не «цілі компанії без тестерів», а «компания, в которой девы выполняют в том числе функцию тестеров, в связи с ограничеными финансовыми возможностями или непониманием менеджмента необходимости тестирования»

в связи с ограничеными финансовыми возможностями или непониманием менеджмента необходимости тестирования

Грошей у MS вистачає — отже винуваті дурні менеджери.
Але якщо є гроші — чому б не брати кращих менеджерів?
А якщо таки узяли кращих — і усе одно нема тестерів ... то може кращі менеджери знайшли як обійтися без тестерів?
Виходить що тестери потрібні там, де процеси розробки ще недостатньо розвинуті!

В англомовному інтернеті купа статей та обговорень про наслідки звільнення Майкрософтом тестувальників, так як це переросло в величезну кількість критичних помилок в оновленнях на віндовс, де в прямому сенсі викочують патч на патч.

Цікаво слухати твердження про людей, які виводили мільярдні компанії на IPO, що вони не розуміють. Ок.

так мы же разговариваем про разработку ПО, а не про бизнес. причем тут те, кто «выводит миллиардные компании» к «правильному процессу разработки», собственно?

Насправді тестування це скоріше експертиза ніж виділена людина. Щоб нормально працював проект потрібна експертиза в девопсі, тестуванні, домені та програмуванні.
Нормально збалансована команда то все покриває, і по факту всі норм розробники + експерти в тестуванні або безпеці або девопсі і т.д.

Насправді тестування це скоріше експертиза ніж виділена людина.

Це мабуть найбільш правильна відповідь!
Є виділені тестери чи нема: техлид і менеджер повинні розуміти що таке тест план, які є види тестування, і знати усю теорію і тули, достатню аби працювати QA. Бо інакше вони не зможуть ані оцінити проект, а не керувати якістю.
А далі можна планувати чи будуть авто-тести, чи найняти товпу мануальних тостерів.

Минулий проект робили малою командою, без CI/CD та інших модних приколів.
Як щось написали нове, чи пофіксили кілька цікавих багів — віддаємо тестувальнику білд (зазвичай раз на 1-2 дні). Він на ньому перевіряє усі пофікшені баги, щось тестить навколо них, щоб впевнитись, що поруч нічого не зламалось, та дивиться нові фічі.

Результати:
* Lean практики, нічого зайвого — навіть без тест планів обійшлися.
* Не було юніт чи автотестів, котрі доводилося б постійно переписувати, коли змінювались інтерфейси чи ієрархія класів (там після 4 років в проді довелося переписати третину проекту).
* Асерти + досвідчений мануальщик ловлять те, про що автотести ніколи не здогадаються.
* Коли тестувальник щось зловив складне — просиш його сісти на твоє місце, запускаєш дебагер, і він ловить проблему під дебагером. Без зусиль з твого боку.
* Програмісти програмлять кожен свій шматок, а тестувальник перевіряє усе одразу, також і в релізній версії як це піде юзерам.
* Тестувальнику можна офлоадити роботу з порівняння з конкурентами, з тестування сумісності — те, що програмерам нецікаво, та на чому вони не розуміються.
* Просто людина, котра не вивчила програмування, забирає велику частину роботи з програмістів, і отримує за це менші гроші. Кожен робить, що ліпше вміє.

Як на мене проблема не в тому, що деви не можуть функціонально протестувати власний код, а в тому, що іноді не розуміють бізнес-логіки і процесів, не можуть коректно налаштувати необхідне тестове оточення (знамените «на моїй машині все працює»), не мають розуміння та уявлення про кінцевий продукт для юзера, тобто погано оріентуються в продукті в цілому.

Десятки разів чула про те, як дев здивовано відкриває для себе елементарний функціонал продукту, який він навіть не дивився, бо працював з вузькими фічами і не має в голові повної картини. Власне, продакт овнери і менеджери, тестувальники — це і є та необхідна проксі меж девом і кліентом, щоб вчасно виявити розбіжності у баченні і пофіксити їх. Бо навіть якщо код працює, кліент може не заапрувити бізнес-рішення через його незручніть або неактуальність для користувачів, поламану логіку роботи аппки в цілому. Якщо ж на проекті немає хорошого бізнес аналітика, який збирає вимоги, то роль QA взагалі стає критичною, бо це фактично єдина людина, яка продукт може оцінити з точки зору юзера.
Теоретично звісно дев може тестити, та хіба це буде доцільно, якщо тестери це роблять дешевше і якісніше, зі складанням метрик і відповідальністю за результат? Вже років 5 всі кричать що скоро мануальні тестувальники вимруть, і це вже тупо, якщо чесно. Ні, не вимруть, так само як і скрам-майстри і продакт овнери.

Як на мене проблема не в тому, що деви не можуть функціонально протестувати власний код, а в тому, що іноді не розуміють бізнес-логіки і процесів, не можуть коректно налаштувати необхідне тестове оточення (знамените «на моїй машині все працює»), не мають розуміння та уявлення про кінцевий продукт для юзера, тобто погано оріентуються в продукті в цілому.

Заради справедливості, це можна сказати про будь-яку роль на проєкті: від дева і кюа до продакт овнера з бізнес аналітиком.

Именно потому что

не розуміють бізнес-логіки і процесів, не можуть коректно налаштувати необхідне тестове оточення (знамените «на моїй машині все працює»), не мають розуміння та уявлення про кінцевий продукт для юзера, тобто погано оріентуються в продукті в цілому.

девы и не могут

функціонально протестувати власний код,

они банально не знают — а на предмет чего его тестировать то?

Якщо ж на проекті немає хорошого бізнес аналітика, який збирає вимоги, то роль QA взагалі стає критичною, бо це фактично єдина людина, яка продукт може оцінити з точки зору юзера.

Тобто використовувати QA як «зламаний телефон» замість БА аби донести до девелопера що хотів клієнт — це ОК.
А використовувати девелопера замість QA аби протести фічу — не ОК, бо він «не має в голові повної картини».
Як вже добре написали вище: і дев і QA і БА — це ролі та експертизи, а не окремі професії!
Software Engineer десь у MS — це людина, яка буде спілкуватися з бізнесом доки не зрозуміє що йому треба, потім він вирішить як ще зробити, зробить і, звичайно, зможе протестувати. Потім він ще покаже це клієнту і, можливо, напише доку як цим користуватися.
Відчуваєте скільки тут переваг? Нема «поламаного телефону», коли БА, QA, дев і юзер кожен розуміє по-своєму. Не треба мітингів аби ділитися цим знанням. А головне: тут інженер бачить усю картину і за усе відповідає!

і дев і QA і БА — це ролі та експертизи, а не окремі професії!

З такої точки зору можна тестера чи скрам мастера посадити писати продукт. Це ж просто експертиза. Там де експертиза там і професія. Тут нема ніякого розділу.

тут інженер бачить усю картину

Не завжди, і особливо на складних проектах. Бувають проекти, де жоден, повторюю жоден член команди, який би він був хоч тричі ейнштейн, не бачить всю картину системи, кожен знає якусь частину але ніхто не знає все, а будьякі зміни треба вносити максимально акуратно. І можна витратити 3 місяці щоб змінити три рядки.

One size doesn’t fit all.

Зазвичай тестерів і окремих людей на інші ролі й наймають тоді і на тому етапі, коли девелопери стають перегружені невластивими їм речами. Коли виявляється що замість робити фанкшен чи фіксити критичний баг, девелопери загрузли в якихось болотах фіксячи uat, якісь пайплайни, чи пишучи якусь технічну мутоту, чи там ганяючи тести, чи
пишучи техдоки чи патякаючи з кастомерами. Сервісний допоміжний персонал має просто розгружати час розробника. Всі інші сенси існування цих окремих ролей — фейкові аргументи як на мене

Залежить. Іноді простіше навчити розробників писати документи, ніж пояснити тех райтеру чи аналітику, що він має написати, а потім вичитати та виправити. Звичайно, верстку в спеціалізованих програмах документації чи вимог у спеціалізованій системі робить окрема людина, але якщо спеки це просто Гугл доки або навіть опис задачі в Джирі, то окрема людина на те не завжди потрібна.

Всі системи прямують до свого ускладнення. Скоріше з’являться нові професії з QA, ніж QA будуть поглинені розробниками. Хоча і будуть існувати окремі компанії, які можуть обходитися без традиційних QA.

згоден, куа не вимруть, але їх стане набагато меньше, вони будуть більш кваліфіковані і частина еволюціонує у шось про перформанс, сікюріті і інші області там де треба більше знань, а кількості куа меньше..
хоча, якщо подивитись на українське ІТ з боку скорочення проектів — то куа мають трансформуватись в СДЕТів

що іноді не розуміють бізнес-логіки і процесів, не можуть коректно налаштувати необхідне тестове оточення (знамените «на моїй машині все працює»), не мають розуміння та уявлення про кінцевий продукт для юзера, тобто погано оріентуються в продукті в цілому.

А як тоді ці деви роблять свою роботу, якщо вони не можуть налаштувати середовище й не розуміють як працює продукт?

Може буті кілька варіантів:
1. Кожна група розробників працює лише над невеликою частиною системи та їм потрібно знати лише формат вхідних даних та формат виводу
2. Використовується єдине тестове середовищє, що майже дублює прод. Тут може трапитися така ситуація, коли певних даних може не бути або їх ще треба знайти
3. Продукт має великий набір функціональності з багатьма параметрами і всі можливі співвідношення цих параметрів вже важко враховувати
4. Доменна область може бути маловідома. Тоді пишуть те, що вказано за специфікацією

На таких дуже великих проектах й тестування відбувається модульно.

Окрім модульного, ще є інтеграційне та системне тестування, коли вже ми оперуємо бізнес сценаріями. І на цьому рівні окрема команда просто не має ресурсу охопити все. Модулі протестити вони в змозі, навіть вправно це роблять. А от далі — це вже справа інших людей

А як тоді ці деви роблять свою роботу, якщо вони не можуть налаштувати середовище й не розуміють як працює продукт?

Элементарно. Модульность и так далее. Вообще нет необходимости понимать, что за продукт в целом ты разрабатываешь, как он работает и зачем.

да, последнее время это тренд, когда нет необходимости что либо понимть вообще

например — не понимать небоходимость тестирования :)

Ага, нафіга напружувати дупцю та намагатися писати код, який містить мінімум помилок. Краще тестів нафігачити побільше. Й так зійде... Мільйони програмістів не можуть помилятися...

Друг мой, вы путаете тёплое с мягким. Тестирование — это метод и инструмент получать более качественный код.
Мы все пытаемся писать код, который содержит минимум ошибок.
Однако возникает вопрос — как после этого ДОКАЗАТЬ что код не содержит хотя бы явных ошибок? Тут — либо математически доказывать теоретическую правильность кода (а вы так делаете?) — либо показывать это на тестах.

зы миллионы программистов МОГУТ ошибаться. Именно поэтому мы покрываем код тестами, чтобы находить хотя бы некоторые из тех мест, в которых они ошиблись.

Друг мой, вы путаете тёплое с мягким.

Я можу аналогічне казати про вас. Ви — типовий носій стереотипного мислення. Це не погано. Але саме воно не дає вам побачити проблему.

Тестирование — это метод и инструмент получать более качественный код.

Якщо б це було правдою, то TDD було б основою розробки всіх продуктів. Але реальний світ каже про те, що наявність тестів взагалі не гарантує ані якість коду, ані зменшення кількості помилок. Тому що тести не вирішують першопричини виникнення помилок.

Мы все пытаемся писать код, который содержит минимум ошибок.

Важливо не що ви пишете, а які підходи ви використовуєте в якості основних для свого коду. Я можу зараз вам висловити думку, яка вам не сподобається. Імперативний стиль написання, якщо він є основою вашого проекту, є першопричиною виникнення помилок. Тому що імперативний стиль, хоча й логічний, не співпадає з реальністю, а є сильним спрощенням, щоб здешевшати розробку. Почитайте мій пост про годування мешканців будинку. В імперативному стилі рішення буде складним та кострубатим, погано масштабуватися та розширюватися.

Однако возникает вопрос — как после этого ДОКАЗАТЬ что код не содержит хотя бы явных ошибок?

Ви мислите категоріями «правильно — не правильно». Побудуйте хоч раз систему, яка побудована на принципі fault-tolerant або fail-safe. Ви будете здивовані, що при цьому підході тести майже повністю втрачають сенс. В підходах, що використовую я, немає навіть гарантованої повторюваності результату, все залежить від поточного стану системи, який постійно змінюється з часом.

Именно поэтому мы покрываем код тестами, чтобы находить хотя бы некоторые из тех мест, в которых они ошиблись.

Ні, це просто звичка та стереотипне мислення.

fault-tolerant

Упаси меня боже.

Ви будете здивовані, що при цьому підході тести майже повністю втрачають сенс

если системе плевать на ошибки — то разумеется, к черту тесты. ну ошибка, и чо? :)

В підходах, що використовую я, немає навіть гарантованої повторюваності результату

Вы, надеюсь, не банковские приложения пишете? если да — дайте мне знать, я включу этот банк в черный список :)

Імперативний стиль написання, якщо він є основою вашого проекту

Скуль, декларативный. Всё равно нужно тестировать, что ты там надекларировал.

що наявність тестів взагалі не гарантує ані якість коду,

Точно так же как наличие замка на двери не гарантирует безопасности, но значительно её повышает.

ну ошибка, и чо?

В таких системах немає явних помилок.

Вы, надеюсь, не банковские приложения пишете?

Вас цікавить тільки це? Не цікавить, як взалалі можна вести розробку в таких умовах? Стереотипне мислення в дії. Я не розумію — значить воно апріорі невірне.

Точно так же как наличие замка на двери не гарантирует безопасности, но значительно её повышает.

Знижує тривожність у власника. А безпека там взагалі не при справах

Вас цікавить тільки це? Не цікавить, як взалалі можна вести розробку в таких умовах? Стереотипне мислення в дії. Я не розумію — значить воно апріорі невірне.

Ну, «не только это». но вы то не ограничили область применимости подхода «тестеры не нужны», поэтому я делаю вывод что вы считаете что «в банковской сфере это тоже подойдет».

Знижує тривожність у власника. А безпека там взагалі не при справах

Скажите, а у вас на двери есть замок?

Якщо ви візьмете АБС (автоматизована банківська система), то під капотом ви знайдете три математичні операції (складання, ділення та множення), купку рахунків та доволі прості скрипти, що коли робити. Це все. Примітивно, що двері. Вгадайте, хто «скрипти» пише або може писати? А там дофігаліарди грошей у-у-у-у-у....

Скажите, а у вас на двери есть замок?

Є, але не для того, щоб унеможливити несанкціоноване пронекнення до оселі сторонніми особами.

Якщо ви візьмете АБС (автоматизована банківська система), то під капотом ви знайдете три математичні операції (складання, ділення та множення), купку рахунків та доволі прості скрипти, що коли робити. Це все. Примітивно, що двері.

ну, еще там есть специальный вариант округления, как минимум
огромная пачка правил, огромная пачка кода для параллельной работы, транзакционность (ну и по самой сути транзакционность — оно из банка пришло), надёжность и так далее.
Не знаю как кто, а лично я бы не хотел пользоваться банковской системой, написанной человеком, который заявляет «просто не надо делать ошибок!». Хотя банковского кода я повидал немало. И, к своему ужасу, немало пообщался с разработчиками из банков. Меня тогда так накрыло, что я года три потом пользовался только наличкой, которую снимал в кассе у живого кассира.

ну, еще там есть специальный вариант округления, как минимум

Розробники не чули, що копійки можна множити на 1E6, наприклад, та саме так зберігати значення? А, точно, ми ж про «правильних» розробників ведемо мову, які канонічно тестують.

огромная пачка правил

Це все скриптується.

огромная пачка кода для параллельной работы

До чого тут це, не збагнув.

транзакционность

А тут які складнощі?

Не знаю как кто, а лично я бы не хотел пользоваться банковской системой, написанной человеком, который заявляет «просто не надо делать ошибок!»

Ви неправильно розумієте те, що вам кажуть. Я кажу, що замість того, щоб прикриватися тестами, треба йти геть від них. А для цього у вас є ціла низка рішень, які дійсно покращують якість коду.

В якій системі простіше допустити помилку, в простій чи складній? Якщо ваша відповідь «в простій», то чому ви ускладнюєте систему тестами?

Розробники не чули, що копійки можна множити на 1E6, наприклад, та саме так зберігати значення? А, точно, ми ж про «правильних» розробників ведемо мову, які канонічно тестують.

Что, простите?????

В якій системі простіше допустити помилку, в простій чи складній? Якщо ваша відповідь «в простій», то чому ви ускладнюєте систему тестами?

Мне кажется — или вы допустили ошибку в своём утверждении?

Что, простите?????

Що саме вам не зрозуміло?

Мне кажется — или вы допустили ошибку в своём утверждении?

Вірно, я забув додати «не». Правильно фраза звучить так

В якій системі простіше НЕ допустити помилку, в простій чи складній? Якщо ваша відповідь «в простій», то чому ви ускладнюєте систему тестами?
Що саме вам не зрозуміло?

Зачем «копейки множить на 1Е6 и так хранить?
Чтобы что? У вас в банке есть суммы с точностью более 0.001? (в случае ливийского динара, например)

Вірно, я забув додати «не». Правильно фраза звучить так

А вот если бы был тестер (в литературе это называется «корректор»), то эта ошибка не была бы опубликована.
Зачем вы делаете ошибки в таких простых предложениях? Просто не надо делать ошибки.

Зачем «копейки множить на 1Е6 и так хранить?

Щоб зберігати в базі цілі числа, а не float’и. Та уникати ситуацій, коли 19.9 * 100 = 1989.9999999999998

А вот если бы был тестер (в литературе это называется «корректор»), то эта ошибка не была бы опубликована.

Ви не бачили книжок, які містять errata наприкінці? Я — бачив. Так що наявність коректора не дорівнює безпомилковості.

Зачем вы делаете ошибки в таких простых предложениях?

Спеціально, щоб вас дратувати. Очевидно ж! :D

Щоб зберігати в базі цілі числа, а не float’и

Mother of god!

Ви не бачили книжок, які містять errata наприкінці? Я — бачив. Так що наявність коректора не дорівнює безпомилковості.

Видел. Я не настолько молод, как кажусь
И да — наличие корректора не даёт 100% гарантии, но значительно уменьшеет количество ошибок.

Mother of god!

В цьому є свої бенефіти. Float — дорога річ.

но значительно уменьшеет количество ошибок.

Таке собі твердження. Ми не знаємо статистики, скільки помилок було, скільки залишилося. Але це повністю підтверджує мої слова, що наявність коректора (тестів) не гарантує на 100% відсутність помилок та не покращує книгу (код)

В цьому є свої бенефіти. Float — дорога річ.

Может я, конечно, не прав. Но я бы использовал для хранения сумм тип money, предназначенный, как бы это банально не звучало, для хранения денежных сумм. это на скуле.
в более general случае я бы использовал что-то вроде decimal(22,4).
А не придумывал бы себе проблему с флоатом и потом георически решал бы её костылями с умножением на миллион(?) (шта???) и хранением их в int4 (я же правильно понял, — хранить надо не во флоат, в котором всё равно будут неточности, а в чем-то типа int4?)

А як ви думаєте, в якому типові даних зберігає база тип money та decimal(22,4)?

Таке собі твердження. Ми не знаємо статистики, скільки помилок було, скільки залишилося. Але це повністю підтверджує мої слова, що наявність коректора (тестів) не гарантує на 100% відсутність помилок та не покращує книгу (код)

Вы меня конечно извините, но после «храните суммы в копейках», «флоат для денег» и так далее я весьма скептически отношусь к вашей экспертизе.

Та мені чхати на вашу думку та ваше ставлення.

Я привів приклад того, що оті ваші особливі алгоритми округлення — вони через інші проблеми, які спричинені третіми умовами. Ланцюг проблем. Якщо систему змінити, змінити базові умови, то проблему можна й не отримати. Це як гугл спростував, що послідовне виконання коду не можна прискорити додаванням ресурсів чи виконавчих блоків.

Якось був в одній компанії на інтервю, то вони сказали, що спецом не наймають QA аби деви не просто писали код, а розбирались в продукті, щоб не було зламаного телефону та щоб весь продукт новеледж був не девах. Не знаю нащо тримати таких девів, які не розбираються в продукті, чи не тестують нормально віддаючи на QA чи взагалі не тестують і не запускають свою фічу локально). Нормальний розробник зможе і потестити і з бізнесом порішати. Ну так, але мабуть коштувати він буде дорого. того багато хто обирає шлях найняти замість одного чотирьох і це буде дешевше.

Мені здається варіант замість одного наняти чотирьох завжди більш безпечний і зручний, ніж взяти одного або двох дуже дорогих девів. Бо якщо той дев звільниться то буде біда, плюс більше членів команди дає можливість делегувати таски і краще розподіляти роботу. Всім треба ходити у відпустку іноді і когось замість себе залишати і так далі.
Ну і тестувати і рішати з бізнесом теж не всі деви люблять і можуть, більшість хоче просто кодити і після чеку, що код працює віддавати фічу і починати щось інше, не забиваючи собі голову глибоким тестуванням і презентацією для замовника. Але звісно інколи це призводить до того, що деви погано знають продукт в цілому і не дуже розуміють цілі бізнесу, бо наприклад код працює, але в якому контексті він працює і що дає юзеру — вони вже слабо розуміють.

Як на мене, вже через 5 років ШІ буде той програміст який зможе у все IT. Навіть у девопс.

Угу, нам в інституті в кінці 90х викладачка так і казала.

Було декілька проєктів на аутстафі по ось таким принципам — погромізд робить усе — і тестує, і деплоїть...у всих проєктах як на підбір найлютіша дічь, та упоротий гівнокод, купа глюків, платили дуже гарно але працювати там ніхто не хотів :-)
...Тестувальник це не обовязково мануал куа, а ще і автоматизація, і підготовка тестових данних для тестів...Тестування це не юніт тести та джира з багами, це в першу чергу процес контролю якості у програмобудуванні яки є дуже складним процесом
Дух стратапу це круто але чим далі ти тестування більше а ціна за баг збілщється на порядки, так на порядки.

Нажаль створення програм зараз це гонитва за юзерами(апдейти заради апдейтів), розпилом амерканських бюджетів, інвесторами, IPO, ROI, але нія не про якість, і від цього стє все більш сумно та просто нудно від того що вся ідя програм це збирати дані, показувати рекламу та 100500 методів змусити тебе підписатись та посидітии за апкою ще.

Працюю без тостерів з комплексними юніт-тестами та інспекцією коду, зникло купу юзлесс комунікації та ніхто не вмер після багів, треба всього-лиш досвідчених та відповідальних колег та фідбек від енд-юзера. Хоча деяку частину комплексного тестування інфри віддаємо на аутсорс, але не дуже часто. В штаті тримати тестувальників не потрібно, принаймі мануальних. В аутсорсі тестувальники будуть завжди, бо кожне тіло білається.

Все залежить від конкретного проєкту. Але я радий, що у вас тестувальників немає. Просто роль — розподілена між усіма інженерами.
Без ролі та поставлених процесів усе це не заведеться та не поїде.

та ніхто не вмер після багів

Была чудесная книжка, про инженерные ошибки и такое прочее.
Там описывался случай, когда обнаружился баг в установке лучевой терапии для лечения рака облучением. И вы вот не поверите......
зы баг там, кстати, был из разряда «странно, всё делаю по мануалу, внимательно, не спеша, не делая ошибок — всё работает. а в проде почему-то пациенты не выживают после облучения....»

А там був аналіз того, чому помилка дійшла до продакшену?

Якщо я правильно пам’ятаю, то фундаментальна помилка там у архітектурі всього пристрою. Попереднє покоління мало і софтовий і залізний запобіжник перемиканню «слабких» та «жорстких» режимів для різних процедур. А в новому поколінні залишили тільки софтовий запобіжник. А далі справа за простим багом, кі трапляються всюди.

Тут детальна інфа якщо цікаво:
en.wikipedia.org/wiki/Therac-25

да, именно оно самое. ПРоблема была банальной, если правильно помню: опытная медсестра при настройке аппарата клацала по кнопкам с такой скоростью, что ПО (в котором была банальная, но ФУНДАМЕНТАЛЬНАЯ ошибка) не успевало среагировать на выставленный флаг — и включало неправильный режим облучения.
В старой версии аппарата дополнительно был тупо «механический железный засов», который просто не позволял аппарату выполнять такое действие (блокировал раскрытие шторой при рентгеновском облучени)
А вот инженера-производители и прочие, когда проверяли/тестили аппарат — они ВДУМЧИВО ВНИМАТЕЛЬНО клацали по кнопкам. медленно. и ПО — успевало заметить флаг и правильно настроить аппарат.
Вспомнилось, кстати — лет 20 назад я точно так же нашел ошибку в одном мс продукте — я ОЧЕНЬ БЫСТРо с ним работал, продукт не успевал за мной и т.к. был построен НЕПРАВИЛЬНО — то он запускал действия с опозданием, выполняя операции не над теми объектами.

Якщо ШІ буде видавати код то потрібні будуть у більшості саме тестувальники. Гг.

ШІ може й сам постестувати, кастомера теж можна посадити в чатік з ШІ.

Зробити з чатботів команду, по аджайлу, які будуть між собою спілкуватись, з ШІ-скрам мастером

Код пишеться, тестується, тести тестуються, тесті тестів теж, вимоги обговорюються, кастомер уявляє що з кимось говорить.

Якщо через місяць хтось заплатить, можна зразу виходити на IPO

Сінгулярность

Хтось має дослідити яка імовірність що піщинки на пляжі зберуться в красиву пасочку

Тільки вони всі чогось думають що без нейронок це не можна зробити.
Якби були інвестиції можна було б спробувати без нейронок, накопичити логіку створення коду та видавати його на query вимогу
Я гадаю що логіка це щось частотне. Тобто можна дослідити залежності.
Ось, наприклад, речення іноді закінчується крапкою. Щось розділене крапками може бути кількома реченнями.

Ох! Правда! У цьому щось — пробіли зустрічаються із частотою К а букви із своїми частотами.
Тобто все це дасть нам якусь картину частот. І це буде якесь речення.

Імхо, але мануальні qa в більшості випадків створюють більше проблем, ніж користі в тих кейсах, де їх може замінити автомейшн qa ( тобто веб проекти і т д, а не різний хардвар).

Зі свого досвіду : перше чекаєш вічність на код ревю, потім вічність на куа, який найде якусь хрінь, яка не була в ТЗ і не пропустить твій пр, поки менеджер не підтвердить, що то не в скоупі таски.

А скільки разів у нас щось на проді падало, хоч і qa ніби то затестив все...)

Інше діло з автоматизованими тестами : код ревю, пройшли тести — деплоїм. Часу займає в рази менше, надійність в рази вища (так як немає людського фактору, що хтось забуде щось протестувати вручну).

Взагалі замітив, що в європейських і американських проектах, де я працював, деви відповідальні покрити свій код юніт тестами і відповідають за свою фічу. З мануал куа, як з БА, срам мастерами і т д зустрічався лише на аутсорсі, де галери доїли замовника :)

Ну крім юніт тестів, які дев має писати звісно, є ще купа всяких інших речей, як таких що автоматизуються за притомний час, так і таких де автоматизація буде ледь не стільки ж коштувати як сам проект. Можливо нерозуміння цього або відсутність цих речей чи вимог до якості і приводить до нерозуміння нащо ці тестувальники

Десь тестувальники не треба, бо аби швидше зарелізить, а десь дев написав 30% покриття, і пішов робити наступне, а решту % дописує тестувальник. Десь інтеграцію робить, десь хтось реліз тестує день з девопсами чи й сам

Підхід затикати всі діри девами, і тести пописати, і на мітингах посидіти, і порелізить, і проклацать, і подеплоїть, і вночі прокинутись, це проекти які або багато відповідно за цю універсальність платять (що цілком можливо і є досвід автора статті з МС) або звідки валять в місця менш стресові.

і таких де автоматизація буде ледь не стільки ж коштувати як сам проект

Це те що я і мав на увазі тут —

в тих кейсах, де їх може замінити автомейшн qa ( тобто веб проекти і т д, а не різний хардвар

Мені важко уявити веб круд проект, де треба мануального куа.

а десь дев написав 30% покриття,

Сорі, але це фігня. Дев має 100% відповідати за свою фічу, а не «ой, у мене лапки». І це нормально, що дев десь може накосячити, наявність куа не гарантує, що той косяк не вилізе на проді.

і порелізить, і проклацать, і подеплоїть

Не спорю, проекти ( знову ж таки, не односторінкові круди) де немає девопсів — зло. Я, правда, ще таких в природі не бачив. В всіх ± серйозних проектах були девопси.

Дев має 100%

Це не завжди можливо і не завжди має сенс

В ідеалі по книжці так

В реальності буває, що основний функціонал покрив дев, а корнер кейси може покрити куа або джун, якісь тестові дані нагенерує, бо основний беклог сам себе не зробить, щоб покрити ідеально одну таску. Ну або це можуть бути якісь кнопочки, чи ще якась мутота

Не подобається 30, хай буде 60, не в цифрі суть

Якщо хоч з іншого боку мою тз, то «страшну річ»

Most software teams do not need dedicated testers anymore

треба написати як

Some software teams do not need dedicated testers anymore

І в мене питань не буде ;)

В реальності буває, що основний функціонал покрив дев, а корнер кейси може покрити куа або джун

Он в мене так і було. В результаті — пишеш код з оглядом лише на основний функціонал, тримаючи в голові, що куа потім потестує, найде факап — ок, поправимо код. В результаті чекаєш вічність рев’ю, вічність поки куа потестує, який найде один баг і 100500 висосе з пальця ( що потім менеджер заверне), робиш за пару хв фікс, знову чекаєш вічність рев’ю і тестування, в результаті умовна проста кнопка попадає в білд за фіг знати скільки днів :)

Або гірше — пишеш код з оглядом лише на основний функціонал, тримаючи в голові, що куа потім потестує, найде факап — ок, поправимо код.Куа прошльопав нормально потестувати, пішло в прод, виліз баг на проді, менеджер двом виписує :)

Інше діло коли ти знаєш, що раптом шось завтикаєш — випишуть саме тобі :) намагаєшся зразу зробити все по красоті ( не завжди виходить, але це вже інше питання).

Це за умов, що проект адекватний, де естімейти враховують тестування і т.д.

Або навпаки, поки довів фічу до ладу, покривати усіляки вичурні кейси від юзерів уже просто нудно і хочеться скоріше взяти іншу, таску бо від старої тошнить :-)

Однозначно, завжди цікавіше ковбасити різноманітні таски, а не одну фічу місяць пиляти, але я не з боку інтересу говорю :)

Факт є факт, з власного досвіду знаю що потім якість роботи помітно падає, хоч який би ти не був мотивований.

для вирішення цієї проблеми існують петпроджекти й редіт ^_^ Звісно, якщо проект адекватний, де естімейти враховують тестування і т.д.

Про косяк на проді — відкрию вам секрет з самих священних скрижалей QA. Ми не робимо нашу роботу, щоб доказати що багів нема. Навіть, коли ми все закінчили, то нахабно стверджуємо ’так, воно скоріше за все забаговане, але я дозволяю деплоїти’. А ще в нас записане, що всю відповідальність ми все одно ділимо порівну з командою :)

Неможливо за один і той же час і запрограмувати і протестувати.
Додайте регресивне тестування, інтеграційне і що там ще...
Тестувальник це професія.
Розробники можуть гарно тестувати — якщо їх навчити — а це теж час.
Але тоді виходить таке: розробник, який буде ще й і тестувальник повинен на розробку вимагати вдвічі більше. А може й втричі, бо навчання.
Часу вимагати. Втричі більше часу. Тому й і існує розподілення робіт що при розподіленні скорочуються витрати часу.
А якщо напроти все від одного і за найменший час вимагати то ніякої якості не буде.

Але тоді виходить таке: розробник, який буде ще й і тестувальник повинен на розробку вимагати вдвічі більше. А може й втричі, бо навчання.

Тільки про це написав:
dou.ua/...​rums/topic/41493/#2545700

Якщо вміло використовувати test-driven підхід то мабуть час розробки таки скоротиться.
Але потрібно вміти у таке, а це потребує навчання, та потребує пошуку таких універсальних спеціалістів. Простіше та швидше набирати окремо звичайних девів та тестувальників.
Бо таки можна і UX попрохати дева створити.
А тоді, побачивши, що все це у голові людській ніяк не вміщується одночасно, винайняти ШІ
Тому мій висновок такий — ця стаття це заказуха від ОпенЕЙАЙ
Бо ОпенЕЙАЙ це як 10000 голів і тому там і дев і тестувальник і дізайнер — всі помістяться.
Якщо вже вони всі не там...

А тоді, побачивши, що все це у голові людській ніяк не вміщується одночасно, винайняти ШІ

Смішно! А хто навчить той ШІ якщо людина не може? Поки що ШІ може лише те, чого його навчили люди (і навчання це — дуже не просте).

Людина може. Але одна може у дев. І ось вона прийде до ШІ і навчить тільки деву.
Друга може у тест-драйвен. І вона навчить ШІ тільки ТД
Третя може у уікс. І навчить.
Четверта ...
...
10 000
І ось так у ШІ з являться 10 000 голів.
Одна людина не може все і не повинна все. Краще вже у чомусь одному майстерність або у суміжних або у тому що найбільш їй підходить і смакує. І все це тільки трошки — бо витрати на відшкодування ізносу універсальної людини будуть дуже великі
Універсал у усьому просто виграє еволюційне змагання. Тому природа не дозволяє універсалів. Бо це порушення закону розподілення маси енергії інформації

Універсал у усьому просто виграє еволюційне змагання. Тому природа не дозволяє універсалів.

Ні — бо універсал буде завжди гірший, ніж спеціаліст. І програє спеціалісту еволюційний відбір.
Аби виживати — вид має бути у чомусь кращій за інших: чи то бігати швидше всіх, чи то ховатися, чи мати броню.

Якщо ми з тобою промоделюємо наші концепції, то побачимо які умови ми обираємо щоб бути правими у наших твердженнях.
Кожна людина має на увазі своє і тільки моделі стандартного формату дозволяють побачити те саме світло у кінці тунеля.

Часу вимагати. Втричі більше часу. Тому й і існує розподілення робіт що при розподіленні скорочуються витрати часу.
А якщо напроти все від одного і за найменший час вимагати то ніякої якості не буде.

А ще більш ефективно буде, коли одна людина буде запускати IDE, інша писати код, наступна комілювати, потім окрема людина пофіксить юніт тести, окрема людина зробить деплой — і буде справжній конвейер. Тейлор був би щасливий!

Але демографічний тиск все це складає на одну людину. Може нам регресувати трохи цей прогресс? Проте для цього мабуть прийдеться відмовитися від шаленої мрії про технологічне довголіття.

Так — але для цього кожній людині треба розповісти що робити. Конвейер працює коли треба робити однакові продукти щоразу. А в ІТ навпаки — щоразу інше.

Кидати девелоперів робити qa — все одно що посадити хірурга в аптеку вітаміни продавати

Чому б архітекторам і сто теж тестплани не поганять раз такий кампот. В команду з 5 сіньор архітектів тестувальники теж не потрібні, тільки хто таку вечірку оплачуватиме?

Ну хіба напевно якщо потенційний qa хоче як дев, то краще взяти в команду дева який і буде й тестувати, але хто притомний дев на таке підпишеться?

Тобто тестування це не технічна професія, завдання якої — тихо клацати однотипні сайти за 200 баксів все життя?
Велью приносять виключно їх величності девелопери?:)

Велью приносять всі, питання у пріо і ефективності витрат, які обмежені, грошей і часу

Але коли треба проклацати якусь апку чи інтеграцію, можна витратити на це годину дева, або годину студента.

В світі з безкінечними бюджетами, дедлайнами і безкінечними чергами кваліфікованих розробників, звісно краще набирати виключно побільше разрабів з 20 роками досвіду і садити їх писати кодити тести

Тобто тестування це не технічна професія, завдання якої — тихо клацати однотипні сайти за 200 баксів все життя?

Доки QA згодні працювати за 200 баксів — їх ніхто не замінить! Але як тільки вони захочуть 2000 баксів — виявиться що автоматизація, чи навіть роботи щоб «клацати» — дешевше. Бо їх налаштував один раз — і далі вони перевіряють кожен реліз безкоштовно.

Автоматизація ніколи не працює у вигляді «один раз написав та працює». Якщо б так і було — той нафіг девелоперів наймають на підтримку — там жеж також «один раз написав і працює».

Доки QA згодні працювати за 200 баксів — їх ніхто не замінить! Але як тільки вони захочуть 2000 баксів — виявиться що автоматизація, чи навіть роботи щоб «клацати» — дешевше. Бо їх налаштував один раз — і далі вони перевіряють кожен реліз безкоштовно.

1. кто настроит автоматические тесты? напишет тест-кейсы? Девелопер? Никогда в жизни.
2. с каждым релизом продукт меняется, меняются, добавляются и удаляются фичи — следовательно, меняются автотесты. Кто будет менять автотесты? Девелопер? Он не умеет тестировать.

Знову цікаве питання: якщо девелопер не може тестувати, не може писати і правити авто-тести, а тестувальник усе це може — то чому ж девелоперу платять більше?!
При цьому тестувальник девелопером бути чомусь не може — інакше давно б перейшов на більшу зарплатню.
І якщо вже йому більше платять — то може девелопер таки може навчитися і тести, якщо ще грошей додати? Чи тестувальник зможе навчитися девелопити аби отримувати як девелопер?

Знову цікаве питання: якщо девелопер не може тестувати, не може писати і правити авто-тести, а тестувальник усе це може — то чому ж девелоперу платять більше?!

Уже говорили — «в связи с непрофессионализьмом менеджмента» ©

то може девелопер таки може навчитися і тести, якщо ще грошей додати?

Нет. просто разный, грубо говоря, темперамент.

Нет. просто разный, грубо говоря, темперамент.

Ну в ручну я б, звичайно, не тестив — здурів від нудьги. А от написати авто-тести — це цікава задача для девелопера. Особливо якщо тестувати свій код.
Ще тішить, що кожен авто-тест потім буде стояти поперек горла бовдуру — гівнокодеру, який полізе псувати мій код. Він утулить костиля — а тут йому 10 тестів впаде!

У вас дані застарілі) Заради цікавості подивіться вимоги до сучасних куеїв. Тупо клацати сайти — такого нема уже років 7(про винятки знаємо) кожна вакансія вимагає як не js так пайтон чи сі. Вже не кажучи про різноманітні інструменти.

такого нема уже років 7

о підняв очі і бачу 5 кнопкодавів
сидять

Нащо Ви так про розробників. Ми ж усі в одній галері.

І люди, які відповідають цим вимогам згодні на 500 баксів?
Кажіть що хочете: але я ніколи не повірю що QA за 1000 баксів перевіре краще, ніж девелопер за 2000 баксів. Як то кажуть «якщо ти такий розумний — то чому не багатий?»

початківці і на менше згодні) а досвідчені — хз. щодо того що девелопер краще зробить, тут теж є нюанси типу «око замилене», "суб"єктивність щодо своєї роботи", витрата лишніх коштів(як на 2-4 куеїв)

Є така штука як ринок. Саме тому ембеддед чи екзотичні та наукоємні сфери в аутсорсі отримують стільки ж чи менше грошей ніж фронтендер який навчився кліпати однотипні проєкт на чомусь модному. Може вони отримують менше тому що фронтендер дуже розумний, а вони тупіші?)

Тут нема змагання, хто краще. Тестувальник використовує інші підходи, яким спеціально вчать. Тим підходам можна навчити і девів. Але нахріна? Якщо за той же час він може навчитись більш складних девовських скілів. Тестувальникам платять менше, бо їх тупо більше на ринку праці, більше конкуренція, тягнуть цінники вниз.

Без девелоперів нема що тестувати.

Без продактів нема ідеї — нічого кодити.

Ну хіба напевно якщо потенційний qa хоче як дев, то краще взяти в команду дева який і буде й тестувати, але хто притомний дев на таке підпишеться?

Жоден дев не буде повторювати тести руками! Він один раз напише автоматизацію — і буде міняти якщо треба.

Буває доволі багато over-engineering від девелоперів. Як у жарті “this script that takes to run 5 seconds needs to be automated. Let’s spend three days to automate it”.

Теж пойнт, бо на диво багато в світі речей робляться в екселі чи скріптом за пару хвилин дешево й сердито ніж автоматизувати й мудрувати ідеальне

Ну от у вас побіг тест. І девайс здох посеред тесту. У білді три різні комміта в п’ять пакетів. І далі що будете робити без повторювання тесту вручну?
ПС: і хто буде вручну рекаверити залізяку до робочого стану?

ПС: і хто буде вручну рекаверити залізяку до робочого стану?

www.mobot.io

Чому б архітекторам

якраз їм буде корисно, ніж просто язиком триндіти. Хоч якась користь.

Ну що за чос.

Кожен займається своїми речами в своїй області, відповідно до досвіду й знань

Якщо від архітекта треба «хоч якась користь» то звільняйте архітекта і найміть студента. Тіки потім не жалійтесь що через рік все чогось поламалось і ваш студент утік на блятки, а архітект ваш у конкурента

Архiтект, який сам не пише код, неминуче втрачає зв’язок із реальністю та перетворюється на чувака в баштi зі слонової кістки.
Виключень майже не бачив.

Dedicated architect — в топку, Staff — так

Це просто з пустого в порожнє
все це специфічно до проекту звісно
але 10 років знань про всю систему, в якій помінялось вже надцять разрабів мають набагато більше ваги ніж якийсь контролєр, рест ендпойнт, таблиця чи спінер в юай

але 10 років знань про всю систему, в якій помінялось вже надцять разрабів

Дуже важливий чувак для бiзнесу, бо документації нема у свiтi, де личку синьора дають за тупе закриття тасочок у джирi, а думати далi

ніж якийсь контролєр, рест ендпойнт, таблиця чи спінер в юай

не звикли, бо є той самий застарiлий архiтект xD

дядя цінитель з нуля читати написану 2 роки тому неповну і невідомо якої актуальності документацію і родити з неї щось на завтра?

В якому ідеальному світі ти живеш?

У реальному свiтi ваш архiтект може завтра звiльнитися чи бути збитим автобусом. Далi що?

Подивiться на так званий big tech. Solutions Architects так, присутнi, але вони займаються дещо iншим. Є стафи та принципали, якi продовжують писати код та бути IC. Зато в аутсорсах тих архитектiв як блох на собацi.

Ну в кндр теж демократична республіка, але ж ми не обговорюємо демократію в контекті кндр мабуть?

Одиноких архітектів одиницями не тримають, зазвичай це костяк ключової команди, але буває по всякому, хтось може й на одну людину молиться, і втратити її — головняк на роки

Щоб бути костяком — треба писати код, а не тiльки триндiти та малювати.

Ну я то згоден, але відірвані ряжені архітекти це ж твій аргумент, а не мій :)
Я про архітектів які соплі не жують

Я ж саме про ряжених

Архiтект, який сам не пише код, неминуче втрачає зв’язок із реальністю та перетворюється на чувака в баштi зі слонової кістки.
Я про архітектів які соплі не жують

А до цiх питань нема

Чому б архітекторам і сто теж тестплани не поганять раз такий кампот.

Так там так і написано:

тільки сам замовник знає, що йому потрібно (та може сказати чи якісний софт чи ні)

Тобто, нехай замовник сам тестує xD

Може замовник ще й сам собі напише й заплатить тоді ;) набіса ж цей непотрібний фудчейн

Ну хіба напевно якщо потенційний qa хоче як дев, то краще взяти в команду дева який і буде й тестувати

Дев не умеет тестировать, по определению. Если бы он умел тестировать — он пошел бы в тестеры.

Дев який не вміє тестувати, шось не віриться. Як же він зарепродьсить багу :) хоч якийсь мінімум має вміти, гнать треба в шию якщо не вміє

Але на професійному рівні то ні, і завжди є девелоперський bias теж. Чомусь ніхто про це не згадав здається до речі

Як же він зарепродьсить багу :)

Используя репро в описании бага, разумеется.

хоч якийсь мінімум має вміти, гнать треба в шию якщо не вміє

минимум — разумеется. но «минимум» єто не «я умею тестировать».

омусь ніхто про це не згадав здається до речі

как это?
Вот же, черным по белому.
"

Дев не умеет тестировать, по определению

"

Если бы он умел тестировать — он пошел бы в тестеры.

Навіщо? Щоб меньше платили?

Бачили ми таких хірургів, коли пацієнт приходив після операції в аптеку жалітися, що щось не так, щось довго бочок болить. І аптекар подивившись такий ’o kurwa mać’ - робить ще одну порожнинну операцію, щоб наприклад видалити забутий затискач. Або перепришити палець з руки з шістьома пальцями, на руку з чотирма.

А ще прибиральниці та офіс-менеджери не потрібні. Розробник сам може)))
Мені здається це досить радянський підхід, коли ти все робиш сам, а потім раптово вигораєш(ой а хто ета здєляль?)

А ще прибиральниці та офіс-менеджери не потрібні.

Так — зараз навіть офіціантів міняють на роботів. Це прогрес — ручну роботу вигідніше доручити роботам. Людський мозок не потрібен аби вимити підлогу.

Залишилась дрібниця — написати код, який буде керувати роботом, що нормально прибирає якесь непрямокутне приміщення з меблями. І ок, на першому етапі можна навіть без переміщення самих меблів. )

Бажано такий код який дасть скіл не жувати кабелі за 100 баксів(((

А на звільнений час можна прийти додому ... І зробити якусь DIY-хрінь, або полуницю на балконі виростити, або раком півдня на дачі провести. Прогрес! :)

Розробник сам може)))

Помним-помним:

Да, на кухне не было мусорного ведра. Но мусорные пакеты с собой приносить/выносить не обязательно — лично я просто втихаря сбрасывал свой мусор в пакет Дани.

ну так а в ідеальному скрамі ж і нема тестувальників. є фулстак девелопери які і бек і фронт і тести вміють.
але завжди все стопається в бюджет. бо фулстак який вміє і в кодінг і тести коштує як два дева і тестувальник разом :D

та і взагалі професію тестувальника дещо спотворили на ринку, адже зараз коли говорять про тестувальників досі думають про мавпочку що клікає на кнопки. не знаю коли це кліше зʼявилось але це прям дико бісить і через це спотворення професії багато девелоперів також деградували. і на питання чому ви не пишете юніт тести відповідають «так у нас же тестувальники є». це антипатерн.

перше, це те , що тестувальник повинен бути ІНЖЕНЕРОМ. вміти програмувати, вміти розуміти архітектуру, алгоритми, та процеси.
а друге — гігієна розробки продукта повинна бути на всіх рівнях — вимог, кодування та тестування.

ну і знову вертаючись до теми статті — так, тестувальники не завжди потрібні. є команди де вони будуть навіть зайвими. але є і інша сторона — є проєкти де тестування це перевірка дуже базови сценаріїв та обмежений бюджет клієнта і вигідніше буде туди посадити окремого тестувальника ніж витрачати вдічі дорожчі часи на розробника.

Це і є секрет. Компанії типу MS можуть дозволити собі набирати у команди ВИКЛЮЧНО інженерів! Інженерам не потрібні манкі-тостери, не потрібні менеджери — погоничі, не потрібні якісь ментори які будуть показувати пальцем що робити. І так: синьор з MS команди зможе і фронт, і бек, і тест ще й девопс.
Але галери добре якщо можуть поставити одного інженера на проект. А решта — то вайтишніки.

Але продукти MS гівняні, такі можливості не зробили їх якісними.

серед тех гігантів у MS найбільший відсоток індусів =)

Так, можна уявити собі набагато кращі. Але майже увесь великий бізнес побудований на цих продуктах і працює роками.
MS, який бачать звичайні юзери — це тільки надводна частина айсбергу. Саме тому MS завжди на плаву і не залежить від моди на айфони чи соціальні мережі. Це як той 1С, який можуть забороняти скільки завгодно, але бізнес вже без нього жити не може.

Інженерам не потрібні манкі-тостери, не потрібні менеджери — погоничі, не потрібні якісь ментори які будуть показувати пальцем що робити.

Спасибо, посмеялся :)
представил себе, скажем, майкрософт офис, написаный инженерами без манагеров :)
Ну и без тестов, разумеется.
Помнится, из истории, MS SQL Server 2005 должен был называться MS SQL Server 2003, но у «инженеров» (неплохих, кстати) — что-то не заладилось.
Пока не пришел новый менеджер, «показал пальцем что делать» — и продукт был таки выпущен.

ну так а в ідеальному скрамі ж і нема тестувальників

Перепрошую, але де саме ви прочитали про такий «ідеальний скрам»? :)

Нібито, по класиці у команді повинні бути присутні усі ролі (back, front, qa, devops...) — як протидія підходу, де є окремо відділ розробки, відділ тестування, відділ сисадмінів, які НЕ співпрацюють між собою як єдина команда.

тестувальники не завжди потрібні. є команди де вони будуть навіть зайвими

Цікаво було б побачити якісь приклади. Бо мені на думку спадає хіба що пиляння якогось MVP, цільова аудиторія якого — півтора інвестора, яким можна показати добре відрепетований демо-сценарій.

Трішки підкорегую вас. В суті/цілі/визначенні скраму полягає ідея того, що БУДЬ-ЯКУ ЗАДАЧУ може виконати БУДЬ-ЯКИЙ ЧЛЕН ДЕВЕЛОПМЕНТ ТІМИ( немає ніяких фронт бек куа девопс мобайл і тд.). У скрамі є тільки 3 ролі — девелопер, скрам майстер та продакт овенр.
Можете ознайомитися з офіційним документом scrumguides.org/...​rum-guide.html#developers там в принципі все розписано про ролі і обовʼязки :) а також про те як відбувається планування ітерації та як розподілення задач відбувається. інакше ви отримуєте не чистий скрам, а його варіації-мутації(як хороші так і погані) :)

Цікаво було б побачити якісь приклади. Бо мені на думку спадає хіба що пиляння якогось MVP

абсолютно ні. Наприклад, розробка складного ембедед, розробка SDK-рішень, розробка бібліотек, розробка тулів по міграціям баз даних і т.д. в світі айті ДУЖЕ багато того де краще тестування віддати на роль розробника ніж залучати тестувальника котрий буде заважати :)
в тестуванні є навіть принцип , один з основних, що тестування залежить ВІД КОНТЕКСТУ. тому тестування повинно бути, АЛЕ НЕ ЗАВЖДИ тестувальник в теперішному розумінні повинен бути на проєкті.

БУДЬ-ЯКУ ЗАДАЧУ може виконати БУДЬ-ЯКИЙ ЧЛЕН ДЕВЕЛОПМЕНТ ТІМИ

Такого в офіційному документі нема. Буквально там сказано наступне:

The specific skills needed by the Developers are often broad and will vary with the domain of work.

Тобто, t-shaping вітається та заохочується, але саме такої вимоги, що будь-який член команди може виконати будь яку задачу — нема.

Гадаю, вищевказану вимогу “виводять” з цього речення:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

але це — невірна трактовка. Якщо подивитися, наприклад, в офіційні учбові матеріали від Scrum Alliance, то поняття крос-функціональної команди пояснюється таким чином:

Cross-functional. Together, the developers have all the skills necessary to create a product increment;

Це також підтверджується дискусіями на форумі scrum.org:
www.scrum.org/...​486/cross-functional-team

I think what you’re hinting at is that Scrum (and agile in general) argues that the team will benefit from having “T-shaped” members. If the UI designer is away for the day, there may still be someone around who can make a screen look decent. This isn’t the same thing as a cross-functional team, where the idea is to break down the functional silos in a company that drive lead-time and create hand-offs. Instead, a cross-functional team gathers people from all the required functions/disciplines to be able to collaborate on the same thing.

Більш того, часто роль Developer помилково трактується як саме “програміст”. Хоча, навіть офіційний документ трактує це поняття трохи ширше:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Тобто, під Developer розуміється, наприклад, так само й графічний дизайнер або DevOps.

Не читаючи статтю ставлю на те що там йде мова про простенькі вебсторінки або pwa app та їх тестування.
(пішов читати)

там йде мова про windows наприклад)

Це так — в MS навіть позиції нема «тестувальник» чи «девелопер», є Software Engineer. Ось:
www.linkedin.com/...​microsoft-dennis-dietrich
В стратегічному плані це — вірне рішення. У 21 столітті мануальне тестування — це щось з середньовіччя! Коли роботи цілком збирають авто, а ИИ розпізнає людей, казати що існує щось, що неможливо автоматично тестувати — дурня.
Але, нажаль, деякі менеджери розуміють це тупо як економія на тестуванні за рахунок перекласти ручне тестування на девелоперів! Звичайно це призводить до погіршення якості.

Ну залежить від проєкту. Якщо проєкт на стадії MVP або UI змінюється із швидкістю світла (спрінта) — то який сенс писати 100500 автотестів, які на настпному тижні потрібно буде переписувати.
Плюс є фічі на один раз — там теж не потрібна автоматизація.

Навіть якщо це якийсь MVP: по-перше кожну фічу має перевірити девелопер (хоч би раз). По-друге завжди є якийсь бета-тест, чи превью де дають подивитися юзерам. Для UI іноді навіть немає сенсу в тестах: якщо щось не гарно — про це скажуть користувачі і це полагодять за тиждень!

В принципі тестувати непотрібно — люди потім прийдуть та самі у підтримку зарепортять що де не працює.

Не те що взагалі не потрібно — бо через помилку на проді можна втратити і мільйон, до того як її зарепортять. Але так — якщо помилку можна обійти, то людина просто подзвонить в сапорт, там їй підкажуть, вибачаться — і усе. Потім колись пофіксять якщо це зачіпає багатато користувачів. Якщо одного чи двох на день — нема сенсу чинити!

Класний підхід, щоб втратити юзера у перспективі. Бо зарепортити баг 1-2 рази — це ще може і ок, але на постійній основі ніхто вам таке робити не буде. Закінчиться все тим, що юзер перестане користуватись вашим глючним софтом, а ви продовжуватиме запевняти всіх, що тестування не потрібно, юзер нам сам всі баги знайде і детально зарепортить. Гуд лак.

Закінчиться все тим, що юзер перестане користуватись вашим глючним софтом

Ні — якщо це не мобільна арлікушечка за 10 баксів, а система для бізнесу.
Це як банкомат: він може бути незручний, глючний, незрозумілий — але вам треба зняти грошей. І ви будете його використовувати, бо іншого вам ніхто не поставить.
Ну або треба буде закривати рахунок і переходити до іншого банку. Мало хто буде таке робити тільки ради красивого банкомату.

Оооо, як би ж то тест виконувався один раз, чи хоча б 10 раз, чи хоча був написаний один раз. А щоб клієнти і перевіряли продукти під час acceptance тестуваннч. Хех, ото б був дивний новий світ!

казати що існує щось, що неможливо автоматично тестувати — дурня.

А если говорить что «существует что-то, что автоматически тестировать — экономически нецелесообразано»?

Тоді інша справа! Поки було економічно вигідно наймати тостерів — макак з Індії за 2 бакси година — ніхто і не вигадував якісь тули для тестування UI. Було очевидно що UI буде тестувати людина. Але зараз той час, коли мануальна робота стає більш дорогою, ніж автоматизація.

Дочитав. Так, на щастя я не вгадав, і це стаття від людини що в темі, і напевно набагато більше ніж багато хто з нас. Я особисто відчуваю себе не в праві критикувати його, бо хто я, а хто тест архітект з МС.

Але я все ж висловлюсь.

По перше навіть він сам опосередковано визнає що complexity of testing нікуди не дівається, він просто перекидає цю комплексіті на девелоперів ("In reality, developers can become excellent testers, and they enjoy testing. With a straight face, I can say that number of developers I’ve worked with are better testers than 95% of the testers I’ve ever met — and they LOVE testing."©).
Це не безкоштовно. Час витрачений девелоперами буде такий самий як і тестувальниками. Десь швидше бо девелопери мають прямий доступ до дебаг телеметрій та спец тулів. Десь довше, бо інтеграціні баги треба дебажити людині яка розбирається у всьому продукту хоч по троху, а зовсім не всі девелопери сходу це зможуть.

Друга проблема — він чомусь вважає що тестувальники не знають що треба замовнику/юзеру. Це досить дивна точка зору, і ймовірно дуже продукт специфік.
("Quality is value to some person, and that person isn’t you. It’s the end user.«©)

Третя проблема — «просто запушіть в прод і збирайте телеметрію». Ну таке.... 100% замовників на моєму проекті просто дропнуть нас і ще і у скроні пальцем покрутять, якщо ми таке утнемо.
("Even desktop app developers can add metrics that can answer questions about customer success and uncover errors that you could never find in traditional testing within a fast feedback loop. If you’re working on a web page or web service, you can update, monitor, and redeploy dozens of times a day in order to make sure you’re learning and adjusting to what’s working for customers. «©)

Девелопери повинні писати автомацію. Ну так, вони і пишуть. Тільки а) покриття автомацією ніколи не буде навіть просто достатнім, не те що повним, і б) а хто власне буде готувати середовище для того автотесту, хто буде запускати, розбирати результати, дебажити фейли, а потім віндовлювати середовище? Кожен день? І якщо це будуть сіньор девелопери за сотні нафти, то хто буде писати код?
І до речі, чогось коли спеціалізовані профі сіньор девелопери звуть «нічого не знаючих» (див пункт 2 вище) тестувальників, то треба сидіти годину і додавати пропущені реквайрменти, перевірки. (які просто девелопери не роблять регулярно і це для них не на часі) Тобто навіть задизайнити автотест інколи це проблема, не те що знайти баг з ним.

ПС: у нас на кожного розробника десь один тестувальник, може трохи менше. І набирають ще. І всі девелопери пишуть автомейшен тести. Такі справи.

Так. Дуже рідко коли тестувальник знає відмінно знає предметну область аппки, що тестує. (Для цього і існують аналітики).
Дуже сумніваюся, ще звичайний тестувальник зможе відтворити ті ж самі паттерни використання, як і професійний трейдер з Wall Street або якась бабусі в онлайн-казино. Він чи вона просто цього або не знає, або знає замало. Тому й існує дуже багато аплікацій, де поставити себе на місце користувача дуже складно.
(Про лікарський чи військовий софт мовчу).

Ну от у мене телеком. І я відверто не розумію де там такі великі розбіжності у очікуванням кастомера та очікуваннями тестувальника. Так, тестувальник може пропустити якусь екзотичну комбінацію конфіга, або якусь опцію, або у нас не буде якоїсь залізяки чи конкретної моделі заліза. Ну так і у девелопера-тестувальника така сама проблема виникне. А переважну більшість сценаріїв використання цілком реально продумати та покрити тестами. Я навіть більше скажу — придумувати сценарії використання то взагалі не проблема. Проблема це покрити їх всі чи ручними чи авто тестами, на це просто не вистачає часу в нормі. А у дев-тестера часу буде ще менше. Звісно можно замість 10 девелоперів + 10 тестувальників найняти 20 девелоперів які будуть половину часу тестувати продукт. Питання смаку імхо.

n reality, developers can become excellent testers, and they enjoy testing

Еще больше девелоперы наслаждаются код-ревью, когда каждая написанная ими строчка кода подвергается сомнению, задаются глупые вопросы, на которые нужно отвечать и так далее.
Я вот, к примеру, точно наслаждаюсь когда ревьювят мой код :)

ПС: До речі, якщо щодо автора матеріалу я не вгадав, то з коментами тут на ДОУ все рівно навпаки — моя здогадка точно в ціль. Рівно 146% девелоперів тут наводять приклади продукту типу вебсайт чи моб додаток, та тестувальників що тупо клікають по кнопкам, і мовляв якщо насипати вагон юніт тестів, то це ж те саме вийде і швидше.
Типова картина для переважної більшості таких тем де згадують тестування, ніби на е-комерсі та лендінгах світ закінчився :) .

для більшості стартапчиків на лендінгах все в принципі й закінчується :) а живчики-стартапчики що ще не легасі, будуть таким через рік-півтора, і виживуть бо когось посадять клацати каталоги з трусами, перевіряти чи костилі збоку ще працюють, й робити АБ й перформанс і всякі інші челенджін таскс, щоб від покращень нічо не ламалось

/Тут має бути мем про нормальний розподіл/

Маємо то шо маємо.

QA — інженери, які можуть розробити тест план, різні види тестів, усе це автоматизувати — потрібні. Тестувальники — тобто мавпочки без технічної освіти — не потрібні!

Згоден. Але

мавпочки без технічної освіти

тут може відкритися портал у пекло.

«Мавпочки» досі популярні, тому що мануальний тостер за 5 баксів / година ще може конкурувати з роботом собівартістю. Але біда що знайшовши проблему — «мавпочка» сама не може зрозуміти що трапилося і відповідно як описати баг. Найпопулярніший баг, який я бачив, називався «whell of death» — у ньому був тільки скріншот спінера у браузері. Кожен раз, як QA бачив таку картину — він пере-відкривав цей баг. Пояснити що він міг бути через будь-яку помилку у фронтенд — аплікейниші було неможливо. QA за 5 баксів з Індії просто не знають що таке HTTP і як відкрити консоль браузера — це вже рівень якогось Senior QA.
Отже після того, як QA знайшов баг — усе одно девелопер повинен був його повторити, зрозуміти у чому справжня помилка, тоді полагодити ще й самому перевірити.
Тобто робота мануального QA це просто відрізнити коректну роботу від некоректної. Задача, яку сучасний ШІ вирішує не відмінно!

А хтось взагалі потрібен в команді крім розробника, якщо він може чітко виконувати завдання замовника?))

Можна будь кого крім дева викинути з команди, та чи дасть це якийсь сенс?
Якщо дев буде сам тестувати, його перформанс впаде в кращому випадку в двічі, але скоріш за все в 3 — 4 рази.

Я би навіть сказав, що не має якогось універсального складу команди по ролям, все дуже залежить від проекту, та людей яких ви набрали.

Написав код, сам потестив, сам задеплоїв, сам моніториш та фіксиш баги, сам спілкуєшся з замовником та пишеш вимоги, сам робиш демо, сам продаєш, сам думаєш архітектуру, сам робиш перфоманс та секьюріті аудит.
Все ж легко! Може робити одна людина.

Колись приблизно так і було ;-) Можна було тягнути комерційні проекти однією особою. А командою з 5-6 людей, один з яких директор (щоб домовлятися щодо відкатів) працювати з великими корпоративними замовниками національного масштабу.

Чуваак! Ти мабуть не повіриш, але десь так працюють наприклад в Амазоні та Твіліо.
Якщо вірити статті на pragmaticengineer, в Фейсбуці також, але там це взагалі викручено на максимум.

Додам лише що в Амазоні, коли намічався якийсь прям великий реліз — то цю функціональність спочатку відкривали лише для співробітників. Далі збирався весь поверх (ну, в кого час був), сідали на 2 години в великий мітінг-рум та «грали в юзерів». На моїй пам’яті, за 2+ роки що я там був — такий крауд-тестінг збирався раза 3.

Один тестувальник на тіму-дві я вважаю ок.
Але випускають їх зі шкіл зараз пачками, мало не половину (тобто один в розробники, інший в тестувальники).
Само собою що на 5 розробників не потрібно 5 текстувальників, бо написати компонент — це трошки довше, ніж глянути що він працює.

бо написати компонент — це трошки довше, ніж глянути що він працює.

З одного боку так.
Але як щодо:
— подивитися чи правильно працює компонент та взаємодіє з іншими компонентами
— подивитися чи компонент робить те, що у вимогах
— подивитися чи не ламає компонент усю структуру сторінки чи аппки
— подивитися чи працює компонент в браузері 1,2,3, версій ХХХ
— подивитися чи працює компонент на різних розмірах екрану
— подивитися як себе буде вести компонент у разі відсутності даних чи неправильних даних
— подивитися на безпеку чи перфоманс характеристику компоненту
— усе це проговорити та спланувати в залежності від ризиків, вимог та часу.

Це все валідно десь до 2015 року, коли були усякі IE, jQuery та інше щастя.
Зараз компоненти самі по собі достатьньо інкапсульовані і вся їх взаємодія — максимум дані по пропсам кинути в найгіршому випадку.
По браузерам все рівно, тільки подивитись чи Сафарі якусь фігню знову не викинув.
По розмірам екрану — це прямо від дизайну і зазвичай скрині по брікпоінтам прямо в ПР вставляють.
Перфоманс коли один раз пулить чи один раз рендерить досить статичний.

На прикладі останніх React SPA проектів — тестувати там дуже мало чогось.

Залежить від проекту та рівня якості який вам потрібен. Співвідношення часу на тестування та розробки дуже сильно залижить від того що ви власне робите. Один компонент який використовується у звязці з купою інших компонентів це вже не так швидко :) а це лише вершина айсбергу.

На самом деле всё зависит от фазы жизни проекта. В самом начале проекта тестировщик нафиг не нужен. Примерно через месяц (если есть спека) или через год (если стартап) на проект должен зайти лид-тестировщик, накидать тест-кейсы, распределить задачи и т.д. и т.п.
Постепенно, как продукт двигается к зрелости соотношение кол-во девелоперов к тестировщикам должно меняться в сторону тестировщиков. Это не значит что девелоперов надо увольнять, возможно их нужно переводить на другие проекты либо на рисерч оптимизаций.

Постепенно, как продукт двигается к зрелости соотношение кол-во девелоперов к тестировщикам должно меняться в сторону тестировщиков.

Класичний приклад чому ІТ проекти з часом помирають. Більше тестувальників — менше девелоперів означає що кожна нова фіча коштуватиме усе дорожче і дорожче. А прибутковість системи з часом зійде на нуль, а може і піде у мінус.

Більше тестувальників — менше девелоперів означає що кожна нова фіча коштуватиме усе дорожче і дорожче.

Нет, это означает что очередная «фича» не сломает воркфлоу.

На теперішньому проекті один тестувальник, коли його завалює тасками, то деякий тестінг перекидають на розробників і це ніфіга не ефективно, бо тільки тестер знає як швидко і якісно протестити будь-яку частину проекту.
На іншому проекті у нас тестив ПМ зі сторони кастомера, мінус — якість гірша ніж у професійного QA, але плюс полягав в більш швидкому делівері фіч, що було цілком виправдано саме на цьому проекті

Мені як тімліду спалося набагаааато спокійніше після релізів, коли в команді був один дотошний та надійний тестувальник, якому я довіряю.

І дуже пагано спиться, коли в тебе три мідла, які «насяльніка, я потестироваль, мамою клянусь» а потім баги вилавлюєм на продакшені. Або замість випивання пива ввечері — фіксиш щось. Дуже бісить.

А дотошний, найдійний та скіловий тестувальник або коштує багато («тиж всього лиш кліке-тестер, чого тобі платити багацько!,») або не існує — бо після сіньйора одразу йде у аналітики, менеджери та де більше ЗП та поваги. Скілових тестувальників тому дуже й дуже мало.

Проблема в тому, що ця концепція («хай розробники самі тестують свій код та релізи») прийшла із Силіконової долини, де:
— розробники часто мають акціі своєї компаніі, тому ___дуже__ зацікавлені не завалювати продакшен, бо це напряму впливає на них грошима
— люди часто цінять свою роботу, та бояться її втратити (бо треба за щось жити, і не хочеться бігати три місяці по співбесідах)

І цю ідею натянули на український аутсорс, де розробнику часто пофіг, завалить він продакшен чи ні, тому що він не в долі, і за це йому нічого не буде, скоріш за все йому просто скажуть «ая-яй», а в найгіршому випадку — його звільнять, і він піде в наступну галеру на +500 або візьме довгоочікуваний сабатікал пограти в плейстейшен пару місяців.

Тобто, там є «шкура на кону», а у нас нема.

Ви абсолютно праві.
Якщо є відношення як до робочого на заводі — та й у співробітника буде таке ж відношення. Без різниці — це розробник, тестувальник чи менеджер. Хоча ні. У менеджерів зазвичай більше шансів отримати якісь акції)))

насмішив про акції — повна маячня. багатьом достатньо здорового глузду щоб тестувати нормально свій код, бо інакше це прямий шлях «обісратися» (коли якась херня через твій код відбувається) і в режимі авралу фіксити код вночі.
Джуни цього можуть не розуміти бо ще вчатся, а всі інші, хто не тестує нормально свій код по дефолту просто профнепридатні дибіли і ідіоти (гівно-кодери). в компаніях силікованої долини таких набагато меньше.
проблема українського і індійського аутсорсу в тому що багато тупих гівно-кодерів. але насправді може це і не проблема, а специфіка, може цілком непогана бізнес модель — найняти дешевих дибілів, а їх тупість компенсувати за допомогою теж дешевого «dedicated tester».

про «бояться її втратити» це взагалі лабуда, нормальний дев так само легко знаходить роботу.

Буває ще так, що скіловий не сам йде в аналітики-менеджери, а його більше «направляють» туди HRи коли чують, що він хоче і далі бути тестувальником.

і шо? будь-хто, якщо не «чмо», росте і йде на вищі рівні з часом, добивається більш високої ЗП і заслуговує поваги.
Чи для вас набрати купку дибілів без амбіція то є команда мрії?

Так воно і виходить — коли мідл викониуе усе)

Поки не стане сіньйором та не піде з тестування на більшу ЗП

ну якщо ви (чи компанія) нездатні найняти когось окрім манки-кодерс то такий костиль як «тестер» досить практичний варіант (якщо дуже дешевий). Але як будувати «з гівна і палок» (тобто без адекватних кадрів) це інша історія, явно стаття не про це

Я не можу погодитись лише зі словом «більшість», оскільки не побачила в статті жодної статистики щодо цього. Думаю, в даному випадку коректно було б вжити слово «деякі». Можливо, в такому формулюванні висловлювання не викликало би бурхливої реакції 🙂

Якщо помилка у open source дуже дошкуляє — можна найняти фрілансера щоб виправив.

у багатьох випадках можна пофіксити самому. Або найняти головного контріб’ютора собі в компанію.

Усе так)
На мій погляд коли девелопер вмотивований та продуктооріентований — він і сам здатен відтестувати.
Гадаю що виділенний тестувальник частково вада аутстафу — з одніеі сторони зекономити на дорогому девові з іншоі — продати замовнику більше голів

Так. Але все залежить від багатьох факторів. Яке навантаження на девелопера, чи зрілий він спеціаліст, чи може він тестувати та робити це ефективно, чи достатньо в нього знань системи, чи є у нього бажання.

«чи є у нього бажання»
ну це взагалі цирк.
девелопер іде в туалет а не сре на стіл теж залежно чи є в нього бажання користуватись туалетом. девелопери без такого бажання йдуть нахер і не отримують роботу (в нормальних компаніях), те саме з тестуванням

майже все правильно, маленька поправка «коли девелопер є девелопер а не тупий гівно-кодер, він і сам здатен відтестувати.»

Хороша стаття від Алана.
Все написано по ділу і те як зараз трансформується робота в ІТ.
Не знаю про шо сперечатись, тим паче він приводить аргументи як в одну так і іншу сторону. 🤷‍♂️

Кажуть девопси теж не потрібні.

у більшості продуктових компаніях в Європі немає тестувальників, деви пишуть весь стек тестів самі (включно до фронту), а після релізу щє й моніторять всі метріки, які щє й аналізують і це норма. Якшо хтось мріє шо він буде тільки код пиляти і все, у мене для них погані новини, ринок вже давно змінився і вимоги до девів також.

Мені здається тестувальники існують шо б їх апсейлити в аутсорсі

Так, у багатьох компаніях тестувальник якщо і є — то це SDET, який може и потестувати, і архітектуру системи проаналізувати на можливі помилки, і написати скрипти чи фреймворк, чи просто бібліотеку корисну.

я би сказав що тут є декілька умов
1) Має бути сильний штат ПМ+БА який пропише всю логіку ідеально і в ній не буде ніяких помилок та не чіткостей, які КУА-інженер зазвичай відловлює, перевіряючи вимоги до фічі на відповідність купі критеріїв та самій існуючій логіці додатку який він знає краще ніж девелопер, тмоу що деви у середньо великих компаніяї зазвичай працюють вузьконаправлено в своїй частині софту і вникають в іншу тільки при потребі.
2)Відповідальний дев, який сам відтестуває хоча би хепі флоу...
3)СДЕТ який сам буде писати тесткейси для своїх автотестів, а також ручками хочаб разок проходити те все, щоб знати як воно працює. А не забьє на те все після того як втомитись від постійного говнокоду своїх девів та правок які потрібно буде ще якось заменеджити.

Якось так :)

Такі проєкти це рідкість, але можна знайти. Або створити в себе.

Хороший тестувальник це дійсно перш за все хороший аналітик.
А хто відмовиться від хорошого аналітика для незалежного погляду на речі?

мені цікаво, яким боком аналітик до тестувальника?

для того чтобы найти потенциальную уязвимость в системе (баг) — необходимо хорошо понимать, как работает система и её части, как они устроены, как взаимодействуют и так далее. Для этого нужно быть неплохим аналитиком.

Аналітичні стратегії тестування — це фундамент. Оті самі black box техніки, це звідси. Тож так, аналітичної роботи у тестувальників вистачає.

Все залежить від ціни. Якщо такий «незалежний погляд на речі» коштуватиме відчутно дорого для бізнесу (при тому, що можна і без нього), то бізнес віл нього відмовиться.

В залежності від специфіки софта тестувальник зможе бути аналітиком. В деяких випадках. Бо аналітик повинен дуже класно шарити в доменній області.

Хороший тестувальник теж повинен, власне це імхо і є однією з рис що відрізняють хорошого від поганого QA


— розробник повинен бути відповідальним за те, чим працює фіча чи продукт з функціональної точки зору
— розробники можуть гарно тестувати (особливо, якщо їх навчити це робити та давати час на це)

Я таких не знаю, кто бы согласился на это по собственному желанию)
Мне интересно, а автор предполагает, что и тестировщики могут программировать, особенно если их научить? Так может и менеджеров научим, почему нет? Они же тоже ответственны за продукт и способны учиться.
Моё мнение — каждый должен заниматься своим делом.

Дуже просто — якщо дев зацікавлений в делівері результату то і протестуе і автоматизуе.
Маю досвід написання власного невеличкого софту в якому я був зацікавленний, зовсім інший майндсет працюе ніж на звичайному голерному конвейері

Автор не тільки припускає, що тестувальник може навчитися писати код. Він сам пише код та бачив безліч прикладів, коли тестувальник пише код. В деяких випадках краще ніж девелопер (тут можна сперечатися).
Плюс автор пропагує, шоб тестувальники усі вчилися писати код — в чому я з ним повністю згоден.

Я таких не знаю, кто бы согласился на это по собственному желанию)

Це якась забобона! Якщо спитати пересічного девелопера — він буде казати що з юніт-тестами буде удвічі довше, а якщо інтеграційні чи функціональні — то щонайменше у чотири рази!
Але ж чекай — після того, як девелопер написав код він усе одно має зробити ці тести! Тільки він зробить це руками аби перевірити що усе працює як треба. Якщо ти розумний девелопер — то для тебе написати код буде навіть швидше, ніж руками вбити тестові данні, дістатися потрібного місця і руками перевірити!
Отже юніт тест заощаджує час — бо дозволяє запускати і дебажити тільки свій код напряму. Інтеграційний тест також допомагає — швидше викликаті API кодом і кодом перевірити результат, ніж руками через якийсь Postman чи навіть swagger. UI тест іноді буває складно написати з нуля. Але якщо використовувати бібліотеки та зробити мінімальний набір своїх методів — то буль які дії користувача можна дуже легко задавати кодом.
Отже якщо процес розробки вже налагоджено, то додати нову сторінку чи форму в аплікейшин з усіма тестами буде не набагато довше, аніж з ручним тестуванням.
І на відміну від ручного, автоматичне тестування можна запускати коли потрібно! І це коштуватиме лише компьют ресурсів — не треба примушувати QA сидіти в овертайм перед релізом.

Є проекти де все використовується разом, по максимуму. І це не тому що вони живуть в 1980х роках. І тест це не тільки прогнати всі тестові джоби, інтегрейшн, чи проклацати візуально вручну а все разом

Допустім дев має писати юніт тести

Але коли вилізла бага чи щось іще, і її треба покрити тестом, бо вимоги, це може зробити тестувальник додавши тест чи відкривши нормальну таску, а не в стилі «там кнопка поламалась», «чомусь падає бекенд». Це все час який розгружає дорогий час розробки, а дев собі вже там пофіксить.

Навіть толковий багрепорт зробить це ненульовий час вобщім і специфічний досвід/навички

Абстрактно відгрібати що тестувальники не треба, деви все самі можуть зробити, це абстрактний відірваний від життя чос

Може девелопери й L1 сапорт будуть робити отлічно й краще за будького, тільки чи варто і чи справді це так?

Тестувальник, який хочаб зробить толковий багрепорт — це вже не тостер за 5 баксів на годину. А такий, що ще й сам тест напише — то вже майже девелопер.
Мова про те, що зараз тестувальник, який не вміє писати код і не розуміє як код працює — не буде корисний. А той, що вміє — вже не зовсім тестувальник!
Якщо одна людина може написати і код і тести — то хіба це не швидше, ніж двом окремим людям доведеться розбиратися з тією самою таскою?

Одна людина яка вміє все до якогось порога зробить звісно все швидше й можливо краще по одному двом параметрам за кількох окремих людей.

Але це не скейлиться на великі проекти

Великі проекти не робляться купою ковбоїв якісно, швидко і дешево, вони робляться купою ковбоїв максимум хіба щоб потім переписати.

Що підходить для якоїсь аппки, не підходить для платіжної системи

Це різниця між 1) трьома ковбоями, що вміють все, 2) футбольною командою, де є пара на заміну і тренер всім здається тільки ходить з умним відом і кричить, 3) і мурашником де кожен робить щось функціонально мінімальне

В майкрософт вважають , що медсестри й аптекарі не потрібні, бо нейрохірурги можуть робити це теж. Кучерява маячня.

Хірург не замінить інший персонал з іншими обов’язками, і це буде тупа трата грошей, а хірург буде сумувати й звільниться

В майкрософт вважають , що медсестри й аптекарі не потрібні, бо нейрохірурги можуть робити це теж.

Неправда ваша.
Если я правильно понял — там считают, что каждый участник проекта должен быть в первую очередь — инженером, а уже дальше иметь свою специализацию — девелопер, тестер, етк
всё как в медицине — все врачи — врачи с базовыми общими медицинским знаниями, а потом уже идёт дополнительная углублённая специализация.

А той, що вміє — вже не зовсім тестувальник!

Простите, что? :) «тестировщик — это человек, который не умеет писать код?» :)

Якщо одна людина може написати і код і тести — то хіба це не швидше, ніж двом окремим людям доведеться розбиратися з тією самою таскою?

А вам как нужно — чтобы «быстрее» или чтобы «как можно меньше ошибок было»? :)

«тестировщик — это человек, который не умеет писать код?» :)

Саме так! Бо якщо б він міг писати код — то працював би девелопером бо платять більше.

А вам как нужно — чтобы «быстрее» или чтобы «как можно меньше ошибок было»? :)

Зараз бізнесу важливіше саме «скоріше». «Щоб було якомога менше помилок» — взагалі бізнес не цікавить! Якщо помилки не заважають працювати та отримувати прибуток — то скільки їх не важливо.
QA які намагаються знайти усі можливі помилки — роблять добру справу, але бізнесу це не цікаво бо помилки не приносять прибутку!

Зараз бізнесу важливіше саме «скоріше».

Я печатаю со скорстью 1800 знаков в минуту, правда такая херня получается... но зато бістро :)

«Щоб було якомога менше помилок» — взагалі бізнес не цікавить!

Ровно до тех пор, пока не окажется, что в результате ошибки всем клиентам предоставлялась скидка 99% на все товары, билеты и так далее.

QA які намагаються знайти усі можливі помилки

у вас очень странное представление о процессе разработки, тестирования, выпуска в продакшн и так далее.
куа всегда пытаются найти все возможные ошибки
после чего баги оценивают, ранжируют, присваивают показатель критичности и гвоорят когда его будут тестить — или просто «да, мы знаем об этом».

куа всегда пытаются найти все возможные ошибки
после чего баги оценивают, ранжируют, присваивают показатель критичности и гвоорят когда его будут тестить — или просто «да, мы знаем об этом».

З погляду замовника: я плачу QA аби вони знайшли та записали максимум помилок. Після цього я вирішую виправили тільки 20% критичних помилок, які не дають юзерам працювати. Отже 80% роботи QA було впусту? Навіщо шукати усі баги якщо не усі чинити?
Якщо ж шукати тільки очевидні баги — то навіщо багато QA чи взагалі QA? Якщо є бага яка заважає юзеру щось робити — її знайде будь — який юзер відразу.

куа всегда пытаются найти все возможные ошибки
после чего баги оценивают, ранжируют, присваивают показатель критичности и гвоорят когда его будут тестить — или просто «да, мы знаем об этом».

З погляду замовника: я плачу QA аби вони знайшли та записали максимум помилок. Після цього я вирішую виправили тільки 20% критичних помилок, які не дають юзерам працювати. Отже 80% роботи QA було впусту? Навіщо шукати усі баги якщо не усі чинити?
Якщо ж шукати тільки очевидні баги — то навіщо багато QA чи взагалі QA? Якщо є бага яка заважає юзеру щось робити — її знайде будь — який юзер відразу.

З погляду замовника: я плачу QA аби вони знайшли та записали максимум помилок. Після цього я вирішую виправили тільки 20% критичних помилок, які не дають юзерам працювати. Отже 80% роботи QA було впусту? Навіщо шукати усі баги якщо не усі чинити?

До тех пор, пока не изобретён волшебный камень, оценить — критичная ошибка или нет — можно только найдя ошибку, а найти ошибку можно только поискав ошибку.

Якщо ж шукати тільки очевидні баги — то навіщо багато QA чи взагалі QA? Якщо є бага яка заважає юзеру щось робити — її знайде будь — який юзер відразу.

И тут мы возрващаемся к истории смок тестов и Нетскейпа — когда «багу, которая мешает юзеру» — нашли сразу несколько десятков миллионов юзеров.

1. Китайцы подбирали пароль к серверу пентагона
2. Каждый второй пароль был «мао цзедун»
3. На 23472635405783м пароле сервер согласился что у него пароль — «мао цзедун».

Ви прийшли до лікаря, він зробив огляд та поставив діагноз. Виписав таблетки. Ви вийшли від нього та вирішили не приймати таблетки. Або приймати тільки одні. Робота лікаря була впусту? Або задача лікарю дати вам потрібну інформацію про ризики для здоров’я та рекомендації що треба зробити щоб було краще? А це вже Ваша (бізнесу) задача чи виправляти баги чи ні. Це як з перфоманс аудитом та аудитом безпеку. Можна зовсім не фіксити такі баги, але якщо стрільне потім заафектить багато кого.

Хм, а хірургам та адвокатам платять таки більше ніж розробникам, то чому ми всі сидимо ще на dou? А ну тому, що не всі хочуть робити щось лише тому, що там більше платять

На розробника можна самому вдома навчитися, а на хірурга ні. Є порог входу і, звичайно, «мені це не цікаво». Хоча є думка, що подобається те, що виходить.

Я таких не знаю, кто бы согласился на это по собственному желанию)

за ту ж саму зп программіста — я б це робив хоч весь час
можу копать, можу не копать...

Підписатись на коментарі