Если ифов 10, то вопрос подбора данных либо комбинаторики, которую дэвы тоже не юзают

Я такую ситуацию вижу только если программист уровня Junior. Но даже если это так, то джун программисту есть более полезные вещи, чтобы учиться.

Я привел один кейс из сотни где асистанс может быть использован Тебе на самом деле важно это интерпретировать как основной?

Давайте такж е рассмотрим моральную сторону вопроса: написание модульных тестов - это часть программирования, а не тестирования (внезапно). Часто ли программисты благосклонно принимают тестировщиков, которые учат их как что и где писать в коде?

Тут много писать, мне проще посылать читать https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

Я привел один кейс из сотни где асистанс может быть использован Тебе на самом деле важно это интерпретировать как основной?

ну, длавай основной. Ты привёл один, я от него и отталкиваюсь.

Я закончил

Я не знаю что ты там закончил, но я мельком пробежал статью - там совершенно не про то, о чем ты говоришь. Там говорят о quality assistance как о процессе взаимодействия между командами разработки. И даже приводятся примеры активностей: Кик-офф митинги в куа, на которые заоут программистов, привлечение разраба на роль "девелопер ин тест", блиц-тесты,

Вы бы хоть читали внимательно то на что даёте ссылки.

Там совершенно не про то о чем ты тут выше писал. И это никак не опровергает мою точку зрения и не подтверждает твою.

У меня сложилось впечатление, что ты не правильно понял статьи и поэтому начал транслировать неверную точку зрения. В свете этих фактов наш спор выше теряет всякий смысл ?

Я надеюсь у тебя хотя-бы руки не трясутся от подгорания То на вы, то на ты Куча букв, чувствуется прям ярость в глазах Все ок с нервами? )

Как мило. Кончились аргументы - перешел на личности?

"Вы" - это обращение ко всем. А к тебе я только на "ты" обращался.

Вы бы хоть читали внимательно то на что даёте ссылки.

Ага

Как это противоречит тому, что я написал?

Я не знаю что ты там закончил, но я мельком пробежал статью - там совершенно не про то, о чем ты говоришь. Там говорят о quality assistance как о процессе взаимодействия между командами разработки. И даже приводятся примеры активностей: Кик-офф митинги в куа, на которые заоут программистов, привлечение разраба на роль "девелопер ин тест", блиц-тесты,

Не надо статьи мельком пробегать Не девелопер ИН тест А девелопер ОН тест

Assigning a "Developer on Test" is a good way to introduce developers to the idea of testing, improve their skills, and make it explicit that quality is everybody's responsibility. It prevents the problem of a QA engineer being the bottleneck for the team. However, long-term reliance on DoTing is a sign that a team isn't confident in the testing done by the developer who implements the story. Effectively, somebody is double-checking the testing tasks that should have been done by the original developer, which is inefficient. Eventually, we want to feel confident that the original developer has sufficiently tested for the risks outlined in the testing notes, without needing another person to repeat that.

Ещё раз - как это противоречит тому, что я написал?

Dev in test != dev on test

Да. И?

Дэв Ин тест качает тестеров на программинг для прокачки тестера с автоматизацией Дэв он тест качает девелоперов на тестирование

И для этого им хватит одного ассистента на 5 девов

Но если тестят только девы это не самый гуд вариант

Дэв Ин тест качает тестеров на программинг для прокачки тестера с автоматизацией Дэв он тест качает девелоперов на тестирование

Да блин. Нет кроме этой статьи никаких DoT. https://www.google.by/?gws_rd=ssl#q=developer+on+test&nfpr=1

Я его хоть "Суперменом" могу назвать, толк не изменится.

Это маленькая практика, применяемая только в Атлассиан, ты уже общую практику мировую из этого сделал.

Developers can test well, as long as they are taught how. You can train them in specific testing skills, to embrace a QA mindset, and to increase their product knowledge to make them better testers.

