Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
Отличные выводы. С мыслью доклада согласен.
А давайте попробуем развить мысль (просто так, без обид):
Тестировщики заводятся не из за багов в продукте, а из за багов в людях и процессах.
Когда аналитик не выполняет часть работы по анализу требований, когда разработчик не думает о архитектуре… И тут появляется тестировщик, который занимается отладкой и работой с требованием — то есть тем, чем должны заниматься другие, но почему-то не делают этого.
Получается, что тестировщик — неправильное решение проблемы, а надо работать с программистами и аналитиками?
А давайте попробуем развить мысль (просто так, без обид):
Разработчик автотестов — это разработчик. Тест-аналитик — это аналитик.
Тестировщики заводятся не из за багов в продукте, а из за багов в людях и процессах.
Когда аналитик не выполняет часть работы по анализу требований, когда разработчик не думает о архитектуре… И тут появляется тестировщик, который занимается отладкой и работой с требованием — то есть тем, чем должны заниматься другие, но почему-то не делают этого.
Получается, что тестировщик — неправильное решение проблемы, а надо работать с программистами и аналитиками?
Нет. При разработке (особенно архитектуры) как правило много вариантов развития, и выбор оптимального редко очевиден. Бизнес требования довольно часто меняются, порой значительно для системы и без права на корректировку архитектуры. Нельзя сделать идеальный продукт раз и на всегда. Очень часто одним из ключевых критериев создания является скорость, что негативно влияет на качество. Да и задач на программистах не по одной и держать детали реализаций всего и вся в голове невозможно. К аналитикам это скорей всего относится в равной степени.
Это самое очевидное, но есть еще к примеру различные ракурсы у различных участников проекта, что тоже вносит влияние.
Это самое очевидное, но есть еще к примеру различные ракурсы у различных участников проекта, что тоже вносит влияние.
Это понятно, что идеально сразу ну никак. Я высказал гипотезу, что лечить неидеальное лучше программистами и аналитиками, а не тестерами.
Опять же нет. Частично исходя из различных взглядов у каждого. Разработчик даже с семью пядями будет видеть только проблемы разработки. Аналитик будет видеть только проблемы бизнеса. Функциональный тестировщик и автоматизатор смотрят уже со стороны потребителя продукта. Области конечно перекрываются, но крайне слабо. Все 3 группы (можно обособленно поставить еще инженеров по производительности и тех кто связан с планированием мощностей, но они отдельная песня) говорят на разных языках и плохо понимают друг друга в виду различных контекстов «обитания». Вместе они могут составить некое необходимое для разработки целое.
Оставить только две группы нельзя. Потому что тяжело видеть одному человеку угол в 180 градусов, не вращая головой.
Оставить только две группы нельзя. Потому что тяжело видеть одному человеку угол в 180 градусов, не вращая головой.
Аналитик будет видеть только проблемы бизнеса.
За бизнес болеет ПМ. А вот аналитик как раз — думает за потребителя. ПМ-аналитик-разработчик — чем не три столпа?
Предлагаю дальше не спорить :)
У меня в профиле, кстати, написано «О себе: Работаю тестировщиком».
Да я не спорю. Лишь ответил на вопрос.
По сему не могу успокоиться и еще раз нет) Задача ПМа — отправить лебедя, рака и щуку в одну сторону (ну хотя бы так чтоб вектора усилий не давали 0). Для осуществления проекта нужна толпа народу (с чего наш диалог и пошел), которые нередко и в глаза друг друга не видели. Кто-то должен их координировать и направлять.
По сему не могу успокоиться и еще раз нет) Задача ПМа — отправить лебедя, рака и щуку в одну сторону (ну хотя бы так чтоб вектора усилий не давали 0). Для осуществления проекта нужна толпа народу (с чего наш диалог и пошел), которые нередко и в глаза друг друга не видели. Кто-то должен их координировать и направлять.
которые нередко и в глаза друг друга не видели
Лучше все-таки чтобы видели и общались, потому что ПМ часто не в курсе о мелких технических недопониманиях и проблемах, либо в курсе, но не может сам нормально объяснить.
Испорченный телефон не нужен конечно. Его задача не общаться, а сводить к общению.Ставить приоритеты, следить за сроками. Можно даже переименовать в координатора проекта. Работы у него хватает и работу эту не выкинуть, когда организация большая. Да и в небольшой организации тоже, где люди не умеют самостоятельно держать сроки и следовать приоритетам. (сейчас речь об идеальном ПМе)
Можно привести контр пример в виде Valve, но чего то их результаты удручают в плане доступности и качества сервиса. Других компаний без управленцев я не ведаю.
Можно привести контр пример в виде Valve, но чего то их результаты удручают в плане доступности и качества сервиса. Других компаний без управленцев я не ведаю.
На мой взгляд то, что разработчик видит только проблемы разработки не есть хорошо. Вернее это и есть основная проблема.
Если каждый участник проекта будет думать о том, как его действия повлияют на других, то будет счастье.
Если каждый участник проекта будет думать о том, как его действия повлияют на других, то будет счастье.
Тестирование — это задача, которая является следствием невозможности выполнить что-то хорошо и правильно с первого раза, без взгляда со стороны.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Как будут называться люди, её выполняющие — неважно.
Я видела примерно следующую схему работы, результаты которой были просто отличными:
* Аналитики, общаясь с пользователями, выясняют требования. Любое требование проходит тщательное ревью другим аналитиком.
* Разработчики пишут код и проводят ревью кода «соседа», регрессия полностью покрывается юнит- и GUI-тестами, которые пишутся разработчиками.
* Аналитик, разработавший требование, финально проверяет реализацию «своего» функционала.
В итоге, тестирование размазано по этапам и по должностям, выделенных «тестировщиков» нет, но суть от этого не меняется.
Такая схема потенциально может работать, но имеет ряд существенных проблем (в зависимости от типа проекта):
Объективные:
— на аналитике повисает достаточно большое количество манкиджоба. В итоге «человек за много денег» делает работу, которую «человек за половину много денег» сделает не хуже. Т.е. неоправданный рост издержек.
— схема очень плохо работает, когда автоматизация GUI (а если быть более точным — функциональных тестов) дорогая.
— основная беда тестов, которые пишутся разработчиками — coverage. Для юнит-тестов можно сравнительно дешево его измерить и оценить, для более-менее сложных сценариев нужна сторонняя экспертная оценка.
Субъективные:
— команде разработчиков может быть банально неинтересно писать тесты. Да, это плохая практика, да, мало ли что кому неинтересно, но это факт — во многих командах эту активность не любят и всячески саботируют.
Объективные:
— на аналитике повисает достаточно большое количество манкиджоба. В итоге «человек за много денег» делает работу, которую «человек за половину много денег» сделает не хуже. Т.е. неоправданный рост издержек.
— схема очень плохо работает, когда автоматизация GUI (а если быть более точным — функциональных тестов) дорогая.
— основная беда тестов, которые пишутся разработчиками — coverage. Для юнит-тестов можно сравнительно дешево его измерить и оценить, для более-менее сложных сценариев нужна сторонняя экспертная оценка.
Субъективные:
— команде разработчиков может быть банально неинтересно писать тесты. Да, это плохая практика, да, мало ли что кому неинтересно, но это факт — во многих командах эту активность не любят и всячески саботируют.
1) Не надо делать манкиджоб и нанимать манкилюдей. Манкипроблемы потом расхлёбывает весь проект, об чём и речь.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
2) Функциональные тесты (в том числе через GUI) легко поддерживаются, если обеспечить достаточно хороший уровень тестируемости проекта на ранних этапах.
3) Code Coverage можно легко померить и на ручном и на функциональном (а-ля selenium) тестировании. Ищите подходящий инструмент.
Функциональные тесты (в том числе через GUI) легко поддерживаются
А речь не про «поддерживаются», к сожалению. Речь про «пишутся». Вот простой сценарий из личного опыта: есть приложение для планшета. Что оно делает — не суть важно, но имеет десяток экранов, на каждом — под тридцать независимо работающих контролов. А теперь — внимание, фокус — ID конкретного контрола из приложения мы получить не можем. Вообще никак. Потому что рисуем приложение через OpenGL. Уже на этом уровне начинаются мысли «три-пять мануальных тестировщиков», ещё до того, как понимаем, что таргет-устройств — минимум семь, разрешение тачскрина не совпадает с разрешением дисплея, причем тачскрин квадратный, а дисплей — нет (по координатам, не физически), что дизайнеры будут перерисовывать рисуемые контролы раз в неделю и ещё раз в неделю — менять лэйаут ихний, так что ни кликеры, ни компьютервижн нормально работать не будет. И мы не можем «сначала дизайнить, а потом кодить», потому что мы не Valve и делать продукт по принципу when it's done нельзя. Вот это я называю «дорогая автоматизация».
Code Coverage можно легко померитьCode coverage — да. А вот вопрос о покрытии именно затребованных сценариев — и детализации этих сценариев, вдобавок — это вопрос, который на откуп самим разработчикам отдавать опасно. Грубо говоря, кто проверит, что пара десятков тестов, по заверению команды разработки, тестирующих некий user story:
— действительно тестируют его, а не какую-нибудь рядом лежащую функциональность?
— тестируют все аспекты, важные в разрезе определенной стори?
и на ручном и на функциональном (а-ля selenium)Функциональное — это не «а-ля селениум». Функциональное — это то, которое проверяет, выполняет ли приложение заданные функциональные требования. И оно может быть как ручным, так и автоматизированным, в зависимости от того, что выгоднее в данный момент.
1) Т.е. в вашем продукте не была заложена testability, и теперь вам сложно разрабатывать тесты? Вся статья примерно об этом.
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
2) Функциональное бывает не только ручным и автоматизированным, оно ещё и не обязательно через GUI делается. Вот ваше приложение для планшета: где основная бизнес-логика, на сервере или на клиенете? Если на сервере — может, тестировать запросами, а на клиенте руками только интеграцию GUI проверять? Если на клиенте много логики — можно ли вытащить API для тестовой версии, чтобы опять же, в GUI только глазками вёрстку смотреть и вызов нужного функционала?
Я сталкивалась с мыслями про «дайте много тестировщиков» и на планшетах, и на множестве поддерживаемых платформ, и на терминальных приложениях. Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.
Т.е. в вашем продукте не была заложена testabilityТ.е. не во всех задачах автоматизация дешевле ручной работы. Понимаете, сделать можно вообще все — при наличии бесконечных денег и бесконечного бюджета. Но есть задачи, где автоматизация будет стоить, грубо говоря, 30 килодолларов, а ручное тестирование — 20, при сопоставимом качестве (просто в случае автоматизации просядут одни показатели, а в случае ручного тестирования — другие). И нужно понимать, что нужно в данный конкретный момент, сколько оно стоит и какого результата с его помощью можно достичь.
Если на сервере — может, тестировать запросамиНу, если под «клиентом» подразумевать модуль рисующий, а под сервером — обработку данных для модуля рисующего, то вроде бы да. На практике все хуже — в первую очередь, из-за того, что интегрироваться приходится с совсем не идеальным блэкбоксом в виде GL-подсистемы, для которой уже «сервером» является наш рисующий модуль. Для корректной имитации всего этого в рамках тестов нужны ОЧЕНЬ развесистые моки, которые:
— (глобальный вопрос) нужно опять же тестировать и поддерживать
— (локальный вопрос) черта с два нормально напишешь, т.к. спецификация видеодрайвера содержит исключительно «прямые пути», без описания того, что происходит внутри и с очень бедно описанными исключениями.
оно ещё и не обязательно через GUI делаетсяНет, не обязательно. Но в рамках неких acceptance test-ов он должен проверяться достаточно часто (и как можно раньше) именно в рамках «сценария пользователя», т.е. когда проходится вся схема, сверху донизу, а не некоего API. Иначе есть много рисков, что ситуация на интеграции пойдет, как в известном анекдоте — «точности не гарантируем, на крайняк будет два туннеля». Но тут есть извечный конфликт практик разработки — в одних случаях предпочитают разрабатывать «снизу вверх», когда вначале пишется некоторое ядро функционала, а в других — «сверху вниз», когда сначала обеспечивают продергать все возможности, пусть даже реальный функционал и забит заглушками.
Слава богу, каждый раз работа мозгом позволила избежать лишней работы руками.Я в свое время на основе всего, что попадалось в руки нашей тест-тиме, вывел для себя список критериев, которые свидетельствуют про то, что, скорее всего, лучше будет тестировать мануально. Правда, он включал в себя такие критерии, как «проект пишут уже больше N месяцев и архитектуру менять нельзя» и «частота изменения сигнатур в API — больше 10 методов в неделю» :)
Я думаю, что самый главный критерий вложений в автоматизацию — это длительность последующей поддержки и развития продукта. Если мы над ним работали 5 лет, а впереди 10, то есть смысл вносить изменения в продукт для улучшения тестируемости и придумывать идеи по совершенствованию фреймворка автотестирования. Если же через полгода мы об этом проекте не вспомним, и на других проектах наработки переиспользовать не сможем, то почти всегда ручного тестирования достаточно и автоматизация будет пустой тратой.
рисуем приложение через OpenGL
а зачем, если не секрет, такое нужно?
игровой интерфейс?
Как заставляли разработчиков писать и, главное, поддерживать GUI-тесты?
После слова «заставить» уже наверное никак :)
В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
В моём опыте обычно на разговоре «жить без них не можем, нужны автотесты» вызываются желающие, которым это интересно и которые понимают, зачем это нужно.
Если общее светлое будущее от автотестов непонятно, а сама задача неинтересная, то конечно никто ничего делать не будет.
Автотесты автотестам рознь. Я не зря сказал именно про GUI. С трудом представляю, как кому-то может быть интересно писать тесты на то, что кнопочка переместилась на 10 пикселей влево, как того захотел заказчик вчера, а завтра исправлять на 20 пикселей вправо, потому что заказчик неправильно оценил где право, а где лево.
Ну автотесты через GUI могут быть интеграционными функциональными, а могут проверять вёрстку.
Вообще, я сильно против проверки вёрстки и отображения автоматизированно, такие вещи всегда лучше смотреть глазками.
Вообще, я сильно против проверки вёрстки и отображения автоматизированно, такие вещи всегда лучше смотреть глазками.
По мне автотесты через GUI и автотесты GUI — две большие разницы. В первом случае мы GUI тестируем поскольку постольку — либо активируем какой-то контрол по его id, селектору или ещё какому признаку, либо «кликаем» в точке с какими-то координатами — этот способ по сути функциональный тест. Во втором нам нужно убедиться, что контрол виден, что он находится в нужном месте экрана, что активен, имеет нужный цвет и т. п. — это тест приемочный.
Действительно, вот этим ребятам тестировщики явно почти не нужны, они сами что хочешь классно протестируют.
Но где ж их набрать в нужном количестве? Вот и приходится как-то учиться…
Но где ж их набрать в нужном количестве? Вот и приходится как-то учиться…
Где их взять только? :)
Странная диаграмма у вас про распределение времени между тестированием, поддержкой и разработкой нового. Из нее получается, что если больше ресурсов выделить на тестирование, то поддержка старого функционала (доработка по требованиям заказчиков, адаптация к изменяющимся бизнес-требованиям и так далее) куда-то пропадает.
Между тем бывает ведь по-разному. Иногда разработка нового не ведется вообще. Иногда продукт замораживается и не поддерживается в пользу перевода ресурсов на полный проект.
Между тем бывает ведь по-разному. Иногда разработка нового не ведется вообще. Иногда продукт замораживается и не поддерживается в пользу перевода ресурсов на полный проект.
Ой, это я может не очень понятно выразилась. Когда что-то меняем по требованию заказчика, это всё-таки новая разработка и новый функционал.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
Но если у нас нет юнит-тестов, если у нас говнокод, то вносить изменения становится очень сложно, всплывают дурацкие баги, и на это всё уходит впустую куча времени — его я серым и изобразила.
По-моему, это у вас с терминологией проблемы. Доработки и адаптации — это новая функциональность, реализация фичереквестов, введение в систему того, что в ней не было и быть не должно было. Поддержка же — это багфиксинг, реакция на багрепорты, введение в систему того, что в ней не было, но должно было быть или удаление того, что было, но не должно было быть.
Задачи классифицируются по отношению к требованиям, а не по коду. Если мне говорят, что теперь «Отчество» необязательное поле, то я заношу этот таск в фичи, если мне говорят, что «Отчество» обязательное, хотя не должно быть таким, то я заношу этот таск в баги. А код, закрывающий таск, будет одинаковый. Просто в первом случае требование об обязательности было озвучено, а во втором — нет, а может даже было озвучено противоположное.
Задачи классифицируются по отношению к требованиям, а не по коду. Если мне говорят, что теперь «Отчество» необязательное поле, то я заношу этот таск в фичи, если мне говорят, что «Отчество» обязательное, хотя не должно быть таким, то я заношу этот таск в баги. А код, закрывающий таск, будет одинаковый. Просто в первом случае требование об обязательности было озвучено, а во втором — нет, а может даже было озвучено противоположное.
Не совсем. Тестировщик роль, как правило, на ровне с программистам или чуть по-важнее.
Оно конечно понятно, что для того чтобы продать что-то должен быть тот кто это «что-то» будет делать. Но Вы не совсем правильно понимаете процесс монетизации продукта.
Достаточно часто программист является или второстепенным или третьестепенным. На первом месте все-таки support и marketting unit именно они знают «Какой скриншот нужно разработать?». Далее идет все-таки тестировщик. Потому что он предотвращает возможную встречу бага с пользователем. Если пользователь найдет найдет критическую багу, то в лучшем случае мат и рефаунд(просьба вернуть деньги обратно), а в худшем потеря имиджа из-за чего и происходит снижение продаж, а это напрямую отражается на зарплатах, тимбилдингах и др.
Поясню мысль:
Приходя в автомагазин за новенькой машиной Вы почти наверняка откажетесь брать машину, если увидите на ней царапину. Уверяю Вас, сколько бы души не вложили в разработку инженера в эту машину Вы ее вряд ли купите и пойдете искать другую. Я еще ни разу не видел человека, который бы хотел купить машину с царапиной! Да, возможно пройдясь по автосалону и увидев другую машину, вы поймете что она точно такая же, но зато она без царапины.
В мире разработки все более-менее похоже на ситуацию с покупкой машины с царапиной. Все также! Если продукт «с царапиной», то его покупать не будут! Почти всегда покупателю не важно как много программист знает паттернов проектирования или идиом разработки. Но зато покупатель очень часто видит продукт «с царапиной» или без нее и ему это очень важно!
Для того чтобы продажи не падали, пользователи не искали другие продукты и решения, и покупали продукты сейчас, а не когда починятся баги и как раз и нужны тестировщики.
Подытожу:
1) Сначала надо знать ЧТО делать
2) Затем знать КТО это купит
3) Далее надо понять как долго это ЧТО-ТО будет делаться
4) Принять решение делать это ЧТО-ТО или не делать.
5) Если все-таки делать, то сделать это ЧТО-ТО
6) Проверить это ЧТО-ТО, т.к. КТО-ТО из п.2 может отказаться от покупки! Зачем ему это ЧТО-ТО с царапиной?
7) Продать это ЧТО-ТО
Уверяю Вас п.5. не самый Важный. Более-того я написал довольно упрощенную схему, более опытные и практикующие люди смогут ее существенно дополнить.
Оно конечно понятно, что для того чтобы продать что-то должен быть тот кто это «что-то» будет делать. Но Вы не совсем правильно понимаете процесс монетизации продукта.
Достаточно часто программист является или второстепенным или третьестепенным. На первом месте все-таки support и marketting unit именно они знают «Какой скриншот нужно разработать?». Далее идет все-таки тестировщик. Потому что он предотвращает возможную встречу бага с пользователем. Если пользователь найдет найдет критическую багу, то в лучшем случае мат и рефаунд(просьба вернуть деньги обратно), а в худшем потеря имиджа из-за чего и происходит снижение продаж, а это напрямую отражается на зарплатах, тимбилдингах и др.
Поясню мысль:
Приходя в автомагазин за новенькой машиной Вы почти наверняка откажетесь брать машину, если увидите на ней царапину. Уверяю Вас, сколько бы души не вложили в разработку инженера в эту машину Вы ее вряд ли купите и пойдете искать другую. Я еще ни разу не видел человека, который бы хотел купить машину с царапиной! Да, возможно пройдясь по автосалону и увидев другую машину, вы поймете что она точно такая же, но зато она без царапины.
В мире разработки все более-менее похоже на ситуацию с покупкой машины с царапиной. Все также! Если продукт «с царапиной», то его покупать не будут! Почти всегда покупателю не важно как много программист знает паттернов проектирования или идиом разработки. Но зато покупатель очень часто видит продукт «с царапиной» или без нее и ему это очень важно!
Для того чтобы продажи не падали, пользователи не искали другие продукты и решения, и покупали продукты сейчас, а не когда починятся баги и как раз и нужны тестировщики.
Подытожу:
1) Сначала надо знать ЧТО делать
2) Затем знать КТО это купит
3) Далее надо понять как долго это ЧТО-ТО будет делаться
4) Принять решение делать это ЧТО-ТО или не делать.
5) Если все-таки делать, то сделать это ЧТО-ТО
6) Проверить это ЧТО-ТО, т.к. КТО-ТО из п.2 может отказаться от покупки! Зачем ему это ЧТО-ТО с царапиной?
7) Продать это ЧТО-ТО
Уверяю Вас п.5. не самый Важный. Более-того я написал довольно упрощенную схему, более опытные и практикующие люди смогут ее существенно дополнить.
>>отсутствие конкурентов
Не факт. У меня были случаи, когда люди обладали временем шли на фриланс биржу и получали то что они хотели не сильно переплатив! Все потому что продукт может содержать в себе N фич, а человеку может быть нужно всего-то 1-2. Так что если нет конкурента сейчас, не факт что его не будет завтра
>>продукты пользуются спросом не потому что в них отсутствуют косяки
Нет. Вы видимо ни разу не присутствовали на собраниях по выбору чего-либо Купить у фирмы-1 или же фирмы-2. Очень часто выбирают именно из-за более стабильной работы.
>>пример с машиной бесполезен
Ну это сугубо ваше неправильное мнение. Попытаюсь привести другую ситуацию, более близкую к программистам. Open-Source системы. Очень много специалистов из разных отраслей технарной мысли(программисты, админы, тестировщики и др.) уверенны в том что «Windows глюкалово» и разубеждать их в этом самое неблагодарное занятие. Я не скажу что они правы или нет, отмечу лишь то что для них настолько важна стабильность продукта что они готовы провести не мало ночей в терминале и уходят на Linux, FreeBSD и др.
А Вы говорите что стабильность и не косячность не важна! К примеру я в свое время после нескольких падений снес со своих компов Google Chrome и стал пользоваться Mozilla FireFox-ом из-за его большей стабильности.
Стабильность продукта это очень важно! Иногда это единственный критерий который выдвигается к продукту. Еще одна ситуация: протектор исполняемых файлов накладывает защиту на исполняемый файл, в результате вдруг получается файл который предлагает пользователю дебажить приложение. Будет ли команда девелоперов применять такой протектор? Возможно, если вдруг альтернатив нет, но если вдруг есть пулей сбежит к конкуренту и попросит вернуть деньги.
Не факт. У меня были случаи, когда люди обладали временем шли на фриланс биржу и получали то что они хотели не сильно переплатив! Все потому что продукт может содержать в себе N фич, а человеку может быть нужно всего-то 1-2. Так что если нет конкурента сейчас, не факт что его не будет завтра
>>продукты пользуются спросом не потому что в них отсутствуют косяки
Нет. Вы видимо ни разу не присутствовали на собраниях по выбору чего-либо Купить у фирмы-1 или же фирмы-2. Очень часто выбирают именно из-за более стабильной работы.
>>пример с машиной бесполезен
Ну это сугубо ваше неправильное мнение. Попытаюсь привести другую ситуацию, более близкую к программистам. Open-Source системы. Очень много специалистов из разных отраслей технарной мысли(программисты, админы, тестировщики и др.) уверенны в том что «Windows глюкалово» и разубеждать их в этом самое неблагодарное занятие. Я не скажу что они правы или нет, отмечу лишь то что для них настолько важна стабильность продукта что они готовы провести не мало ночей в терминале и уходят на Linux, FreeBSD и др.
А Вы говорите что стабильность и не косячность не важна! К примеру я в свое время после нескольких падений снес со своих компов Google Chrome и стал пользоваться Mozilla FireFox-ом из-за его большей стабильности.
Стабильность продукта это очень важно! Иногда это единственный критерий который выдвигается к продукту. Еще одна ситуация: протектор исполняемых файлов накладывает защиту на исполняемый файл, в результате вдруг получается файл который предлагает пользователю дебажить приложение. Будет ли команда девелоперов применять такой протектор? Возможно, если вдруг альтернатив нет, но если вдруг есть пулей сбежит к конкуренту и попросит вернуть деньги.
Лучше всё-таки машина с царапиной, чем отсутствие и машины, и царапины :)
Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины (а софт у нас обычно не просто царапаный, а битый), разработчики важнее и это ОК.
На высококонкурентных продуктовых западных рынках софта роль тестировщика соответствует значимости разработки.
Но врядли когда-либо тестирование будет важнее, т.к. нет разработки — нет машины :)
Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины (а софт у нас обычно не просто царапаный, а битый), разработчики важнее и это ОК.
На высококонкурентных продуктовых западных рынках софта роль тестировщика соответствует значимости разработки.
Но врядли когда-либо тестирование будет важнее, т.к. нет разработки — нет машины :)
Ну для кого-то может машина с царапиной и хороший вариант, но я лично проследую к другой машине или совсем в другой автосалон. Ведь мы знаем, что машина теряет в цене сразу же после того как она покинула пределы салона, а царапина еще больше обесценивает стоимость машины. Ведь не исключена ситуация когда мне надо будет продать машину, а машина с царапиной стоит дешевле! ;)
>>нет разработки — нет машины
Да. В своем комментарии как раз и отметил этот факт во втором предложении. Но я о другом. К примеру два продукта с примерно одинаковой функциональностью и вам нужна одна из фич, которая есть в одном из них. Допустим на сайте каждого вендора выложены демо-версии. Мы перед покупкою скачиваем и видим что у Вендор1 интересуемая нас фича не работает, а у Вендора2 работает. При тех же деньгах, том же списке фич, той же цене к кому Вы пойдете? Неужели к тому вендору у которого демо-версия не работает?
>>нет разработки — нет машины
Да. В своем комментарии как раз и отметил этот факт во втором предложении. Но я о другом. К примеру два продукта с примерно одинаковой функциональностью и вам нужна одна из фич, которая есть в одном из них. Допустим на сайте каждого вендора выложены демо-версии. Мы перед покупкою скачиваем и видим что у Вендор1 интересуемая нас фича не работает, а у Вендора2 работает. При тех же деньгах, том же списке фич, той же цене к кому Вы пойдете? Неужели к тому вендору у которого демо-версия не работает?
Правильно. Всё зависит от конкурентности рынка, т.е. от наличия «нецарапаных» вендоров :)
У майкрософта SDET'ов чуть больше, чем разработчиков (SDE). В некоторых компаниях с известными мировыми именами, в которых я работала, тестировщики зарабатывают больше разработчиков. Т.к. каждый мелкий баг, про который напишут в PC Magazine, стоит сотни тысяч долларов убытков.
Но это исключения, т.к. в основном рынки софта пока что — это рынки царапаных машин :)
У майкрософта SDET'ов чуть больше, чем разработчиков (SDE). В некоторых компаниях с известными мировыми именами, в которых я работала, тестировщики зарабатывают больше разработчиков. Т.к. каждый мелкий баг, про который напишут в PC Magazine, стоит сотни тысяч долларов убытков.
Но это исключения, т.к. в основном рынки софта пока что — это рынки царапаных машин :)
Поэтому, на нашем рынке, где народ пока готов покупать царапаные машины
мне всегда на это рассказывали историю Васи и Пети:
Жили да были Вася да Петя, и решили они делать один программный продукт. Вася был сторонник вылизывания всех фич, предварительного тестирования, написания юнит тестов и т.д, Петя был сторонник быстрого прототипирования и выдачи заказчику. Поссорились они на этом и разбежались. Прошло полгода, Вася всё ещё писал продукт, вылизывая фичи и интерфейс, покрывая код тестами. В это время Петя, за первый месяц выпустил сырую версию продукта, без половины функционала и собрал первые отзывы покупателей, через 2 месяца выпустил вторую версию, закрывающую большую часть функционала и добавив новый по запросам пользователей, собрал отзывы и на вырученные деньги нанял двух программистов и они целиком переписали продукт под требования пользователей, и через 3 месяца выпустил уже третью версию с которой снял хороший барыш. Вылизанный продукт Васи стал не актуален, т.к. не было отзывов пользователей и он не знал, что идёт не туда с чем и пролетел. В итоге Петя купил Васин код, включил его в свой и продаёт версию 4, ездит на порш-каене и доволен жизнью, а Вася работает на Петю за обычную зарплату.
Ну тут всегда будет вечный спор, и любые крайности плохи.
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Без половины функциональности всё же не значит с неработающей функциональностью. Про баги ни слова в истории :)
Если продукт «с царапиной», то его покупать не будут!
Продажи кучи продуктов это опровергают. Самый известный пример, наверное, Windows.
Отсутствие предрилизного тестирования может снижать продажи, в некоторых случаях до нуля, отсутствие разработки продажи обязательно снизит до нуля — тупо нечего будет продавать (мошеннические и близкие к ним схемы не берём). Разработчики — необходимое звено, тестировщики — опциональное.
>>Самый известный пример, наверное, Windows
Вы ее покупали? ;) Я лично нет и не собираюсь! Вокруг меня вращается достаточно много технарей как программеров так и админов и др. Но не могу назвать ни одного человека, который бы себе купил Windows ;) Более того, знаю человека который ходил в Microsoft с целью написания заявления вернуть денег за предустановленную систему при покупке ноутбука.
Также могу отметить, что среди моих знакомых охотнее возьмутся админить, сопровождать систему Linux или что-нибудь из BSD-лагеря, чем Windows. Да и далеко ходить у нас(где работаю) почти все на Linux.
Еще могу заметить что среди моих знакомых не технарей, которые задумываются что-то развернуть у себя в конторе почему-то первым задают вопрос «У тебя есть знакомые которые понимают в Linux?». Очень часто находятся и Windows Server решения не ставятся!
>>в некоторых случаях до нуля
Да и любой владелец бизнеса должен такое предусмотреть и иметь финансовую «подушку безопасности» в случае таких вот форс-мажоров. Но не у всех это получается. Имеются в памяти примеры, когда программисты просто вставали и уходили к другим работодателям. Лично я услышав «Зарплата будет задержана на месяц» не пойму, хоть что-то да попрошу, ибо семья, др. обязательства и расходы. Также думают и многие другие. «Доведение до нуля» даже в «некоторых случаях» оочень опасно для бизнеса!
Вы ее покупали? ;) Я лично нет и не собираюсь! Вокруг меня вращается достаточно много технарей как программеров так и админов и др. Но не могу назвать ни одного человека, который бы себе купил Windows ;) Более того, знаю человека который ходил в Microsoft с целью написания заявления вернуть денег за предустановленную систему при покупке ноутбука.
Также могу отметить, что среди моих знакомых охотнее возьмутся админить, сопровождать систему Linux или что-нибудь из BSD-лагеря, чем Windows. Да и далеко ходить у нас(где работаю) почти все на Linux.
Еще могу заметить что среди моих знакомых не технарей, которые задумываются что-то развернуть у себя в конторе почему-то первым задают вопрос «У тебя есть знакомые которые понимают в Linux?». Очень часто находятся и Windows Server решения не ставятся!
>>в некоторых случаях до нуля
Да и любой владелец бизнеса должен такое предусмотреть и иметь финансовую «подушку безопасности» в случае таких вот форс-мажоров. Но не у всех это получается. Имеются в памяти примеры, когда программисты просто вставали и уходили к другим работодателям. Лично я услышав «Зарплата будет задержана на месяц» не пойму, хоть что-то да попрошу, ибо семья, др. обязательства и расходы. Также думают и многие другие. «Доведение до нуля» даже в «некоторых случаях» оочень опасно для бизнеса!
Все? Аргументы закончились? Когда не нанашлось аргументов сразу же пошло в ход «религиозный фанатик»? ;) Смешно. Вынужден Вас огорчить сижу на Windows :) В данный момент на Seven, собираюсь бежать на 8.1. На работе тоже Seven. Так что настоящие «религиозные фанатики» про меня бы сказали закоренелый виндузядник ;)
Согласен с тезисом, что тестировать нужно сразу. Очень много спорил с экс-коллегой, который упорно не хотел отдавать тестировщикам первую версию продукта, пока сам может найти хоть один баг, и как итог — громадный срыв сроков, тестирование в последний день и куча безусловных try-catch в коде, которые находятся иногда до сих пор. Успел уволиться :)
Очень красивые графики, но на чем они основаны? Можно посмотреть на исходную статистику?
Сисадмин — роль второго плана?
Почему такое происходит, вполне понятно: мало кто вживую встречал квалифицированных сисадминов, сисадмины не делают полезный результат (продукт не пишут), да и вообще у нас принято экономить на всём, на чём только получается. Интересен другой вопрос: что получается благодаря такому подходу?
Сюда какую специальность не подставь — все подойдет. Логично ведь, если компания специализируется на разработке, то в ней разработчик — роль первого плана, остальные — второго, и менеджеры и бухгалтеры и юристы. Если компания юридическая, например, то юрист — роль первого плана, остальные второго и тд.
Дня меня это выглядит как слегка завистливый пост на тему, почему другие зарабатывают больше чем я?
Почему такое происходит, вполне понятно: мало кто вживую встречал квалифицированных сисадминов, сисадмины не делают полезный результат (продукт не пишут), да и вообще у нас принято экономить на всём, на чём только получается. Интересен другой вопрос: что получается благодаря такому подходу?
Сюда какую специальность не подставь — все подойдет. Логично ведь, если компания специализируется на разработке, то в ней разработчик — роль первого плана, остальные — второго, и менеджеры и бухгалтеры и юристы. Если компания юридическая, например, то юрист — роль первого плана, остальные второго и тд.
Дня меня это выглядит как слегка завистливый пост на тему, почему другие зарабатывают больше чем я?
Кстати о заработке. Не такая уж и редкость встретить функциональщика, который получает побольше многих разработчиков. Естественно это не аутсорсинг и не студенты.
Вот на что мне грех жаловаться, так это на зарплату :)
А вот за некачественные продукты в случаях, когдя я не могу на это повлиять — обидно!
А вот за некачественные продукты в случаях, когдя я не могу на это повлиять — обидно!
Уже почти все описанное в статье испытал. Бонус еще есть — когда руководители понимают, что все уже ОЧЕНЬ плохо, находят чувака по-дороже, но по инерции каждый встречный-поперечный пытается учить делать его работу «более лучше». Что-то вроде «ну он же тестер, наверняка и wireshark пользоваться не может». И когда ты автоматизируешь вход с модифицированной gina, а тебе под руку дают капитанские советы «как nat в vmware настроить», это просто бесит. В замечательнейшем докладе Дмитрия Петунина, про 1001 заблуждение(очень советую) про это отношение к тестерам замечательный стихотворный эпиграф. Куча времени уходит на пруфы, что ты не верблюд. Но основная проблема мне видится в отсутствии простых способов повышения качества. Невозможно просто взять студента и провести анализ багов за год, создать единые тестовые среды, сформировать требования, провести code review.
Чтобы уж совсем не депрессовать расскажу о хорошем — о мотивации, почему люди работают тестерами, несмотря на все: just for fun. Нет, реально, тестировать — это довольно весело. IT вообще одно из немногих направлений человеческой деятельности, где можно зарабатывать, что-то изучая большую часть рабочего времени, и тестирование в IT — сплав разработки, администрирования, внедрения, менеджмента позволяет узнать гораздо больше.
Чтобы уж совсем не депрессовать расскажу о хорошем — о мотивации, почему люди работают тестерами, несмотря на все: just for fun. Нет, реально, тестировать — это довольно весело. IT вообще одно из немногих направлений человеческой деятельности, где можно зарабатывать, что-то изучая большую часть рабочего времени, и тестирование в IT — сплав разработки, администрирования, внедрения, менеджмента позволяет узнать гораздо больше.
Некоторое время назад упразднил в своей команде роль автотестировщика и перешел на сторону разработки.
Самое сложное — привить разработчикам мысль на уровне подсознания, что больше нет никакого волшебного человечка, который все еще раз перепроверит (или даже просто проверит, ведь «зачем, там и так все будет работать, я поправил одну строчку»), а также искоренить мнение, что разработчику не к лицу писать функциональные тесты.
В целом, пока все еще устаканиваем новый процесс работы, но конечная цель — команда без слабых звеньев («ой, а у нас тестировщик заболел») с вовлеченностью каждого в обеспечение качества — стоит того, чтобы это попробовать.
Самое сложное — привить разработчикам мысль на уровне подсознания, что больше нет никакого волшебного человечка, который все еще раз перепроверит (или даже просто проверит, ведь «зачем, там и так все будет работать, я поправил одну строчку»), а также искоренить мнение, что разработчику не к лицу писать функциональные тесты.
В целом, пока все еще устаканиваем новый процесс работы, но конечная цель — команда без слабых звеньев («ой, а у нас тестировщик заболел») с вовлеченностью каждого в обеспечение качества — стоит того, чтобы это попробовать.
Расскажите об итогах после релиза и отзывов клиентов.
Рассказать уже можно, поскольку релизы у нас примерно раз в месяц. Чудес не бывает, сразу все гладко не пошло. Чем больше я погружался в разработку, тем меньше времени у меня оставалось напоминать коллегам, не просмотреть отдельные нюансы и учесть их в тестах и при финальной проверке. В результате постоянно были ситуации, когда ошибки обнаруживались при подготовке к демонстрации. Пару ошибок мы-таки пропустили в релиз :-( Но мы знаем, что нужно делать и корректируем свой процесс.
1. Не получится ли, что исключая звено тестировщиков, вы погружаете разработчиков в большую детализацию работы и тем самым повышаете зависимость от каждого конкретного человека (Bus factor)?
2. Насколько тяжело дается отработка кейсов человеку, который делает систему? Нет ли замыливания глаз?
3. Во время работы тестировщиков, разрабы обычно берутся за реализацию других задач. Получается некое распараллеливание. В вашем случае разработчик делает все сам, плюс ему больше придется общаться с пользователями и аналитиками. Что со временем? Не придется ли в итоге нанимать дополнительного разработчика?
2. Насколько тяжело дается отработка кейсов человеку, который делает систему? Нет ли замыливания глаз?
3. Во время работы тестировщиков, разрабы обычно берутся за реализацию других задач. Получается некое распараллеливание. В вашем случае разработчик делает все сам, плюс ему больше придется общаться с пользователями и аналитиками. Что со временем? Не придется ли в итоге нанимать дополнительного разработчика?
1. Безотносительно процесса тестирования всегда хорошо, когда в решении задач из одной и той же области кроме признанного в ней эксперта участвует кто-то еще из команды. В традиционном подходе таким «кем-то еще» становится тестировщик (на уровне понимания бизнес-домена и нюансов реализации с точки зрения пользователя/конфигурации), в нашем случае им становится другой разработчик (на уровне понимания бизнес-домена, нюансов реализации с точки зрения пользователя/конфигурации и нюансов реализации с точки зрения кода).
2. Пока есть сложности с этим. Пробуем решать командным ревью результатов анализа (анализ включает составление кейсов) и ревью собственно реализации.
3. Безусловно, навешивание на разработчиков полного цикла задач по обеспечению качества увеличивает общую скорость решения задачи разработчиком. С другой стороны, исчез пинг-понг и переключение между новой задачей и той, что вчера была передана в тестирование.
А насчет общения, уверен, что разработчикам полезно больше общаться с пользователями и аналитиками для улучшения понимания ценностей, целей, задач бизнеса компании и бизнеса ее клиентов. Лично меня очень расстраивает, что некоторым совершенно неинтересно это знать («я лучше код порефакторю, чем поеду на экскурсию на объект клиента» ©).
2. Пока есть сложности с этим. Пробуем решать командным ревью результатов анализа (анализ включает составление кейсов) и ревью собственно реализации.
3. Безусловно, навешивание на разработчиков полного цикла задач по обеспечению качества увеличивает общую скорость решения задачи разработчиком. С другой стороны, исчез пинг-понг и переключение между новой задачей и той, что вчера была передана в тестирование.
А насчет общения, уверен, что разработчикам полезно больше общаться с пользователями и аналитиками для улучшения понимания ценностей, целей, задач бизнеса компании и бизнеса ее клиентов. Лично меня очень расстраивает, что некоторым совершенно неинтересно это знать («я лучше код порефакторю, чем поеду на экскурсию на объект клиента» ©).
тогда, надеюсь, у вас принят метод тыканья разработчиков голово в их собственное гумно, как у мелкомягких?
(у них у разработчиков приняты ночные дежурства в техподдержке своей части приложения)
(у них у разработчиков приняты ночные дежурства в техподдержке своей части приложения)
Я согласен с тем, что разработчик побывавший хотя бы раз поздно вечером на запуске на объекте клиента, в последствии более трепетно относится к качеству своей работы. Но сам факт позднего выявления ошибки это повод для оперативных действий по устранению последствий и тема для ретро, а не повод для линчевания.
а также искоренить мнение, что разработчику не к лицу писать функциональные тесты
Функциональные (дернули событие/запрос по ид или ещё чему — проанализировали изменения данных/ответ) куда не шло, но каждый раз после «сделайте кнопочку побольше» исправлять тесты этой кнопочки, что у неё ширина 147 пикселей, что не появляется прокрутка на куче разрешений, что другие элементы не уплыли и т. п… Не то, что не к лицу, а очень скучно — можно найти занятия и поинтереснее.
Напишите, пожалуйста, чем все закончилось? Два года прошло уже, достаточный срок для анализа.
Идея, что разработчики сами закроют функциональное тестирование не взлетела.
Перед тем, как уйти на новый проект, мне пришлось взять в команду толкового автотестировщика, чтобы не уронить качество.
В то время, когда разработчики пишут функциональные тесты, они не пишут код. Как следствие:
1. разработчики хотят писать код, а не тесты;
2. бизнес хочет, чтобы разработчики писали код, а не тесты;
3. никто не хочет тесты.
В моей новой команде выделенная роль автотестировщика была запланирована сразу.
Перед тем, как уйти на новый проект, мне пришлось взять в команду толкового автотестировщика, чтобы не уронить качество.
В то время, когда разработчики пишут функциональные тесты, они не пишут код. Как следствие:
1. разработчики хотят писать код, а не тесты;
2. бизнес хочет, чтобы разработчики писали код, а не тесты;
3. никто не хочет тесты.
В моей новой команде выделенная роль автотестировщика была запланирована сразу.
> «поикать ошибки»
Отличное описание работы тестировщика!
Отличное описание работы тестировщика!
В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго планаТак может быть перестать называть специалиста, занимающегося повышением качества ПО «тестировщиком», и начать называть, скажем, «инженером по качеству» (программных продуктов)? Ну, конечно, от одного изменения названия мало что поменяется, но это — необходимое условие. Как там говорили — «в африке — живут негры», вот и выходит, что «тестировщик — тестирует». А не повышает качество.
Вопрос есть и в другом. Пишете, что есть хорошие процессы обеспечения качества в российских компаниях — почему бы о них и не рассказать? Не в ключе — «вот так делать плохо», а в позитивном — «вот такое дает результаты». И вообще в области управления качеством продукции есть технологии, которые почему-то в разработке софта задействуются мало. Хоть ПО не с конвейера выходит, дефекты у него существуют, и их можно прогнозировать, и уровнем качества, следовательно, можно управлять. Было бы интересно узнать больше об этом.
Ну и отдельное спасибо за тэг ROI.
Получается, что тестировщики определённо нужны. Но из-за мнения работодателей, что тестировщики — это роль второго плана, платят им значительно меньше, чем должны были бы. Хотя, в последнее время, есть тенденция к увеличению зарплаты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестировщики — роль второго плана?