По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели. Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.
Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
Думаю, что минус будет в том, что последние будут труднее поддерживать в актуальном состоянии. Если при тестировании API мы смотрим ответ и интерфесную часть(имена эндпоинтов и параметры), то автоматизированные интеграционные тесты будут зависеть от реализации классов. А они могут изменяться чаще. Но я могу ошибаться.
Так вот я же выше написал по этому поводу. Отказ от ручных тестов в пользу юнит. Если смотреть с точки зрения управления ресурсами, час тестировщика стоит меньше, чем час разработчика. И чем больше тестировщик залазит в код(в чужой или в свой), тем дороже он стоит.
Я слышал, что есть истории отказа от QA в команде, и увеличение нагрузки на разработчиков по написанию модульных тестов на свой код. Если "бывший менеджер" хочет быть в рынке, то пусть пишет чище и сам себя же проверяет.
Касаемо стратегии из статьи, кажется что описано максимально возможные элементы процесса тестирования. Сомневаюсь, что заказчик будет писать настолько подробные требования. На усмотрение QA можно выделить наиболее критичные и нужные, в зависимости от уровня доступности API - открытое тестировать более тщательно, закрытое - на усмотрение внутреннего заказчика.
Не ради спора, но даже для меня это смешно. Экономить на покупке стандарта, но платить кучу денег за внешнего консультанта и за всю эту бюрократию.
Ну, то есть, я вообще не вижу смысла искать аналогичные РФ ГОСТы. Написанные на нашем псевдоИТязыке, нужным для откатов:
"критически важная система информационной инфраструктуры-ключевая система информационной инфраструктуры; КСИИ: Информационно-управляющая или информационно-телекоммуникационная система, которая осуществляет управление или информационное обеспечение критическим объектом"
"насколько я знаю, квитанцию во время аудита не проверяют"
Да, это очень "по-российски".
Там еще был упомянут внешний консультант по ИБ и законодательству. Ему бы тоже понравился данный финт :)
Интересно, а такой "лайфхак" каким-то образом поможет при прохождении аудита? Кажется, "покупка" стандарта является неотъемлемой частью того, что компания все делает по определенной схеме.
Для кого этот лайфхак?
Это бесполезно.
Сделайте лучше конфигурацию, которая будет просчитывать хэджирование рисков компании-экспортера ценными бумагами (фьючами, опционами). Озолотитесь.
Единственное замечание, данные по котировкам за 6 дней для построения оптимизации — слишком не репрезентативно. Нужно брать цены месячных закрытий на промежутке год или больше.
Upd: а, всё, увидел, что дневные за три месяца. Ну, все равно надо побольше, чтобы построить долгосрочный портфель, надо брать бОльшие промежутки, чтобы учитывать, допустим, колебания товарных трендов.
Надо было вот этим дать парням из Стэнфорда дать почитать. А то они деньги привлекают, привлекают. А потом сливают, сливают… И хорошо бы свои, так нет — чужие! https://smart-lab.ru/blog/607989.php
То есть, по вашему разраб(вы посмотрите, что такое тестирование ПО, тестировщики — почти разрабы) не должен тестировать, а саппорт (который только интерфейс может протестировать) почему-то должен? Просто потому, что саппорт дешевле? Но я вам рассчитал экономию, а вы не поняли в чем. Судя по "обилию терминов" я в этой сфере уже 8 лет, представляю жизненный цикл ПО от встречи с заказчиком и проектированию до тестирования и приемки проекта. Откройте любое мало мальское нормальное ТЗ и встретите там термины. Вы еще раз прочтите статью. Вы мне вменяете, что я отказывался работать, а я вам говорю, что та работа, которую "давали" была несестематизированна и непродуктивна. Давайте закончим нашу беседу и каждый останется при своем:)
Давайте, так как вы, я так понимаю, работаете по той же схеме, приведу вам пример: представьте, что вы должны протестировать доработку, но при этом вам надо сделать 100 итераций. По 20 итераций после каждого найденого бага. ТЗ на доработку нет, чтобы правильно протестировать вам надо сначала вникнуть в принцип работы модуля, т.е. повторить задачу разработчика. Вы тратите пол дня на разбор методики тестирования и еще пол дня на само тестирование. Теперь представьте, что эти 100 итераций можно свернуть в один цикл и разраб может сделать это за час, а вам надо делать такое тестирование по каждой доработке(допустим их 10) к каждому спринту. Готовы ли вы заплатить за час работы программиста, чтобы убрать с себя ~10рабочих дней? Эти 10 рабочих дней вы можете потратить на monkey job, или на саморазвитие-допустим, научится писать тесты. В данном примере несколько нюансов, решив которые вы оптимизируете свою работу и работу отдела. Кто должен принимать решение и какое?
Со вторым я согласен, а вот с первым можно было бы поспорить. Хороший линейный специалист может просто быть другого склада характера и не подходить для руководящей должности и топ-менеджмента. На этом проекте как раз хорошо было видно, что руководитель вырос из программиста, но в менеджменте слабоват.
Универсальность, она разная бывает. Вы, конечно, можете и в домене покопаться, и циску настроить и телефон поставить, и код потестировать, и телефон прошить. Но как профессионал вы можете делать что-то одно. И дело тут даже не в глубинке.
По существу твоего ответа мне скажу, что " жестко разграничивать обязанности" - первый шаг к состоянию "перегорел на работе". Встречал много людей, которые знают как лучше и правильнее делать. Обычно они сидели в одной компании очень долго и им уже всё и все не нравились. И на командную работу они плевать хотели.
Распознавать и перемещать на другие позиции таких людей - тоже задача тимлида.
А ты токсичный :) Наверняка тебя ценят как сотрудника.
Я тут, давеча, с аналитиком вычленял методы из бизнес процесса и приоретезировал задачи на разработку, чтобы протестировать и задеплоить бц целиком, а не кусками.
И это было глубоко "До" разработки.
Думаю, что минус будет в том, что последние будут труднее поддерживать в актуальном состоянии. Если при тестировании API мы смотрим ответ и интерфесную часть(имена эндпоинтов и параметры), то автоматизированные интеграционные тесты будут зависеть от реализации классов. А они могут изменяться чаще.
Но я могу ошибаться.
Так вот я же выше написал по этому поводу. Отказ от ручных тестов в пользу юнит.
Если смотреть с точки зрения управления ресурсами, час тестировщика стоит меньше, чем час разработчика. И чем больше тестировщик залазит в код(в чужой или в свой), тем дороже он стоит.
Я слышал, что есть истории отказа от QA в команде, и увеличение нагрузки на разработчиков по написанию модульных тестов на свой код. Если "бывший менеджер" хочет быть в рынке, то пусть пишет чище и сам себя же проверяет.
Касаемо стратегии из статьи, кажется что описано максимально возможные элементы процесса тестирования. Сомневаюсь, что заказчик будет писать настолько подробные требования. На усмотрение QA можно выделить наиболее критичные и нужные, в зависимости от уровня доступности API - открытое тестировать более тщательно, закрытое - на усмотрение внутреннего заказчика.
Статья не совсем соответствует заголовку. Что же в итоге "скрывает" API и почему не сошлись цифры?
Спасибо! Было полезно. И за источники информации тоже спасибо!
Не ради спора, но даже для меня это смешно. Экономить на покупке стандарта, но платить кучу денег за внешнего консультанта и за всю эту бюрократию.
Ну, то есть, я вообще не вижу смысла искать аналогичные РФ ГОСТы. Написанные на нашем псевдоИТязыке, нужным для откатов:
"критически важная система информационной инфраструктуры-ключевая система информационной инфраструктуры; КСИИ: Информационно-управляющая или информационно-телекоммуникационная система, которая осуществляет управление или информационное обеспечение критическим объектом"
"насколько я знаю, квитанцию во время аудита не проверяют"
Да, это очень "по-российски".
Там еще был упомянут внешний консультант по ИБ и законодательству. Ему бы тоже понравился данный финт :)
Интересно, а такой "лайфхак" каким-то образом поможет при прохождении аудита? Кажется, "покупка" стандарта является неотъемлемой частью того, что компания все делает по определенной схеме.
Для кого этот лайфхак?
Не быть вам висялкомом.
Да хотя бы пару фоток распаковки, скрины экрана с ошибкой хрома и т.п.
Уже веселее!
Сделайте лучше конфигурацию, которая будет просчитывать хэджирование рисков компании-экспортера ценными бумагами (фьючами, опционами). Озолотитесь.
Единственное замечание, данные по котировкам за 6 дней для построения оптимизации — слишком не репрезентативно. Нужно брать цены месячных закрытий на промежутке год или больше.
Upd: а, всё, увидел, что дневные за три месяца. Ну, все равно надо побольше, чтобы построить долгосрочный портфель, надо брать бОльшие промежутки, чтобы учитывать, допустим, колебания товарных трендов.
Надо было вот этим дать парням из Стэнфорда дать почитать. А то они деньги привлекают, привлекают. А потом сливают, сливают… И хорошо бы свои, так нет — чужие!
https://smart-lab.ru/blog/607989.php
То есть, по вашему разраб(вы посмотрите, что такое тестирование ПО, тестировщики — почти разрабы) не должен тестировать, а саппорт (который только интерфейс может протестировать) почему-то должен? Просто потому, что саппорт дешевле? Но я вам рассчитал экономию, а вы не поняли в чем. Судя по "обилию терминов" я в этой сфере уже 8 лет, представляю жизненный цикл ПО от встречи с заказчиком и проектированию до тестирования и приемки проекта. Откройте любое мало мальское нормальное ТЗ и встретите там термины. Вы еще раз прочтите статью. Вы мне вменяете, что я отказывался работать, а я вам говорю, что та работа, которую "давали" была несестематизированна и непродуктивна. Давайте закончим нашу беседу и каждый останется при своем:)
Давайте, так как вы, я так понимаю, работаете по той же схеме, приведу вам пример: представьте, что вы должны протестировать доработку, но при этом вам надо сделать 100 итераций. По 20 итераций после каждого найденого бага. ТЗ на доработку нет, чтобы правильно протестировать вам надо сначала вникнуть в принцип работы модуля, т.е. повторить задачу разработчика. Вы тратите пол дня на разбор методики тестирования и еще пол дня на само тестирование. Теперь представьте, что эти 100 итераций можно свернуть в один цикл и разраб может сделать это за час, а вам надо делать такое тестирование по каждой доработке(допустим их 10) к каждому спринту. Готовы ли вы заплатить за час работы программиста, чтобы убрать с себя ~10рабочих дней? Эти 10 рабочих дней вы можете потратить на monkey job, или на саморазвитие-допустим, научится писать тесты. В данном примере несколько нюансов, решив которые вы оптимизируете свою работу и работу отдела. Кто должен принимать решение и какое?
Со вторым я согласен, а вот с первым можно было бы поспорить. Хороший линейный специалист может просто быть другого склада характера и не подходить для руководящей должности и топ-менеджмента. На этом проекте как раз хорошо было видно, что руководитель вырос из программиста, но в менеджменте слабоват.
Универсальность, она разная бывает. Вы, конечно, можете и в домене покопаться, и циску настроить и телефон поставить, и код потестировать, и телефон прошить. Но как профессионал вы можете делать что-то одно. И дело тут даже не в глубинке.
О, вот видите. Вы уже считаете деньги:)