Стоит просто запретить голосование за карму корп-аккаунтам и лицам, ими приглашенным. ВСЕ! Прямо сейчас наблюдаю очень веселый прикол, когда не захожу полмесяца, а все льецца и льецца.
Поясню точнее — пришел что-то рекламить — не участвуешь в сообществе, сидишь сбоку.
Не даю. С чего укрепилось ограниченность мышления, с чего присвоено себе право кому-то что-то задавать? Я не твой студент, очнись!
(задачко, кстати, гуглиццо левой пяткой)
Примерно туда же, куда тебе стоило бы засунуть свою душность, конечно же =)
ЗасунЕте, Я, Я, Я, Я, Я — меня уже тошнит, не то чтоб рекламить что-то на хабре плохо, но ты сейчас отрекламил только то, что платку фпга стоит взять — но к тебе идти куда-то учиться — это цирковой номер — только посмеяться.
А еще маленьким детям, идущим на элктриков, стоит давать такие же кабеля, только сечением поменьше — пусть сразу привыкают к долбежке током, лол. Ограничен верилогом, так и запишем
Я скорей про то, что возврат углекислоты в атмосферу будет получше выбросов при сжигании НДМГ. Кислород с углекислоты электролизом. С водородом проблемы, но мб чте придумается навроде ледяных астероидов (бггггг, на самом деле вся эта ситуация — ишак-падишах)
Ох, какое выделение.
Поехали дальше.
Процесса чего? Разработки? Проверки качества?
По последней фразе я могу только вывести, что QA — это тестер, который еще и думает как этим пользоваться — то есть просто хороший тестер.
SDET — это симбиоз разраба и тестера, причем тут QA?
По последним двум не надо ничего доказывать, я спросил пример, а не отписку — it depends немного не катит, тебе так не кажется?
Все еще очень расплывчато, ни одной метрики не названо, оценивать нечего — «сразу видно» — да японамать… Ну го хоть с одной?
Не понял в корне.
Проясним.
За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»? Как дается обратная связь при такой задаче?
QA пишет тесты при TDD?
Как QA влияет на именно процесс при TDD?
Какие метрики есть? Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований, и QA отвечает именно за процесс такого понижения? Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста.
Пока что не продано в моей голове
Все верно, но как всегда есть маленькое «но».
Тимлид команды в данном конкретном случае обязан присутствовать, так как именно он знает команду, ее возможности, слабости, а еще ему отвечать за результат. Размазать ответственность по тонне людей — хорошая конечно практика, прямо на полвека назад отправляет. Пока что не понял, каким боком QA мне здесь помощник, а не сбоку подсел. Очень долго — это сколько? Больше одного проекта? Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки. Я если честно так и не понял — бц? Точно ли хороший подход тестировать что-то сразу целиком, без кусков (нагрузочка)? За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоретезировал задачи»? Как я, к примеру, смогу оценить качество работы такого специалиста по качеству?
Мне кажется, или командная рабоота — это сложение лучших компетенций каждого из команды? Разделение труда и зон ответственности работает лучше, чем одноранговая сеть. То есть сегодня мы вдвоем работаем над проблемой, над которой я собаку сьел — я веду, ты помогаешь, я отвечаю за; завтра ты более компетентен в стоящей перед нами задаче, и все наоборот, но главный принцип — всегда есть точка входа для контроля команды — ответственный за задачу. Таким образом мы не «жестко разграничиваем обязанности», но всегда есть ответственный — при этом по орг. вопросам, срокам и приоритетам — это тимлид, увы. Может я ограничен, может я #ok_boomer, но QA без наличия хотя бы MVP, которое можно assure — не вписывается в такую схему. Где он, поясни, раз уж начали?
Поздравляю, ты взял на себя обязанности тимлида!
бц?
ПриорИтИзировал — то бишь высказывал свое классное мнение? Сроки вырабатывал?
Ну я вобщем-то понял, какая тут выборка.
>> Apps in the Kids Category should not include third-party analytics or third-party advertising.
Есть May be permitted, но вроде были отказы за модель телефона
Обеспечение качества (англ. quality assurance, QA) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания, а также — поддержание этих характеристик при хранении, транспортировании и эксплуатации продукции.
DMAIC, может хоть как с черным ящиком работать. Или тестирование уже не мероприятие по обеспечению качества?
Тестирование требований QA все равно не сделает, по факту этим занимается разработка — потому что, внимание — у них достаточно знаний и имеется возможность оценить полноту, однозначность, выполнимость.
Это все, что вызвало внутренние противоречия конкретно у Вас?
Вы смешиваете мух и котлеты.
Задача QA — она на другом конце конвеера — после разрабов. Начальные риски при выборе технологий ложатся на плечи разработчика, а не QA.
Если сеньор говорит мне, что будет использовать определенный инструмент и только его — я не буду с кислой рожей заявлять ему, что он тогда не сеньор. Возможно ему этого инструмента хватает, а при нехватке проторенных дорог он уверен, что выкрутится, потому что знает инструмент как свои пять пальцев. В статье же я вижу явное противоречие, когда наиболее эффективный инструмент в своих требованиях имеет низкий порог входа — это облака и луна, повторюсь. Говорить при этом о каких-то серебряных пулях не приходится — логика всего абзаца выглядит жутко вывернутой: «не буду писать на Java — сроки вальнем наглухо», «только Appium — он стабилен и я с ним знаком, будет качество».
Задача QA — найти проблему и сообщить, не надо лезть дальше и копать, какая у него может быть ответственность в домейне разработчика? Всмысле копать??? Это хлеб разработчика. Достаточно описания и способа воспроизведения — дальше ждать следующей итерации и не рвать волосы, если она ушла к коллеге. Тут же культивируется какое-то непонятное собственничество над тикетом — job security практикуем?
>> перекидывать ответственность на специалистов, у которых этих знаний достаточно
япооооонамать, серьезно? То есть если мне надо построить дом, мне не вызывать строителя, который будет отвечать за качество своей работы, а самому колхозить? Или вызывать, но отвечать самому? Класс.
Простите, конечно, но это какая-то вялая жвачка из инфоцыганства.
Должен *ню, обязан мешать разрабам, должен до всех доколупаться, всегда за, нет слов «это так не работает» — ванильные сопли эффективного менеджмента. Из статьи четко ясно одно — с вами кашу не сварить — Head of QA же не может ошибаться, профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался, просто по слову какого-то осла.
>>На мой взгляд, опытный сеньор не станет перекидывать ответственность на специалистов, у которых этих знаний достаточно — «пусть дальше разбираются разработчики/девопсы/продакты». А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости. — Вообще пушка! Зачем передавать обратную связь — надо самому нафигачить как поймешь, лишь бы бедный разраб не прикладывал мозги и не знал, что он делает не так. Спускайся с луны!
fun.co/vacancies#jobs — давайте поговорим еще и о том, что чтобы растить каких-то специалистов — надо нанимать не only senior (учитывая вышеизложенное — адекватного технаря вы не увидите)
Поясню точнее — пришел что-то рекламить — не участвуешь в сообществе, сидишь сбоку.
(задачко, кстати, гуглиццо левой пяткой)
ЗасунЕте, Я, Я, Я, Я, Я — меня уже тошнит, не то чтоб рекламить что-то на хабре плохо, но ты сейчас отрекламил только то, что платку фпга стоит взять — но к тебе идти куда-то учиться — это цирковой номер — только посмеяться.
А еще маленьким детям, идущим на элктриков, стоит давать такие же кабеля, только сечением поменьше — пусть сразу привыкают к долбежке током, лол. Ограничен верилогом, так и запишем
НДМГ то бишь нормально, не волнует?
Поехали дальше.
Процесса чего? Разработки? Проверки качества?
По последней фразе я могу только вывести, что QA — это тестер, который еще и думает как этим пользоваться — то есть просто хороший тестер.
SDET — это симбиоз разраба и тестера, причем тут QA?
По последним двум не надо ничего доказывать, я спросил пример, а не отписку — it depends немного не катит, тебе так не кажется?
Все еще очень расплывчато, ни одной метрики не названо, оценивать нечего — «сразу видно» — да японамать… Ну го хоть с одной?
Проясним.
За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоритизировал задачи»? Как дается обратная связь при такой задаче?
QA пишет тесты при TDD?
Как QA влияет на именно процесс при TDD?
Какие метрики есть? Приоритизация как раз и двигает сроки доставки полезности, как она может именно помочь ужаться, или там идет как раз-таки понижение требований, и QA отвечает именно за процесс такого понижения? Если есть разница с какой позиции отвечать, то со всех позиций, пожалуйста.
Пока что не продано в моей голове
Тимлид команды в данном конкретном случае обязан присутствовать, так как именно он знает команду, ее возможности, слабости, а еще ему отвечать за результат. Размазать ответственность по тонне людей — хорошая конечно практика, прямо на полвека назад отправляет. Пока что не понял, каким боком QA мне здесь помощник, а не сбоку подсел. Очень долго — это сколько? Больше одного проекта? Внезапно, открытая аргументированная дискуссия между реальными участниками процесса, которые будут выполнять работу, а не только контролировать качество — выявит больше нюансов как «до», так и «во время» разработки. Я если честно так и не понял — бц? Точно ли хороший подход тестировать что-то сразу целиком, без кусков (нагрузочка)? За что ты конкретно отвечаешь при «вычленял методы из бизнес процесса и приоретезировал задачи»? Как я, к примеру, смогу оценить качество работы такого специалиста по качеству?
Мне кажется, или командная рабоота — это сложение лучших компетенций каждого из команды? Разделение труда и зон ответственности работает лучше, чем одноранговая сеть. То есть сегодня мы вдвоем работаем над проблемой, над которой я собаку сьел — я веду, ты помогаешь, я отвечаю за; завтра ты более компетентен в стоящей перед нами задаче, и все наоборот, но главный принцип — всегда есть точка входа для контроля команды — ответственный за задачу. Таким образом мы не «жестко разграничиваем обязанности», но всегда есть ответственный — при этом по орг. вопросам, срокам и приоритетам — это тимлид, увы. Может я ограничен, может я #ok_boomer, но QA без наличия хотя бы MVP, которое можно assure — не вписывается в такую схему. Где он, поясни, раз уж начали?
бц?
ПриорИтИзировал — то бишь высказывал свое классное мнение? Сроки вырабатывал?
Ну я вобщем-то понял, какая тут выборка.
mgimo not even started
Есть May be permitted, но вроде были отказы за модель телефона
DMAIC, может хоть как с черным ящиком работать. Или тестирование уже не мероприятие по обеспечению качества?
Тестирование требований QA все равно не сделает, по факту этим занимается разработка — потому что, внимание — у них достаточно знаний и имеется возможность оценить полноту, однозначность, выполнимость.
Это все, что вызвало внутренние противоречия конкретно у Вас?
Задача QA — она на другом конце конвеера — после разрабов. Начальные риски при выборе технологий ложатся на плечи разработчика, а не QA.
Если сеньор говорит мне, что будет использовать определенный инструмент и только его — я не буду с кислой рожей заявлять ему, что он тогда не сеньор. Возможно ему этого инструмента хватает, а при нехватке проторенных дорог он уверен, что выкрутится, потому что знает инструмент как свои пять пальцев. В статье же я вижу явное противоречие, когда наиболее эффективный инструмент в своих требованиях имеет низкий порог входа — это облака и луна, повторюсь. Говорить при этом о каких-то серебряных пулях не приходится — логика всего абзаца выглядит жутко вывернутой: «не буду писать на Java — сроки вальнем наглухо», «только Appium — он стабилен и я с ним знаком, будет качество».
Задача QA — найти проблему и сообщить, не надо лезть дальше и копать, какая у него может быть ответственность в домейне разработчика? Всмысле копать??? Это хлеб разработчика. Достаточно описания и способа воспроизведения — дальше ждать следующей итерации и не рвать волосы, если она ушла к коллеге. Тут же культивируется какое-то непонятное собственничество над тикетом — job security практикуем?
>> перекидывать ответственность на специалистов, у которых этих знаний достаточно
япооооонамать, серьезно? То есть если мне надо построить дом, мне не вызывать строителя, который будет отвечать за качество своей работы, а самому колхозить? Или вызывать, но отвечать самому? Класс.
Должен *ню, обязан мешать разрабам, должен до всех доколупаться, всегда за, нет слов «это так не работает» — ванильные сопли эффективного менеджмента. Из статьи четко ясно одно — с вами кашу не сварить — Head of QA же не может ошибаться, профессионал сменит свой привычный инструмент на точно такой же, в менюшках которого он не разобрался, просто по слову какого-то осла.
>>На мой взгляд, опытный сеньор не станет перекидывать ответственность на специалистов, у которых этих знаний достаточно — «пусть дальше разбираются разработчики/девопсы/продакты». А сам продолжит нести ответственность и копать, привлекая помощь других людей при необходимости. — Вообще пушка! Зачем передавать обратную связь — надо самому нафигачить как поймешь, лишь бы бедный разраб не прикладывал мозги и не знал, что он делает не так. Спускайся с луны!
fun.co/vacancies#jobs — давайте поговорим еще и о том, что чтобы растить каких-то специалистов — надо нанимать не only senior (учитывая вышеизложенное — адекватного технаря вы не увидите)
Не принял Конфуция
Печально видеть