хорошо бы определить зачем вообще нужны тесты

С таким же успехом - "если <...> будут программировать, то и роль программиста не нужна".

а тестирование это не инженерная практика программиста ?

Это гораздо шире инженерных практик, кого бы то не было.

вы таки допускаете что есть чтото за гранью того что может сделать программист ?

Который программист?

или я не так прочитал

Про что тестирование - приходите в Киев на QAFest через 2 недели. Пока не спойлю:)

так не приду

далеко

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

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

Ога. У них чаще есть более глубокое понимание работы продукта, чем у программистов.

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

Потому что знания в IT часто шире (но не глубже).

В широком аспекте Quality Assurance - это обеспечение качества, Но правильная команда привержена делать качественный софт. А если она привержена делать качественный софт, то они непрерывно улучшают свой процесс через ретроспектвы, и качество через TDD и автотесты. Таким образом обеспечение качества лежит на самой команде. И если команда сичтает что её нужен выделенный тестировщик (QC) который будет гонять тесты которые экономически не выгодно автоматизировать (UI) то это тоже будет встроено в процесс. Следовательно, все нужные практики будут подтянуты правильной командой если она действително привержена делать качественный продукт. XP это только практики, Kaizen философия.

ну как то так да

В широком аспекте Quality Assurance - это обеспечение качества, Но правильная команда привержена делать качественный софт. А если она привержена делать качественный софт, то они непрерывно улучшают свой процесс через ретроспектвы, и качество через TDD и автотесты. Таким образом обеспечение качества лежит на самой команде. И если команда сичтает что её нужен выделенный тестировщик (QC) который будет гонять тесты которые экономически не выгодно автоматизировать (UI) то это тоже будет встроено в процесс. Следовательно, все нужные практики будут подтянуты правильной командой если она действително привержена делать качественный продукт. XP это только практики, Kaizen философия.

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

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

и бывает что чуть ли не основной приоритет в дизайне системы это сделать возможность её тестировать. изолированно, прогнозируемо

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

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

Для этого есть Наставник, который задавая вопросы помогает команде , помогает принимать правильные решения. Да, бывает что команда не опытная, поэтому практика Pair Programing позволяет поднять технологический уровень. А если не хватает внешних знаний, то это обеспечивается Наставником. Хороший Настаник может воспитать крутую, высокопроизводительную "команду тигров". Расширяя границы практик XP до философии Kaizen, философии непрерывное совершествования, можно познать Дао программирования. И тогда команда сама будет знать когда и что ей нужно для того чтобы выпускать классные продукты качественноо и быстро. ...жаль только что познав "Дао программирования" участники команды престают нуждаться в самом программировании.

>...жаль только что познав "Дао программирования" участники команды престают нуждаться в самом программировании. это сильно

это не командная разработка это справедливое разделение труда

Справедливое разделение труда? Эт что за зверь такой эфемерный?

Дао Программирования (правильный перевод) http://taopooh.narod.ru/5/dao_prog.html 2.4 Ученик спросил Учителя: “Я знаю программиста, который никогда не разрабатывал, не документировал и не тестировал свои программы. Но все считают его лучшим программистом в мире. Почему?” Учитель ответил: “Этот программист творит в Дао. Он стоит выше необходимости в разработке, он не сердится, если система перестаёт работать, он принимает вселенную, как она есть. Он стоит выше необходимости в документации, ему не нужно, чтобы кто-нибудь хвалил его код. Он стоит выше необходимости в тестировании, все его программы совершенны в себе, безмятежны и элегантны, их назначение самоочевидно. Истинно, он постиг тайну Дао.”

Справедливое разделение труда? Эт что за зверь такой эфемерный?

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

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

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

Тимур в чем разница между разработчиком и тестировщиков?

В том, что первый пишет код по описанию фичи, а второй -- делает тесты (ручные или машинные) по описанию фичи.

Разработчик тесты не пишет?

Про тдд слыхали?

Приемочные -- скорее всего нет. В больших проектах может и интеграционные не писать.

Тестировщик не пишет код? Вы про автотесты не слышали?

в это описание как то не укладываются разработчики которые по описанию фичи планируют рефакторинг и делают зачатки под будущие фичи которые очевидно захочется

центральный вопрос любой разработки не код, а фича

Тимур, я перестану троллить и напишу вам одну правильную вещь

Все - разработчики

центральный вопрос любой разработки не код, а фича

ПУШКА

вы чтото кроме натягивания тем на вордпресс разрабатывали ?

простите, у меня просто не нашлось более красивой аналогии

вы чтото кроме натягивания тем на вордпресс разрабатывали ?

Жжоте

Запомните одну вещь чтобы понимать тот язык на котором в этом чатике общаются - разрабы все, кто делает вэлью

что такое велью ?

Запомните одну вещь чтобы понимать тот язык на котором в этом чатике общаются - разрабы все, кто делает вэлью

Какой прямой вэлью делают тестировщики или аналитики?

В скраме есть команда, PO и SM. Ещё стейкхолдеры и весь остальной мир

что такое велью ?

value - ценность для Клиента

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

value - ценность для Клиента

как всегда, хитро

Какой прямой вэлью делают тестировщики или аналитики?

Наипрямейший Неоттестированный продукт не попадёт к пользователю

Увольняем тестировщиков и начнет попадать быстрее. В чем проблема?

И я не в курсе кто такие аналитики, извините

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

Увольняем тестировщиков и начнет попадать быстрее. В чем проблема?

Если для вас ок не тестировать - не тестируйте

И я не в курсе кто такие аналитики, извините

Можно я не буду повторять шутку про темы для вордпресса? :-)

value - ценность для Клиента

черт я не знаю это просто гениально. у меня сейчас просто истерика. это мать его ГЕНИАЛЬНО

на самом деле это ок. никто не в курсе кто такие аналитики

Можно я не буду повторять шутку про темы для вордпресса? :-)

Если грамотно расскажете - я с удовольствием почитаю

черт я не знаю это просто гениально. у меня сейчас просто истерика. это мать его ГЕНИАЛЬНО

Сарказм?

нет

вы просто реально не понимаете насколько это гениально

вы просто реально не понимаете насколько это гениально

Я думаю что в этом чатике должны все это понимать

ну значит я тупой

Если для вас ок не тестировать - не тестируйте

Я не говорил, что ок и что нет. Я спрашивал, какую ценность создают тестировщики, если они только замедляют поставку продукта к пользователю?

Они создают продукт которым можно пользоваться

кирил у вас нет шансов. серьёзно )

Если вы не будете тестировать - продукта не будет

на самом деле будет конечно, куда он денется

качество продукта – это тоже вэлью

на самом деле нет

качество обеспечивают тестировщики, в т. ч

Разницу между продуктом и херней "это работаетнамоеймашине" надеюсь все понимают?

Разницу между продуктом и херней "это работаетнамоеймашине" надеюсь все понимают?

ее нет

я думаю, пора переходить к вопросу, о том, что такое "продукт"?

качество продукта – это тоже вэлью

Качество не велью. Вэлью - решение проблем пользователя

о. сильно

решение проблем пользователя требует какого-то качества, вот это «минимальное качество» и есть то, что нужно от продукта в разном случае – разное требуемое качество и тестировщики отсюда следуют

Я могу смять вам лист а4 очень качественно

Пользуйтесь на здоровье

а я такое скажу - тестирование вообще не показывает качество продукта

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