А почему не использовать fiber-lock вместо сварки. Да он даёт более высокое затухание, но заметно дешевле. Если их не ставить 100 штук на один кабель, то проблем не будет.
Думаю тут нужно разбирать конкретный кейс. Обычно, faker приносит пользу разработчикам для юнит-тестов. Тестировщики же, как правило, и так отлично понимают какие в рамках теста корнер-кейсы и что нужно подать на вход теста. Применяют всяке техники, например Pair Wise Testing, Border Values Analysis, Equivalence Classes, etc. Я тут больще за всякие утилиты вроде PICT для помощи с Pair Wise. Потому как если просто отдать на откуп faker, то колличество тестов начинает расти неадекватной прогрессией. И на действительно нужные тестовые данные, будет приходиться 100 за компанию. А ведь каждый набор данных - это лишний тест ран, т.е. время. Регулярная практика на больших проектах вычищать бесполезные тесты, которые накидали на всякий случай. Иногда, проще вообще выкинуть такие фреймворки, чем разбирать что там такого насочиняли и почему тест-ран занимает 2-3 дня.
Для меня AI - это прежде всего экономия собственной памяти. Достаточно помнить названия паттернов или алгоритмов и кейсы для их применения, а сам алгоритм или паттерн отлично накидает сам AI. Ну и хорошо помогает для начального ликбеза по незнакомому функционалу. Глубоко - потом все равно лучше посмотреть документацию. Но для быстрого старта - очень даже.
Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых. Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
Тоже так скитаюсь, только в тестировании. Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку. Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
Позволю с вами не согласиться. Есть важные особенности. Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык. Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами. Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает. Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д. А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может. И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции. Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта. Вы считаете, что человек ничем в жизни не занимался кроме Python последние лет 5-10. Желательно все это время он ходил по собеседованиям или сам кого-то собеседовал подобным образом. У меня на текущий момент подобная проблема, я давно не помню эту базовую мишуру из справочника, потому что могу посмотреть ее в справочнике. Я уже молчу про Copilot. Но за 13 лет, мне довелось поработать с C/C++, Python, RobotFramework, Java, JS, Golang. Да, я не знаю ни один из них так же хорошо как джун который только на 1 язык и готовился. И довелось мне работать с этими языками, потому что в тот или иной момент так нужно было проекту/компании. Но, при этом я могу развернуть сам kubernetes/terraform, могу развернуть проект на стэке Azure, Atlassian, GitLab с пайплайнам, тестированием, quality gates, pre-commit хуками, настройками код стилей для IDE и чтобы вот это все автоматически побежало, и деплоилось без ручных манипуляций. Когда нужно было поднять проект на JS, а договаривались изначально на Java, просто пошел за месяц освоился с фреймворком, параллельно его поднял и настроил всю обвязку. Вот интересно, мне узнать. Приходит к вам проект, например. Есть у вас супер Python инженер. Какой язык и стэк он подберёт исходя из потребностей проекта? А скажем проект нацелен на Automotive или Embedded? Или другой проект для High Frequency Trading? Я же надеюсь Senior Engineer не пойдет просить DevOps или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
Ну я работал с Medtronic. Проект на более 100 человек Manual testers, Automarted Testers, SDET, Test Leads, Test Managers, DevOps. Всё было, и этот проект был чисто по тестированию, потому как по стандарту требуется максимальная независимость на уровне сторонней компании от разработки. Т.е. нельзя доверять результатам тестирования самой компании разработчика, потому что продукт из Safety Critical области. И в крайнем случае может привести к смерти людей. Работал Thomson Reuters, когда они еще были таковыми и с Refinitiv/LSEG. Там были платформы из fintech $ risk&legal доменов. Аналогично, никто не экономил. Все команды и роли были, включая Business Analytics. Так что всё вполне есть, только не у всех. Также работал и в стартапах, где приходилось делать всё. В общем основной посыл, что время и ресурсы потраченные компанией на "свой велоосипед" для определений ролей - это во-первых зря потраченные ресурсы. А во-вторых, я еще не видел, чтобы кто-то это сделал лучше или хотя бы на уровне как у ISTQB. Вместо того чтобы тратить на это время, можно просто почитать ISTQB и уже решать какие роли совмещать в конкретных людях. А на практике, выдумывают что-то своё и 99,5% случаев много чего упускают, получают фейл и начиают исправлять, опять что-то упуская. И так по спирали. Пока не приёдут к решению максимально близкому к давно описанному.
Ну статья про AI, написанная AI. С чем могу согласиться, что это действительно сильно помогает разобраться с возможностями незнакомых инструментов, запустив набросанные примеры. Я получал от разработчиков документацию, написанную AI без вычитки, хотелось их пристрелить. Плюс, всё очень сильно зависит от инструмента и доступной по нему открытой информации. Т.е. все проприетарное - без шансов. Пробовал, Java тесты и Python тесты - работает сносно. Пробовал RobotFramework и тут попандос. Сыпет примерами 3-4 мажорных версий назад. Ну и его примеры хороши для PoC. А нужна сразу продуманная архитектура с учётом особенностей твоего проекта. Чего никто тебе тут не скажет. Ну и выйдет что ты с помощью AI быстро накидаешь костыльное решение, которое очень скоро будет практически невозможно поддерживать. Т.е. для буяк-буяк ив продакшн - это ОК. Если ты планируешь с этим жить какое-то время. То ничего хорошего так просто не выходит. Нужен, человек с опытом, который разберёт все проблемы и разложит по проектам и пайплайнам. Ну и саму архитектуру и модули сделает как-надо, без мешанины.
Если релиз менеджер не делает свою работу, а получает деньги просто так. Это вообще не означает, что эту работу должен начать делать кто-то другой бесплатно. Просто нужно уволить такого релиз-менеджера. Просто он должен был выработать метрики и настроить их автоматический сбор. Получить тест репорт от QA с разбивкой дефектов по кластерам и если это укладывается в рамки оговоренные в тест-плане. Например, 0% - critical/major defects, <10% - minor defects, <25% - cosmetic defect. Цифры указаны для примера и должны быть установлены для конкретного проекта. Сверил репорт с реферальными значениями, прошел по чек-листу, что остальные компоненты тоже не пропущены. Например, пользовательская документация, собран пакет, обновлены ссылки, версии, копирайта и т.д. и закрыл релиз. Тут не требуется глубоких знаний. Или эти все операции - тоже QA выполняет?
Я вот работал в компании, где проще было самому исправить баги и сделать Pull Request. Чем описывать 100500 одинаковых дефектов в каждом модуле. Ведь разработчики код писали копи-пастой и один дефект с перечислением модулей их не устраивал, подавай на каждый модуль отдельный. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт. А потом понимаешь, что твоя оплата вообще не соответствует уровню обязанностей. Почему менеджеры получают много? Потому что они несут на себе ответственность за успех продукта/проекта. Уровень ответственности прямо пропорционален уровню оплаты. Почему так много фейлов на практике компаний? Потому что, менеджеры либо некомпетентны, либо на отморозе сбрасывают ответственность на QA. QA не бывает в состоянии принять верные решения, просто потому что не обладает всей информацией особенно про зависимости с другими модулями, проектами, подрядчиками и т.д. Его просто никто никогда не позовет на митинги, где торгуются компании, без этой информации про стоимость и сроки - невозможно сделать правильного решения про релиз. Ты можешь сделать все как можно лучше, всех пригнать в обозначенные сроки, а потом узнать что в этом нет смысла, потому что модуль подрядчика будет через пол-года. Так с ним договорились. Эта информация уровня минимум QA Manager, но ведь в вашей компании вообще нет такой роли, раз поднимается подобный вопрос. Release Manager выделенного может и не быть, если проектов не так много. Но эта роль должна быть на Project Manager или Product Owner в крайнем случае. Да что там, QA даже priority багам не должны выставлять, только severity. Но я встречал единицы представителей бизнеса, которые бы нормально делали свою работу и отвечали за приоритеты и риски и занимались риск менеджментом. Я думаю, хоть раз слышали про Triage дефектов? Почему слово-то такое? Да потому что тут своя триада - бизнес, разработка, тестирование. И этот процесс означает совместный анализ дефектов. А как на практике? Ты QA - вот или сам и триаж. А потом получаются компании уровня Боинг, у которых что-нибудь отваливается в полёте. И я не понял, какое отношение команда имеет к MTTR? Это вообще понятие из категории надёжности продукта. Время за которое продукт восстанавливает работоспособность в случае непредвиденной ошибки. Т.е. сколько времени пользователь не сможет воспользоваться продуктом после наступления ошибки. Я бы рекомендовал ознакомиться хоть немного с ISTQB. Эти идеи массово витают в стартапах, банально в силу неграмотности. Но не работают на практике, для любого продукта с хоть сколь-нибудь существующей фазой его поддержки(Maintenance Phase).
Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc. Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций. Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич. У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами. Жил я себе, заработал на автомобиль в кредит. Выплатил за год. Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции. Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются. Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету. Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет. Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты. Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь. Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто. Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях. То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему. Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
А почему не использовать fiber-lock вместо сварки. Да он даёт более высокое затухание, но заметно дешевле. Если их не ставить 100 штук на один кабель, то проблем не будет.
Думаю тут нужно разбирать конкретный кейс.
Обычно, faker приносит пользу разработчикам для юнит-тестов.
Тестировщики же, как правило, и так отлично понимают какие в рамках теста корнер-кейсы и что нужно подать на вход теста. Применяют всяке техники, например Pair Wise Testing, Border Values Analysis, Equivalence Classes, etc. Я тут больще за всякие утилиты вроде PICT для помощи с Pair Wise.
Потому как если просто отдать на откуп faker, то колличество тестов начинает расти неадекватной прогрессией. И на действительно нужные тестовые данные, будет приходиться 100 за компанию. А ведь каждый набор данных - это лишний тест ран, т.е. время. Регулярная практика на больших проектах вычищать бесполезные тесты, которые накидали на всякий случай. Иногда, проще вообще выкинуть такие фреймворки, чем разбирать что там такого насочиняли и почему тест-ран занимает 2-3 дня.
Для меня AI - это прежде всего экономия собственной памяти. Достаточно помнить названия паттернов или алгоритмов и кейсы для их применения, а сам алгоритм или паттерн отлично накидает сам AI. Ну и хорошо помогает для начального ликбеза по незнакомому функционалу. Глубоко - потом все равно лучше посмотреть документацию. Но для быстрого старта - очень даже.
Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых.
Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
Тоже так скитаюсь, только в тестировании.
Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку.
Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
Всё идёт по плану... (с)
Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
Позволю с вами не согласиться. Есть важные особенности.
Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык.
Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами.
Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает.
Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д.
А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может.
И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции.
Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта.
Вы считаете, что человек ничем в жизни не занимался кроме Python последние лет 5-10. Желательно все это время он ходил по собеседованиям или сам кого-то собеседовал подобным образом.
У меня на текущий момент подобная проблема, я давно не помню эту базовую мишуру из справочника, потому что могу посмотреть ее в справочнике. Я уже молчу про Copilot.
Но за 13 лет, мне довелось поработать с C/C++, Python, RobotFramework, Java, JS, Golang. Да, я не знаю ни один из них так же хорошо как джун который только на 1 язык и готовился.
И довелось мне работать с этими языками, потому что в тот или иной момент так нужно было проекту/компании.
Но, при этом я могу развернуть сам kubernetes/terraform, могу развернуть проект на стэке Azure, Atlassian, GitLab с пайплайнам, тестированием, quality gates, pre-commit хуками, настройками код стилей для IDE и чтобы вот это все автоматически побежало, и деплоилось без ручных манипуляций.
Когда нужно было поднять проект на JS, а договаривались изначально на Java, просто пошел за месяц освоился с фреймворком, параллельно его поднял и настроил всю обвязку.
Вот интересно, мне узнать. Приходит к вам проект, например. Есть у вас супер Python инженер.
Какой язык и стэк он подберёт исходя из потребностей проекта?
А скажем проект нацелен на Automotive или Embedded? Или другой проект для High Frequency Trading?
Я же надеюсь Senior Engineer не пойдет просить DevOps или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
Ну я работал с Medtronic. Проект на более 100 человек Manual testers, Automarted Testers, SDET, Test Leads, Test Managers, DevOps. Всё было, и этот проект был чисто по тестированию, потому как по стандарту требуется максимальная независимость на уровне сторонней компании от разработки. Т.е. нельзя доверять результатам тестирования самой компании разработчика, потому что продукт из Safety Critical области. И в крайнем случае может привести к смерти людей.
Работал Thomson Reuters, когда они еще были таковыми и с Refinitiv/LSEG. Там были платформы из fintech $ risk&legal доменов. Аналогично, никто не экономил. Все команды и роли были, включая Business Analytics. Так что всё вполне есть, только не у всех. Также работал и в стартапах, где приходилось делать всё.
В общем основной посыл, что время и ресурсы потраченные компанией на "свой велоосипед" для определений ролей - это во-первых зря потраченные ресурсы. А во-вторых, я еще не видел, чтобы кто-то это сделал лучше или хотя бы на уровне как у ISTQB.
Вместо того чтобы тратить на это время, можно просто почитать ISTQB и уже решать какие роли совмещать в конкретных людях. А на практике, выдумывают что-то своё и 99,5% случаев много чего упускают, получают фейл и начиают исправлять, опять что-то упуская. И так по спирали. Пока не приёдут к решению максимально близкому к давно описанному.
Ну статья про AI, написанная AI.
С чем могу согласиться, что это действительно сильно помогает разобраться с возможностями незнакомых инструментов, запустив набросанные примеры.
Я получал от разработчиков документацию, написанную AI без вычитки, хотелось их пристрелить.
Плюс, всё очень сильно зависит от инструмента и доступной по нему открытой информации. Т.е. все проприетарное - без шансов. Пробовал, Java тесты и Python тесты - работает сносно. Пробовал RobotFramework и тут попандос. Сыпет примерами 3-4 мажорных версий назад.
Ну и его примеры хороши для PoC. А нужна сразу продуманная архитектура с учётом особенностей твоего проекта. Чего никто тебе тут не скажет. Ну и выйдет что ты с помощью AI быстро накидаешь костыльное решение, которое очень скоро будет практически невозможно поддерживать.
Т.е. для буяк-буяк ив продакшн - это ОК. Если ты планируешь с этим жить какое-то время. То ничего хорошего так просто не выходит. Нужен, человек с опытом, который разберёт все проблемы и разложит по проектам и пайплайнам. Ну и саму архитектуру и модули сделает как-надо, без мешанины.
Если релиз менеджер не делает свою работу, а получает деньги просто так. Это вообще не означает, что эту работу должен начать делать кто-то другой бесплатно. Просто нужно уволить такого релиз-менеджера.
Просто он должен был выработать метрики и настроить их автоматический сбор. Получить тест репорт от QA с разбивкой дефектов по кластерам и если это укладывается в рамки оговоренные в тест-плане. Например, 0% - critical/major defects, <10% - minor defects, <25% - cosmetic defect. Цифры указаны для примера и должны быть установлены для конкретного проекта. Сверил репорт с реферальными значениями, прошел по чек-листу, что остальные компоненты тоже не пропущены. Например, пользовательская документация, собран пакет, обновлены ссылки, версии, копирайта и т.д. и закрыл релиз. Тут не требуется глубоких знаний.
Или эти все операции - тоже QA выполняет?
Я вот работал в компании, где проще было самому исправить баги и сделать Pull Request. Чем описывать 100500 одинаковых дефектов в каждом модуле. Ведь разработчики код писали копи-пастой и один дефект с перечислением модулей их не устраивал, подавай на каждый модуль отдельный. Но это вообще не говорит о здоровой атмосфере в компании, а очень даже наоборот. Это всё прикольно, только когда тебе интересно получить некий опыт. А потом понимаешь, что твоя оплата вообще не соответствует уровню обязанностей.
Почему менеджеры получают много? Потому что они несут на себе ответственность за успех продукта/проекта. Уровень ответственности прямо пропорционален уровню оплаты.
Почему так много фейлов на практике компаний? Потому что, менеджеры либо некомпетентны, либо на отморозе сбрасывают ответственность на QA.
QA не бывает в состоянии принять верные решения, просто потому что не обладает всей информацией особенно про зависимости с другими модулями, проектами, подрядчиками и т.д.
Его просто никто никогда не позовет на митинги, где торгуются компании, без этой информации про стоимость и сроки - невозможно сделать правильного решения про релиз. Ты можешь сделать все как можно лучше, всех пригнать в обозначенные сроки, а потом узнать что в этом нет смысла, потому что модуль подрядчика будет через пол-года. Так с ним договорились.
Эта информация уровня минимум QA Manager, но ведь в вашей компании вообще нет такой роли, раз поднимается подобный вопрос. Release Manager выделенного может и не быть, если проектов не так много. Но эта роль должна быть на Project Manager или Product Owner в крайнем случае.
Да что там, QA даже priority багам не должны выставлять, только severity. Но я встречал единицы представителей бизнеса, которые бы нормально делали свою работу и отвечали за приоритеты и риски и занимались риск менеджментом.
Я думаю, хоть раз слышали про Triage дефектов?
Почему слово-то такое? Да потому что тут своя триада - бизнес, разработка, тестирование. И этот процесс означает совместный анализ дефектов. А как на практике? Ты QA - вот или сам и триаж. А потом получаются компании уровня Боинг, у которых что-нибудь отваливается в полёте.
И я не понял, какое отношение команда имеет к MTTR? Это вообще понятие из категории надёжности продукта. Время за которое продукт восстанавливает работоспособность в случае непредвиденной ошибки. Т.е. сколько времени пользователь не сможет воспользоваться продуктом после наступления ошибки.
Я бы рекомендовал ознакомиться хоть немного с ISTQB. Эти идеи массово витают в стартапах, банально в силу неграмотности. Но не работают на практике, для любого продукта с хоть сколь-нибудь существующей фазой его поддержки(Maintenance Phase).
Потому что учиться нужно всегда. Работа в командах не панацея. Буквально на последнем проекте. Писали полную дичь, на вопрос почему так? Ответ всегда один - не знаю, я в компании 20 лет, и на всех проектах так делали. Т.е. люди даже не удосужившись почитать рекомендации от создателей фреймворка, а просто использовали подходы 20 летней давности, потому что они как-то работали. Неудобно, сложно, невозможно читать и поддерживать. Но все остальное считалось неправильным, просто потому что было им не знакомо.
Я бы поправил название. Оно слишком громкое. А по факту, применимо исключительно к тестированию веб-приложений. Даже для desktop и mobile не очень подходит. Не говоря уже про более специфичные кейсы вроде embedded, medical, automotive, aircraft, etc.
Ещё бы неплохо больше ссылок на источники информации. Например, пирамида тестирования - взята из ISTQB Basic. Если заглянуть в syllabus advanced level. То там уже все ближе к реальности. Пирамида всегда строиться от архитектуры конкретного приложения. Колличество, слоёв между unit и system как раз от архитектуры зависит. У меня бывали проекты когда unit оборачивались в module, module оборачивались в component, component оборачивались в subsystem, а уже subsystem собирались в system. И везде свои протоколы коммуникаций.
Также, интересно посмотреть источник по sanity vs regression. У меня отложилось в памяти, что основная разница - это регрессия покрывает старый функционал, не тронутый последней итерацией. Т.е. тесты на писанные ранее. А вот sanity - это как раз тестирование последнего инкремента, а не просто абстрактного функционала. Именно того функционала, что был внесён/изменён в последнем спринте или более долгой итерации.
Крутая подборка фич.
У меня только вопрос - есть ли какой-то вменяемый способ дебажить пайплайн в принципе. Ну и особенно со всеми вложениями вроде variables/include/etc? Или я правильно понял, что ничего особенно хорошего для этой проблемы нет?
Что-то вы совсем плохого мнения про этот мир. Ножницы для левшей - сущесвуют, погуглите. Даже продаются в канцеляриях. У меня жена и дочка в семье левши, сломали статистику. Зато удобно было дочку кормить, она себе левой рукой ест на коленях а я правой. Ну и с жена за столом всегда садиться слева, чтобы удобней было.
Играл я в такую экономику. А потом понял, что жизнь имела тебя ввиду со всеми твоими расчетами.
Жил я себе, заработал на автомобиль в кредит. Выплатил за год.
Женился, появился ребенок. А потом жена заболела через год. И тут тебе приходят и говорят, что чтобы жена имела шанс выжить нужно делать операцию в другой стране, потому что в твоей - не умеют. Нужно на этот шанс 120 тысяч долларов, не считая проживания и лечения до момента операции, так как нужно ещё донора подобрать. Насобирал с помощью родственников, а потом узнал что слава Богу у страны есть программы помощи таким пациентам и да нам повезло, эти деньги клинике перевело государство. Так что свои расходы составили всего тысяч 30. На лечение билеты и другие расходы до операции.
Потом купил дом за городом, потому что жене обычной простудой болеть смертельно опасно, а тут привет COVID от которого и спортсмены загибаются.
Но тут здравствуйте, сосед решил, что тебя сильно ущемляют и решил освободить. Пришлось бросить дом и валить, пока от тебя и твоей семьи не освободили эту планету.
Я сразу знал, что а Европе жизнь ITшника не такая уж и клёвая. Но тут пришлось прочувствовать полностью. Стоимость аренды совсем не та, расходы тоже, а вот net зарплата оказывается поменьше будет.
Да и у компании с заказами на фоне войны было все не супер гладко. Пришлось меня уволить. Хорошо, тут повезло, пока меня увольняли нашел другую контору. И ещё слава Европе тут тебя увольняют с нормальными выплатами где-то за полгода зарплаты. Ну вот уволили, но вышел на новую работу через неделю и купил второй автомобиль. Потому что для этой работы нужно было ездит в офис, а ребенка из школы забирать самому не всегда получиться. Работа позже заканчивается. Поработал в новой компании, но у них тоже не все так гладко. Уволили через полтора года, получил ещё раз выплаты.
Так что, что я могу сказать. Планы - это все хорошо и весело и строить из нужно. Только вот без плана Б, это все не стоит ничего. Как и недвижимость, которую купил, а теперь пользоваться толком не можешь.
Надёжней вкладывать в себя. А то рынок он такой, сегодня IT в топе, а завтра тебя заменили на ИИ.
Из всего перечисленного, одна хорошая новость, менеджеры наконец-то должны обладать техническим бэкграундом, а не просто рассказывать про единорогов. Но по личному опыту пока такого не наблюдаю. Может мне так повезло просто.
Ну а вообще хотелось бы на собеседованиях более приближенных к реалиям вопросов. Только пару раз попадались такие в израильских компаниях.
То алгоритмы хотят от тестировщика, а потом оказывается что ты их будешь использовать - никогда. Да и вообще, автоматизацией заниматься некогда, потому что мы планировать не умеем и не хотим. То напиши пару фреймворков с нуля, за пару дней под наш стек. Ну да их же по-любому, каждую неделю переписываешь. Да и вообще на поверку в компании уже давно написаны фреймворки и никто тебе их улучшать не даст хоть им уже и 10 лет. Твоё дело заниматься поддержкой.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему.
Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.