Comments 27
В нашей компании тестировщики и разработчики постоянно тесно взаимодействуют. И никаких конфликтов не возникает. Адекватность — наше все.
А третье лицо при взаимодействии разработчиков и тестировщиков только усложнит процесс.
А третье лицо при взаимодействии разработчиков и тестировщиков только усложнит процесс.
Не знаю, не знаю им и так беднягам достается.
Лично я, как только тестеры находят баг в моем коде или даже смежном, говорю им «Биг сенкс! — без вас не прога была бы, а ....»
зы
да и опять таки — тестеры это крыша для программеров, если вдруг в релизе вылез баг, то на вопли менеджеров спокойно отсылаешь их в отдел тестирования.
Так и говорю им, культурно,- «Я же не могу исправить того чего нет на багтреке? Так что идите вы в отдел тестирования, пожалуйста.»
Лично я, как только тестеры находят баг в моем коде или даже смежном, говорю им «Биг сенкс! — без вас не прога была бы, а ....»
зы
да и опять таки — тестеры это крыша для программеров, если вдруг в релизе вылез баг, то на вопли менеджеров спокойно отсылаешь их в отдел тестирования.
Так и говорю им, культурно,- «Я же не могу исправить того чего нет на багтреке? Так что идите вы в отдел тестирования, пожалуйста.»
UFO just landed and posted this here
Что разработчик, что тестировщик — обычные люди, которые могут ошибаться. Но каждый по своему. Надо это понимать и работать в команде.
UFO just landed and posted this here
Мне кажется, проблема несколько надумана. Сам уже давно являюсь руководителем небольшой команды, а до того еще дольше был разработчиком, но с этой проблемой встречался всего раз, да и то в связке сисадмин/тестировщик. Сисадмина, к слову, сменили.
UFO just landed and posted this here
Помимо «тестирования кода» есть же еще много разных видов тестирования. Ручное, например, или нагрузочное. Например, тестировщик, занимающийся ручным тестированием, знает много-много бизнес-логики и должен ее всю держать постоянно в голове. Если этим (с таким погружением) будут заниматься программисты, то никаким программированием они не будут успевать заниматься.
UFO just landed and posted this here
UFO just landed and posted this here
Давайте, для начала, вспомним, что фразу «тестирование кода» это Вы сказали, а не я. Да, я за нее зацепился.
По-моему, нагрузочным тестированием занимаются специалисты по нагрузочному тестированию. Разве нет?
В целом Вы правы, программист должен протестировать то, что он сделал. Но например, после написания какого-то модуля/функционала, переключившись на другую задачу да месяц-другой, и вернувшись к этому модулю обратно — даже если там никто ничего не поменял за это время, сложно вспомнить все нюансы и тонкости логики. Да, написанные тесты облегчают регрессионное тестирование, как Вы и сказали, но эти тесты, как я считаю, должны писать не те же программисты, которые реализуют бизнес-логику, а как раз тестировщики, которые больше по бизнес-логике и, независимо от того, какой именно программист переписывал логику, именно тестировщик должен эту логику знать.
Ведь, если программисты были бы лучшими тестировщиками, чем сами тестировщики — то получается, что и тестировщики были бы не нужны. Но они же нужны! Или Вы считаете, что тестировщики нужны там, где плохие программисты?
ИМХО, тестировщики нужны там, где система реально большая и сложная. Ведь, если программист «пришел» переписывать/дописывать какой-то функционал, он может не знать всех тонкостей реализации данного модуля и что имено надо протестировать.
По-моему, нагрузочным тестированием занимаются специалисты по нагрузочному тестированию. Разве нет?
В целом Вы правы, программист должен протестировать то, что он сделал. Но например, после написания какого-то модуля/функционала, переключившись на другую задачу да месяц-другой, и вернувшись к этому модулю обратно — даже если там никто ничего не поменял за это время, сложно вспомнить все нюансы и тонкости логики. Да, написанные тесты облегчают регрессионное тестирование, как Вы и сказали, но эти тесты, как я считаю, должны писать не те же программисты, которые реализуют бизнес-логику, а как раз тестировщики, которые больше по бизнес-логике и, независимо от того, какой именно программист переписывал логику, именно тестировщик должен эту логику знать.
Ведь, если программисты были бы лучшими тестировщиками, чем сами тестировщики — то получается, что и тестировщики были бы не нужны. Но они же нужны! Или Вы считаете, что тестировщики нужны там, где плохие программисты?
ИМХО, тестировщики нужны там, где система реально большая и сложная. Ведь, если программист «пришел» переписывать/дописывать какой-то функционал, он может не знать всех тонкостей реализации данного модуля и что имено надо протестировать.
UFO just landed and posted this here
Не встречал таких, всегда сами делали.
Вот небольшая подборочка. Да, не все вакансии подходят только под нагрузочное тестирование, но все же: hh.ru
Ту работу тестировщиков которую я видел, можно было автоматизировать. Я считаю, если тестировщик не автоматизирует свою работу, то это плохой тестировщик.
На моей практике тестировщики тестируют не только конкретные реализованные фичи и баги, но и находят новые, часто даже там, где сложно предугадать всем, даже программистам. (Ах-ха, я забыл, это плохие программисты, у них же есть тестировщики).
Вот именно эту проблему решают тесты, если что-то сделал не так, тесты не пройдут.
Вы, наверное, и правда никогда не делаете ошибок, особенно в тестах, которые покрывают всё-всё. Каждый день, наверное, звонят, предлагают работу?
А если серьезно. Вы участвовали когда-нибудь в разработке по-настоящему больших систем в очень больших (ну или многочисленных) командах разработчиков?
Например, банковское ПО. Я видел ситуацию, где было около 7-8 систем, каждая из которых «тянет» данные из остальных. Каждую систему разрабатывает какая-то конкретная команда программистов. Код покрыт юнит-тестами. Обновления систем происходят одновременно около 4-х раз в год. Думаете, и тут без тестировщиков можно обойтись?
UFO just landed and posted this here
там понимается использование тулов типа JMeter. Этого бывает недостаточно, приходится иногда свои тулы писать
Не спорю, когда я работал специалистом по нагрузочному тестированию, было необходимо не только JMeter использовать, но и свои скритпты на Python, Perl, etc. писать. Также, например, необходимо было и в профилировщиках СУБД разбираться (Oracle, на тот момент).
Я предлагаю не переходить на личности
Искренне извиняюсь, если так получилось. Не хотел переходить на личности.
Я лишь говорил о том, что тестирование — это ответственность разработчика и нет необходимости нанимать отдельных людей.
И конечно же это мое личное мнение, но оно сложилось из опыта.
Да уж, и правда, мы с Вами по-разному смотрим на процесс.
И я согласен с тем, что бывает нужно выделить команду тестирования, но это те же программисты, которые тоже пишут код, только для тестов, а не бизнес логики (и это не то, что понимают под тестировщиком, который пишет автотесты).
Мой посыл, как раз, в том, чтобы не было людей-оркестров. До сих пор, мне кажется, это держится в тренде — разделять обязанности и ответственность. Все к этому привыкли.
тестирование — это не «тестирование кода», это доказательство корректности программы.
Вот потеха! И часто вам удавалось доказать корректность программмы?
А зачем нужны тестировщики, я имею ввиду как отдельный класс? Я всегда считал, что тестировать код — ответственность программиста.
Похоже, вы слепо верите в то, что тестирование — это лишь процесс поиска дефектов в приложении, а программист — в состоянии дать объективную оценку своего собственного кода.
Интереса ради, опишите ваш текущий процесс: как разработчики проводят планирование, тестирование, анализ, ретроспективы без участия QA? Над какими продуктами по масштабу вам приходилось работать? Да и к слову, чем по-вашему testing отличается от QA?
UFO just landed and posted this here
Почему вы решили, что у нас нет QA? QA — это одна из задач, просто не выделяем под это отдельных специалистов.
Т.е. вы хотите сказать, что у вас девелоперы тестируют, к примеру, требования / мокапы, собирают различные метрики / ведут тестовую документацию, мониторят плотность дефектов по отношению к функциональным областям во времени и т.п.? Я ведь не зря попросил описать ваши процессы. Что, к примеру, входит в скоуп имеено ваших задач на проекте(-ах)?
Разделение testing и QA, это как разделение кодер и программист
Прошу заметить, что я написал testing (как процесс), а не tester (как сленговая характеристика позиции). И прежде чем заводить дискуссию на тему тестирования с девелопером, хотелось бы для начала понимать, что именно вы вкладываете в это понятие (в качестве процесса, а не определения из учебника)?
Вот вы поделились своим опытом, что работу всех тех QA, которые вам встречались, можно было бы смело автоматизировать. Потому собственно вы и не видите смысла в позиции manual QA, как таковой. А я вот, к примеру, практически не встречал программистов, реально понимающих QA процессы. Но в целом, это нормально, поскольку для этого существуют соответствующие специалисты. Каждый занимается своим делом, не обучая других жизни, и не вставляя палки в колеса. Следовательно, в условиях плотной кооперации, вся команда достигает положительного результата. А рассказывать о том, что какая-то специализация бесполезна, исходя лишь из своего личного опыта, — ни чуть не лучше использования сленговых "кодер" и "тестер". Тем самым, вы закинули огромный камень в огород QA инженеров, среди которых много толковых ребят.
Все профессии нужны, все профессии важны. (с)
вы, имо, конечно правы по принципу: «Кто сторожит сторожей» в замечании
но слишком переоцениваете QA, что видно из
Есть qa, нет его, и есть только «testing»—конечная задача всего этого действа сдать проект заказчику с «приемлемым качеством».
программист — в состоянии дать объективную оценку своего собственного кода.
но слишком переоцениваете QA, что видно из
чем по-вашему testing отличается от QA?
Есть qa, нет его, и есть только «testing»—конечная задача всего этого действа сдать проект заказчику с «приемлемым качеством».
А ты шаришь :)
Тут есть несколько подводных камней.
1) Я работал на проекте, которому уже больше 8 лет, на котором тестирование не автоматизировалось совсем. Там такое колличество кода и функционала, что просто написать с ноля «классическую» тестовую документацию (забить тест кейсы в какой-нить тул) займёт где-то месяцев 6 у всей QA тимы, а потом ещё месяца 3, чтоб догнать все изменения, которые были сделаны за эти пол года. Не говоря уже о покрытии всего этого тестами. Т.е. разработку нужно будет закрыть на год. Или нанять отдельную команду, которая будет только автоматизировать. Ну я таких заказчиков ещё не видел. В лучшем случае просят просто переписать всю систему с нуля и её уже покрывать тестами (как минимум «оригинал» прийдётся переделывать к тому виду чтоб он без костылей принимал Моки). Проект с нуля это другая история. А в ситуации выше без QA не знаю как обойтись. Да проект\момент упущен, но не нужно забывать, что не всегда Вам прийдётся работать над новыми системами…
2) Сейчас я работаю на проекте, в котором все тесты должны быть автоматизированны (как часть деливери). Девелоперы пишут Юнит и Интегрейшин тесты. Отдел QA — system-tests (т.е. мы не используем Моки, а пытаемся следовать юзер-кейсам). Изначально я скептически к этому относился (ну то есть авто тесты — круто, но покрыть ВСЁ это перебор), но через 3 месяца вырисовалась картина, что автоматизировать можно действительно всё. Но если на простых компонентах тесты пишутся быстро, то в тех местах где появляется средненький уровень взаимодействия с юзером, то сложность тест кода возрастает в разы. И вот тут вываливается огромная проблема.
3) Я не видел ещё программиста который по собственному желанию будет писать тесты для кода, написанного другим программистом. Можно нанять отдельного человека писать только тесты. НО! В головах работодателей до сих пор бытует мнение что QA это низкоквалифицированная работа. Соответственно ЗП на эту позицию ниже. Если есть выбор пойти в отдел QA или в отдел разработки — ответ становится очевиден. Тем кто в итоге попадает в такую команду — очень не хватает опыта. Вкладывать деньги в образование персонала — очень врятли, да и времени нет. Поэтому качество написанных тестов резко падает с увеличением сложности бизнесс логики. В итоге мне как тимлиду либо приходится переписывать тест код самому (когда уже капец времени нет), либо наперёд писать мини-фреймворк (в моём понимании это план, которому нужно следовать для тестирования похожих сценариев но с разным ожидаемым результатом), либо заставлять по 3 раза переписывать одно и тоже, т.к. колличество копипаста зашкаливает и т.п.
4) На мой взгляд возможным решением тут был-бы наём Junior«ов тестить чужой код с обещанием промоушена через год. Но тут уже появляется проблема снобства и не желанием или нехваткой времени у старших учить правильно кодить.
5) Я рад что у Вас „полный agile“, и у Вас есть возможность собрать фидбек от пользователей. Но QA очень часто приходится просить изменить UI или весь user case, т.к. логическая цепочка слишком сложная либо не очевидная. Да это проблема проектирования и документации, но именно тестирование документации тоже является частью работы QA. А потом ещё пойди докажи PM, SA и Dev, что после релиза саппорт будет завален звонками.
Ещё хотелось-бы добавить, что тестировать СВОЙ код (white box) — очень плохая практика. Не зря всегда выделяют „black box“ тестинг…
Я свои приложения всегда даю попользовать знакомым\семье. И всегда появляются упущенные сценарии либо не понимание workflow. Банально некоторые вещи слишком заумные. Для меня было шоком, когда 3 человека не смогли найти страничку favorites, которая открывалась по тапу стандартной иконки „звёздочка“.
1) Я работал на проекте, которому уже больше 8 лет, на котором тестирование не автоматизировалось совсем. Там такое колличество кода и функционала, что просто написать с ноля «классическую» тестовую документацию (забить тест кейсы в какой-нить тул) займёт где-то месяцев 6 у всей QA тимы, а потом ещё месяца 3, чтоб догнать все изменения, которые были сделаны за эти пол года. Не говоря уже о покрытии всего этого тестами. Т.е. разработку нужно будет закрыть на год. Или нанять отдельную команду, которая будет только автоматизировать. Ну я таких заказчиков ещё не видел. В лучшем случае просят просто переписать всю систему с нуля и её уже покрывать тестами (как минимум «оригинал» прийдётся переделывать к тому виду чтоб он без костылей принимал Моки). Проект с нуля это другая история. А в ситуации выше без QA не знаю как обойтись. Да проект\момент упущен, но не нужно забывать, что не всегда Вам прийдётся работать над новыми системами…
2) Сейчас я работаю на проекте, в котором все тесты должны быть автоматизированны (как часть деливери). Девелоперы пишут Юнит и Интегрейшин тесты. Отдел QA — system-tests (т.е. мы не используем Моки, а пытаемся следовать юзер-кейсам). Изначально я скептически к этому относился (ну то есть авто тесты — круто, но покрыть ВСЁ это перебор), но через 3 месяца вырисовалась картина, что автоматизировать можно действительно всё. Но если на простых компонентах тесты пишутся быстро, то в тех местах где появляется средненький уровень взаимодействия с юзером, то сложность тест кода возрастает в разы. И вот тут вываливается огромная проблема.
3) Я не видел ещё программиста который по собственному желанию будет писать тесты для кода, написанного другим программистом. Можно нанять отдельного человека писать только тесты. НО! В головах работодателей до сих пор бытует мнение что QA это низкоквалифицированная работа. Соответственно ЗП на эту позицию ниже. Если есть выбор пойти в отдел QA или в отдел разработки — ответ становится очевиден. Тем кто в итоге попадает в такую команду — очень не хватает опыта. Вкладывать деньги в образование персонала — очень врятли, да и времени нет. Поэтому качество написанных тестов резко падает с увеличением сложности бизнесс логики. В итоге мне как тимлиду либо приходится переписывать тест код самому (когда уже капец времени нет), либо наперёд писать мини-фреймворк (в моём понимании это план, которому нужно следовать для тестирования похожих сценариев но с разным ожидаемым результатом), либо заставлять по 3 раза переписывать одно и тоже, т.к. колличество копипаста зашкаливает и т.п.
4) На мой взгляд возможным решением тут был-бы наём Junior«ов тестить чужой код с обещанием промоушена через год. Но тут уже появляется проблема снобства и не желанием или нехваткой времени у старших учить правильно кодить.
5) Я рад что у Вас „полный agile“, и у Вас есть возможность собрать фидбек от пользователей. Но QA очень часто приходится просить изменить UI или весь user case, т.к. логическая цепочка слишком сложная либо не очевидная. Да это проблема проектирования и документации, но именно тестирование документации тоже является частью работы QA. А потом ещё пойди докажи PM, SA и Dev, что после релиза саппорт будет завален звонками.
Ещё хотелось-бы добавить, что тестировать СВОЙ код (white box) — очень плохая практика. Не зря всегда выделяют „black box“ тестинг…
Я свои приложения всегда даю попользовать знакомым\семье. И всегда появляются упущенные сценарии либо не понимание workflow. Банально некоторые вещи слишком заумные. Для меня было шоком, когда 3 человека не смогли найти страничку favorites, которая открывалась по тапу стандартной иконки „звёздочка“.
Часто конфликты, вне зависимости от профессии, при работе над смежными задачами с обязанностями одного уровня, возникает из-за различия уровня компетенции (или субъективной оценки уровня компетенции себя\коллеги).
Например, Вы же описали, что вам не нравится, когда приходит [некомпетентное] описание задачи «протестируй сайт», точно так же разработчику не нравится [некомпетентное] описание бага «пустая страница при переходе в корзину» вместо «реквест таймаут со статусом 504 при переходе в корзину, когда там находится товар с количеством миллион единиц». В итоге, разработчику нужно тратить свое время на тестирование (работу тестировщика), что бы разобраться, в чем же причина, ведь в тех случаях, что он предварительно проверил — все работает. Кстати, на практике достаточно часто получается, что ошибка совсем в другом месте, или даже совсем не зависит от разработчика и разработчик ее не может исправить.
Ситуация наоборот, это, например, когда разработчик не обрабатывает простейшие случаи: при переходе в корзину шаблон выбрасывает исключение, потому что товаров нет (а у самого разработчика для тестов корзина заполнена), добавили скидку по формуле цена = цена — цена / скидка, но если у пользователя нет скидки — то происходит деление на 0 и т.д.
Например, Вы же описали, что вам не нравится, когда приходит [некомпетентное] описание задачи «протестируй сайт», точно так же разработчику не нравится [некомпетентное] описание бага «пустая страница при переходе в корзину» вместо «реквест таймаут со статусом 504 при переходе в корзину, когда там находится товар с количеством миллион единиц». В итоге, разработчику нужно тратить свое время на тестирование (работу тестировщика), что бы разобраться, в чем же причина, ведь в тех случаях, что он предварительно проверил — все работает. Кстати, на практике достаточно часто получается, что ошибка совсем в другом месте, или даже совсем не зависит от разработчика и разработчик ее не может исправить.
Ситуация наоборот, это, например, когда разработчик не обрабатывает простейшие случаи: при переходе в корзину шаблон выбрасывает исключение, потому что товаров нет (а у самого разработчика для тестов корзина заполнена), добавили скидку по формуле цена = цена — цена / скидка, но если у пользователя нет скидки — то происходит деление на 0 и т.д.
Багтреккер это одновременно прикрытие и для девелоперов и для тестировщиков. Даже если компания только начинает путь становления, то можно использовать любой таск менеджер или на крайний случай shared online documents. Найти общий язык девелоперам и тестировщикам довольно просто, только если один из них не возомнил себя пупом мира («баг в моём божественном коде существовать просто не может» или «эта кнопка находится на 1px ниже чем я предполагаю, поэтому мы ничего не деплоим в продакшин»). Но третий человек должен быть для принятия бизнесс решений (хотя-бы сделать выборку тех багов которые должны быть пофикшены перед релизом), и желательно образование\опыт этого человека должно быть хоть немного лежать в плоскости ИТ или разрабатываемого продукта. Меня сейчас кинули на проект, который уже давно жёстко отстаёт от сроков. Девелоперы просто игнорят все имейлы и тикеты от QA. А ПМ на проекте только для навешивания лапши кастомеру и проведения Daily stand up. Смотреть список открытых багов это из разряда космических технологий, да и если продемонстрировать как это сделать — пользы никакой.
Sign up to leave a comment.
Тестировщик vs разработчик