Если словарный запас есть и разговорный блок снят, то есть preply, на котором можно найти учителя
Можно найти учителя из местных и маленькую группу айтишников, которая работает в этом направлении. У нас такая есть, если хотите присоедениться - напишите в личку. Уровень intermediate
Можно взять того же учителя и заниматься парой с кем-то, задавая друг другу вопросы.
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов или Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет. Для пм - сроки тасок и бюджет в человеко\часах Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?" Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6. Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов". И вот это: " Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.
По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели. Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.
Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
Думаю, что минус будет в том, что последние будут труднее поддерживать в актуальном состоянии. Если при тестировании API мы смотрим ответ и интерфесную часть(имена эндпоинтов и параметры), то автоматизированные интеграционные тесты будут зависеть от реализации классов. А они могут изменяться чаще. Но я могу ошибаться.
Так вот я же выше написал по этому поводу. Отказ от ручных тестов в пользу юнит. Если смотреть с точки зрения управления ресурсами, час тестировщика стоит меньше, чем час разработчика. И чем больше тестировщик залазит в код(в чужой или в свой), тем дороже он стоит.
Я слышал, что есть истории отказа от QA в команде, и увеличение нагрузки на разработчиков по написанию модульных тестов на свой код. Если "бывший менеджер" хочет быть в рынке, то пусть пишет чище и сам себя же проверяет.
Касаемо стратегии из статьи, кажется что описано максимально возможные элементы процесса тестирования. Сомневаюсь, что заказчик будет писать настолько подробные требования. На усмотрение QA можно выделить наиболее критичные и нужные, в зависимости от уровня доступности API - открытое тестировать более тщательно, закрытое - на усмотрение внутреннего заказчика.
Не ради спора, но даже для меня это смешно. Экономить на покупке стандарта, но платить кучу денег за внешнего консультанта и за всю эту бюрократию.
Ну, то есть, я вообще не вижу смысла искать аналогичные РФ ГОСТы. Написанные на нашем псевдоИТязыке, нужным для откатов:
"критически важная система информационной инфраструктуры-ключевая система информационной инфраструктуры; КСИИ: Информационно-управляющая или информационно-телекоммуникационная система, которая осуществляет управление или информационное обеспечение критическим объектом"
"насколько я знаю, квитанцию во время аудита не проверяют"
Да, это очень "по-российски".
Там еще был упомянут внешний консультант по ИБ и законодательству. Ему бы тоже понравился данный финт :)
Интересно, а такой "лайфхак" каким-то образом поможет при прохождении аудита? Кажется, "покупка" стандарта является неотъемлемой частью того, что компания все делает по определенной схеме.
Для кого этот лайфхак?
Это бесполезно.
Сделайте лучше конфигурацию, которая будет просчитывать хэджирование рисков компании-экспортера ценными бумагами (фьючами, опционами). Озолотитесь.
Единственное замечание, данные по котировкам за 6 дней для построения оптимизации — слишком не репрезентативно. Нужно брать цены месячных закрытий на промежутке год или больше.
Upd: а, всё, увидел, что дневные за три месяца. Ну, все равно надо побольше, чтобы построить долгосрочный портфель, надо брать бОльшие промежутки, чтобы учитывать, допустим, колебания товарных трендов.
Надо было вот этим дать парням из Стэнфорда дать почитать. А то они деньги привлекают, привлекают. А потом сливают, сливают… И хорошо бы свои, так нет — чужие! https://smart-lab.ru/blog/607989.php
Есть несколько вариантов:
Если словарный запас есть и разговорный блок снят, то есть preply, на котором можно найти учителя
Можно найти учителя из местных и маленькую группу айтишников, которая работает в этом направлении. У нас такая есть, если хотите присоедениться - напишите в личку. Уровень intermediate
Можно взять того же учителя и заниматься парой с кем-то, задавая друг другу вопросы.
Мое самое проблемное место - боязнь собеса на английском. Именно для международной компании
Усиленно психологически настраиваю себя на этот этап. Все остальные страхи уже развеяны и не страшны.
Собрать процесс выпуска карточки клиента кредитного продукта из 5 шагов
или
Собрать процесс скоринга из 50-ти тасков с несколькими интеграциями.
Понятно, что во втором случае придется тестить отдельно, мокировать сервисы. И метрики качества работы будут разные, потому как цена ошибки разная.
Для бизнеса будет важен сроки и бюджет.
Для пм - сроки тасок и бюджет в человеко\часах
Для лида кол-во дефектов на проде, которые влияют на процесс и бюджет
"За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»?"
Конекретно за качество выпущенного в итоге процеса. А не за качество отдельной таски. Что и было указанно у автора п.6.
Тестировщик еще не умеет в бизнес. QA уже должен вникать.
"Как QA влияет на именно процесс при TDD?" - Формирует общую политику тестирования, совместно с тимлидом. Симбиозом позиции будет SDET, который занимаются этим же на более высоком уровне.
"Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований" - Зависит от сложности процесс. Иногда есть возможность это сделать, иногда нет. Я не утвержаю, что надо всегда строить в тесте весь процесс. Но QA может указать на наличие возможности.
Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста. - Пожалуй, откажусь. Лень доказывать.
Изначально мой комментарий был на реплику "Задача QA — она на другом конце конвеера — после разрабов".
И вот это:
" Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки."
А QA не участник процесса что ли? Как будто на твоем проекте были не QA, а кто-то похожий на QA или просто тестировщик. Который никак и не должен влиять ни на процесс. И не должен иметь никаких компетенций по отношению к процессу разработки. А если на проекте TDD подход, QA тоже не влияет на процесс?
По срокам и приоритетам скорее PM, а не тимлид. Причем в разных проектах по разному. Твой опыт, скорее, относится к чему-то типа Scrum-команд, у меня больше опыт в корпоративных Waterfall + scrum. В них смещена ответственность на Senior-ов, и тимлид, конечно, отвечает тоже. Но за более масштабные этапы проекта.
"Как я, к примеру, смогу оценить качество работы такого специалиста по качеству" - С позиции кого отвечать на этот вопрос? PM? Тимлида? Бизнеса? Есть метрики, в чем проблема? Если приоритизация помогла доставить полезность в срок и уменьшила время на поиск тестовых данных, там сразу видно.
По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели.
Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.
А ты токсичный :) Наверняка тебя ценят как сотрудника.
Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
И это было глубоко "До" разработки.
Думаю, что минус будет в том, что последние будут труднее поддерживать в актуальном состоянии. Если при тестировании API мы смотрим ответ и интерфесную часть(имена эндпоинтов и параметры), то автоматизированные интеграционные тесты будут зависеть от реализации классов. А они могут изменяться чаще.
Но я могу ошибаться.
Так вот я же выше написал по этому поводу. Отказ от ручных тестов в пользу юнит.
Если смотреть с точки зрения управления ресурсами, час тестировщика стоит меньше, чем час разработчика. И чем больше тестировщик залазит в код(в чужой или в свой), тем дороже он стоит.
Я слышал, что есть истории отказа от QA в команде, и увеличение нагрузки на разработчиков по написанию модульных тестов на свой код. Если "бывший менеджер" хочет быть в рынке, то пусть пишет чище и сам себя же проверяет.
Касаемо стратегии из статьи, кажется что описано максимально возможные элементы процесса тестирования. Сомневаюсь, что заказчик будет писать настолько подробные требования. На усмотрение QA можно выделить наиболее критичные и нужные, в зависимости от уровня доступности API - открытое тестировать более тщательно, закрытое - на усмотрение внутреннего заказчика.
Статья не совсем соответствует заголовку. Что же в итоге "скрывает" API и почему не сошлись цифры?
Спасибо! Было полезно. И за источники информации тоже спасибо!
Не ради спора, но даже для меня это смешно. Экономить на покупке стандарта, но платить кучу денег за внешнего консультанта и за всю эту бюрократию.
Ну, то есть, я вообще не вижу смысла искать аналогичные РФ ГОСТы. Написанные на нашем псевдоИТязыке, нужным для откатов:
"критически важная система информационной инфраструктуры-ключевая система информационной инфраструктуры; КСИИ: Информационно-управляющая или информационно-телекоммуникационная система, которая осуществляет управление или информационное обеспечение критическим объектом"
"насколько я знаю, квитанцию во время аудита не проверяют"
Да, это очень "по-российски".
Там еще был упомянут внешний консультант по ИБ и законодательству. Ему бы тоже понравился данный финт :)
Интересно, а такой "лайфхак" каким-то образом поможет при прохождении аудита? Кажется, "покупка" стандарта является неотъемлемой частью того, что компания все делает по определенной схеме.
Для кого этот лайфхак?
Не быть вам висялкомом.
Да хотя бы пару фоток распаковки, скрины экрана с ошибкой хрома и т.п.
Уже веселее!
Сделайте лучше конфигурацию, которая будет просчитывать хэджирование рисков компании-экспортера ценными бумагами (фьючами, опционами). Озолотитесь.
Единственное замечание, данные по котировкам за 6 дней для построения оптимизации — слишком не репрезентативно. Нужно брать цены месячных закрытий на промежутке год или больше.
Upd: а, всё, увидел, что дневные за три месяца. Ну, все равно надо побольше, чтобы построить долгосрочный портфель, надо брать бОльшие промежутки, чтобы учитывать, допустим, колебания товарных трендов.
Надо было вот этим дать парням из Стэнфорда дать почитать. А то они деньги привлекают, привлекают. А потом сливают, сливают… И хорошо бы свои, так нет — чужие!
https://smart-lab.ru/blog/607989.php