Все перечисленые практики, это про то, что бы дэвы имели больше критического мышления, больше детектировали ошибок во всем процессе, а не надеялись на тестеров Это придти к раннему выявлению ошибок, но не потому что так построены процессы, как после Quality Assurance, а потому, что люди прокачаны Тестеры и менеджеры прокачаны на программинг там, где им надо Менеджеры и дэвы прокачаны на тестирование там, где им надо Тестеры и дэвы прокачаны на менеджмент там, где и надо Это аджайл, которого тоже как такового нет, есть скрамы, канбаны, лин итд

По сути дела - это просто презентация того, каким стеком методик пользуется куа аотдел.

Все перечисленые практики, это про то, что бы дэвы имели больше критического мышления, больше детектировали ошибок во всем процессе, а не надеялись на тестеров Это придти к раннему выявлению ошибок, но не потому что так построены процессы, как после Quality Assurance, а потому, что люди прокачаны Тестеры и менеджеры прокачаны на программинг там, где им надо Менеджеры и дэвы прокачаны на тестирование там, где им надо Тестеры и дэвы прокачаны на менеджмент там, где и надо Это аджайл, которого тоже как такового нет, есть скрамы, канбаны, лин итд

Да я и без гугол транслейта умею читать.

Да блин. Нет кроме этой статьи никаких DoT. https://www.google.by/?gws_rd=ssl#q=developer+on+test&nfpr=1

То, что атласиан это назвал, не означает что этого нет Тестеры тоже используют техники, которые не всегда понимают или знают как называется

Я просто не пойму что ты мне пытаешься доказать?

У меня тот же вопрос, о чем спор? )

Обозначте тему дискуссии

Тема дискуссии: как дать мзды оппоненту

О.

Так у тебя такая?

Юмора видимо вообще нет

Если вернуться к изначальному предмету спора - пока что никаких аргументов к тому, что обучающий разработчиков написанию юнитов тестировщик - это полезно я не вижу.

Юмора видимо вообще нет

Я а что-то пропустил когда дискуссия перешла в плоскость стендапа.

И это мне говорит человек вот с этим аватаром)))))

А как мой аватар относится к предмету дискуссии?

Ок, дэв пишет юнит на метод, в методе три разных по типу параметра, он покрывает это одной комбинацией данных, позитивной Ему есть что улучшить?

Глупый дэв? Нет, у него сроки

А если не сроки, то сколько комбинаций ему надо покрыть?

Дэвы шлют лесом таких вот настырных практичеси усехда, просто потому что

мне известны только четыре варианта, когда дэвы пишут юниты - приказ сверху, так принято в команде/компании, личная инициатива или за это доп бабло

а что говорить про тестирвщика, который будет дэвов учить - это что-то на грани добра и зла

Ну, давайте примем за постулат в диалоге, что писать юнит-тесты - это нормально. Идём дальше. Должны ли юнит-тесты проверять отказы системы? Или только проверять, что код, ради которого они были написаны работает успешно?

Именно юнит-тесты?

А как же интеграционные?

Не, давайте всё в кучу не валить.

а как юниты могут всё проверить? по определению юниты, на то и юниты, чтобы проверять каждый юнит отдельно

Да, все, молодцы, вы правы Я пошёл завтракать)

И юниты не должны все проверять, я такого не говорил

Оф

Я тоже не говорил.

Тогда какая польза только от асистанс?

Ну, я вижу пользу в улучшении взаимодействия между отделами, шаринге знаний.

Но разговор начался с того, что один асистанс на 5 девов решает вопрос с тестированием, в общем случае

