Комментарии 59
Я считаю, что тестировщики, (как, кстати, и верстальщики) недооценены в современных подходах к разработке. Может быть потому что само понимание хорошего тестировщика у меня отличается от общепринятого.
Как правило под тестировщиком понимают этакого человека, который сидит и миллион раз проверяет одно и то же на каждом билде. Я же считаю, что такую работу нужно в принципе исключать при современном развитии технологий, а вместо них создавать неких гуру тестирования.
Требования у меня к нему такие:
Он должен быть перфекционистом.
Его перфекционизм должен быть направлен не только на поиск косяков в софте, но и на автоматизацию самого тестирования. Он должен неустанно стремиться автоматизировать всё.
И он действительно способен автоматизировать практически всё.
Он не должен бояться рутины — какая-то часть ручной проверки всё равно останется.
Он должен испытывать страсть к своему делу. Почти кончать при нахождении очередного существенного труднообнаружимого косяка.
Он должен иметь значительный опыт программирования. Чтобы понимать что вообще можно сломать и как. Например проверить софт на проблемы при параллельном выполнении без понимания этих механизмов невозможно. К тому же эти навыки помогут ему общаться с разработчиками.
Он должен быть еще и немного дизайнером. Тестирование в современном мире это не просто стремление вызвать некий эксепшен, а еще и проверка того, как все это выглядит и работает. Человек должен понимать, когда что-то съехало, когда что-то пошло не так на логическом уровне и т. д.
Думаю, что такой человек может родиться например из программиста, выбравшего тестирование своей специализацией. Так что он по определению не может стоить дешевле тестировщиков, зато его производительность тестирования может быть ошеломляющей.
Я также убежден, что такой человек должен быть ответственен за тестирование в целом — от юнит-тестов до функциональных. Юнит-тесты он, конечно, сам не пишет, но учит разработчиков делать это правильно и следит за этим. Зачем? Чтобы ни один фрагмент не оказался упущенным обоими сторонами.
А идею нанять обученных обезьянок я не одобряю. Имхо, не эффективно и не естественно.
Как правило под тестировщиком понимают этакого человека, который сидит и миллион раз проверяет одно и то же на каждом билде. Я же считаю, что такую работу нужно в принципе исключать при современном развитии технологий, а вместо них создавать неких гуру тестирования.
Требования у меня к нему такие:
Он должен быть перфекционистом.
Его перфекционизм должен быть направлен не только на поиск косяков в софте, но и на автоматизацию самого тестирования. Он должен неустанно стремиться автоматизировать всё.
И он действительно способен автоматизировать практически всё.
Он не должен бояться рутины — какая-то часть ручной проверки всё равно останется.
Он должен испытывать страсть к своему делу. Почти кончать при нахождении очередного существенного труднообнаружимого косяка.
Он должен иметь значительный опыт программирования. Чтобы понимать что вообще можно сломать и как. Например проверить софт на проблемы при параллельном выполнении без понимания этих механизмов невозможно. К тому же эти навыки помогут ему общаться с разработчиками.
Он должен быть еще и немного дизайнером. Тестирование в современном мире это не просто стремление вызвать некий эксепшен, а еще и проверка того, как все это выглядит и работает. Человек должен понимать, когда что-то съехало, когда что-то пошло не так на логическом уровне и т. д.
Думаю, что такой человек может родиться например из программиста, выбравшего тестирование своей специализацией. Так что он по определению не может стоить дешевле тестировщиков, зато его производительность тестирования может быть ошеломляющей.
Я также убежден, что такой человек должен быть ответственен за тестирование в целом — от юнит-тестов до функциональных. Юнит-тесты он, конечно, сам не пишет, но учит разработчиков делать это правильно и следит за этим. Зачем? Чтобы ни один фрагмент не оказался упущенным обоими сторонами.
А идею нанять обученных обезьянок я не одобряю. Имхо, не эффективно и не естественно.
Ваш подход близок к идеалистичному, примерно так происходит в Google — они даже называют эту роль не тестировщиком, а программистом тестов, или типа того. Это оправдано для многих организаций, готовых инвестировать в кадры. НО, для индустриальных компаний, которые занимаются массовой разработкой, такой подход невозможен. У них большая текучка кадров, множество однотипных проектов, для которых экономически оправдан конвейерный подход.
Думаю, что для организаций с конвейерным подходом этот подход как раз очень хорош — можно автоматизировать всё по максимуму и один человек сможет приглядывать за большим количеством проектов.
Этот подход не подходит скорее совсем маленьким компаниям и отделам, где такого человека после создания методологии и самих тестов будет не выгодно держать. Ну тут уж как раз придется сочетать роли.
Этот подход не подходит скорее совсем маленьким компаниям и отделам, где такого человека после создания методологии и самих тестов будет не выгодно держать. Ну тут уж как раз придется сочетать роли.
Тест-инжинер :) Здорово.
>НО, для индустриальных компаний, которые занимаются массовой разработкой, такой подход невозможен. У них большая текучка кадров, множество однотипных проектов, для которых экономически оправдан конвейерный подход
Программисты наверное тоже не хило «перетекают», так что решать кого брать вопрос организации. А для множества однотипных проектов скорее всего нужно делать единую базу, в смысле один проект, и чтобы без программных изменений с минимальными настройками подходил куда нужно.
Программисты наверное тоже не хило «перетекают», так что решать кого брать вопрос организации. А для множества однотипных проектов скорее всего нужно делать единую базу, в смысле один проект, и чтобы без программных изменений с минимальными настройками подходил куда нужно.
Тут проблема в другом. Подобные фирмы ориентированы на «ближнюю перспективу», а разработка эффективной системы автоматизированного тестирования — это очень трудозатратная на первых этапах вещь. И что самое страшное для мракетоидов — не приносящая никакого результата (aka денег) в течение как минимум года. Плюс не существует какой-либо хорошо документированной и детально продуманной системы автотестирования, с детальной документацией, техподдержкой и прочими прелестями. (Я имею в виду системы тестирования абстрактного веба, Selenium и прочие инструменты системами не являются).
И винить такие фирмы абсолютно не в чём. Может, руководство у них не строит планов на несколько лет вперёд. Однако если случится чудо и фирма выжевет и укрепится, отсутствие такой системы очень больно аукнется.
И винить такие фирмы абсолютно не в чём. Может, руководство у них не строит планов на несколько лет вперёд. Однако если случится чудо и фирма выжевет и укрепится, отсутствие такой системы очень больно аукнется.
Вы не представляете, в какой кошмар вырастает такая автоматизаци. Я где-то вычитал оценку трудозатрат: на написание и ПОДДЕРЖАНИЕ (специально большими буквами) системы автоматизированного тестирования нужно примерно столько же денег, сколько на основной продукт. Это очень деликатный процесс, требующий исключительного профессионализма. Увы, в дикой природе практически не встречается, поскольку профессионалу числиться «тестером» исключительно неприятно.
Ещё тенденция, хороший тестер вскоре перестаёт быть тестером и уходить в девелоперы или начальники. В итоге работу всегда делают новички и приравненные к ним лица.
Ещё тенденция, хороший тестер вскоре перестаёт быть тестером и уходить в девелоперы или начальники. В итоге работу всегда делают новички и приравненные к ним лица.
Мой случай — был «хорошим тестером», ушёл «в девелоперы или начальники». Но товарищ, с которым практически одновременно начинали подымать тестовый отдел в фирме, остался тестером, о чём нисколько не жалеет (да и поводов пожалеть ему не дают). Ну нравится ему. Его случай, конечно, редкий. Скорее исключение, подтверждающее правило. А жаль.
таких можно смело отправлять в космос)))
это немножко я, сорри за оффтопик :)
А в некоторых случаях тестировщику приходится еще и «пинать» программистов: те, как правило, тоже довольно-таки ленивы, и писать «лишний» код юнит-тестов не всегда хотят :) а без юнит-тестов добавляется ручной работы тестировщику…
насчет «один профессионал» или «три обычных тестировщика». Я считаю, что 3 человека будут работать эффективнее. Либо они будут проверять весь проект независимо — тогда каждая функция будет проверена 3 раза, либо каждый будет отвечать за свою часть проекта, и тогда каждая часть будет протестирована более тщательно.
насчет «один профессионал» или «три обычных тестировщика». Я считаю, что 3 человека будут работать эффективнее. Либо они будут проверять весь проект независимо — тогда каждая функция будет проверена 3 раза, либо каждый будет отвечать за свою часть проекта, и тогда каждая часть будет протестирована более тщательно.
Работал в команде, где задача написания юнит-тестов лежала на тестировщиках. Это экономило дорогстоящее время разработчиков и давало тестерам возможность покодировать в свое удовольствие. Они еще и Code Review делали. Вполне работоспособная схема оказалась.
не было эффекта, как случается у программистов, занимающихся тестированием — «свое ломать сложно»?
Вы ничего не путаете? Как может тестировщик писать юнит-тесты? Разве что у вас были полные спецификации всего, вплоть до мельчайших подробностей. И система отслеживания изменений в коде, для которого написан тест. И ещё куча всего.
а еще очень бы хотелось узнать, какими инструментами пользуются тестировщики — Bug Tracking System, Test Management System, test automation итд.
Bug Tracking System.
Используем JIRA, как наиболее гибкую систему, в качестве BTS. Возможность подключить дополнительные модули/плагины — делает её очень качественным инструментом трэкинга.
Test Management System.
Testlink. Интеграция с JIRA позволяет усовершенствовать процесс тестирования. Отчёт в виде графиков/таблиц, удобен для анализа.
Используем JIRA, как наиболее гибкую систему, в качестве BTS. Возможность подключить дополнительные модули/плагины — делает её очень качественным инструментом трэкинга.
Test Management System.
Testlink. Интеграция с JIRA позволяет усовершенствовать процесс тестирования. Отчёт в виде графиков/таблиц, удобен для анализа.
У нас распределенный проект, планы по тестированию, тестовые наборы, кейсы и сам процесс прохождения тестов расположены в одном месте: www.devprom.net
Создаете базу тестовых наборов и тестировать может кто угодно из команды, результаты тестирования видны кому нужно и связаны с дальнейшими задачами по исправлению ошибок, а также с требованиями и т.п. Рекомендую.
Создаете базу тестовых наборов и тестировать может кто угодно из команды, результаты тестирования видны кому нужно и связаны с дальнейшими задачами по исправлению ошибок, а также с требованиями и т.п. Рекомендую.
у нас вся команда в одном офисе, поэтому инструменты для распределенной работы не особо нужны.
пока использую TestLink, и его вроде хватает, но интересно, чем пользуются другие разработчики
пока использую TestLink, и его вроде хватает, но интересно, чем пользуются другие разработчики
Тестлинк ужасен. Для интенсивной работы совершенно не подходит, для реальной работы требует сильного допиливания под конкретные нужды. И тормоооозииит, о боже, как он тормозит…
а какие у него есть аналоги? чтоб не тормозил и был удобен?
Мы не нашли. В этой области всё глухо. Хотя такой класс систем очень сильно востребован, но их просто нет. Хотя были какие-то перспективные проекты, вроде бы на базе Django, но к тому моменту слишком сырые. Но повторюсь, я был очень сильно удивлён, узнав, что достойных инструментов для этой задачи просто нет.
П.С.
На всякий случай уточню задачу, путём введения основных требований:
формализованное описание тестпланов и тесткейзов, версионность/древовидность тестпланов/тесткейзов, автоматическое/ручное прохождение, интеграция с bug tracking system, интеграция с integration engine (build system, unit testing system), генерация отчётов-графиков, ну и самое главное — модульность. Очень желательна ещё и опенсорсность, но подойдёт и проприетарщина с детальной и полной документацией
П.С.
На всякий случай уточню задачу, путём введения основных требований:
формализованное описание тестпланов и тесткейзов, версионность/древовидность тестпланов/тесткейзов, автоматическое/ручное прохождение, интеграция с bug tracking system, интеграция с integration engine (build system, unit testing system), генерация отчётов-графиков, ну и самое главное — модульность. Очень желательна ещё и опенсорсность, но подойдёт и проприетарщина с детальной и полной документацией
Да, забыл ещё более главное — цену :) Чтобы бесплатно или за мало денег.
Ой, ну это вы слишком много хотите:) Хотите совместить билд-машину и инструмент учета тест-кейсов.
Если тест-кейсы ведутся в Jira, то подойдет Atlassian Bamboo.
Если нет, то Cruise Control.Net, там и модульность, и свои примочки можно писать. Правда, придется помучиться с интеграцией.
Если тест-кейсы ведутся в Jira, то подойдет Atlassian Bamboo.
Если нет, то Cruise Control.Net, там и модульность, и свои примочки можно писать. Правда, придется помучиться с интеграцией.
Тут нужно шире смотреть: сегодня у вас есть офис, а через пару месяцев его может и не стать по известным причинам. Тем более, что эффективнее может быть использование внешних ресурсов (monkey-testing как самый простой пример), где их брать? Искать людей очень долго и дорого.
> Test Management System.
> Testlink. Интеграция с JIRA позволяет усовершенствовать процесс тестирования. Отчёт в виде графиков/таблиц, удобен для анализа.
а можете рассказать как у вас сделана интеграция Jira и Testlink?
> Testlink. Интеграция с JIRA позволяет усовершенствовать процесс тестирования. Отчёт в виде графиков/таблиц, удобен для анализа.
а можете рассказать как у вас сделана интеграция Jira и Testlink?
JIRA — очень удобно и гибко, HP Mercury QC (TestDirector). А также HP Mercury LR, QTP, Confluence, Sybase PowerDesigner… Про инструменты можно отдельно опросить всех, правда перечень может быть слишком громоздок…
JIRA (для рабочих проектов, платит зарубежный заказчик)
Mantis (для пилотных проектов, бесплатно и сердито)
Mantis (для пилотных проектов, бесплатно и сердито)
«Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?» — то есть кто-то сомневается в этом и хорошо бы узнать почему он сомневается, его аргументацию. Тогда и ответить будет проще.
Общая тенденция — разделение ролей, создание конвейера. Вот уже больше сотни лет доказывается, что конвейер лучше чем работа мастера одиночки.
Экстремальное программирование не предполагает совмещение ролей тестировщика и программиста. Там просто немного по другому подходят к разработке, не более того.
Общая тенденция — разделение ролей, создание конвейера. Вот уже больше сотни лет доказывается, что конвейер лучше чем работа мастера одиночки.
Экстремальное программирование не предполагает совмещение ролей тестировщика и программиста. Там просто немного по другому подходят к разработке, не более того.
Я работаю в небольшой компании. У нас как раз стоит проблема с тестировщиками. Все продукты тестируются только разработчиками, в самом лучшем случае это разработчик с другого проекта. Начальство просто жопит деньги на тестировщика, маркетологов тьма, продажи идут, фидбек от клиентов очень часто негативный (ясно, что заказчики выступают в роли тестировщиков). По-моему если начальство не понимает, что нужен отдел QA, то о какой вообще разработке продуктов может идти речь?
Тут вопрос, что перевешивает — деньги или качество; как только найдётся жирный (или особо занудный) клиент, или в популярном журнале напечатают разгромную рецензию на продукт, короче, как припрёт, так сразу найдутся деньги на QA :) Даже на два QA.
На прошлой работе была аналогичная ситуация, только продажи не шли. Полтора года было состояние «вот-вот что-нибудь продадим», соответственно не повышений по зарплате, ни других излишеств. В итоге послал работодателя в жопу и ушел на другую работу.
Как объяснить, говорите? А что ему объяснять, он же тупой. Ой, забыл, он деньги платит. Значит не тупой. Ну или тупой, но с деньгами. Н-да. Дилема или как там ее?
Уважаемый коллега, 2*2=4 звучит, разумеется, отлично, но возникает вопрос, почему руководитель не вы, а он — Тупой Начальнег? Объясняю, в арифметике 2*2=4, но вот в жизни это не всегда так. Начальнег исходит из своей алгебры, в которой 2*2 может и не быть равно 4.
Теперь, что делать: не надо пытаться объяснить, не надо пытаться показать цифрами, почему это выгодно. Надо изучить логику начальника. Логика начальника в большинстве случаев состоит в сохранении отдела/отделения/организации. Еще раз: не в максимальной эффективности, а в сохранении.
Это нужно понимать и тогда станет понятно, что делать.
Уважаемый коллега, 2*2=4 звучит, разумеется, отлично, но возникает вопрос, почему руководитель не вы, а он — Тупой Начальнег? Объясняю, в арифметике 2*2=4, но вот в жизни это не всегда так. Начальнег исходит из своей алгебры, в которой 2*2 может и не быть равно 4.
Теперь, что делать: не надо пытаться объяснить, не надо пытаться показать цифрами, почему это выгодно. Надо изучить логику начальника. Логика начальника в большинстве случаев состоит в сохранении отдела/отделения/организации. Еще раз: не в максимальной эффективности, а в сохранении.
Это нужно понимать и тогда станет понятно, что делать.
что-то идеальный какой-то у вас начальник получился… все об отделе думает, отдохнуть ему надо, не бережет он себя…
Как всегда, между начальниками, пытаемся найти компромисс, иначе — кто-то лишний. Доказываем сначала полезность тестирования как процесса, затем эффективность тестировщиков — как специалистов, затем — автоматизацию, как интенсификацию, далее и всегда — совершенствование процессов…
Признателен за эту фразу — «изучить логику начальника».
Признателен за эту фразу — «изучить логику начальника».
Не в ту степь. Полезность тестирования он отлично понимает. Полезность тестировщиков тоже. Подумайте, почему он до сих пор не согласился с вами, отлично ПОНИМАЯ полезность предложенных вами мер.
Мой ответ из психологии (не паранойя): скорее всего он стремится контролировать тех, кто его проверяет (проверяет его работу, находит ошибки в его системе). Если это единое подразделение со здоровой атмосферой — сработаются при грамотном начальнике. А если у них разные боссы — вмешивается политика.
Формально же звучит обоснование, что тестировщики отвлекают аналитиков при входе в задачу, не владеют прикладной областью, не эффективны на критичных коротких участках проекта — когда все горит, все плохо — а кто новый тут поможет?! — и их смогут заменить свои разработчики (аналитики, менеджеры, пользователи), которые всегда в теме, могут и автоматизировать при надобности, управляемы, подотчётны, гибко перераспределяемы. Может быть помог бы «свой» тестировщик, но как я вижу, один в поле не воин, точнее важен принцип независимости тестирования как процесса, иначе все сводится к человеческому фактору.
Формально же звучит обоснование, что тестировщики отвлекают аналитиков при входе в задачу, не владеют прикладной областью, не эффективны на критичных коротких участках проекта — когда все горит, все плохо — а кто новый тут поможет?! — и их смогут заменить свои разработчики (аналитики, менеджеры, пользователи), которые всегда в теме, могут и автоматизировать при надобности, управляемы, подотчётны, гибко перераспределяемы. Может быть помог бы «свой» тестировщик, но как я вижу, один в поле не воин, точнее важен принцип независимости тестирования как процесса, иначе все сводится к человеческому фактору.
Опять не туда.
Его задача проста: выживание отдела. Нужно, чтобы отдел выжил для этого он ищет и получает заказы, для этого он решает ряд других задач и проблем. Наличие тестировщика для выживания отдела не критично.
Кроме того, он эгоист. И он понимает, что тестер важен и ничего не делает.
Важно не почему, важно что делать.
КАк мотивировать эгоиста принять тестера? Каким образом можно показать, что выживание отдела зависит от тестера. Еще раз: не улучшение деятельности, а выживание.
Его задача проста: выживание отдела. Нужно, чтобы отдел выжил для этого он ищет и получает заказы, для этого он решает ряд других задач и проблем. Наличие тестировщика для выживания отдела не критично.
Кроме того, он эгоист. И он понимает, что тестер важен и ничего не делает.
Важно не почему, важно что делать.
КАк мотивировать эгоиста принять тестера? Каким образом можно показать, что выживание отдела зависит от тестера. Еще раз: не улучшение деятельности, а выживание.
У нас в компании, когда баги фиксятся, то они сначала тестируются разработчиком, а потом qa.
Иногда просто протестировать соответствующий кейс, но в большинстве случаев тестирование проводится не основательно, поэтому нужен куа. Порой тестирование может потребовать предварительные усилия, по созданию соотвествующего окружения. Опытный сотрудник куа же сделает так, что минимизирует затраты по времени. Ну и, конечно же, у них свой инструментарий, на освоение которого нужно время. Новому сотруднику это может показаться чересчур большая нагрузка.
Иногда просто протестировать соответствующий кейс, но в большинстве случаев тестирование проводится не основательно, поэтому нужен куа. Порой тестирование может потребовать предварительные усилия, по созданию соотвествующего окружения. Опытный сотрудник куа же сделает так, что минимизирует затраты по времени. Ну и, конечно же, у них свой инструментарий, на освоение которого нужно время. Новому сотруднику это может показаться чересчур большая нагрузка.
я вот программист, и понимаю что я не могу быть тестировщиком, ибо как бы не пытался, но тестирую ПО или сайт по той же модели, по которой я и делал его, что есть неправильно по моему мнению
Объяснение может быть несколько проще (и описано в великих трудах великих людей :)): разработчик, тестировщик и аналитик — суть три роли.
У каждой роли свои показатели эффективности деятельности, причем есть общие, но с противоположными целевыми значениями.
Яркий пример показателя: количество ошибок — у разработчка этот показатель — суть количество допущенных ошибок — должен быть минимален, в то время как у тестировщика — суть количество найденных ошибок — должен быть максимален. Поэтому роли «разработчик» и «тестировкщик» не должны совмещаться в одном лице в рамках выполнения одной задачи.
То же самое про остальные комбинации: «разработчик» и «аналитик», «аналитик» и «тестировщик» — ни одна из этих трех ролей не должна быть совмещена с другой в одном лице в рамках выполнения одной задачи — золотое правило обеспечения качества.
У каждой роли свои показатели эффективности деятельности, причем есть общие, но с противоположными целевыми значениями.
Яркий пример показателя: количество ошибок — у разработчка этот показатель — суть количество допущенных ошибок — должен быть минимален, в то время как у тестировщика — суть количество найденных ошибок — должен быть максимален. Поэтому роли «разработчик» и «тестировкщик» не должны совмещаться в одном лице в рамках выполнения одной задачи.
То же самое про остальные комбинации: «разработчик» и «аналитик», «аналитик» и «тестировщик» — ни одна из этих трех ролей не должна быть совмещена с другой в одном лице в рамках выполнения одной задачи — золотое правило обеспечения качества.
Ну так говорите, что вам нужен не тестировщик, а QA. И отличается он тем, что не просто тестирует, а гарантирует отсутствие багов. Просто у нас пока что культура писать ПО без багов не привита.
«Софт могут писать и обезьяны, главное качественное QA» (с) не помню кто
P.S. Девелоперы не обижайтесь это шутка: )
P.S. Девелоперы не обижайтесь это шутка: )
Меня пару дней назад поразило следующее (хотя это и согласуется с моими наблюдениями) — у Макконнелла в «Совершенном коде» в 20-й главе «Качество ПО» есть одна таблица.
Табл. 20-2. Эффективность нахождения дефектов при использовании разных методик
Методика устранения дефектов
Минимальная
Типичная
Максимальная
Неформальные обзоры проекта 25,00% 35,00% 40,00%
Формальные инспекции проекта 45,00% 55,00% 65,00%
Неформальные обзоры кода 20,00% 25,00% 35,00%
Формальные инспекции кода 45,00% 60,00% 70,00%
Моделирование или прототипирование 35,00% 65,00% 80,00%
Самостоятельная проверка кода 20,00% 40,00% 60,00%
Блочное тестирование 15,00% 30,00% 50,00%
Тестирование новых функций (компонентов) 20,00% 30,00% 35,00%
Интеграционное тестирование 25,00% 35,00% 40,00%
Регрессивное тестирование 15,00% 25,00% 30,00%
Тестирование системы 25,00% 40,00% 55,00%
Ограниченное бета-тестирование (менее чем в 10 организациях) 25,00% 35,00% 40,00%
Крупномасштабное бета- тестирование (более чем в 1000 организаций) 60,00% 75,00% 85,00%
И я могу судить по себе, и по другим людям, и опять-таки процитировать Стива —
«Самый длительный этап в большинстве проектов — отладка и исправление не-
правильного кода. При традиционном цикле разработки ПО эти действия зани-
мают около 50% времени… Сокращение потребности в отладке,
достигаемое благодаря предотвращению ошибок, повышает производительность
труда. Следовательно, наиболее очевидный метод сокращения графика разработ-
ки — повышение качества ПО и снижение объема времени, уходящего на его
отладку и исправление. „
А в случае небольших команд — почему бы не задуматься о внедрении парного программирования?
Табл. 20-2. Эффективность нахождения дефектов при использовании разных методик
Методика устранения дефектов
Минимальная
Типичная
Максимальная
Неформальные обзоры проекта 25,00% 35,00% 40,00%
Формальные инспекции проекта 45,00% 55,00% 65,00%
Неформальные обзоры кода 20,00% 25,00% 35,00%
Формальные инспекции кода 45,00% 60,00% 70,00%
Моделирование или прототипирование 35,00% 65,00% 80,00%
Самостоятельная проверка кода 20,00% 40,00% 60,00%
Блочное тестирование 15,00% 30,00% 50,00%
Тестирование новых функций (компонентов) 20,00% 30,00% 35,00%
Интеграционное тестирование 25,00% 35,00% 40,00%
Регрессивное тестирование 15,00% 25,00% 30,00%
Тестирование системы 25,00% 40,00% 55,00%
Ограниченное бета-тестирование (менее чем в 10 организациях) 25,00% 35,00% 40,00%
Крупномасштабное бета- тестирование (более чем в 1000 организаций) 60,00% 75,00% 85,00%
И я могу судить по себе, и по другим людям, и опять-таки процитировать Стива —
«Самый длительный этап в большинстве проектов — отладка и исправление не-
правильного кода. При традиционном цикле разработки ПО эти действия зани-
мают около 50% времени… Сокращение потребности в отладке,
достигаемое благодаря предотвращению ошибок, повышает производительность
труда. Следовательно, наиболее очевидный метод сокращения графика разработ-
ки — повышение качества ПО и снижение объема времени, уходящего на его
отладку и исправление. „
А в случае небольших команд — почему бы не задуматься о внедрении парного программирования?
На мой взгляд самое простое с чего можно начать процесс улучшения кода — это продумывание архитектуры приложения с точки зрения возможности его автоматизированного тестирования (не суть каким инструментом).
Наличие автоматизированных тестов — это правильный начальный шаг, позволяет быстро обеспечить достойный механизм проверки кода на регрессию.
Дальше нужно двигаться в сторону unit-тестирования и конечно же парного программирования.
Наличие автоматизированных тестов — это правильный начальный шаг, позволяет быстро обеспечить достойный механизм проверки кода на регрессию.
Дальше нужно двигаться в сторону unit-тестирования и конечно же парного программирования.
Я бы даже сказал по другому — «На мой взгляд самое простое с чего можно начать процесс улучшения кода — это продумывание архитектуры приложения». :)
Нет панацеи и «серебряной пули», кроме профессионализма (по возможности) во всех проявлениях. Есть такой афоризм: «У непрофессионала руки растут из задницы. А у профессионала даже из задницы растут руки». Мне кажется к этому следует стремится.
Пример из жизни — после того, как по коду модуля прошёл человек, который с этим модулем напрямую не работает он за день повысил его стабильность, скорость и спокойствие при его использовании. Просто потому, что этот человек — профессионал.
Нет панацеи и «серебряной пули», кроме профессионализма (по возможности) во всех проявлениях. Есть такой афоризм: «У непрофессионала руки растут из задницы. А у профессионала даже из задницы растут руки». Мне кажется к этому следует стремится.
Пример из жизни — после того, как по коду модуля прошёл человек, который с этим модулем напрямую не работает он за день повысил его стабильность, скорость и спокойствие при его использовании. Просто потому, что этот человек — профессионал.
Мне кажется, у Вас тут личное отношение проявляется, а не итог серьёзных раздумий. Серьёзно.
> Если лидер пытается совместить роли, то это из-за экономии или из-за непонимание психологии.
> Экономия — чаще всего от бедности или от жадности.
Далеко не всегда. Тестирование — это серьёзная задача, которая требует для решения самых разных специалистов. Участие в тестировании разработчиков, на мой личный взгляд — весьма полезная практика. Знаете, например, как улучшить стиль собственного программирования? Разбираться в чужом коде. После такой работы появляется кровью заработанное знание, зачем и как писать понятный код. Точно также, для выработки навыка безопасного программирования требует перекрёстное тестирование.
Однако, это не означает, что не должно быть отдельных тестировщиков, которые погоняют код на неверных данных, или пользователей, которые скажут — удобно ли, понятно ли. Или специалистов по нагрузочному тестированию.
> 1. Разработчики — это созидатели.
> 2. Тестировщики — разрушители. Эффективность тестирования при прочих равных выше у того,
> кто намеренно ломает систему.
Красиво, но к реальной жизни имеет мало отношения. Эффективность выше у того, у кого больше знаний об устройстве. Он и построит хорошо, и сломает тоже хорошо.
> 1. Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
> 2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но
> стоимость такого ресурса может оказаться намного выше стоимости привлечения тестировщика.
Логично. Тем не менее, Вы пишете, скорее всего, о том, что тестированием должны заниматься «студенты» (самые неопытные разработчики в команде). Которые сами хотят стать разработчиками.
> Если лидер пытается совместить роли, то это из-за экономии или из-за непонимание психологии.
> Экономия — чаще всего от бедности или от жадности.
Далеко не всегда. Тестирование — это серьёзная задача, которая требует для решения самых разных специалистов. Участие в тестировании разработчиков, на мой личный взгляд — весьма полезная практика. Знаете, например, как улучшить стиль собственного программирования? Разбираться в чужом коде. После такой работы появляется кровью заработанное знание, зачем и как писать понятный код. Точно также, для выработки навыка безопасного программирования требует перекрёстное тестирование.
Однако, это не означает, что не должно быть отдельных тестировщиков, которые погоняют код на неверных данных, или пользователей, которые скажут — удобно ли, понятно ли. Или специалистов по нагрузочному тестированию.
> 1. Разработчики — это созидатели.
> 2. Тестировщики — разрушители. Эффективность тестирования при прочих равных выше у того,
> кто намеренно ломает систему.
Красиво, но к реальной жизни имеет мало отношения. Эффективность выше у того, у кого больше знаний об устройстве. Он и построит хорошо, и сломает тоже хорошо.
> 1. Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
> 2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но
> стоимость такого ресурса может оказаться намного выше стоимости привлечения тестировщика.
Логично. Тем не менее, Вы пишете, скорее всего, о том, что тестированием должны заниматься «студенты» (самые неопытные разработчики в команде). Которые сами хотят стать разработчиками.
Мы все обмениваемся личными мнениями и опытом. И это хорошо. Действительно, повод для статьи — непонимание и нежелание ПМ использовать независимых тестировщиков, а желание поручить тестирование своим разработчикам.
Тестирование системы как черного ящика не имеет никакого отношения к пониманию кода, но общее понимание устройства — необходимо. И часто — достаточно. И не факт, что совершенствуясь в понимании устройства — некто, не имея таланта или тяги к тестированию как деструктивному подходу — сможет соревноваться в процессе разрушения. ИМХО.
У меня был лишь один студент за 8 лет, кто ушел в разработчики, правда и студентов было мало :-) менее 10. Не поддерживаю такого подхода — ставить неопытных на тестирование — это примитивно, безответственно и неэффективно. Другое дело, что расти как профессионал нужно с простых, элементарных активностей. Но это другая песня, про наставничество, линейный рост в профессии.
Тестирование системы как черного ящика не имеет никакого отношения к пониманию кода, но общее понимание устройства — необходимо. И часто — достаточно. И не факт, что совершенствуясь в понимании устройства — некто, не имея таланта или тяги к тестированию как деструктивному подходу — сможет соревноваться в процессе разрушения. ИМХО.
У меня был лишь один студент за 8 лет, кто ушел в разработчики, правда и студентов было мало :-) менее 10. Не поддерживаю такого подхода — ставить неопытных на тестирование — это примитивно, безответственно и неэффективно. Другое дело, что расти как профессионал нужно с простых, элементарных активностей. Но это другая песня, про наставничество, линейный рост в профессии.
> Действительно, повод для статьи — непонимание и нежелание ПМ использовать независимых тестировщиков, а желание поручить тестирование своим разработчикам.
Я бы ещё в повод записал нежелание (или неспособность?) вести строгую и актуальную проектную документацию. Это не так сложно, как кажется, есть отличная литература (например, Эрик Брауде «технология разработки программного обеспечения»), но почему-то не делается. Мне кажется, что от этого все беды. По-крайней мере, подобный подход освещает хоть какой-то путь, лежит в основе всего процесса.
Я бы ещё в повод записал нежелание (или неспособность?) вести строгую и актуальную проектную документацию. Это не так сложно, как кажется, есть отличная литература (например, Эрик Брауде «технология разработки программного обеспечения»), но почему-то не делается. Мне кажется, что от этого все беды. По-крайней мере, подобный подход освещает хоть какой-то путь, лежит в основе всего процесса.
Есть частичный, а может, и полный ответ на вопрос Victor435.
Ох. Все верно, но устарело лет на 10.
Как «The Art of Software Testing» версии восьмидесятых годов, когда машинное время было дороже человеческого.
>Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
Эффективней только на «точке своего профессионализма», а не для решения реальных задач в команде.
>2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но стоимость такого >ресурса >может оказаться намного выше стоимости привлечения тестировщика. Например, ещё Джоель Спольски написал в >своем блоге, >что за эти деньги можно привлечь трёх тестировщиков.
Главред software-testing.ru утверждает что теперь правильные тестировщики стоят дороже программистов.
>3. Исключение: для малых проектов, небольших команд или для agile-разработок — эффективно использовать универсалов, >т.к. время проекта невелико, а коммуникационные затраты в виде экспоненциального роста от числа участников проекта — >как описано у Ф.Брукса — никто не отменял.
C учетом, что Agile-разработка становится массовой, исключение переходит в правило.
В общем, чтобы не заниматься муторной критикой тезисов, просто хотел бы представить возможным читателям ссылку на актуальное мнение известных тестировщиков, ибо конференция AgileDays-2008 получилось тестировочной, чуть более чем полностью.
видео, слайды и т.п..
Особенно рекомендую (начните с него) доклад «Каким должно быть приемочное тестирование в agile-проектах?».
Как «The Art of Software Testing» версии восьмидесятых годов, когда машинное время было дороже человеческого.
>Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
Эффективней только на «точке своего профессионализма», а не для решения реальных задач в команде.
>2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но стоимость такого >ресурса >может оказаться намного выше стоимости привлечения тестировщика. Например, ещё Джоель Спольски написал в >своем блоге, >что за эти деньги можно привлечь трёх тестировщиков.
Главред software-testing.ru утверждает что теперь правильные тестировщики стоят дороже программистов.
>3. Исключение: для малых проектов, небольших команд или для agile-разработок — эффективно использовать универсалов, >т.к. время проекта невелико, а коммуникационные затраты в виде экспоненциального роста от числа участников проекта — >как описано у Ф.Брукса — никто не отменял.
C учетом, что Agile-разработка становится массовой, исключение переходит в правило.
В общем, чтобы не заниматься муторной критикой тезисов, просто хотел бы представить возможным читателям ссылку на актуальное мнение известных тестировщиков, ибо конференция AgileDays-2008 получилось тестировочной, чуть более чем полностью.
видео, слайды и т.п..
Особенно рекомендую (начните с него) доклад «Каким должно быть приемочное тестирование в agile-проектах?».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование ПО: как объяснить руководителю, что 2 х 2=4?