Comments 129
Мировая практика усредняет этот показатель до 1:2
Как все печально в российском бизнесе производства ПО…
Я надеюсь на лучшее :)
В нероссийском не лучше, не волнуйтесь :)
Почему печально? У нас идеологически все построено так, что код или рабочий, или нерабочий. Трудноотловимых багов ничтожно мало. Зачем нам тестировщики? Проедать бюджет?
вот так неграмотные манагеры и рассуждают.
А потом: «У нас кризис, насяльника!»
А потом: «У нас кризис, насяльника!»
Так рассуждают уверенные в себе манагеры, которые проверили на собственном опыте сказанное. А вот бестолково проедать бюджет неэффективными работниками, это как раз в духе неграмотных манагеров.
"-А зачем он самогон гонит и народ спаивает?!
— Так а ты не пей"
Используйте тестеровщиков эффективно. Платите такие ЗП, за которые будут работать профессиональный QA вместо 3 ламеров
— Так а ты не пей"
Используйте тестеровщиков эффективно. Платите такие ЗП, за которые будут работать профессиональный QA вместо 3 ламеров
Вот, скажите, вы можете обвинить, например, Red Gate в неэффективности и проедании бюджета? А у них тестировщиков столько же, сколько и разработчиков (если не больше). В некоторых (наиболее эффективных) подразделениях Microsoft та же картина, кстати.
Структура их компании и их методы разработки не позволяют работать без тестировщиков. Но это не значит, что это самый эффективный способ разработки. Мысль понятна?
Мне понятно, что вам не понятно все, что за пределами вашей узенькой области.
Любой софт такого типа, ориентированный на массового пользователя, обязательно должен тестироваться. Это и есть самая эффективная модель разработки, как показывает практика. Ваш частный случай (причем, исключительно по вашим же словам, а верить вам у меня нет никакого основания) абсолютно ничего не доказывает, кроме разве что того, что или у вас captive market, или вообще рыночные механизмы конкуренции в вашем сегменте не действуют (типично для финансового сектора, особенно в постсовковых странах).
Так же мне понятно, что у вас весьма ограниченные представления о разработке софта вообще. Знаете, узкая специализация ещё никому не шла на пользу.
Любой софт такого типа, ориентированный на массового пользователя, обязательно должен тестироваться. Это и есть самая эффективная модель разработки, как показывает практика. Ваш частный случай (причем, исключительно по вашим же словам, а верить вам у меня нет никакого основания) абсолютно ничего не доказывает, кроме разве что того, что или у вас captive market, или вообще рыночные механизмы конкуренции в вашем сегменте не действуют (типично для финансового сектора, особенно в постсовковых странах).
Так же мне понятно, что у вас весьма ограниченные представления о разработке софта вообще. Знаете, узкая специализация ещё никому не шла на пользу.
Я разве говорил, что софт не должен тестироваться ни при каких обстоятельствах? Как мы любим перекручивать сказанное…
Вы говорите, что софт должны тестировать сами разработчики, и что «хорошая архитектура позволяет исключить баги». А чего они, разработчики, натестируют, всем хорошо известно. Так же как и известно, что самые гнусные баги всегда ныкаются в мелких деталях, которые никакая архитектура никогда на 100% учесть не сможет. Даже самая гениальная архитектура, супер-пупер языки с зависимыми типами и верификацией через HOL не защитят от банальной очепятки или от забытого при деплойменте файлишки.
И? Думаете, это найдут тестировщики? Им может год понадобиться для нахождения этой мифической баги. Я вашу мысль прекрасно понял. Ваш мир разработчика нереален без тестировщиков. Исходя из данной аксиомы все мои слова не имеют смысла и являются ложью по умолчанию.
Да, им может и год понадобиться. Бывает и такое. Вот пусть и ищут. Пять дней в неделю, восемь часов в день, в поте лица своего. Пока разработчики занимаются своим делом — код пишут, автоматизированные тесты, стресс-тесты, и т.п. А тестировщик должен найти то, что в голову разработчику даже и не придет.
И, да, ваши слова являются бездоказательными, потому как являются обобщением вашего личного опыта, единичного случая. Сравнение вашего опыта с опытом всей остальной индустрии, с опытом компаний неизмеримо более авторитетных чем ваша, будет всегда не в вашу пользу.
И, да, ваши слова являются бездоказательными, потому как являются обобщением вашего личного опыта, единичного случая. Сравнение вашего опыта с опытом всей остальной индустрии, с опытом компаний неизмеримо более авторитетных чем ваша, будет всегда не в вашу пользу.
Если бы я поступал всегда так, как делают другие, то вы бы меня не увидели на Хабре. Да и опыт всей индустрии не был показателям тем людям, которые изобрели XP (eXtreme Programming)
Индустрия разнообразна. На каждую хитрую практику всегда найдется множество готовых примеров применения. Только вот на практику экономии на тестировщиках позитивных примеров почему-то нет нигде. Почему ваш опыт не интересен я уже сказал — у вас явно весьма специфичный рынок, где качество и юзабельность продукта далеко не в первой десятке важных критериев.
И почему вы постоянно XP-практики пытаетесь противопоставить ручному тестированию? Они вообще-то совершенно не пересекаются и никак друг другу не мешают, они к разным областям разработки относятся.
И почему вы постоянно XP-практики пытаетесь противопоставить ручному тестированию? Они вообще-то совершенно не пересекаются и никак друг другу не мешают, они к разным областям разработки относятся.
Все мимо. Тему закрываю по причине, которая описана выше. Я ничего не смогу вам доказать, так как ваше обустройство мира не может допустить исключения тестировщиков из процесса разработки.
То есть, вы тупо слили. Это типично.
Конечно вы ничего мне не сможете доказать, потому что вы ничего и не доказываете, не пытаетесь даже. Вы только по кругу лепите одно и то же, что мол «у меня это работает, у меня это работает, ничего про других и слышать не желаю, я умный а они все дураки». Это на доказательство не тянет. Доказательство должно состоять из логически непротиворечивых и верифицируемых (и фальсифицируемых) аргументов, а не из anecdotical evidence.
Советики еще какие-то смешные с высокомерным апломбом даете, про «абстракции выделить». Вот только разработчики «аналитических систем для финансов» меня еще и не учили абстракции выделять, смешно даже. Вы ведь и не знаете, что такое абстракции. Вы и что такое «сложность» не знаете, как выяснилось, если свято верите что можно, грубо говоря, написать архиватор, который сто гигов сожмет в десять байт.
Конечно вы ничего мне не сможете доказать, потому что вы ничего и не доказываете, не пытаетесь даже. Вы только по кругу лепите одно и то же, что мол «у меня это работает, у меня это работает, ничего про других и слышать не желаю, я умный а они все дураки». Это на доказательство не тянет. Доказательство должно состоять из логически непротиворечивых и верифицируемых (и фальсифицируемых) аргументов, а не из anecdotical evidence.
Советики еще какие-то смешные с высокомерным апломбом даете, про «абстракции выделить». Вот только разработчики «аналитических систем для финансов» меня еще и не учили абстракции выделять, смешно даже. Вы ведь и не знаете, что такое абстракции. Вы и что такое «сложность» не знаете, как выяснилось, если свято верите что можно, грубо говоря, написать архиватор, который сто гигов сожмет в десять байт.
Кстати, со внимательностью у вас тоже проблемы. Я как раз сказал, что как раз в моем процессе независимое тестирование не используется, потому что просто ничем не поможет. И я прекрасно понимаю, что как раз мой случай нетипичен.
А вот более типичный случай, с которым мне приходится иметь дело — разработка компилятора. Есть стандарт, плоховато написанный, комитет постоянно публикует уточнения. Язык довольно большой и сложный, есть множество мелких деталей. Спрашивается, кто должен заниматься тестированием на соответствие букве стандарта — сами разработчики компилятора, отвлекаясь от своих непосредственных функций, или все же отдельная группа специалистов, ничем другим не занимающаяся? И какая такая «архитектура» этого самого компилятора позволит обойтись без тестирования и магическим образом реализовать все параграфы стандарта буква в букву?
А вот более типичный случай, с которым мне приходится иметь дело — разработка компилятора. Есть стандарт, плоховато написанный, комитет постоянно публикует уточнения. Язык довольно большой и сложный, есть множество мелких деталей. Спрашивается, кто должен заниматься тестированием на соответствие букве стандарта — сами разработчики компилятора, отвлекаясь от своих непосредственных функций, или все же отдельная группа специалистов, ничем другим не занимающаяся? И какая такая «архитектура» этого самого компилятора позволит обойтись без тестирования и магическим образом реализовать все параграфы стандарта буква в букву?
Вы так и не поняли мысль, которую я пытаюсь до вас донести. Если программер знает, что за ним потом будет еще проходиться тестер, то ошибка не будет иметь для него никакого значения. Ну есть она, ну и что, ведь есть тестер, который отловит все баги. Зачем читать внимательно спецификацию? Пусть тестер ее читает, ему за это деньги платят, а мое программерское дело маленькое — выполнять свои прямые обязанности.
По поводу компилятора. При транслировании одного языка в другой можно использовать промежуточный метаязык, который будет описывать именно спецификацию. Дальнейшая разработка потребует поддержания метаязыка в актуальном состоянии. Этот же метаязык будет помогать тестировать программистами код на максимум.
По поводу компилятора. При транслировании одного языка в другой можно использовать промежуточный метаязык, который будет описывать именно спецификацию. Дальнейшая разработка потребует поддержания метаязыка в актуальном состоянии. Этот же метаязык будет помогать тестировать программистами код на максимум.
Нет, это до вас так и не дошло то, о чем я говорю. Что работа тестировщика не в том, чтобы «ошибки» искать. Это тоже, да, но есть и гораздо более важные задачи, которые разработчик выполнить не может. Это и user experience testing (юзеры из разработчиков херовейшие получаются), и занудное тестирование на соответствие букве спецификации (мало какой разработчик сможет вогнать себя в ментальное состояние, позволяющее хотя бы осилить пару страниц какого либо стандарта).
Про метаязык для описания спецификации — фиг вам. Не бывает. Спецификации как правило пишутся идиотами. Они не поддаются какой либо формализации.
Так что вы тут не теоретизируйте. Теоретизирования не интересны. Сможете такой метаязык продемонстрировать — тогда будет о чем поговорить. Такой, чтобы, например, кривую и противоречивую спецификацию C99 мог описать.
Про метаязык для описания спецификации — фиг вам. Не бывает. Спецификации как правило пишутся идиотами. Они не поддаются какой либо формализации.
Так что вы тут не теоретизируйте. Теоретизирования не интересны. Сможете такой метаязык продемонстрировать — тогда будет о чем поговорить. Такой, чтобы, например, кривую и противоречивую спецификацию C99 мог описать.
Если разработчик не может изучить спецификацию, то что он может написать? Бред напишет, заведомо ошибочный код. Разработчики, это не только программисты, это в том числе и UI-дизайнеры. Если дизайнер не в состоянии придумать изначально удобный продукт, то толку его потом тестировать? И так понятно, что это будет отстой.
Про метаязык скажу просто. Тот кто хочет найти решение, ищет возможности. Кто не хочет его искать — ищет причины.
Про метаязык скажу просто. Тот кто хочет найти решение, ищет возможности. Кто не хочет его искать — ищет причины.
Ясно, вы не имеете ровным счетом ни малейшего представления о разработке компиляторов. Поздравляю. Упёртости, чванства и самоурвенности у вас хоть отбавляй — если бы еще знания были на том же уровне. Но обычно так не бывает.
Вы, кстати, уже облажались со страшной силой про алгоритмическую сложность. Теперь пытаетесь еще глубже опозориться, неся несусветную чушь про «метаязыки». Скажите честно, вам что, совсем, нисколечко не стыдно?
Вы, кстати, уже облажались со страшной силой про алгоритмическую сложность. Теперь пытаетесь еще глубже опозориться, неся несусветную чушь про «метаязыки». Скажите честно, вам что, совсем, нисколечко не стыдно?
Сможете доказать, что метаязык в компиляторе чушь?
Смотрите мой последний блогпост. Там используется метаязык для описания компилятора Си, в 3000 строк кода с комментариями.
Так что не буду доказывать, что это «чушь». В конце концов, метаязыки — это моя специальноть. А вот почему все не так просто с промышленными компиляторами я вам уже объяснял. Вы, как и положенно упертым и самоуверенным людям, читаете очень выборочно. С вами невозможно вести нормальную дискуссию, все неудобные вам аргументы вы просто игнорируете. Своих же аргументов, кроме anecdotical evidence, у вас нет вообще.
Так что не буду доказывать, что это «чушь». В конце концов, метаязыки — это моя специальноть. А вот почему все не так просто с промышленными компиляторами я вам уже объяснял. Вы, как и положенно упертым и самоуверенным людям, читаете очень выборочно. С вами невозможно вести нормальную дискуссию, все неудобные вам аргументы вы просто игнорируете. Своих же аргументов, кроме anecdotical evidence, у вас нет вообще.
Итак, я предложил вам использовать в качестве улучшения качества кода промежуточный метаязык. Вы сказали, что я несу чушь. Теперь вы говорите, что это не чушь, а ваша специальность?
Я специально читаю выборочно, чтобы не уводить тему в дебри, мало того, я не отвечают на провокации и оскорбления.
Я специально читаю выборочно, чтобы не уводить тему в дебри, мало того, я не отвечают на провокации и оскорбления.
На соседнее сообщение ответить слабо?
Читать выборочно — это хамство и глупость. Ну да с вами и так уже давно всем всё ясно.
Читать выборочно — это хамство и глупость. Ну да с вами и так уже давно всем всё ясно.
Кстати, вы еще и врунишка. Вы не предлагали использовать метаязык для «улучшения качества кода». Вы предложили его использовать как убер-панацею, которая сделает трудоемкое ручное тестирование ненужным. Разницу не видите? Ну да куда уж вам, вы же «аналитические системы» разрабатываете. Логика вам в работе не требуется, вот вы ей и не владеете.
Ну так что, кроме смешного чванливого бла-бла-бла, будет что либо конкретное?
Примерчики давайте в студию. Хотя бы одной реализации хотя бы одного компилятора, где использовался бы некий «метаязык», простой и компактный настолько, что разработчики легко отслеживают все изменения в стандарте не отвлекаясь от своих основных обязанностей, что из этого метаязыка генерятся полностью покрывающие все граничные случаи стресс-тесты, и при этом еще и нет никаких проблем с производительностью.
Конечно же я понимаю, что вы неграмотны, вы не знаете даже, что в любом промышленном компиляторе и никакой гламурный генератор парсеров неприменим, любой парсер крив, кособок и пишется руками, оптимизируется зверски. Какой уж там «метаязык», если даже синтаксис языка нельзя на хоть немного приличном DSL описать.
Что, будете снова свою чванку включать и заливаться, что мол вы там все дураки, а вот грамотный архитектор, руку набивший ажно на Аналитических Финансовых Системах (читать с придыханием) вам быстро бы придумал опупенные абстракции и гламурные метаязыки, из которых бы при этом генерился заоптимизированный до крайности код? Не советую. Не лезте в область, в которой вы настолько полный ноль.
И это я только про синтаксис. Семантику языка тоже, знаете ли, распрекрасно можно на красивом и простом метаязыке описать, благо, тема давно вдоль и поперёк изученная, способов описания операционной и денотационной семантик множество. Но только это будет игрушка. Идеально для reference implementation, неприминимо для практики. Ну да разработчики финансовой аналитики конечно же гораздо лучше всё знают, просто они настолько суровы, что знания при себе держат, на CiteSeer никаких следов по себе не оставляют.
Примерчики давайте в студию. Хотя бы одной реализации хотя бы одного компилятора, где использовался бы некий «метаязык», простой и компактный настолько, что разработчики легко отслеживают все изменения в стандарте не отвлекаясь от своих основных обязанностей, что из этого метаязыка генерятся полностью покрывающие все граничные случаи стресс-тесты, и при этом еще и нет никаких проблем с производительностью.
Конечно же я понимаю, что вы неграмотны, вы не знаете даже, что в любом промышленном компиляторе и никакой гламурный генератор парсеров неприменим, любой парсер крив, кособок и пишется руками, оптимизируется зверски. Какой уж там «метаязык», если даже синтаксис языка нельзя на хоть немного приличном DSL описать.
Что, будете снова свою чванку включать и заливаться, что мол вы там все дураки, а вот грамотный архитектор, руку набивший ажно на Аналитических Финансовых Системах (читать с придыханием) вам быстро бы придумал опупенные абстракции и гламурные метаязыки, из которых бы при этом генерился заоптимизированный до крайности код? Не советую. Не лезте в область, в которой вы настолько полный ноль.
И это я только про синтаксис. Семантику языка тоже, знаете ли, распрекрасно можно на красивом и простом метаязыке описать, благо, тема давно вдоль и поперёк изученная, способов описания операционной и денотационной семантик множество. Но только это будет игрушка. Идеально для reference implementation, неприминимо для практики. Ну да разработчики финансовой аналитики конечно же гораздо лучше всё знают, просто они настолько суровы, что знания при себе держат, на CiteSeer никаких следов по себе не оставляют.
Методология юнит-тестирования, которую проповедует XP, не является серебрянной пулей и не сопособна защитить от всех багов. Юнит-тесты никогда не заменят живых тестировщиков. Оба подхода должны дополнять друг друга, особенно для крупных проектов.
Вы не поверите, но тестировщики тоже не в состоянии найти все баги.
Правильно, раз тестировщики не в состоянии найти все баги, давайте их всех уволим, раз юнит-тесты не в состоянии отловить все баги, давайте не будем писать юнит-тесты… список можно продолжать бесконечно.
Я так понимаю вы изобрели свой мегапроцесс, который позволяет полностью исключить возможность возникновения багов? Предоставьте пожалуйста на суд публике статью с описанием такого процесса, чтоб все заткнулись и поняли, что устоявшиеся мировые практики по разработке ПО это УГ, и надо делать по вашему.
Я так понимаю вы изобрели свой мегапроцесс, который позволяет полностью исключить возможность возникновения багов? Предоставьте пожалуйста на суд публике статью с описанием такого процесса, чтоб все заткнулись и поняли, что устоявшиеся мировые практики по разработке ПО это УГ, и надо делать по вашему.
уважаемый собеседник, вы, вероятнее всего, экономист. Ну уж точно разработка это не ваша основная профессия. Иначе бы вы знали, что разработчик не должен и НЕ МОЖЕТ тестировать вообще свой продукт (ну кроме разумных приделов соответствия задаче), потому что подсознательно он уверен, что все написал правильно и ошибки нет. Вот соседский код может тестить, а свой — нет. Это Майерс еще 30 лет назад описал в своей книги по тестированию. Вот такая вот досада.
Вы, безусловно, можете иметь свою точку зрения, но чем раньше вы поймете, что ошибаетесь и просто жадничаете, тем быстрее дела пойдут куда лучше. Зря вы уперлись, вы наверное даже не подозреваете, что вами и вашим подходом в коллективе могут быть недовольны, а проект задыхается без команды тестеров, которые нужны чтобы сломать продукт, а не прожрать деньги.
А архитектура вообще ни какого отношения к мелкобаговой надежности не имеет и иметь не может. Потому что баги рождает реализация (с учетом того, что архитектор не школьник и понимает что делает в целом)
Вы, безусловно, можете иметь свою точку зрения, но чем раньше вы поймете, что ошибаетесь и просто жадничаете, тем быстрее дела пойдут куда лучше. Зря вы уперлись, вы наверное даже не подозреваете, что вами и вашим подходом в коллективе могут быть недовольны, а проект задыхается без команды тестеров, которые нужны чтобы сломать продукт, а не прожрать деньги.
А архитектура вообще ни какого отношения к мелкобаговой надежности не имеет и иметь не может. Потому что баги рождает реализация (с учетом того, что архитектор не школьник и понимает что делает в целом)
Что же вы так катигорично? Может у вас продукт не нуждающийся в тестировании? Вот например клепать сайты визитки на готовой CMS можно вполне без тестеров… все тесты ограничеваются проверкой не поползла ли верстка и делаются верстальщиком.
А вот писать саму CMS уже лучше с тестерами. Вообще с усложнением продукта разработчик не в состоянии все держать под контролем, и может не осознавать каких-то граничных условий.
А вы какой продукт делаете?
А вот писать саму CMS уже лучше с тестерами. Вообще с усложнением продукта разработчик не в состоянии все держать под контролем, и может не осознавать каких-то граничных условий.
А вы какой продукт делаете?
А что вы разрабатываете, если не секрет?
Аналитический комплекс для фин. учреждений. Избавиться от багов можно не только при помощи тестеров, но и при помощи архитектуры системы. А об этом мало кто думает.
Тестирование вовсе не только для отлова багов нужно. Например, если у вас есть хоть какой либо пользовательский интерфейс, то необходимо непрерывное user experience-тестирование. Вы его не делаете? Мне жалко ваших пользователей.
Да и, знаете ли, позвольте не поверить, что у вас архитектура решает все потенциальные проблемы. Так не бывает.
Да и, знаете ли, позвольте не поверить, что у вас архитектура решает все потенциальные проблемы. Так не бывает.
Наши внутренние требования к UI гораздо выше тех, что предоставляют наши пользователи. И мы лучше них знаем, что им лучше. И ни разу еще никто не жаловался.
Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем.
Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем.
Пользователи не жалуются, потому как привыкли. Очень мало софта, который разрабатывается с правильным процессом, с участием UX-engineers, с корректным тестированием. Вот например вы даже не понимаете, что разработчики в принципе, никогда и ни при каких обстоятельствах это тестирование делать сами не могут, и что их вклад даже в само проектирование интерфейса должен быть весьма ограниченным. Никогда человек, знающий хорошо внутреннее устройство какой либо системы не сможет придумать или даже просто оценить хороший интерфейс, понятный тому, кто внутренностей системы не знает и не представляет себе.
"Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем."
Не верю. Абсолютно. Потому как прекрасно знаю, что без тестирования проблемы будут даже в полностью аннотированном, верифицированном коде с абсолютно идеальной архитектурой. Потому как общая архитектура никогда не может учитывать гнусные мелкие честности. Те, которые только при тестировании и выявляются.
Конечно, возможно что ваш продукт просто очень примитивен. Но мне сложно представить себе что-то хоть немного сложнее чем «Hello, world!», что не нуждалось бы в независимом (то разработчиков) тестировании.
"Архитектура решает. И наши конкуренты убедились в этом на своей шкуре. Можете не верить мне, это ваше полное право, но подумайте на досуге, из-за чего у вас возникает 95% проблем."
Не верю. Абсолютно. Потому как прекрасно знаю, что без тестирования проблемы будут даже в полностью аннотированном, верифицированном коде с абсолютно идеальной архитектурой. Потому как общая архитектура никогда не может учитывать гнусные мелкие честности. Те, которые только при тестировании и выявляются.
Конечно, возможно что ваш продукт просто очень примитивен. Но мне сложно представить себе что-то хоть немного сложнее чем «Hello, world!», что не нуждалось бы в независимом (то разработчиков) тестировании.
Разработчики ни при каких условиях не должны заниматься проектированием интерфейсов. Ибо напроектируют такого… На своей шкуре убедился.
Я разве говорил, что тестирование бессмысленно или не нужно? Приведенный пример выявят спокойно и разработчики на момент разработки.
Вы можете сколь угодно долго думать про сложность нашего проекта, хотя я предлагаю вам подумать над вашим проектом. Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте. Если есть желание, напишите их в комментариях, и я расскажу как это можно решить.
Те, которые только при тестировании и выявляются.
Я разве говорил, что тестирование бессмысленно или не нужно? Приведенный пример выявят спокойно и разработчики на момент разработки.
Вы можете сколь угодно долго думать про сложность нашего проекта, хотя я предлагаю вам подумать над вашим проектом. Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте. Если есть желание, напишите их в комментариях, и я расскажу как это можно решить.
"Разработчики ни при каких условиях не должны заниматься проектированием интерфейсов. Ибо напроектируют такого… На своей шкуре убедился."
Правильно. Ну а кто у вас этим тогда занимается? UX-инженеры? И они не проводят всего положенного по их науке тестирования? Не верю.
Я разве говорил, что тестирование бессмысленно или не нужно?
Да, именно это вы и говорили. Что тестировать можно силами самих разработчиков, и специальных, отдельных людей для этого вовсе не требуется.
Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте.
Основные причины: недостаточно достоверные и полные спецификации на используемые стандарты (как следствие — требуется очень много тестирования, к счастью автоматизируемого, и много reverse engineering), банально очень высокая алгоритмическая сложность (тут больше формальная верификация помогает и автоматизированные тесты), тупость и безалаберность разработчиков (не лечится, меня головой вниз роняли и с тех пор я такой). Этому проекту тестировщики ничем не помогут. Но это специфичный и редкий случай, там даже UI нет. А вот 99% других проектов, с которыми я имел когда либо дело, многое выигрывают от выделенных тестировщиков, не знающих ничего про внутреннее устройство проекта.
Правильно. Ну а кто у вас этим тогда занимается? UX-инженеры? И они не проводят всего положенного по их науке тестирования? Не верю.
Я разве говорил, что тестирование бессмысленно или не нужно?
Да, именно это вы и говорили. Что тестировать можно силами самих разработчиков, и специальных, отдельных людей для этого вовсе не требуется.
Возьмите листок и ручку, и запишите все причины, по которым возникают ошибки в вашем проекте.
Основные причины: недостаточно достоверные и полные спецификации на используемые стандарты (как следствие — требуется очень много тестирования, к счастью автоматизируемого, и много reverse engineering), банально очень высокая алгоритмическая сложность (тут больше формальная верификация помогает и автоматизированные тесты), тупость и безалаберность разработчиков (не лечится, меня головой вниз роняли и с тех пор я такой). Этому проекту тестировщики ничем не помогут. Но это специфичный и редкий случай, там даже UI нет. А вот 99% других проектов, с которыми я имел когда либо дело, многое выигрывают от выделенных тестировщиков, не знающих ничего про внутреннее устройство проекта.
Я вижу, вы любитель сложных путей.
Читайте про экстремальное программирование, особенно главу под названием Разработка через тестирование (Test driven development)
Их кто-то написал. Сотрудничайте с авторами спецификаций и стандартов.
Решается архитектурой проекта. Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
Решается путем смены состава, налаживанием информационных потоков, тренингами.
Читайте про экстремальное программирование, особенно главу под названием Разработка через тестирование (Test driven development)
недостаточно достоверные и полные спецификации на используемые стандарты
Их кто-то написал. Сотрудничайте с авторами спецификаций и стандартов.
банально очень высокая алгоритмическая сложность
Решается архитектурой проекта. Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
тупость и безалаберность разработчиков
Решается путем смены состава, налаживанием информационных потоков, тренингами.
Я вижу, вы любитель сложных путей.
Нет. Я же написал — я туп и ленив. Мне нужны пути наименьшего сопротивления при наилучшем результате.
Разработка через тестирование (Test driven development)
Давайте только юнит-тесты не приплетать сюда. Мы про совсем другое говорим.
Сотрудничайте с авторами спецификаций и стандартов.
Думаете, эти люди из Microsoft сами всякие мелкие детали знают лучше, чем они же про них соврали в спецификации? Я с ними сотрудничаю. Полезно. Но не решает проблемы в целом. Полного знания нет ни у кого.
Решается архитектурой проекта.
Не решается. Вы представляете себе, что такое сложность? Почитайте Колмогорова, Чейтина, да хотя бы Эша. Есть такое понятие, как количество информации. Меньше и проще определенного предела без потерь не получится, таково фундаментальное свойство Вселенной.
Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
Это всё способы устранения шума из данных. Таким образом мы получаем чистую информацию. Сложность в чистом виде, без лишних примесей. Для задач, в которых настоящей сложности нет, но есть много шума, это работает идеально. Для случая, когда истинная сложность высока, не поможет ничто. У меня и так всё сделано в виде иерархии из более чем десятка eDSL, каждый из которых туп как пробка и решает свою отдельную маленькую задачу. Никаких текучих абстракций, ничего лишнего — чистейшее математическое выражение самой сути задачи. И эта суть весьма сложная.
Нет. Я же написал — я туп и ленив. Мне нужны пути наименьшего сопротивления при наилучшем результате.
Разработка через тестирование (Test driven development)
Давайте только юнит-тесты не приплетать сюда. Мы про совсем другое говорим.
Сотрудничайте с авторами спецификаций и стандартов.
Думаете, эти люди из Microsoft сами всякие мелкие детали знают лучше, чем они же про них соврали в спецификации? Я с ними сотрудничаю. Полезно. Но не решает проблемы в целом. Полного знания нет ни у кого.
Решается архитектурой проекта.
Не решается. Вы представляете себе, что такое сложность? Почитайте Колмогорова, Чейтина, да хотя бы Эша. Есть такое понятие, как количество информации. Меньше и проще определенного предела без потерь не получится, таково фундаментальное свойство Вселенной.
Введите дополнительный уровень абстракции, не решайте задачу в лоб, разбивайте сложное на много простого, и т.д. и т.п.
Это всё способы устранения шума из данных. Таким образом мы получаем чистую информацию. Сложность в чистом виде, без лишних примесей. Для задач, в которых настоящей сложности нет, но есть много шума, это работает идеально. Для случая, когда истинная сложность высока, не поможет ничто. У меня и так всё сделано в виде иерархии из более чем десятка eDSL, каждый из которых туп как пробка и решает свою отдельную маленькую задачу. Никаких текучих абстракций, ничего лишнего — чистейшее математическое выражение самой сути задачи. И эта суть весьма сложная.
Помни манагер: нет программ, в которых нет ошибок, есть те, которые плохо тестировались!
Мне кажется проблема в специфике. Продуктов или проектов не слишком много разрабатывается в России. Чаще аутосрсятся целиком программистские коллективы, а тестировщики заказываются отдельно.
Плюс к этому было бы интересно узнать корреляцию Количество работников — процент из них тестеров. Коллектив в до 5 человек не очень выгодно нанимать еще и тестера. И если моя гипотеза верна, то результаты опроса показывают, что большая часть аудитории хабра — студенты, фрилансеры, работники маленьких фирмочек.
Плюс к этому было бы интересно узнать корреляцию Количество работников — процент из них тестеров. Коллектив в до 5 человек не очень выгодно нанимать еще и тестера. И если моя гипотеза верна, то результаты опроса показывают, что большая часть аудитории хабра — студенты, фрилансеры, работники маленьких фирмочек.
ОМГ, все катастрофично, я смотрю, по результатам опроса О_О
ну а что, в фейсбуке вот нет QA отдела. есть юнит-тесты и пользователи, кто еще нужен? =))
Не думаю, что с увеличением голосов, что-то координально изменится. По-прежнему будут лидиловать два последних пункта, причем последний выйграет, потому что большинству компаний не выгодно держать отдельного тестировщика, когда то же самое могут делать рядовые люди за «спасибо».
Работаю в ISP — «тестировщиков» больше 30 000. Баги ловят быстро.
www.theinquirer.net/inquirer/news/1720797/facebook-qa-team
ну кроме того, Andrew Bosworth на РИТе в этом году лично рассказывал об этом. Кратко: «Делаем фичу, выкатываем на стейджинг, юниттесты, если надо — стресстесты, смотрим сами мельком, если всё ок — выкладываем на маленькую долю пользователей, миллиона на три =), очень быстро собираем фидбэк и либо фиксим, либо откатываем, короче действуем по ситуации. Все критичные вещи покрываются юниттестами, поэтому шанс нарваться на серьезную ошибку немногим больше, чем при тщательном функциональном тестировании».
в свою очередь могу сказать, что это работает, мы проверяли и по крайней мере вывели для себя очень большую важность экспериментов на долях аудитории и важность сбора фидбэка. но qa у нас все же есть, я ответил «менее 20%».
ну кроме того, Andrew Bosworth на РИТе в этом году лично рассказывал об этом. Кратко: «Делаем фичу, выкатываем на стейджинг, юниттесты, если надо — стресстесты, смотрим сами мельком, если всё ок — выкладываем на маленькую долю пользователей, миллиона на три =), очень быстро собираем фидбэк и либо фиксим, либо откатываем, короче действуем по ситуации. Все критичные вещи покрываются юниттестами, поэтому шанс нарваться на серьезную ошибку немногим больше, чем при тщательном функциональном тестировании».
в свою очередь могу сказать, что это работает, мы проверяли и по крайней мере вывели для себя очень большую важность экспериментов на долях аудитории и важность сбора фидбэка. но qa у нас все же есть, я ответил «менее 20%».
это был коммент для @blv. промахнулся
Спасибо :) Но заголовок согласитесь немного желтоват, народ фактически занимается QA, ведь пишут функциональные тесты (модульные я все-таки отношу к девелоперской деятельности).
ну мне кажется заголовок очень точен: у фейсбука нет qa-team. и действительно, никакой выделенной команды нет.
то что разработчики пишут юнит-тесты и даже немножко автоматические функциональные тесты (их совсем не много, основной упор на юнит-тесты), это не делает из разработчиков QA. это просто делает разработчиков более хорошими =)
основная идея фейсбука в том, что для крупных веб-проектов основным тестером является пользователь и миллион пользователей делает это быстро и бесплатно. сложность только в сборе качественного фидбэка.
некоторые крупные проекты отечественного рунета тоже так делают. особенно любопытна идея оптимизации UI важных страниц: миллион пользователей своим ctr за несколько часов скажут вам об эффективности изменений в UI больше и точнее, чем серьёзная юзабилити-экспертиза =)
то что разработчики пишут юнит-тесты и даже немножко автоматические функциональные тесты (их совсем не много, основной упор на юнит-тесты), это не делает из разработчиков QA. это просто делает разработчиков более хорошими =)
основная идея фейсбука в том, что для крупных веб-проектов основным тестером является пользователь и миллион пользователей делает это быстро и бесплатно. сложность только в сборе качественного фидбэка.
некоторые крупные проекты отечественного рунета тоже так делают. особенно любопытна идея оптимизации UI важных страниц: миллион пользователей своим ctr за несколько часов скажут вам об эффективности изменений в UI больше и точнее, чем серьёзная юзабилити-экспертиза =)
Борис, а как это происходит у вас в компании? Не хотите в блог Софтлайна перенести? :)
Вот тут можно ознакомиться с результатами аналогичного исследования:
jnechaeva.blogspot.com/2009/10/blog-post.html
jnechaeva.blogspot.com/2009/10/blog-post.html
На блог Юлии подписан, на www.software-testing.ru тоже, но за ссылку спасибо, там информация очень структурирована :)
У нас к каждому разработчику на время проекта или части проекта привязан тестировщик. И постоянная ротация, чтоб не застаивалось это все.
Придерживаюсь мнения что профессиональных тестировщиков должно быть не меньше чем программеров. Т.к. качественно протестировать новую функциональность занимает не меньше, а то и больше времени чем ее разработка.
Чем плохи пользователи как тестеры — это тем что их нельзя заставить что-то сделать. Качество тестирования «бета-тестеров» оставляет желать лучшего.
Чем плохи пользователи как тестеры — это тем что их нельзя заставить что-то сделать. Качество тестирования «бета-тестеров» оставляет желать лучшего.
«Тестировщиков больше, чем разработчиков» и «Тестировщиков 80-60% от количества разработчиков» в чем разниться?
> в чем разниться
ОМГ :).
ОМГ :).
Фух, я думал что это у меня на работе только программисты сами тестируют как могут.
Даже как-то обидно, что так много где еще
Даже как-то обидно, что так много где еще
у нас количество тестировщиков может быть больше в 2-3 раза, но они сопровождают проект только от беты до релиза (+ патчи если есть)…
У нас в команде сейчас 8 разработчков и 9 тестеров. Впрочем, некоторые тестеры сочетают тестирование с бизнес-анализом и общением с заказчиками.
Я думаю, оптимальное соотношение сильно зависит от специфики продукта, над которым работает команда — то, что работает для сайта с миллионной аудиторией не очень подходит для продукта, написанного на заказ для крупной организации и наоборот.
Я думаю, оптимальное соотношение сильно зависит от специфики продукта, над которым работает команда — то, что работает для сайта с миллионной аудиторией не очень подходит для продукта, написанного на заказ для крупной организации и наоборот.
А сфера деятельности, если не секрет?
Софт для рассчета зарплат и биллинга для клиентов в крупных юридических конторах США. Продукт почти коробочный — заказчиков много, но практически с каждым работа идет индивидуально. Определенное бета-тестирование у заказчика конечно проводится, но цена ошибки довольно большая, поэтому у тестировщиков работы много и она очень важная.
у нас количество тестировщиков может быть больше в 2-3 раза, но они сопровождают проект только от беты до релиза (+патчи, если есть)…
В лучших домах лондона и парижа принято делать юнит тестирование прямо на уровне проекта. Для тестирования GUI тоже пишутся тесты. «Живые» тестировщики конечно тоже нужны, но если все сделано по уму (реализованы автоматические тесты на самых разных уровнеях комплекса), то их процент будет крайне мал (порядка 10%).
Программер не может написать нормальный автотест. Менталитет не тот. А тестер может, но если его 10% то не успеет.
Не согласен. Внутренние тесты должен писать ТОЛЬКО сам разработчик. Причем при нахождении нового бага должен писаться сначала сам тест, а потом уже исправляться сама бага. А вот тестер как раз не будет вникать во внутренную структуру кода. Максимум что он сможет сделать — это протыкать GUI и сравнить результат с ожидаемым.
О каких тестах речь? О юнитах или о функциональных? Первые никто кроме самих разработчиков написать не сможет в принципе, а вот автоматизация вторых как раз и заключается в том чтобы автоматизировать тыканье ГУЯ.
О юнитах или о функциональных? Первые никто кроме самих разработчиков написать не сможет в принципе
Я пишу тоже самое :))
а вот автоматизация вторых как раз и заключается в том чтобы автоматизировать тыканье ГУЯ.
Не всегда. Для тестирования GUI тоже есть автоматические инструменты.
А это ничего, что ГУЙ должен быть не только тыкабелен, но и юзабелен? А чтобы он был юзабельным и нужны тестеры. Разработчики дальше тыкабельности никогда не пойдут.
А это ничего, что ГУЙ должен быть не только тыкабелен, но и юзабелен? А чтобы он был юзабельным и нужны тестеры
Для этого нужны проектировщики взаимодействия и специалисты по юзабилити, а не тестировщики. Причём их работа происходит до того как будет написана первая строчка кода, а когда программа уже написана о юзабилити думать уже поздно. Так что тестировщики тут ничем не помогут, разве что сделают запрос на косметические улучшения.
Хоть кто-то понимает ошибки проектирования…
Зачем говорите глупостями? Зачем свой куцый частный опыт проецируете?
Во первых, специалисты по юзабилити обязаны быть тестировщиками. Вам понятие user experience testing ничего не говорит? Во вторых, часто GUI появляется намного позже, чем функциональность. Если вы ничем кроме самого примитивного формошлепства не занимались, то вряд ли поймете, почему оно так бывает.
Во первых, специалисты по юзабилити обязаны быть тестировщиками. Вам понятие user experience testing ничего не говорит? Во вторых, часто GUI появляется намного позже, чем функциональность. Если вы ничем кроме самого примитивного формошлепства не занимались, то вряд ли поймете, почему оно так бывает.
Вам понятие user experience testing ничего не говорит?
Говорит, это когда писали, писали программу, уже почти дописали и вдруг как вспомнили «А ей же люди будут пользоваться», «рюшечек» на самые уродливые места понавесили и поставили штамп «User Friendly».
Никто на этапе тестирования не даст менять концепцию UI, т.к. это будет стоить в 2 раза больше, чем то что уже есть.
А вот Вам понятие Interaction Design явно не знакомо. Советую ознакомиться.
часто GUI появляется намного позже, чем функциональность.
А кто спорит, именно из-за такого подхода большинство программ имеют уродский GUI. Всем известна гонка функциональных возможностей, которыми пользуются от силы 0.1% пользователей, зато остальных 99.9% эти излишние функции только в тоску вгоняют.
Только при таком херовом подходе к разработке, никакое тестирование уже не поможет.
Опять глупостями разговариваете. Когда ж словами говорить научитесь?
Вы узколобо упускаете множество вариантов. Например:
— Никакого GUI не было, но вдруг потребовалось таковой прикрутить
— GUI было, но концепция поменялась и GUI приходится переделывать
Вы очевидно мыслите в терминах проектов, где 90% функциональности это UI. Я говорю про проекты, где на долю UI приходится 1-5%.
Вы узколобо упускаете множество вариантов. Например:
— Никакого GUI не было, но вдруг потребовалось таковой прикрутить
— GUI было, но концепция поменялась и GUI приходится переделывать
Вы очевидно мыслите в терминах проектов, где 90% функциональности это UI. Я говорю про проекты, где на долю UI приходится 1-5%.
Доверить проектирование GUI тестеру — всё равно что доверить обезьяне управлять танком и не важно какой процент от кода приходится на долю UI, на его долю в любом случае приходится 100% взаимодействия с пользователем.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
Научитесь уже проигрывать в споре достойно. Ваша точка зрения уже давно признана в корне ошибочной. Обратитесь уже наконец к мировому опыту IxDA, если ума хватит.
Вот вы опять. Я не говорил, что тестер должен «разрабатывать» GUI. Он должен участвовать в его проектировании, на каждом этапе. GUI надо начинать тестировать на живых людях еще когда он существует в виде картинок в тетрадке.
И проиграли именно вы. Вы несете несусветную чушь, да еще и с чванством и с апломбом. Это глупо. Ваше примитивное мнение не имеет абсолютно ничего общего с устоявшимися в мире практиками.
И проиграли именно вы. Вы несете несусветную чушь, да еще и с чванством и с апломбом. Это глупо. Ваше примитивное мнение не имеет абсолютно ничего общего с устоявшимися в мире практиками.
Если под внутренними тестами подразумевать юнит, то соглашусь что это дело программера, но все равно мне кажется что необходимо периодически проводить тренинги программистов на тему правильного покрытия кода юнитами.
Тестеры тоже вникают во внутреннюю структуру кода. У меня также на компе стоит студия, и я также как и программеры копаюсь в коде, это залог успешного тестирования, белый ящик+черный ящик.
Тестеры тоже вникают во внутреннюю структуру кода. У меня также на компе стоит студия, и я также как и программеры копаюсь в коде, это залог успешного тестирования, белый ящик+черный ящик.
А вы понимаете разницу в тестировании, что делает QA и что делают юнит тесты? :)
Не согласен. Внутренние тесты должен писать ТОЛЬКО сам разработчик. Причем при нахождении нового бага должен писаться сначала сам тест, а потом уже исправляться сама бага. А вот тестер как раз не будет вникать во внутренную структуру кода. Максимум что он сможет сделать — это протыкать GUI и сравнить результат с ожидаемым.
У нас, к сожалению, еще приходиться за тестировщиками проверять.
Так гнать таких, делов-то.
Будь моя воля… :))
Кстати не так-то просто найти хороших QA'щиков. Это должны быть люди, которые умеют мыслить out of the box. А так как зарплата невысокая, то мало подходящего народа в это дело идет.
Кстати не так-то просто найти хороших QA'щиков. Это должны быть люди, которые умеют мыслить out of the box. А так как зарплата невысокая, то мало подходящего народа в это дело идет.
Я, честно говоря, уже давно не сталкивался с тем, чтобы тестировщикам платить сколь-либо заметно меньше чем разработчикам (регион — Киев).
У нас в полтора-два раза (регион Иерусалим)
Поэтому и тестировщики у вас такие, которые в полтора-два раза хуже хороших :)
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам, а потом говорить: «тестировщики чего-то у нас не тянут, а те кто получше почему-то уходят (в другие компании, в разработчики, вообще из ИТ)».
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам, а потом говорить: «тестировщики чего-то у нас не тянут, а те кто получше почему-то уходят (в другие компании, в разработчики, вообще из ИТ)».
Ну, им все равно платят от $2,5К до $3,5К. Не так уж и мало, просто девелоперы все равно получают больше.
Инженер и фрезеровщик тоже по разному зарабатывают.
Инженер и фрезеровщик тоже по разному зарабатывают.
Вы, наверное, здесь сравниваете программистов с инженерами, а тестеров с фрезеровщиками, правильно?
На мой же взгляд (у меня был небольшой опыт работы программистом — ушёл так как скучно было) — работа тестера более интересная и творческая, чем работа программиста. Причём, я слышал подобные высказывания от других людей, работающих в тестировании, способных писать код и попробовавших и то и другое.
Но думаю, что дело даже не в самой работе, а в предласположенности людей к той или иной профессии. И поэтому в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники, одни из которых специализируются на написании кода (программисты) и которые понимают, что тестирование вовсе не «прокликать GUI», а другие специализируются на поиске багов (тестеры), но если надо могут и код поревьювить. И те и другие — разработчики называются.
На мой же взгляд (у меня был небольшой опыт работы программистом — ушёл так как скучно было) — работа тестера более интересная и творческая, чем работа программиста. Причём, я слышал подобные высказывания от других людей, работающих в тестировании, способных писать код и попробовавших и то и другое.
Но думаю, что дело даже не в самой работе, а в предласположенности людей к той или иной профессии. И поэтому в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники, одни из которых специализируются на написании кода (программисты) и которые понимают, что тестирование вовсе не «прокликать GUI», а другие специализируются на поиске багов (тестеры), но если надо могут и код поревьювить. И те и другие — разработчики называются.
в нормальных компаниях нет кланов разработчиков и тестировщиков, а есть айтишники
Не знаю почему отделы стали называться кланами, но «айтишники» — это полный аут…
Если в компании работают люди без определённых должностных обязанностей, которые и принтер чинят, и баги ищут, да ещё и код ревьювят, то ничего нормального в такой компании нет.
Где написано, что нет должностных обязанностей?
Возможно вы не поверите, но бывают тестировщики которые понимают код программы или которые вместе с программистами и руководителями проекта совместно разрабатывают программу или находят место в коде где сломано или предлагают варианты решения проблемы или пишут небольшие программы позволяющие локализовать ошибки. Нет, они не пишут код продукта — это задача программистов, но участвуют в обсуждении архитектуры или функциональной наполнености продукта. Поэтому я и говорю, что и те и другие — разработчики.
Если вам не повезло встретиться с такими — не отчаивайтесь, как только попадёте в компанию, где тестировщикам платят достойную зп — сразу поймёте.
Возможно вы не поверите, но бывают тестировщики которые понимают код программы или которые вместе с программистами и руководителями проекта совместно разрабатывают программу или находят место в коде где сломано или предлагают варианты решения проблемы или пишут небольшие программы позволяющие локализовать ошибки. Нет, они не пишут код продукта — это задача программистов, но участвуют в обсуждении архитектуры или функциональной наполнености продукта. Поэтому я и говорю, что и те и другие — разработчики.
Если вам не повезло встретиться с такими — не отчаивайтесь, как только попадёте в компанию, где тестировщикам платят достойную зп — сразу поймёте.
это уже не тестировщики
Во! Как раз именно это-то и есть тестировщики.
Я вам и пытаюсь показать, что в мире уже давно начали происходить изменения. «Мир сдвинулся» (с) С. Кинг.
Просто, к сожалению, многие считают, что тестировщики сидят в отдельной комнате, ничего не знают, ничего не умеют, делают что-то странное (монотонно раз за разом прокликивают ГУЙ по спекам), но иногда пишут баги. И этом, отчасти, есть и вина тестировщиков.
Я вам и пытаюсь показать, что в мире уже давно начали происходить изменения. «Мир сдвинулся» (с) С. Кинг.
Просто, к сожалению, многие считают, что тестировщики сидят в отдельной комнате, ничего не знают, ничего не умеют, делают что-то странное (монотонно раз за разом прокликивают ГУЙ по спекам), но иногда пишут баги. И этом, отчасти, есть и вина тестировщиков.
Очень похоже, что Вы описываете должность, совмещающую обязанности инженера по качеству, больше известны как QA, и бизнес-аналитика (Business Analyst). Только это аж 2 другие профессии. Тестировщики (Software Test Engineer) не должны заниматься тем, что вы выше указали, это не входит в их должностные обязанности.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
Кстати, мне довелось работать в компании, где были представители всех 3 вышеназванных профессий, вот там бюрократия то была… хотя сейчас не об этом. Они кстати все отличались и по уровню знаний и по уровню зарплат.
Поэтому мне в голову не приходило, что вы под тестировщиками имеете в виду людей, которые по вашему описанию аж на 3 ставки (SwT, QA, BA) работают. Я всё-таки считаю такое именование абсолютно некорректным.
Меня вообще такой подход удивляет — давайте будем платить тестировщикам в полтора, в два, в три раза меньше чем разработчикам
А что плохого в том, чтобы платить тестировщикам в 1.5 раза меньше, чем программистам? Это всё-таки разные профессии, с разными требованиями по квалификации. Причём квалификация программиста включает квалификацию тестировщика как небольшое подмножество. Поэтому программисты и не любят выполнять функции тестировщиков, т.к. для них они слишком скучны и неинтересны, в силу своей тривиальности… Правда, ещё нужно учитывать, что программист может тестировать только те проекты или те части проекта, над которыми сам не работает.
К тому же экономическая сообразность QA отделов сводится как раз к тому, чтобы снять с программистов задачи интеграционного и функционального тестирования и поручить их людям с более низкой квалификацией и зарплатой. А если прибавить сюда проблемы с поиском тестировщиков, уровень знаний которых будет выше, чем просто «продвинутый юзер», то возможны варианты с зарплатами и в 2-3 раза меньше, чем у программистов. Но это уже скорее штатные бета-тестеры, чем тестировщики.
А чего плохого в том, чтобы платить кодерам в 1.5 раза меньше чем архитекторам? Далее по вашему тесту первого параграфа, заменяя слово «программист» на слово «архитектор», а слово «тестировщик» на слово «кодер».
А в словах "… для них они слишком скучны и неинтересны, в силу своей тривиальности" я вижу просто Ваше непонимание профессии тестировщик. У нас задачи, зачастую, намного более нетривиальны и сложны. В этом, кстати, и есть более глобальная проблема — большинство тестеров прекрасно понимают сложность работы программистов, а вот программисты (не все, к счастью) не понимают сложности работ по тестированию.
А в словах "… для них они слишком скучны и неинтересны, в силу своей тривиальности" я вижу просто Ваше непонимание профессии тестировщик. У нас задачи, зачастую, намного более нетривиальны и сложны. В этом, кстати, и есть более глобальная проблема — большинство тестеров прекрасно понимают сложность работы программистов, а вот программисты (не все, к счастью) не понимают сложности работ по тестированию.
А чего плохого в том, чтобы платить кодерам в 1.5 раза меньше чем архитекторам?
Ничего плохого. Скорее даже градация ещё более детальная: кодер получает в 1.5 раза меньше, чем программист, а программист — в 1.5 раза меньше, чем архитектор. Понятно, что все профессии нужны, все профессии важны, но это не значит, что у всех должна быть одинаковая зарплата.
У нас задачи, зачастую, намного более нетривиальны и сложны.
Можно примеры? Я работал с тестировщиками и даже читал, интереса ради, их учебник «Тестирование dot com», поэтому суть вашей работы понимаю, но ваше утверждение кажется мне довольно комичным.
Да, у вас муторная и даже, можно сказать, психологически трудная (пункт за пунктом десятки раз проходить по всей спецификации) работа, но чтобы в ней нашлось что-то нетривиальное для программиста… Мне реально интересны примеры таких уникальных случаев.
Вы, судя по вашим словам, работали не с тестировщиками, а с кликерами. А книга, которую вы приводите в пример написана для тестировщиков, которые только начали работать. Книга для базового уровня знаний — весьма хорошая.
Для примера, вот вам пара вакансий.
spb.hh.ru/vacancy/3064218
spb.hh.ru/vacancy/3064231
Еще для примера — работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных). Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось, но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно. В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
И да, как ликбез — нормальный тестировщик, находясь в здравом умен не будет работать по принципу: пункт за пунктом десятки раз проходить по всей спецификации. Я вот никогда так не делал. Во-первых я никогда в жизни не видел идеальных спецификаций. Во-вторых — описанный вами алгоритм действий не эффективен.
Для примера, вот вам пара вакансий.
spb.hh.ru/vacancy/3064218
spb.hh.ru/vacancy/3064231
Еще для примера — работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных). Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось, но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно. В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
И да, как ликбез — нормальный тестировщик, находясь в здравом умен не будет работать по принципу: пункт за пунктом десятки раз проходить по всей спецификации. Я вот никогда так не делал. Во-первых я никогда в жизни не видел идеальных спецификаций. Во-вторых — описанный вами алгоритм действий не эффективен.
работа программиста заключается в том, чтобы написать код который будет решать поставленную задачу (обычно четко понятную) и выполняться в рамках каких-то ограничений (тоже обычно оговоренных).
Далековато от истины, «чётко» известно что надо сделать, только сложность в том, что надо придумать как это сделать.
Т.е. для тестировщика единственной чётко поставленной задача будет «найти все несоответствия спецификации и здравому смыслу». А у программистов подобных «чётко» поставленных задач по несколько штук в день.
Задача тестировщика, мало того, что проверить, что код работает именно так как планировалось
ну это совсем тривиальная часть. согласны?
но и еще придумать случаи в которых программа может работать не правильно, и не только придумать а и заставить программу повести себя не правильно.
А вот тут у программистов преимущество, они прекрасно знают все эти случаи и уж тем более знают, что надо ввести чтобы получить ошибку, просто никогда не будут гонять по этим сценариям свою программу, т.к. это неосновной сценарий и т.к. для этого есть тестировщики.
Ничего нетривиального для программистов в этой части работы тестировщиков тоже нет.
В добаков не плохо еще и убедиться, что программа верно обрабатывает ошибки и исключительные ситуации.
Ну по найденному сценарию проверить реакцию программы — это совсем тривиально.
я никогда в жизни не видел идеальных спецификаций.
Идеальная, не идеальная, а формальную проверку на соответствие спецификации тестировщики обязаны делать для каждого минорного релиза.
Для примера, вот вам пара вакансий.
А ничего, что QA Engineer и Software Test Engineer (тестировщик) — это разные профессии?
Как обычно, вся дискуссия перестала иметь смысл, раз вы соединили эти 2 профессии в нечто единое и непонятное.
Если бы система производства ПО работала идеально, то работа была бы у всех скучная: программисту говорят: какие технологии использовать, какова должна быть логика работы, какие должны быть интерфейсы полученного продукта. Тестировщик должен, кстати, подключаться раньше, начиная тестирование еще со спецификаций и технического задания. Затем тестировщик берет те же входные документы, что были у программиста и сверяет то, что должно было с тем, что получилось, и насколько стабильно работает продукт. Затем он собирает из компонентов систему и проверяет, чтобы все вместе работало как надо. Все рутинно и скучно, так и ведь деньги платят не за развлечения.
В реальной жизни ведь все совсем не так. И у кого еще скучная работа: у программиста, который зажат в рамках одного модуля, или у тестировщика, который зачастую работает с полной системой, изучая ее вдоль и поперек? Всегда забавляли подобные сентенции.
Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи. Кроме тривиальных исключений бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях, которые порой вылезают только в продуктиве. Поэтому и нужно конфигурационное и нагрузочное тестирование. Вообще, в распределенных системах бывает много такого, что обычно программистами почему-то не учитывается. К тому же, у программистов другое мышление, им интереснее создавать, чем искать уязвимости. В данном случае поговорка «ломать — не строить» имеет совсем другой акцент.
К тому же, тестировщики должны знать, как будет эксплуатироваться разрабатываемая система (степень востребованности и приоритет функционала, профили нагрузки и т. д.), чтобы искать не все ошибки подряд, а наиболее важные. Сроки всегда сжатые, что у разработчиков, что у тестировщиков, поэтому всегда будут дефекты ПО, и время на тестирование и исправление сильно ограничено. Тоже вполне творческая и ответственная работа.
Насчет монотонности — плох тот тестировщик, который не умеет программировать ;) Автоматизация помогает справляться с рутиной, ведь монотонно проверяя одно и то же, можно легко проглядеть дефект.
Насчет соотношения зарплат: почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат? По-моему, квалификация проверяющего должна быть не ниже квалификации автора, иначе просто нет смысла в таких проверках.
В реальной жизни ведь все совсем не так. И у кого еще скучная работа: у программиста, который зажат в рамках одного модуля, или у тестировщика, который зачастую работает с полной системой, изучая ее вдоль и поперек? Всегда забавляли подобные сентенции.
Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи. Кроме тривиальных исключений бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях, которые порой вылезают только в продуктиве. Поэтому и нужно конфигурационное и нагрузочное тестирование. Вообще, в распределенных системах бывает много такого, что обычно программистами почему-то не учитывается. К тому же, у программистов другое мышление, им интереснее создавать, чем искать уязвимости. В данном случае поговорка «ломать — не строить» имеет совсем другой акцент.
К тому же, тестировщики должны знать, как будет эксплуатироваться разрабатываемая система (степень востребованности и приоритет функционала, профили нагрузки и т. д.), чтобы искать не все ошибки подряд, а наиболее важные. Сроки всегда сжатые, что у разработчиков, что у тестировщиков, поэтому всегда будут дефекты ПО, и время на тестирование и исправление сильно ограничено. Тоже вполне творческая и ответственная работа.
Насчет монотонности — плох тот тестировщик, который не умеет программировать ;) Автоматизация помогает справляться с рутиной, ведь монотонно проверяя одно и то же, можно легко проглядеть дефект.
Насчет соотношения зарплат: почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат? По-моему, квалификация проверяющего должна быть не ниже квалификации автора, иначе просто нет смысла в таких проверках.
> у программиста, который зажат в рамках одного модуля
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
> Я не согласен с тем, что программисты прекрасно знают все возможные фолтовые случаи
Ну не то чтобы «прекрасно знают», но как минимум догадываются при каких обстоятельствах посыпятся ошибки. Попробуй попроси у программиста, не занятого в проекте, прочитав спецификацию, назвать 20 мест, где могут возникнуть проблемы. Особого труда это для него составить не должно, при этом в 12-15 из 20 названных мест, ты потом реально найдёшь баги. А всё потому, что каких-то уникальных багов на практике встречается крайне мало и даже не в каждом проекте.
> бывают утечки памяти под нагрузкой, проблемы синхронизации в многопоточных приложениях
Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
> плох тот тестировщик, который не умеет программировать ;)
Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
> почему Вы считаете, что квалификация хорошего тестировщика ниже квалификации разработчика? Как же он тогда будет проверять результат?
Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
> Это уж слишком проектнозависимо, мне не встречались проекты, в которых программисты работали только над одним модулем, как будто зашоренные.
Это просто плохой пример организации работы программистов.
Ну, модуль условно. Например, в моей личной практике часто бывало, что разработчик ведет пяток компонентов в течение нескольких лет, а тестировщик за это время успевает поучаствовать в нескольких больших проектах.
> Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
Судя по спецификации проблемы могут быть в одном месте, а по реализации — совершенно в другом) Да, ошибки неуникальны в принципе, но ведь согласитесь, что надо еще уметь их найти, а это уже другое дело. Кроме того, хороший тестировщик должен не только найти багу, но и описать условия возникновения, возможные причины и влияние на работу с продуктом, возможные последствия. Тоже не тривиально и требует аналитических способностей.
> Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
80% тестировщиков в принципе, во всем мире, в России, в какой-то области, в Вашей компании? Уточните, пожалуйста, и пруфлинк тоже не помешал бы. Да, я согласен, что есть такая профессиональная болезнь у некоторых тестировщиков, которые считают, что им не надо понимать принципов разработки и уметь программировать, но это скорее проблема квалификации отдельных людей, молодости профессии и весьма специфического к ней подхода. Набирайте тестировщиков исходя из того, что они должны уметь программировать, или хотя бы учиться этому, и соотношение будет меняться как вокруг Вас, так и в целом :)
> Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Тестировщики должны проверять качество программного продукта, а не его реакцию на действия пользователя, а это немного разные вещи. Многие программные продукты с пользователем напрямую вообще никогда не взаимодействуют, и с чьей квалификацией тогда сравнивать квалификацию тестировщика?) Для эффективной работы тестировщик должен знать особенности платформы, технологии реализации, специфику окружений и условий работы, архитектуру продукта и принципы взаимодействия системных компонентов. Для прощелкивания кнопок на формах есть специальные фреймворки и инструменты.
Это просто плохой пример организации работы программистов.
Ну, модуль условно. Например, в моей личной практике часто бывало, что разработчик ведет пяток компонентов в течение нескольких лет, а тестировщик за это время успевает поучаствовать в нескольких больших проектах.
> Так это как раз одни из самых очевидных случаев, в Топ-20 они будут одними из первых, конечно если спека предусматривает мультипоточность и немонопольный доступ к приложению :-)
Судя по спецификации проблемы могут быть в одном месте, а по реализации — совершенно в другом) Да, ошибки неуникальны в принципе, но ведь согласитесь, что надо еще уметь их найти, а это уже другое дело. Кроме того, хороший тестировщик должен не только найти багу, но и описать условия возникновения, возможные причины и влияние на работу с продуктом, возможные последствия. Тоже не тривиально и требует аналитических способностей.
> Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…
80% тестировщиков в принципе, во всем мире, в России, в какой-то области, в Вашей компании? Уточните, пожалуйста, и пруфлинк тоже не помешал бы. Да, я согласен, что есть такая профессиональная болезнь у некоторых тестировщиков, которые считают, что им не надо понимать принципов разработки и уметь программировать, но это скорее проблема квалификации отдельных людей, молодости профессии и весьма специфического к ней подхода. Набирайте тестировщиков исходя из того, что они должны уметь программировать, или хотя бы учиться этому, и соотношение будет меняться как вокруг Вас, так и в целом :)
> Так дело в том, что результат работы программиста — это код, а тестировщики проверяют отнюдь не код, а реакцию программы на действия пользователя, поэтому им достаточно чтобы квалификация была выше чем у пользователя, а не выше чем у программиста.
Тестировщики должны проверять качество программного продукта, а не его реакцию на действия пользователя, а это немного разные вещи. Многие программные продукты с пользователем напрямую вообще никогда не взаимодействуют, и с чьей квалификацией тогда сравнивать квалификацию тестировщика?) Для эффективной работы тестировщик должен знать особенности платформы, технологии реализации, специфику окружений и условий работы, архитектуру продукта и принципы взаимодействия системных компонентов. Для прощелкивания кнопок на формах есть специальные фреймворки и инструменты.
"Оно может и так, но к сожаленью 80% тестировщиков даже базовых основ программирования не знают, куда уж там до умения…"
Скажите, у вас какой-то тестировщик жену увёл, да? Какой-то вы на них озлобленный.
Скажите, у вас какой-то тестировщик жену увёл, да? Какой-то вы на них озлобленный.
Скиллы программиста и тестировщика лишь немного пересекаются. Мало какой программист может быть хорошим тестировщиком. Не потому что «скучно», отставьте своё подростковое высокомерие, а потому что просто не может, мозги по другому заточены, нет нужных знаний и умений.
Злорадно хихикаю: было уже несколько проектов, в начале которых разработчики кричали «нафиг этих тестировщиков, дайте весь бюджет нам, мы все заавтоматизируем». А потом заказчик платил цену³ за то, что эти деятели наавтоматизировали а наша команда потом перепроверяла руками.
Конечно круто, когда в команде разработки написание тестов и их прогоны поставлены по уму на поток. Там действительно в большинстве случаев достаточно 1-2 ручных раундов перед релизом, просто чтобы убедиться в том, что автоматика ничего не пропустила. Но для этого надо еще разработчиков нормальных нанимать а не колхоз, хе-хе.
Конечно круто, когда в команде разработки написание тестов и их прогоны поставлены по уму на поток. Там действительно в большинстве случаев достаточно 1-2 ручных раундов перед релизом, просто чтобы убедиться в том, что автоматика ничего не пропустила. Но для этого надо еще разработчиков нормальных нанимать а не колхоз, хе-хе.
I don't do build tests before comitting; users generate better error messages than gcc
Результаты предсказуемые :)
«Продавай, потом тестируй» © Гай Кавасаки
Sign up to leave a comment.
Каково соотношение тестировщиков и разработчиков в вашей компании?