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

Замени слово "тестировщики" на любую другую роль и смысл не поменяется.

Нет. Если бизнесу норм объясняют - таких вопросов не возникает.

да, бизнес просто уменьшает ресурсі на тестирование и улучшает процессі разработки, то есть повішает качество процесса, а не тестирования

#dilemmas - например, можно ли сказать, что тестирование выполнено, если все тесты пройдены?

смотри, мы должны зарелизить фичу. Весь набор манипуляций я описал в чеклисте к задаче, а если к этому куску кода есть описанный набор функционала, который покрывается тест-планом, еще и тестплан прошел. Могу ли я назвать, что я протестировал и тестирование закончилось? фактически, да. А что?

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

у нас есть тест ревью, где тругой тестировщик смотрит на такие жо ровно вещи как и я: а) спека, насколько она абсурдна или хороша б) мой чеклист, не упустил ля и чего в) как оно протестировано

например, если процесс будет через ТДД, то там сначала нужно сделать тестдизайн

у нас есть тест ревью, где тругой тестировщик смотрит на такие жо ровно вещи как и я: а) спека, насколько она абсурдна или хороша б) мой чеклист, не упустил ля и чего в) как оно протестировано

а если тестировщиков нет?

и зачем тестировщик смотрит на твою работу?

да, бизнес просто уменьшает ресурсі на тестирование и улучшает процессі разработки, то есть повішает качество процесса, а не тестирования

Выстраивание процессов обеспечения качества, как со стороны тестирования, так и со стороны разработки - все ещё QA.

например, если процесс будет через ТДД, то там сначала нужно сделать тестдизайн

Нет, не надо.

Юниты пишутся без тест дизайна.

и зачем тестировщик смотрит на твою работу?

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

Выстраивание процессов обеспечения качества, как со стороны тестирования, так и со стороны разработки - все ещё QA.

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

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

Кьюа включает в себя тестирование. Это не значит, что всё, что связано с кьюа связано с тестированием.

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

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

свободных тестировщиков или вообще?

Кьюа включает в себя тестирование. Это не значит, что всё, что связано с кьюа связано с тестированием.

никак, кьюа - это постановка процессов, чо там, CMMi например

там про тестирование по факту ни слова

свободных тестировщиков или вообще?

вообще

никак, кьюа - это постановка процессов, чо там, CMMi например

Кьюа это обеспечение качества. Не только постановка процессов.

Если ваше кьюа ограничивается постановкой процессов - sad for you, вы его не правильно готовите.

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

без тестировщиков тестирование будет другим в условихя сжатых ресурсов

о чем речь

какие-то странные ложные дилеммы в общем

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

мб потому они и ложные что абсурдные

ничего более

только хз кто на это обманывается

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

без тестировщиков тестирование будет другим в условихя сжатых ресурсов

с чего это? нормально можно тестировать без "тестировщиков"

но там люди уникальные можно сказать :) поэтому много где так не получится

я и не спорю. но это начинается с другой модели. где изначально самоорганизация разработчика несколько иная

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

Обеспечение качества - это всё необходимое для создания условий, в которых в продакшен попадает качественный продукт. Это и процессы, и инструменты, и QA евангелизм, и тестирование, и формирование критериев этого самого качества, и внедрение аналитики и метрик по этим критериям.

Всё остальные "это не qa" вы придумали из своей головы на основе болезненного опыта.

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

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

Всё остальные "это не qa" вы придумали из своей головы на основе болезненного опыта.

это из разряда скучной мантры "кто занимается качеством в команде?" правильный ответ "все, от уборщицы до президента компании"

но речь была изначально о КьюА против КьюСи

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

честно – я не знаю, как у них поставлен процесс, пока не интересовался :) точно не бдд и не тдд

так вот отдел занимающийся кьюа не должен заниматься кьюси никак вообще-то

если правда интересно, я могу спросить и рассказать как будет инфа

вполне, Алименков вон коротко описывал свой опыт, когда всё через тдд

это из разряда скучной мантры "кто занимается качеством в команде?" правильный ответ "все, от уборщицы до президента компании"

Ещё раз, Роман, давай не экстраполировать свой грустный опыт на всю индустрию.

интересно ещё как

так вот отдел занимающийся кьюа не должен заниматься кьюси никак вообще-то

Кому не должен?

тдд слабо применимо, когда у тебя короткие интерации и надо быстро релизиться

Ещё раз, Роман, давай не экстраполировать свой грустный опыт на всю индустрию.

какой опыт? сходите на любое собеседование - как раз будет вопрос такой, гугл в интернете даст тоже самое

тдд слабо применимо, когда у тебя короткие интерации и надо быстро релизиться