асистанс вполне себе будет тестировать, просто он не будет клепать простые линейные тесты, он будет писать тесты которые тестируют не простой функционал, не на уровне сложить две цифры он будет писать тесты проходящие по куче компонент, стори тесты, енд ту енд тесты он будет запускать тесты на надёжность, производительность, на комбинацию данных и т.д. потому что у него будет время, потому что дэву будут выдавать код с другой пропорцией качество\количество это уже не манки работа, и не первые 5 лет в профессии этим надо заниматься, для этого требуется опыт это как фраза джуниор нагрузочных тестировщиков не бывает, да и регулар это чувак с бэкграундом тут та же история, тебя слушают дэвы только если ты их можешь научить по новому код ревьюит а если нет, занимайся QC

Я думаю тут слово "учить" плохое, там больше организация, процесс, методы...

При которых девы будут делать то что тут написано

И может оказаться что пара манки дешевле

Хм... Одна из перввх должностей моих была Quality Assistant. И с тестированием она тогда никак не была связанна. В основном была работа связанная с процессом разработки, написанием новых и обновлением старых процессов и т.п. Никакого течтирования тогда не было, хотя может что-то уже и изменилось

хм, когда речь идет про процессы с этим ассоциируется именно ашуранс так как под ашуранс обычно подразумевают _обеспечение качества_ через процессы а контроль - обеспечение качества через проверку а асистент - обеспечение через ассистирование другим заниматься качеством, т.е. помощь хотя конечно ничто не мешает заниматься этим всем сразу и брать название позиции от той роли, которая преобладает как и ничто не мешает называть должность как угодно не связано

ERROR: S client not available

Непонятно почему qa с процессами часто упоминают. Строить процессы это задача руководителей

я так понимаю руководители занимаются процессами на уровне людей, отделов, бюджетов, обучения, коммуникаций между отделами, сроками глобальными (а не на уровне таски) куа занимается процессом на уровне разработки, процесс ревью требований, процесс код ревью, процесс стейджей тест сред и этапов тестирований (альфа, бета, аксептанс) и т.д.

Девочки, не ссорьтесь

о, подружка бородатая с Германии)

с харизмой щас накинет

ладно, я гулять, всем чмоки в этом чате

Непонятно почему qa с процессами часто упоминают. Строить процессы это задача руководителей

Нет

что-то у меня уже какая-то каша в голове. который день тема мусолится.

Просто люди боятся сделать лишнюю работу нечаянно

лол, надо рассказать директору нашего департамента, что он куа

вот поясните, на основе вышесказанных определений, что это за люди:

в описаниях вакансий как правило ни слова про выстраивание процессов и т.д.

А если он один там будет?

Допустим

И тут как бы про ашуранс нет в должности

всм? все 4 - в заголовке "КуА".

Да и вообще, как должность называется, чтот они имеют ввиду, что происходит на самом деле, немного разные вещи

это я уже давно заметил

всм? все 4 - в заголовке "КуА".

Чет сморозил

в описаниях вакансий как правило ни слова про выстраивание процессов и т.д.

Да потому что бессмысленно приписывать куашкам выстраивание процессов. Каждый сам всегда везде выстраивает себе и окружающим процессы, на любой должности.

Если я себя заставил приходить на работу пораньше, к 11, делать самые важные задачи до обеда а вечером писать отчет - я выстроил себе процесс.

Если куа попросил тимлида сказать разработчикам чтобы они после выполнения задачи переводили тикет в статус "ready for testing" - они вот так выстроили процесс )

наверное, эту тему надо предложить для круглого стола на dump-е.

?

А есть еще вообще выделенная должность - business process development manager

Который только и занимается с утра до вечера тем что выстраивает процессы

Просто люди боятся сделать лишнюю работу нечаянно

Хорошо сказал!

И боятся сделать не свою работу случайно! А вдруг я сделаю, а окажется, что это должен был программист или менеджер сделать.

И боятся сделать не свою работу случайно! А вдруг я сделаю, а окажется, что это должен был программист или менеджер сделать.

переделать всё назад?

кстати, я тоже выстроил процесс, каждый вечер я почёсываю свой пузик

Ты его так называешь?