Drive your career as React Developer with Symphony Solutions!
×Закрыть
  • Як наодинці автоматизувати тестування у продуктовій ІТ-компанії: покрокова інструкція

    Можно. Например нужно перевести на автотесты все имеющиеся мануальные тесты.
    Стратегия начинается с правильной постановки задачи — автоматизировать существующие тесты, так чтобы не поломались существующие основные QA цыклы (периодические регрессии, CI/CD планы, релизные цыклы и т.п.).
    Пример достижения цели
    1. Проанализировать имеющиеся кейсы.
    Наметить как именно можно их все автоматизировать (какие фреймворки, почему именно эти фреймворки, насколько тот или иной подход затратный, как это потом интегрировать в существующий CI и т.д.)
    2. Набросать примерный план действий, включая случаи когда все идёт сильно не так.
    Когда, как и сколько новых автотестов включать в основной QA.
    3. Взять несколько пробных тестов, и проделать всю автоматизацию до конца. Такой себе Proof of Concept. Посмотреть на все проблемы которые по ходу дела возникнут.
    Если надо, то проделать все сначала, допока весь подход к автоматизации не окажется приемлемым.
    4. Проскейлить пункт 3 на оставшиеся кейсы.

    Note: сложна часть это пункт 1. Сформулировать и обосновать подход к автоматизации. Многие проблемы можно избежать только так (а-ля выбрали фреймворк который к примеру не скейлиться, или не налазит на CI)

    Поддержали: Yuriy Kish, roma marinsky
  • Як наодинці автоматизувати тестування у продуктовій ІТ-компанії: покрокова інструкція

    Речь идёт именно про стратегию тестирования. Какие тесты делать, зачем их делать.
    Сюда же входит какие тесты авто, в каком порядке, куда эти авто тесты приткнуть, какие части софта и как покрывать, и т.д. и т.п.
    Можно даже сделать отдельную ’стратегию автоматизации’.
    Такие задачи обычно делает как раз лид.
    И да, это я так не прозрачно намекаю/советую делать стратегию перед тем браться за такие большие таски, как автоматизация.
    Ну а так лайк за попытку.

  • Як наодинці автоматизувати тестування у продуктовій ІТ-компанії: покрокова інструкція

    А где стратегия тестирования (то бишь всего QA процесса) ? Опять нету?
    Или вся стратегия это ’ будем писать такие тесты которые умеем, и черт его знает что из этого выйдет’ ?
    Note: автоматизация автоматизацией, а без стратегии довольно быстро приходит хаос.

  • Які найбільші проблеми в Україні?

    Феодализм. В Украине действует феодализм. Ну а из него проистекают плюс минус все проблемы описанные в соседних ветках.
    Ну а за что обычно не любят феодализм надеюсь не надо объяснять. Это если не любят конечно, а то некоторым , судя по всему, норм.

  • Фича или баг: как когнитивные искажения мешают в тестировании

    Читаешь такие статьи, и складывается устойчивое впечатление что QA в большинстве своем вообще не занимаются качеством софта. Не понимают что такое формальная логика, не понимают как работает софт, и что такое это самое его качество.
    Я уже молчу про более сложные понятия (покрытие, статистический фейл рейт и т.п.)
    Disclaimer: когнитивные искажения , bias и т.п. конечно есть, но они влияют на работу куда меньше чем Отсутствие понятия о формальной логике.
    Печалька....

  • Кто отвечает за качество игр: разработчик или тестировщик

    А что, тестировщики уже научились проверять качество софта ? (Сарказм)
    Да? А критерии где? Нету?
    Вот то-то же
    Disclaimer: имеется в виду средний по палате тестировщик, а не инженеры nasa

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    лучше бы он их знать не знал

    А что изменится если пытаться что-то объяснять клиенту? Експертизы у него как не было так и нет. Проверить ваши слова он не может. решения принимает все ещё клиент. И он все ещё хочет верить в то что хочет верить.

    Не стоит отказываться от каких-либо действий убедив себя заведомо в «не разрешат» и «не получится» =)

    Вообще-то весь процесс по выбору тулов/фреймворков и средств разработки это очень дорого (по времени). И оно не делается ’generic’ чтоб можно было потом использовать. Это надо делать под каждую конкретную задачу. Иначе просто бессмысленно.
    И вот пришел такой клиент, и говорит -’хочу либку х’ , я тут у дяди Васи, соседа такую видел. Он платит, он решает какая будет либка. И что бы вы ему не говорили, он все равно в конце может сказать ’я ими не доволен’

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Ту надо ставить вопрос ’кто принимает решения и насколько принимающий решения компетентен ?’ можно ещё добавить ’кто будет нести ответственность’. Если расклады таковы, что решения принимает клиент, при этом он не компетентен в области, но платит деньги и несёт ответственность, то все вопросы отпадают. Нет смысла ему что-либо объяснять про ’неработающие штуки’.
    А вот если часть ответственности на исполнителях, то тут все сложно. Тут или предлагать только заранее годные варианты, и так чтобы клиент выбирал только из них. Самодеятельность не позволять. Ну или сразу оговаривать — на ком ответственность тот и принимает решения

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Ну, во-первых донести что ’такой-то тул не подходит для решения такой-то задачи’ это уже сложно. Во-вторых, вариант с накидать на коленке альтернативу вообще-то не работает. И это даже хуже чем рандомный выбор кастомера.
    Потому что для начала надо сформулировать задачу (ее как правило нет сформулированной на этом этапе).
    Потом определиться с критериями выбора тулов/фреймворков/языков/технологий. Это уже долго. А потом надо ещё и проевальюировать пол рынка, чтобы найти хотя бы первый годный тул.
    На коленке такое не делается. Штатного времени на такое тоже как правило не дают.
    А вариант предложить на коленке альтернативу — он местами хуже варианта кастомера. Как минимум потому что ,на свой собственный вариант кастомер уже был согласен

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Оттого что вы расскажете клиенту, что текущий стек технологий/языки/либки/фреймворки не способны решить ту задачу, которую поставили — ничего особо не поменяется.
    Не редкость когда выбор фреймворка это что-то вроде ’ а у наших конкурентов именно этот фреймворк, мы его тоже возьмём’.
    И никакие аргументы не работают.
    Более того, если спросить напрямую а почему выбрали именно этот тул — то это вгоняет клиента в ступор. Это мы ещё даже не начали говорить про критерии выбора.
    Кстати, менее компетентных левов никто не отменял. Они все ещё придут и объявят неработающую штуку работающей.
    Иногда в роли таких девов сам клиент. И тогда вообще зашибись

  • Почему стоит включить в разработку прототипирование

    А что именно вы пытаетесь решить такого рода прототипами? Зачем они ? Для кого ?
    Судя по рисункам это не MVP. И это уж точно не прототип UI от дизайнеров.
    Это и не прототип дизайна/архитектуры системы. Потому как в нем отсутствуют структурные связи (целостная картина). Тем более что в разработке этого прототипа отсутствовал техлид.
    Если это был прототип требований от заказчика, то он ИМХО содержит много лишней информации (визуальной), и даже вводит в заблуждение...что из этого требование , а что просто часть прототипа/заглушки

    Поддержал: Сергей Сахно
  • Как добиться взаимопонимания с клиентом: 5 простых правил

    С пунктом 1 ( про impossible ) все далеко не так однозначно. Не редко бывает что приходит клиент и ставит некую задачу. Тим лид или команда садятся и начинают Брейн шторм. И по ходу дела оказывается что в постановке задачи есть противоречия. Или что у каких-то штук есть зависимости и нельзя просто так взять и подкрутить чтобы обе были с некоторыми характеристиками , а можно только 1. Или что некоторые вещи в принципе невозможны в неких условиях (используем не real time OS, а хотим строгие гарантии по времени отклика)
    На этой все лид /дев прямо скажет impossible.
    А потом к клиенту приходит кучка менее компетентных девов, и гордо объявляют неработающую штуку работающей. И клиент им верит, потому что ему очень хочется верить. А проверить он не может....

  • Портрет ІТ-спеціаліста — 2019. Інфографіка

    Лего картинки это конечно забавно. Но лучше б отдали raw данные. И графичками. А то выборка параметров для написания текста отчета как-то не очень.
    Даёшь raw!

  • «Метод наводчика» при работе с пул реквестами

    Поинт в том, что по сути нужно не пост фактум ревью сделанного кода, а ревью решения/дизайна Перед началом имплементации.
    И да, это будет микро agile.

  • «Метод наводчика» при работе с пул реквестами

    Есть один интересный нюанс.
    В схема с 2мя исполнителями получается скорее ’дизайн ревью’. Ревью неких решений, архитектурных и не только. То есть из пост фактум ревью пулл реквестов мы так плавно перешли к ревью дизайна Перед началом исполнения.
    Это действительно полезно. Вот только собственно сам пулл реквест теперь ревьювить не очень надо. Потому что если что-то пойдет не так, то принимающий опять будет ревьювить дизайн. И потом снова имплементация. И так по кругу.

  • Меньше, но лучше: как повысить качество кода

    А что за метрики production-а такие?
    Интересно как вы меряете что приложение действительно работает у пользователя.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    А что есть рекрутеры, которые действиткльно обладают навыками для оценки soft skills? Если да, то это что-то новенькое.
    Обычно там не оценка, а описание каких-то ощущений рекрутера. Обратное чрезвычайно редко.
    А насчёт Codility и ему подобных. Ни рекрутер, ни менеджер во многих случаях понятия не имеют что действительно надо будет делать на проекте. Могут даже лидов не спросить. Описание вакансии пишут как-нибудь . В итоге найти надо универсального единорога.
    Вот и прилетают всякие тесты.
    Не то, чтобы от них нет пользы. Просто они как правило не релевантны с реальной вакансией.
    Бесит именно то что они не релевантны.

  • Программист разумный

    Вообще-то для embedded очень даже характерна задача добиться размера бинаря не больше чем Х. А размер бинаря это один из видов метрик для измерения сложности. Так что...

  • Программист разумный

    Т.е. есть как минимум 3 разных понятия, подразумеваемых под ’сложность’. Но нет, будем смешивать их в одно потому что есть 1 слово?
    Теперь про пресловутую ’общественно полезность’ и ’трудоемкость’.
    Трудоемкость можно выразить через количество логических операций необходимых для решения задачи. Оно очень даже осязаемое и измеряемое. Причем консистентно от человека к человека. Другой вопрос что для некоторых подзадач существуют уже готовые решения, и некоторые об этом знают, а некоторые нет.

  • Программист разумный

    Будет ли измеренная сложность объективной действительно зависит от метрики. И тем не менее, если иметь дело только с обективно измеряемыми параметрами, то и измеренную таким образом сложность тоже можно назвать объективной.
    Не ’истинной ’ или ’правдивой’. А всего-лишь объективной

← Сtrl 12 Ctrl →