Здравствуйте, Gradiens, Вы писали:
G>Потому что когда людям хочется что-то не делать, они просто берут, и _не_ делают это что-то. Если аналитика может быть интересна разрабам (в плане погружения в предметную область, а не в плане написания спек), то тестирование и саппорт разрабам не интересны. Они будут отлынивать, терять мотивацию. Как результат, скорость разработки значительно упадет, а текучка кадров — возрастет.
Если людям интересен продукт, область и они чувствуют за него ответственность, то все нормально. Разумный человек понимает, что надо и саночки катать. Если же посрать, то ничего не поможет.
G>Порочный круг — нагадишь с качеством, а радоваться саппорту будет следующий неудачник, который придет на твое место. После того, как он поймет, где оказался — придет череда следующего. Вам доводилось видеть проекты без требований, без тестирования, которые писало пять поколений разрабов? Душераздирающее зрелище (С)
Не надо только придумавать проблемы и последствия. Кто сказал, что при таком подходе ничего не документируется? Где сказано, что разрабочик сразу уходит как только нагадит?
SK>>Единственный тонкий момент, что разработчик должен чувствовать личную ответственность за продукт. G>Личная ответственность легко похерится необходимостью разруливать противоречивые хочучки заказчика про семь перпендикулярных красных линий, а потом еще необходимостью тестировать и поддерживать. Особенно в том нередком случае, когда проект уже не девочка, и первым у проекта был не ты.
Все правда. Единственный момент, что "ответственность легко похерится необходимостью разруливать противоречивые хочучки заказчика" не только у разработчика, а у кого угодно — тестера, аналитика, да у кого угодно.
Здравствуйте, StanislavK, Вы писали:
SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо.
Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы.
В этой схеме нет и не может быть гарантий качества.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, StanislavK, Вы писали:
SK>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо. I>Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы.
Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.
I>В этой схеме нет и не может быть гарантий качества.
Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).
Здравствуйте, opt1k, Вы писали:
O>Не надо быть семи пядей во лбу, дабы понять, что ТС работает в конторе рога и копыта, в которой всего 5 человек штата и финансовой ответственности 0.0. Посмотрел бы я как он запускал свой код в продакшн без тестирования и менеджеров в моей конторе на проекте стоимостью пару десятков миллионов. Мне кажется клиент даже контракт с нами отказался подписывать, если бы узнал, что у нас ни тестировщиков, ни менеджеров в штате нету.
не надо, у нас 100 чел штата.
Просто в отделе 2 разраба, 4 ПМ, и 3 тестера. Такое вот соотношение
Так что вас конкретно напрягает? Что для того чтоб вы работали нормально вам надо 4 ПМа? Или то что ваш код три тестера тестят, а иначе продуктив падает?
Здравствуйте, StanislavK, Вы писали:
SK>>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо. I>>Браво — исполнители сами контролируют качество. То есть, исполнитель всегда прав. Гы-гы. SK>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему.
Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
И каким это образом бизнес без тестеров скажет, что продукт некачественный?
I>>В этой схеме нет и не может быть гарантий качества. SK>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).
Тестировщики как раз заинтересованы в автоматизации — никому не нравится вручную кликать одно и то же. Тестерам выгодно создавать не баги, а тест-кейсы и тест-планы. В нормальной организации именно так и делается. Т.е. решение проблем, а не просто количество чего то. Тестеры, они прикинь, тоже решаются решением проблем, а не просто чего то кликают.
"начинают разводить руками и косится на других" — это похоже на локальный симптом, там где ты работаешь.
Здравствуйте, cocacola, Вы писали:
O>>Не надо быть семи пядей во лбу, дабы понять, что ТС работает в конторе рога и копыта, в которой всего 5 человек штата и финансовой ответственности 0.0. Посмотрел бы я как он запускал свой код в продакшн без тестирования и менеджеров в моей конторе на проекте стоимостью пару десятков миллионов. Мне кажется клиент даже контракт с нами отказался подписывать, если бы узнал, что у нас ни тестировщиков, ни менеджеров в штате нету.
C>не надо, у нас 100 чел штата. C>Просто в отделе 2 разраба, 4 ПМ, и 3 тестера. Такое вот соотношение
Так у вас похоже нету внятного проектного управления, раз в отделе ажно 4 пм на двух разрабов и трех тестеров. Наверняка один пм занят девелоперами, другой тестерами, третий координацией, а четверный всем проектом занимается
В целом понятно, почему у тебя тестеры "лишние" — плохой руководитель обычно сталкивает тестеров и девелоперов лбами. Т.е. ты говоришь про свои страхи и боль.
Здравствуйте, StanislavK, Вы писали:
CC>>4. После кучи говорильни с заказчиком на собственно работу времени не остаётся. SK>Суть не в том, чтобы перерабатывать, а в том, чтобы делать ту же работу, но с меньшим кол-вом людей. Разработчикам не хочется заниматься тестированием, поэтому они это делают так, чтобы делать этого как можно меньше. Тоже же самое с бизнес-требованиями, мало того, что они гораздо лучше чем любой аналитик понимают, что можно реализовать и как, но они еще стараются сократить ненужные обсуждения, так как это отнимает время разработки.
Именно — разработчикам не хочется заниматься тестированием. Потому они его избегают, ты сам же про это и говоришь(делать этого как можно меньше). Девелоперы до кучи как раз плохо понимают бизнес-требования. Они хорошо понимают технические возможности. Бизнес-аналитик — бизнес требования. Обсуждения нужны для того, что бы сократить разработку, что бы обе стороны лучше понимали, что хотят другие.
Странно, если было бы иначе. Бизнес-аналитик — специалист по домену, например по страхованию, и он обычно собаку в этом съел. Разработчик в страховании том же может весьма слабо разбираться.
Технические проблемы это не повод менять бизнес-требования. А то похоже у тебя такой кейс — девелоперам трудно, вот они и меняют требования под себя.
Здравствуйте, StanislavK, Вы писали:
SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо. SK>Когда же встает задача тестирования работы приложения при реальной коммуникации с другими системами, то там тоже нефиг тестеров брать — разрабы быстро выбешиваются от этого и пилят всякие приблуды, чтобы этого руками не делать.
Это и есть проблема — "приблуды, чтобы этого руками не делать".
Здравствуйте, StanislavK, Вы писали:
G>>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них SK>Да, именно так и значит. И очень стараемся сделать так, чтобы ее было меньше и больне никогда к ней не возвращаться. Признаться, я не вижу разницы в написании одного типа кода или другого, зачем для этого разные люди?
Тесты это не просто код, это часть тестирующей системы. Она проектируется, работает, решает проблемы принципиально иначе, нежели целевая система(продукт, сервис). Т.е. девелоперам прежде всего приходится переключать внимание.
В тестировании самое важно не код, а тест-кейсы, сценарии, планы и тд. И вот здесь выясняется, что скилы нужны принципиально иные. Девелоперу надо думать о проектировании продукта, а тестеру думать о выявлении проблем и проверке соответствия требованиям. У девелопера огромная часть работы напрямую на требования не мапится. У тестера ровно наоборот — вся работа целиком с требованиями.
Формально обе группы могут быть программистами. Только методы решения проблем у них разные. Программист еще не значит девелопер. Программисты нынче и админы, и девопсы, и безопасники и вообще кто угодно. Это не повод всю работу давать девелоперам.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, StanislavK, Вы писали:
SK>>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему. I>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ?
Извиняюсь, но ничего не понял. То тестеры, то саппорт.
I>И каким это образом бизнес без тестеров скажет, что продукт некачественный?
У бизнеса только один способ сказать что продукт качественный или не качественный — пользоваться им, если бизнес им пользуется. Если пользуется не непосредственно бизнес, а клиенты, то дать клиентам. Тогда все узнают насколько он качественный. До этого момента можно только предполагать основываясь на чем-то мнении.
Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.
SK>>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное). I>Тестировщики как раз заинтересованы в автоматизации — никому не нравится вручную кликать одно и то же.
Как не нравится? за это же деньги платят!
I>Тестерам выгодно создавать не баги, а тест-кейсы и тест-планы. В нормальной организации именно так и делается. Т.е. решение проблем, а не просто количество чего то. Тестеры, они прикинь, тоже решаются решением проблем, а не просто чего то кликают.
Верю, верю. Но все же конфликт интересов никуда не пропадает — тестерам выгодно чтобы было больше работы. При этом совсем не значит, что они будут ее плохо делать. Делать могут на отлично, но много не нужного.
I>"начинают разводить руками и косится на других" — это похоже на локальный симптом, там где ты работаешь.
Это вы откуда взяли?
Здравствуйте, StanislavK, Вы писали:
SK>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.
Давайте уже от разработчиков отказываться, чо, пусть клиент за качество сам отвечает. Вы вообще представляете себе объём тестирования корпоративного мастодонта в котором 500 отделений и каждое работает на одной и той же системе, только с разными процессами? Ваше предложение имеет смысл только в случае маленькой конторы, где разработчик 15 минут пишет код и 45 минут тестирует, а потом идёт пить чай.
Здравствуйте, opt1k, Вы писали:
O>Давайте уже от разработчиков отказываться, чо, пусть клиент за качество сам отвечает.
Да хорошо бы, но все же кто-то должен делать продукт.
O>Вы вообще представляете себе объём тестирования корпоративного мастодонта в котором 500 отделений и каждое работает на одной и той же системе, только с разными процессами? Ваше предложение имеет смысл только в случае маленькой конторы, где разработчик 15 минут пишет код и 45 минут тестирует, а потом идёт пить чай.
Я конечно извиняюсь, но строить аргумент только на том, что вам кажется, что кто-то что-то видел или не видел имеет крайне малое отношение к логике. А вы не предполагали, что возможно все дело в том я как раз видел такие компании и знаю как они работают, а возможно даже работаю в такой, и поэтому знаю, что будет если сделать не так как делают все?
Здравствуйте, StanislavK, Вы писали:
SK>>>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. G>>Если же вы пишете автоматизированные тесты, если проводите нагрузочное тестирование и т.д. — то значит, вы выполняете работу тестеров вместо них SK>Да, именно так и значит.
Есть мнение, что автоматизированные тесты должны писать не те, кто пишет продакшн-код. И в этом есть смысл. Смысл тестирования — выявить ошибки. Тот, кто пишет тесты, должен искать потенциально проблемные места и проверять их. Сам разработчик продакшн-кода думает об этом с другой стороны — как просто покрытие существующего кода тестами.
Здравствуйте, StanislavK, Вы писали:
I>>Здравствуйте, StanislavK, Вы писали:
SK>>>Почему это проблема? Если продукт не качественный в техническом плане, то девелоперу это не выгодно, так как саппорта становится много. Если он не качаственный с бизнес точки зрения, то спрос опять с разработчика — претензии бизнеса будут именно к нему. I>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ? SK>Извиняюсь, но ничего не понял. То тестеры, то саппорт.
Это и неудивительно — ты такими вопросами никогда не задавался. Кто контролирует девелоперов ? Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр.
I>>И каким это образом бизнес без тестеров скажет, что продукт некачественный? SK>У бизнеса только один способ сказать что продукт качественный или не качественный — пользоваться им, если бизнес им пользуется. Если пользуется не непосредственно бизнес, а клиенты, то дать клиентам. Тогда все узнают насколько он качественный. До этого момента можно только предполагать основываясь на чем-то мнении. SK>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик.
Это и есть проблема. Разработчик заинтересован в том, что бы все зависели от него. И качество будет падать, при чем обнаруживается это далеко не сразу.
SK>>>Я как раз в схеме с тестерами и аналитикам не вижу гарантий качества. Аналитикам выгодно переусложнять требования и утяжелять процесс, так как это делает их все более значимыми и нужными. Тестерам же выгодно чтобы багов было больше и было бы меньше автоматизации, так как тогда без них просто никуда. А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное). I>>Тестировщики как раз заинтересованы в автоматизации — никому не нравится вручную кликать одно и то же. SK>Как не нравится? за это же деньги платят!
А вот так — не нравится. Однообразный механический труд никому не нравится. И тестировщики стремятся автоматизировать поиск регрессии. Руками надо только эксплорейтори выполнять.
Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс.
I>>Тестерам выгодно создавать не баги, а тест-кейсы и тест-планы. В нормальной организации именно так и делается. Т.е. решение проблем, а не просто количество чего то. Тестеры, они прикинь, тоже решаются решением проблем, а не просто чего то кликают. SK>Верю, верю. Но все же конфликт интересов никуда не пропадает — тестерам выгодно чтобы было больше работы. При этом совсем не значит, что они будут ее плохо делать. Делать могут на отлично, но много не нужного.
Нет конфликта интересов, если только начальство не сталкивает лбами и тех и других. И девелоперы, и тестеры заинтересованы в качестве продукта. Высокое качество — и те и другие занимаются новой работой. Низкое — и те и другие мусолят одно и то же по сотне раз.
I>>"начинают разводить руками и косится на других" — это похоже на локальный симптом, там где ты работаешь. SK>Это вы откуда взяли?
Здравствуйте, StanislavK, Вы писали:
SK>Тестеры не нужны, так как 100% бизнес логики мы тестируем автоматически. Да, не все приложения написаны так, что это возможно, но это их проблемы и так им и надо. SK>Когда же встает задача тестирования работы приложения при реальной коммуникации с другими системами, то там тоже нефиг тестеров брать — разрабы быстро выбешиваются от этого и пилят всякие приблуды, чтобы этого руками не делать.
Согласен.
Но, правды ради, надо оговориться, что фирмы есть разные и продукты у них разные, и задачи тестирования тоже очень разные.
Я напр. работал в фирме (платёжный шлюз), где отдел тестирования занимался в основном подключением клиентов к системе, созданием для них тестового
и рабочего окружения и проверки работы их с системой после этого. Это наверное 60% их работы.
Потому что фирма технологичная, и продукта внешнего почти нет, работа с клиентами только через технологические каналы.
Там их работа не то что незаменима -- она центральная.
Здравствуйте, Ikemefula, Вы писали:
I>>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ? SK>>Извиняюсь, но ничего не понял. То тестеры, то саппорт. I>Это и неудивительно — ты такими вопросами никогда не задавался.
Ну это грубо.
I>Кто контролирует девелоперов ?
Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.
I>Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр.
На то они и другие. Многие идустрии напрямую зависят от того, что люди каждый день делают ровно одно и то же, в таком случае индивидуальный вклад минимален. Если у вас есть конктерный сравнимый привмер, то его можно обсудить.
SK>>Вы не забывайте, что я не предлагаю отказаться от тестирования, я предлагаю отказаться от тестеров — за качество при этом на 100% отвечает разработчик. I>Это и есть проблема. Разработчик заинтересован в том, что бы все зависели от него. И качество будет падать, при чем обнаруживается это далеко не сразу.
Конечно, коненчо. Только это проблемы не только разработчика, это проблема всех кто участвует в процессе — и тестерова и аналитиков. Только когда есть тестеры и аналитики эти проблемы возникает в трех местах, соответственно контролировать их сложнее.
SK>>Как не нравится? за это же деньги платят! I>А вот так — не нравится. Однообразный механический труд никому не нравится. И тестировщики стремятся автоматизировать поиск регрессии. Руками надо только эксплорейтори выполнять. I>Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс.
Правду сказать, у нас тут диссонанс. Я верю в разработчиков и вижу примеры, когда они делают все эти вещи хорошо и эффективно. На мой взгляд гораздо более эффективно, чем если бы этим занимались отдельные люди. Причем благодаря тому, что они это делают сами, разработка становится быстрее. Они знают бизнес лучше, лучше понимаю фичи, соответственно далют их быстрее и "правильнее". Приложения становятся более дружелюбные для тестирования, так как разработчик с самого начала знает, что его ему надо будет тестированить. и т.д и т.п.
Вы же (как мне кажется, поправьте если не прав!) уверены, что разрабочик это узокнаправленный человек, конвеерный рабоник. Я ни разу не работал на проекте, где бы это было так.
I>>>Тестерам выгодно создавать не баги, а тест-кейсы и тест-планы. В нормальной организации именно так и делается. Т.е. решение проблем, а не просто количество чего то. Тестеры, они прикинь, тоже решаются решением проблем, а не просто чего то кликают. SK>>Верю, верю. Но все же конфликт интересов никуда не пропадает — тестерам выгодно чтобы было больше работы. При этом совсем не значит, что они будут ее плохо делать. Делать могут на отлично, но много не нужного. I>Нет конфликта интересов, если только начальство не сталкивает лбами и тех и других. И девелоперы, и тестеры заинтересованы в качестве продукта. Высокое качество — и те и другие занимаются новой работой. Низкое — и те и другие мусолят одно и то же по сотне раз.
Я же написал, что "При этом совсем не значит, что они будут ее плохо делать". Т.е. я совсем не утверждаю, что от тестеров будет страдать качество. Я говорю, что без них оно не будет хуже, если разработчики достаточно ответственны и понимают, что делают.
I>>>"начинают разводить руками и косится на других" — это похоже на локальный симптом, там где ты работаешь. SK>>Это вы откуда взяли? I>Прочел внимательно твои сообщения.
Проверил. Нет, я не писал такого.
Здравствуйте, StanislavK, Вы писали:
I>>>>Что значит много ? Вот тестеры, как независимые лица, и определяют, что много, а что мало. А если тестеров устранить, как предлагаешь решать проблемы ? Вот миллион долларов на суппорт это много или мало ? SK>>>Извиняюсь, но ничего не понял. То тестеры, то саппорт. I>>Это и неудивительно — ты такими вопросами никогда не задавался. SK>Ну это грубо.
Это факт. В нормальном проекте эти вопросы всегда подымаются. Кто решает, что продукт годен к релизу ? Кто решает, какие вещи можно отдать на суппорт ? На каком основании ? Как бизнес без тестеров решает, что качество должного уровня ?
В разработке тестировщики защищают сторону заказчика или бизнеса, а не исполнителя. Девелоперы — именно сторону исполнителя. Если тестировщиков убрать, то заказчик попадает в зависимость от девелоперов — девелоперы начинают диктовать условия. Бывает так, что девелоперы объясняют заказчику, что де проблемы имеют под собой объективные причины (юзеры не те, компы у юзеров не те, а что вы хотите и тд). Скажем, в энтерпрайзе такое может цвести не то что годами, а десятками лет. Например потому, что основной бизнес не может выбрать себе других исполнителей по ряду внутриполитических причин.
I>>Кто контролирует девелоперов ? SK>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое.
Интересно, как зарплата может проверить продукт на соответсвие требованиям ? Или Зарплата это имя индуса который вручную кликает ?
Пожалуйста, подробнее, а то я вижу, что ты говоришь про бонусы и стимулы, а не про контроль.
I>>Из опыта других индустрий оказывается, что исполнитель всегда плохой контролёр. SK>На то они и другие. Многие идустрии напрямую зависят от того, что люди каждый день делают ровно одно и то же, в таком случае индивидуальный вклад минимален. Если у вас есть конктерный сравнимый привмер, то его можно обсудить.
Недавно мы узнали, что под словом контроль ты понимаешь зарплату. Между тем контроль качества во всех индустриях это проверка на соответствие требованиям. Её выполняют люди. Исполнитель всегда и везде заинтересованое лицо, ему выгодно что бы проблемы не были найдены. Потому нужно найти то лицо, которому выгодно выявлять проблемы.
И вот парадокс — разработка и контроль в одном лице совмещаются плохо.
Для того, что бы это понять, нужно перестать называть контроль зарплатой и наоборот.
I>>Это и есть проблема. Разработчик заинтересован в том, что бы все зависели от него. И качество будет падать, при чем обнаруживается это далеко не сразу. SK>Конечно, коненчо. Только это проблемы не только разработчика, это проблема всех кто участвует в процессе — и тестерова и аналитиков. Только когда есть тестеры и аналитики эти проблемы возникает в трех местах, соответственно контролировать их сложнее.
Разумеется, сложнее. Зато и качество будет классом выше.
I>>Что характерно, девелоперы кое как справляются с автоматизацией, но у них весьма хилые тест-кейсы и тест-планы. А вот эксплорейтори у девелоперов отсутствует как класс. SK>Правду сказать, у нас тут диссонанс. Я верю в разработчиков и вижу примеры, когда они делают все эти вещи хорошо и эффективно.
А мы не обсуждаем веру. Где гарантия что твоё "эффективно" это то же самое "эффективно" что и у других людей ? Ну вот контроль у тебя есть эквивалент зарплаты. Эффективность ты тоже в своей зарплате меряешь ?
>На мой взгляд гораздо более эффективно, чем если бы этим занимались отдельные люди.
Как ты установил эту закономерность ?
SK>Вы же (как мне кажется, поправьте если не прав!) уверены, что разрабочик это узокнаправленный человек, конвеерный рабоник. Я ни разу не работал на проекте, где бы это было так.
Я даже не знаю, какой смысл ты в это вкладываешь.
SK>Я же написал, что "При этом совсем не значит, что они будут ее плохо делать". Т.е. я совсем не утверждаю, что от тестеров будет страдать качество. Я говорю, что без них оно не будет хуже, если разработчики достаточно ответственны и понимают, что делают.
Как у вас дела с эксплорейшн тестированием ? Кто из девелоперов занимается им неделями и месяцами, то есть, вообще все время ?
I>>>>"начинают разводить руками и косится на других" — это похоже на локальный симптом, там где ты работаешь. SK>>>Это вы откуда взяли? I>>Прочел внимательно твои сообщения. SK>Проверил. Нет, я не писал такого.
... А самое обидное, что в итоге проблемы продукта становятся "коллективной ответственностью" и все начинают разводить руками и косится на других, типа недотестили/неправильно записали/криво закодили (подчеренуть нужное).
Итак — ты уже начал отказываться от своих слов. Это говорит о том, что твоим словам цена около нуля и ты сам с этим согласен
Здравствуйте, Ikemefula, Вы писали:
I>>>Кто контролирует девелоперов ? SK>>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое. I>Интересно, как зарплата может проверить продукт на соответсвие требованиям ? Или Зарплата это имя индуса который вручную кликает ? I>Пожалуйста, подробнее, а то я вижу, что ты говоришь про бонусы и стимулы, а не про контроль.
Контроль? Тесты, многие тысячи тестов — покрыто все.
Здравствуйте, StanislavK, Вы писали:
SK>>>Зарплата, бонусы, гордость за то, что они делают. Все так же как у всех. Тестеров контролирует то же самое. I>>Интересно, как зарплата может проверить продукт на соответсвие требованиям ? Или Зарплата это имя индуса который вручную кликает ? I>>Пожалуйста, подробнее, а то я вижу, что ты говоришь про бонусы и стимулы, а не про контроль. SK>Контроль? Тесты, многие тысячи тестов — покрыто все.
Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те. Далее, если ты допишешь тест на символы, то оба твоих теста будут делать одно и тоже годами — длину строки и символы.
Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.
И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование ?