с тобой EvilMartians поспорили бы

какой опыт? сходите на любое собеседование - как раз будет вопрос такой, гугл в интернете даст тоже самое

Ходил по собеседованиям, таких вопросов не было. ;(

даже в вумных книжках такое пишут, что "за качество отвечают все"

с тобой EvilMartians поспорили бы

а есть линка про подход марсиан к тестированию?

я знаю, что у них нет тестировщиков

и насколько я понял по их продуктам, они не релизятся несколько раз в день

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

с тобой EvilMartians поспорили бы

Так себе пример, честно говоря.

да ладно, реально не спрашивали чем отличается quality control от quality assurance и "кто в команде отвечате за качество?"

лучше про инструменты поговорить и узнать

марсиане офигенный пример на самом деле

да ладно, реально не спрашивали чем отличается quality control от quality assurance и "кто в команде отвечате за качество?"

Первое спрашивали, второе не спрашивали.

марсиане офигенный пример на самом деле

В чем офигенность?

а есть линка про подход марсиан к тестированию?

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

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

у Ситника вроде

вон например, даж ж'стко разделают http://asq.org/learn-about-quality/quality-assurance-quality-control/overview/overview.html

Аск.орг.

Давайте ещё к мейл.ответы аппелировать.

ERROR: S client not available

Первое спрашивали, второе не спрашивали.

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

Зависит от процессов внутри команды.

Где-то да, где-то нет.

вся команда отвечает за качество всегда :)

Давайте ещё к мейл.ответы аппелировать.

чем тебе не нра American Society for Quality?

вся команда отвечает за качество всегда :)

+

кстати сами вопрос с quora и прочих про QA vs QC намекает, что

даже если где-то регламентировано, что нет – на самом деле да, и это попытка поругать одного конкретного человека в случае факапа

потому что за продукт отвечает куча людей

вся команда отвечает за качество всегда :)

В идеальном мире я бы с тобой согласился.

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

QA процессы типа https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration и аналоги строго говорят, что в обеспечении качества учавствуют все

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

за качество продукта отвечают все, кто прикладывают руки к продукту

и что процессы по обеспечению качества регламентируют не степени ответственности, а то, что все должны понимать за качество ЧЕГО они отвечают в конкретный момент и как они могут влиять внутри процесса

за качество продукта отвечают все, кто прикладывают руки к продукту

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

Это сомнительное такое влияние на качество, больше похожее на выполнение рабочих обязанностей.

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

индийский аутсорс тестировщик может плохо пройти кейсы и выпустить плохой релиз – прямой импакт на продукт) значит, он отвечает за свой кусок

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

индийский аутсорс тестировщик может плохо пройти кейсы и выпустить плохой релиз – прямой импакт на продукт) значит, он отвечает за свой кусок

Ну блин, Никита, это совсем философия. Если он не выполнил кейсы - он не повлиял на качество продукта, он просто не выполнил свою работу.

Так, знаешь, ответственность за продукт и на Трампа ложится, если он завтра ядерную бомбу на Спб сбросит - мы так и не заделиверим багфиксов и качество продукта будет грустненькое. Ололо, влияние на продукт.

также можно сказать, что если разраб не написал юнит-тесты – он не выполнил свою работу, потому что юниты это часть работы :)

также можно сказать, что если разраб не написал юнит-тесты – он не выполнил свою работу, потому что юниты это часть работы :)

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

Так, знаешь, ответственность за продукт и на Трампа ложится, если он завтра ядерную бомбу на Спб сбросит - мы так и не заделиверим багфиксов и качество продукта будет грустненькое. Ололо, влияние на продукт.

это уже софистика чистой воды, речь о команде и всех, кто влияет работой на продукт

это уже софистика чистой воды, речь о команде и всех, кто влияет работой на продукт

Пройти тест-кейсы, заранее заготовленные другим человеком, написанные по тз, составленным третьим человеком - не влияние на качество.

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

да, но если разраб накосячил в коде, не перепроверив его, что повлекло за собой вовлечение большего числа людей и релиз продукта сдвинулся, то это испакт на качество

Пройти тест-кейсы, заранее заготовленные другим человеком, написанные по тз, составленным третьим человеком - не влияние на качество.

влияние

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

а что является частью работы?

а что является частью работы?

Зависит от процессов компании, очевидно же.

Пройти тест-кейсы, заранее заготовленные другим человеком, написанные по тз, составленным третьим человеком - не влияние на качество.

хотя тут вообще вопрос - пройти тесты = протестировать?

так а где процессы регламентированы?

хотя тут вообще вопрос - пройти тесты = протестировать?

В конкретном случае выше - очевидно что нет.