Comments 37
Цитируя историю про «русский код, бессмысленный и беспощадный»: но все проблемы так не решить.
Основные проблемные места такого решения достаточно тривиальны:
— подобную систему сложно организовать, если помимо тестирования работы одной команды, нужно выполнять ещё и интеграционные тесты, ковыряться с автотестовыми/бенчмаркинговыми фреймворками. Люди, ответственные за это, априори должны быть выведены из разработчиков.
— введение тестировщиков в команды разработчиков очень осложняет внедрение подхода «тестировщик аналогичен заказчику». Невнедрение такого подхода чревато различными прелестями — от того, что получившееся решение работает только на одной конфигурации, заканчивая неработающими скриптами для автосборок/деплоймента и заведомым укрывательством.
— в процессах с длинными итерациями (не везде применимы «двухнедельные спринты» и непрерывное тестирование людями) такой подход приведет к простаиванию тестировщиков.
А вот разъяснение общих целей — это правильно. Главная из виденных проблем — поощрение тестировщиков за количество найденных дефектов, а разработчиков — за строго обратное.
Основные проблемные места такого решения достаточно тривиальны:
— подобную систему сложно организовать, если помимо тестирования работы одной команды, нужно выполнять ещё и интеграционные тесты, ковыряться с автотестовыми/бенчмаркинговыми фреймворками. Люди, ответственные за это, априори должны быть выведены из разработчиков.
— введение тестировщиков в команды разработчиков очень осложняет внедрение подхода «тестировщик аналогичен заказчику». Невнедрение такого подхода чревато различными прелестями — от того, что получившееся решение работает только на одной конфигурации, заканчивая неработающими скриптами для автосборок/деплоймента и заведомым укрывательством.
— в процессах с длинными итерациями (не везде применимы «двухнедельные спринты» и непрерывное тестирование людями) такой подход приведет к простаиванию тестировщиков.
А вот разъяснение общих целей — это правильно. Главная из виденных проблем — поощрение тестировщиков за количество найденных дефектов, а разработчиков — за строго обратное.
+5
У нас в компании эти вопросы в общем-то решены. Попробую по пунктам:
Ну и в конце интеграционное тестирование делают тупо все. Т.е. все команды тестируют таски всех команд. Заодно еще и межкомандное общение улучшается и народ лучше узнаёт продукт в целом.
- Этим занимаются те же тестировщики, но «во время простоя». Задачи по интеграционным тестам / автотестам / прочим тестерским заданиям просто вносятся в итерацию как задания, которые выполняет тестировщик, и оно осмечивается в рамках итерации. В «межспринтье» составляются планы и подгоняются хвосты.
- А откуда берутся проблемы внедрения подхода? Ну да, они друг другу не враги, но поскольку цель общая — выдать работающий билд и в срок, то тестеры заинтересованы завалить билд. Укрывательство непонятно кому выгодно. В билде заказчик нашел баги — страдает весь коллектив, а не тестеры. Прогеры — поскольку не указали такой тест-кейс (ну или не указали его отсутствие в тестплане), тестеры — поскольку баг был пропущен. Лодка то одна.
- У тестеров всегда есть что потетстить или поделать — не тестирование тасок, так автотест, не автотест так бенчмарки, не бенчмарки так составление тестпланов и т.д.
Ну и в конце интеграционное тестирование делают тупо все. Т.е. все команды тестируют таски всех команд. Заодно еще и межкомандное общение улучшается и народ лучше узнаёт продукт в целом.
+3
>>Этим занимаются те же тестировщики, но «во время простоя».
Возможно, проектная специфика. Далеко не всегда можно иметь «и швецов, и жнецов, и на дуде игрецов». Грубо говоря, придется составлять весь SQA-коллектив из весьма высокоуровневых и дорогих спецов и периодически тратить их время на тривиальную манулку по тесткейсам.
>>то тестеры заинтересованы завалить билд
ОЧЕНЬ сильно зависит от ряда факторов, основные из которых:
— разовая ли задача или планируется саппорт;
— что больше влияет на KPI/премирование — сдача в срок или дефекты, найденные у заказчика;
>> не тестирование тасок, так автотест…
Ситуация аналогичная п.1 — стратегия перестает работать в случае, если команда неоднородна по скиллам и требованиям задач к этим скиллам. Если же задачи ещё и технологически неоднородны — вот тут-то прелесть и начинается.
Возможно, проектная специфика. Далеко не всегда можно иметь «и швецов, и жнецов, и на дуде игрецов». Грубо говоря, придется составлять весь SQA-коллектив из весьма высокоуровневых и дорогих спецов и периодически тратить их время на тривиальную манулку по тесткейсам.
>>то тестеры заинтересованы завалить билд
ОЧЕНЬ сильно зависит от ряда факторов, основные из которых:
— разовая ли задача или планируется саппорт;
— что больше влияет на KPI/премирование — сдача в срок или дефекты, найденные у заказчика;
>> не тестирование тасок, так автотест…
Ситуация аналогичная п.1 — стратегия перестает работать в случае, если команда неоднородна по скиллам и требованиям задач к этим скиллам. Если же задачи ещё и технологически неоднородны — вот тут-то прелесть и начинается.
0
Безусловно, для реализации описываемого подхода, когда тестировщики и программисты работают в одной команде, требуется удовлетворение определенных требований. Некоторые из этих требований у нас были выполнены изначально, а вот для выполнения остальных пришлось потрудиться.
В этой статье я специально не стал углубряться в необходимые внешние условия (думаю, это может стать отдельной большой статьей), а заострил внимание именно на сути подхода, что главное, это общая цель!
А если все-таки говорить про то, в каких усовиях это работает у нас, то, например, денежное премирование у нас индивидуальное и основано на росте компетенций, а не на результате, команды достаточно однородны, спецы все крутые (а если нет, то быстро вырастают в крутых), создаваемый продукт один, вся команда сконцентрированна только на нем, проблемы с простаиванием не наблюдается, работаем в потоке, без итераций и почти не знаем слово «дедлайн».
В этой статье я специально не стал углубряться в необходимые внешние условия (думаю, это может стать отдельной большой статьей), а заострил внимание именно на сути подхода, что главное, это общая цель!
А если все-таки говорить про то, в каких усовиях это работает у нас, то, например, денежное премирование у нас индивидуальное и основано на росте компетенций, а не на результате, команды достаточно однородны, спецы все крутые (а если нет, то быстро вырастают в крутых), создаваемый продукт один, вся команда сконцентрированна только на нем, проблемы с простаиванием не наблюдается, работаем в потоке, без итераций и почти не знаем слово «дедлайн».
0
Вообще хорошо данный кофликт описан в книге Уолтера Айзексона о Стиве Джобсе. Apple удалось добиться многого благодаря тому, что все структуры компании работали во благо одной общей цели, не преследуя личные интересы отделов, так характерные для корпораций.
0
Мне показалось, что автор знаком с Теорией Ограничений (TOC), если нет — советую ознакомиться.
0
Нет, с теорией ограничений автор не был знаком. Спасибо, ознакомился.
Теперь можно на языке этой теории сказать, что в данном случае основной ограничивающий фактор был конфликт интересов. Его причина — различие целей. Убрав это ограничение случился прорыв.
Думаю, когда эйфория от этого прорыва пройдет, стоит заняться поиском следующего ограничения.
Спасибо ещё раз, мне приятнее думать на языке каких-то умных теорий, нежели на своем «велосипедном».
Теперь можно на языке этой теории сказать, что в данном случае основной ограничивающий фактор был конфликт интересов. Его причина — различие целей. Убрав это ограничение случился прорыв.
Думаю, когда эйфория от этого прорыва пройдет, стоит заняться поиском следующего ограничения.
Спасибо ещё раз, мне приятнее думать на языке каких-то умных теорий, нежели на своем «велосипедном».
0
Разработка в бранчах. Разработчик не вливает новых задач в основную ветку до тех пор, пока все уже влитые задачи не будут протестированы. Это позволяет избежать «снежного кома», т.е. эффекта накопления большого количества наполовину сделанных задач в основной ветке. И так же не дает бездельничать программистам – они всегда могут делать следующую задачу в бранче.
Вы читали Continuous Delivery?
0
Нет, но кажется догадываюсь о чем это.
Читал о чем-то подобном в документах от Microsoft, про их философию разработки в TFS.
Буду признателен ссылке на книгу.
Читал о чем-то подобном в документах от Microsoft, про их философию разработки в TFS.
Буду признателен ссылке на книгу.
0
www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
И это, прямо скажем, строго обратно тому, что предлагает Microsoft.
И это, прямо скажем, строго обратно тому, что предлагает Microsoft.
0
В принципе решение очевидно, особенно для человека который успел побывать и в шкуре тестера и программиста, но спасибо что подробно описали процесс перехода, цели и мотивы. Я работал тестировщиком по первому варианту и программистом почти по вашему окончательному.
Некоторые люди считают что если отдел тестирования никак не связан с отделом разработки это обеспечит более качественное тестирование, так-как программисты не смогут влиять на тестеров. Но ведь все равно смогут, через комментарии в багтрекере например. Только это займет больше времени и будет более конфликтным.
А подход, когда команда состоит из программистов и тестировщиков намного снижает конфликт и повышает качество. Программист может подсказать тестировщику кейсы которые являются критичными, которым нужно уделить особое внимание. Он разрабатывал систему, он лучше знает где что может сломаться. И это не отменяет независимого взгляда тестировщика на продукт. При этом программисты и тестировщики учатся понимать друг друга, вырабатывают модель максимальной эффективности (например, чтобы баги поступали как можно раньше, но при этом не отрывали программиста от работы). Эту модель нельзя выработать «на бумажке» и закрепить за всеми для всех обстоятельств. Люди разные и обстоятельства тоже. Все не продумаешь и не опишешь. В такой модели значительно реже возникают конфликты что важно для багфиксинга, а что нет (обучение друг у друга). Ну и экономия на переписке в багтрекере (устное обсуждение быстрее и дает больше информации).
Это все, конечно, работает только в том случае, если команда заинтересована в результате и если ей дают работать. Если существует постоянный прессинг по дедлайнам, например, (ну есть и такой подход к управлению), то конечно они будут халтурить, деваться то некуда, а возможностей схалтурить чуть побольше, но в таком случае мало что спасет.
И еще один бонус, если такая команда закреплена за 1-2 сложными длительными проектами, и отсутствует нормальная документация, тестировщики знают функционал значительно лучше программистов (по специфике работы, неоднократное повторение действий с этим функционалом), и временами лучше менеджеров, и могут выступать «ходячей документацией по проекту», особенно в старых частях проекта.
Некоторые люди считают что если отдел тестирования никак не связан с отделом разработки это обеспечит более качественное тестирование, так-как программисты не смогут влиять на тестеров. Но ведь все равно смогут, через комментарии в багтрекере например. Только это займет больше времени и будет более конфликтным.
А подход, когда команда состоит из программистов и тестировщиков намного снижает конфликт и повышает качество. Программист может подсказать тестировщику кейсы которые являются критичными, которым нужно уделить особое внимание. Он разрабатывал систему, он лучше знает где что может сломаться. И это не отменяет независимого взгляда тестировщика на продукт. При этом программисты и тестировщики учатся понимать друг друга, вырабатывают модель максимальной эффективности (например, чтобы баги поступали как можно раньше, но при этом не отрывали программиста от работы). Эту модель нельзя выработать «на бумажке» и закрепить за всеми для всех обстоятельств. Люди разные и обстоятельства тоже. Все не продумаешь и не опишешь. В такой модели значительно реже возникают конфликты что важно для багфиксинга, а что нет (обучение друг у друга). Ну и экономия на переписке в багтрекере (устное обсуждение быстрее и дает больше информации).
Это все, конечно, работает только в том случае, если команда заинтересована в результате и если ей дают работать. Если существует постоянный прессинг по дедлайнам, например, (ну есть и такой подход к управлению), то конечно они будут халтурить, деваться то некуда, а возможностей схалтурить чуть побольше, но в таком случае мало что спасет.
И еще один бонус, если такая команда закреплена за 1-2 сложными длительными проектами, и отсутствует нормальная документация, тестировщики знают функционал значительно лучше программистов (по специфике работы, неоднократное повторение действий с этим функционалом), и временами лучше менеджеров, и могут выступать «ходячей документацией по проекту», особенно в старых частях проекта.
0
Да, с Вами абсолютно согласен.
Наша команда закреплена надолго, точнее, в принципе не предусмотрено её переформирование, да и работаем мы над одним очень большим продуктом.
Поэтому бонусов от совместной работы мы имеем ещё больше.
Наша команда закреплена надолго, точнее, в принципе не предусмотрено её переформирование, да и работаем мы над одним очень большим продуктом.
Поэтому бонусов от совместной работы мы имеем ещё больше.
0
«Некоторые люди считают что если отдел тестирования никак не связан с отделом разработки это обеспечит более качественное тестирование, так-как программисты не смогут влиять на тестеров.»
Вы мне открыли новый, удивительный мир! В смысле, мне казалось, что такой подход перестали считать эффективным еще в 60-х. (Примерно тогда же, когда и концепция 'zero defect' перестала быть популярной).
Вы мне открыли новый, удивительный мир! В смысле, мне казалось, что такой подход перестали считать эффективным еще в 60-х. (Примерно тогда же, когда и концепция 'zero defect' перестала быть популярной).
0
Не знаю кто и когда перестал считать это эффективным, но до сих пор существую отдельные, довольно большие подразделения тестирования в некоторых крупных компаниях (ну в одной точно). Эти подразделения работают практически независимо от разработки, над многими проектами одновременно. И на курсах для студентов они проповедуют данный подход, в духе «Продукт тестировщика баг репорты, задача противоположна задаче программиста, найти как можно больше багов», про взаимподействие программистов и тестировщиков за пределами багтрекера ни слова. Правда zero defect к счастью не проповедуют. Видел своими глазами :) и даже некоторое время работал тестировщиком.
Поэтому и написал, что согласен с автором статьи, задача у тестировщиков и разработчиков одна, выпустить качественный продукт, и акцентировать внимание тестер должен не на количестве багов, а на качестве в принципе. Багов можно много найти если начинать использовать продукт нелогично, но это не сильно повысит качество для 99% пользователей и время тестера будет потрачено не на то (и это еще кстати создает основной конфликт).
Тестер это продвинутый пользователь, хорошо знающий систему, проверяющий ее на качество и, в критических местах, на прочность, а не «искатель багов».
Поэтому и написал, что согласен с автором статьи, задача у тестировщиков и разработчиков одна, выпустить качественный продукт, и акцентировать внимание тестер должен не на количестве багов, а на качестве в принципе. Багов можно много найти если начинать использовать продукт нелогично, но это не сильно повысит качество для 99% пользователей и время тестера будет потрачено не на то (и это еще кстати создает основной конфликт).
Тестер это продвинутый пользователь, хорошо знающий систему, проверяющий ее на качество и, в критических местах, на прочность, а не «искатель багов».
0
Вопрос к автору. После реорганизации не возникает ли у вас простоев у тестировщиков, если теперь каждый тестировщик работает в конкретной команде только на одном проекте?
0
Нет. Тестировщики концентрируются на написании автотестов, а их зачастую можно писать не дожидаясь разработчиков. А если даже и не получается, то тестовое окружение готовить заранее и тест планы писать на будущие задачи никто не запрещает.
Получается что-то вроде параллельной разработки. Да, к тому же мы работаем в потоке: закончил один тест, всегда есть следующий. Вопрос только в синхронизации, что бы ни программисты, ни тестировщики не убегали сильно вперед.
Получается что-то вроде параллельной разработки. Да, к тому же мы работаем в потоке: закончил один тест, всегда есть следующий. Вопрос только в синхронизации, что бы ни программисты, ни тестировщики не убегали сильно вперед.
0
Если правильно подобран баланс программистов / тестеров на проекте, то либо и простаивать будут вместе, либо простоев не будет (по причинам перечисленным в комментарии автора).
0
Заявлена проблема: сложно оценить сроки, неизвестное количество итераций тестирования задачи.
Каким образом и менеджер узнает срок готовности фичи/релиза? У кого?
По поводу раннего информирования — вы не боитесь перейти на bug driven development, когда программист отдает тестировщику бажную сборку, чтоб тому было чем заняться на ранних этапах?
И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет.
Каким образом и менеджер узнает срок готовности фичи/релиза? У кого?
По поводу раннего информирования — вы не боитесь перейти на bug driven development, когда программист отдает тестировщику бажную сборку, чтоб тому было чем заняться на ранних этапах?
0
* Каким образомсейчас менеджер узнает срок готовности фичи/релиза?
0
Срок готовности сообщает команда. Это очень удобно для менеджера. Команда полностью ответственна за выпуск релиза — и разработка и тестирование и документирование и деплоймент — все делает одна команда.
Кстати, когда программисты и тестировщики стали работать вместе, они стали давать более реалистичные оценки.
Хотя, на самом деле, в последнее время мы почти отказались от оценок и сроков — поставляем фичи с той скоростью, с которой способны. И максимально часто. Нам повезло, заказчик нам доверяет.
Bug driven development не боимся. В одном из комментариев я уже ответил, что тестировщики теперь сконцентрированы все больше на написании автотестов, поэтому на ранних этапах им есть чем заняться.
Кстати, когда программисты и тестировщики стали работать вместе, они стали давать более реалистичные оценки.
Хотя, на самом деле, в последнее время мы почти отказались от оценок и сроков — поставляем фичи с той скоростью, с которой способны. И максимально часто. Нам повезло, заказчик нам доверяет.
Bug driven development не боимся. В одном из комментариев я уже ответил, что тестировщики теперь сконцентрированы все больше на написании автотестов, поэтому на ранних этапах им есть чем заняться.
0
Не совсем офф-топ, скорее топик навеял…
Есть великолепная книга «Тестирование dot com» Романа Савина (на русском, и вроде на английском тоже).
Мне она случайно попалась после того, как я проработал пару лет менеджером в фирме, где был великолепно поставлен процесс разработки (а до этого в фирме, где процесс разработки был сделан на коленке, хотя тоже был не плох).
Очень советую эту книжку, прежде всего тестировщикам и менеджерам, и разрабам тоже пригодится. Процесс тестирования и взаимодействия между командами в ней расписан просто великолепно.
Есть великолепная книга «Тестирование dot com» Романа Савина (на русском, и вроде на английском тоже).
Мне она случайно попалась после того, как я проработал пару лет менеджером в фирме, где был великолепно поставлен процесс разработки (а до этого в фирме, где процесс разработки был сделан на коленке, хотя тоже был не плох).
Очень советую эту книжку, прежде всего тестировщикам и менеджерам, и разрабам тоже пригодится. Процесс тестирования и взаимодействия между командами в ней расписан просто великолепно.
0
что-то меня зациклило на «великолепно» :-)
+1
Честно говоря, не понимаю восторгов вокруг книги Савина, которая упоминается практически в любом треде по тестированию. Читал её ровно два раза и все пытался понять, в чем же её смысл.
По содержанию оная книга в главах наполовину состоит из Коупленда (причем, например, из раздела про тест-дизайн выброшено самое интересное), наполовину из тривиальных вещей (например, прекрасная глава по поводу того, какими атрибутами должен обладать баг); при этом автор делает очень спорные утверждения — например, про водопадную модель в стартапах или про недопустимость зависимости тест-кейсов, плюс изложение своего взгляда (с которым тоже можно поспорить) на конфигурационное управление.
Лично я бы рекомендовал людям начинать именно с Коупленда, параллельно образовываясь технологически в том направлении, в котором планируется работать: объяснить человеку всю бюрократию тест-процесса можно за неделю, которую этот человек будет работать, а вот получение знаний о том, куда тестируемую систему полагается пинать — обычно более затяжной процесс.
По содержанию оная книга в главах наполовину состоит из Коупленда (причем, например, из раздела про тест-дизайн выброшено самое интересное), наполовину из тривиальных вещей (например, прекрасная глава по поводу того, какими атрибутами должен обладать баг); при этом автор делает очень спорные утверждения — например, про водопадную модель в стартапах или про недопустимость зависимости тест-кейсов, плюс изложение своего взгляда (с которым тоже можно поспорить) на конфигурационное управление.
Лично я бы рекомендовал людям начинать именно с Коупленда, параллельно образовываясь технологически в том направлении, в котором планируется работать: объяснить человеку всю бюрократию тест-процесса можно за неделю, которую этот человек будет работать, а вот получение знаний о том, куда тестируемую систему полагается пинать — обычно более затяжной процесс.
0
Честно говоря, не понимаю восторгов вокруг книги Савина, которая упоминается практически в любом треде по тестированию.
Наверное, что-то там таки есть :-) просто написано популярно, доходчиво, и в тему…
Лично я бы рекомендовал людям начинать именно с Коупленда
Пытался нагуглить — не нашел. Можно ссылку?
Наверное, что-то там таки есть :-) просто написано популярно, доходчиво, и в тему…
Лично я бы рекомендовал людям начинать именно с Коупленда
Пытался нагуглить — не нашел. Можно ссылку?
0
books.google.com.ua/books/about/A_Practitioner_s_Guide_to_Software_Test.html?id=dMX_C8z9PfMC&redir_esc=y
В принципе, после неё лучше всего сразу брать конспекты с istqb.org и разбираться с незнакомыми словами в них.
В принципе, после неё лучше всего сразу брать конспекты с istqb.org и разбираться с незнакомыми словами в них.
0
Я работаю программистом в крупной международной организации, где нет тестировщиков и аналитиков вообще. Тестирование, оно же UAT осуществляет пользователь системы. Вы можете представить себе, что это за тестирование. Проверка функционала занимает недели, а иногда и месяцы. Таким образом в одновременной разработке у одного человека находится несколько задач. Все это еще накладывается на отсутствие четких требований. Нередка ситуация, что через несколько месяцев разработки какого-то плевого функционала, всплывают новые требования. Подобные посты про организацию процесса, просто как соль на рану. Это был крик души, не обращайте внимания. ;)
+1
«Тестировщики узнают о задачах только в момент передачи их в тестирование, т.е. о начале разработки новой задачи они уведомлений не получают.» — тестеры должны привлекаться к этапу планирования, а так же к этапу разработки требований (вместе с разработчиками), так как тесты, которые будут выполняться для тестирования ПО пишутся на основе требований. В большистве своем тесты пишутся тестерами.
0
Дождались! Начали думать сами, а не перенимать опыт более старший товарисчей из-за океана! Дак держать!
0
Именно в этом разница между «тестировщиками» и QA. Тестирование — это часть QA, и, разумеется, если выкинуть прочие аспекты обеспечения качества, то получится, кхм, плохой продукт.
Роль QA на этапе составления требований — обеспечение качества требований (что нелогично, что недостаточно детально, что конфликтует с имеющимися требованиями). Да, для этого зачастую есть бизнес- и IT-аналитики, но даже они порой помнят не все нюансы по сравнению с тем, кто тестирует это приложение каждый день.
На этапе разработки — QA участвует в дизайн-ревью (как под архитектуре приложения, так и UI) и, опять еж, дает обратную связь как можно раньше. Параллельно начинается составление тест-кейсов и всплывают новые сценарии, уточняются требования, так что они не становятся неожиданностью на более позднем этапе.
Этап тестирования — тут у тестировщика стоит задача «найти баг», а у QA-специалиста — «обеспечить фикс бага». Прсоледить чтобы он не завис в недрах багтрекинговой системы, в прошел триаж и получил правильный приоритет. Чтобы разработчик получил вовремя ответы на свои уточнения и помощь в анализе проблемы.
Все это, кстати, тоже давно написано, чуть ли не у Цема Канера. Просто, наверное, не всегда усваивается с первого прочтения, а только когда поработаешь в системе, где приходится все процессы разработки выстраивать с нуля.
Роль QA на этапе составления требований — обеспечение качества требований (что нелогично, что недостаточно детально, что конфликтует с имеющимися требованиями). Да, для этого зачастую есть бизнес- и IT-аналитики, но даже они порой помнят не все нюансы по сравнению с тем, кто тестирует это приложение каждый день.
На этапе разработки — QA участвует в дизайн-ревью (как под архитектуре приложения, так и UI) и, опять еж, дает обратную связь как можно раньше. Параллельно начинается составление тест-кейсов и всплывают новые сценарии, уточняются требования, так что они не становятся неожиданностью на более позднем этапе.
Этап тестирования — тут у тестировщика стоит задача «найти баг», а у QA-специалиста — «обеспечить фикс бага». Прсоледить чтобы он не завис в недрах багтрекинговой системы, в прошел триаж и получил правильный приоритет. Чтобы разработчик получил вовремя ответы на свои уточнения и помощь в анализе проблемы.
Все это, кстати, тоже давно написано, чуть ли не у Цема Канера. Просто, наверное, не всегда усваивается с первого прочтения, а только когда поработаешь в системе, где приходится все процессы разработки выстраивать с нуля.
0
Да, Вы действительно живете в современном мире, а не в нашем «удивительном»!
А вот не все мои знакомые, которые называют себя QA, это понимают.
А вот не все мои знакомые, которые называют себя QA, это понимают.
0
Про требования согласен целиком и полностью. Это, правда, затягивает написание ТЗ и начало разработки, но слишком много может стоит ошибка (в широком смысле, вы описали) в требованиях уже в середине или в конце разработки. Жаль что не всегда и не все это понимают.
Ревью архитектуры — ну пока мне не доводилось работать с тестерами (именно тестерами, а не выполняющими такую функцию другими программистами) которые достаточно квалифицированы для этого. Возможно они и существуют, но все кого я знаю, переходили в программирование и назад в тестеры не возвращались. Ревью дизайна (UI) — не берусь судить.
«тут у тестировщика стоит задача «найти баг»» — чуть выше писал по этому поводу. Если у тестера задача найти баг, то велик соблазн начать заниматься не тем, создавать ситуации которые повторят 0,01% пользователей (при этом не критические для системы), вместо того чтобы проверять как система ведет себя для остальных 99.9% (образно). И получаем конфликт между тестировщиком и программистом, потраченное на этот конфликт время программиста, тестировщика и зачастую менеджера (ну или в вашем случае QA специалиста), и прочие вещи. Мой любимый пример: админка (заточенная под продукт, про cms и подобное не говорим), и прочие вещи которые предназначены для обученного пользователя, который понимает что и зачем делает. Тестер нацеленный на «найти баг» начинает вбивать, ну допустим, в поле email строку не соотвествующую формату email, получает возможность сделать это и пишет багрепорт. Или пытается как то взломать систему. При этому забывает что администратор не будет вводить некорректные данные и ему не нужно ломать систему в админке, если он и так имеет к ней достаточный доступ. Дальнейшее развитие ситуации думаю понятно, много нервов, много переписки, кто-то точно остается недоволен, время потрачено, качество системы не повысилось. Зато одним «багом» меньше (ну или больше) :)
Ревью архитектуры — ну пока мне не доводилось работать с тестерами (именно тестерами, а не выполняющими такую функцию другими программистами) которые достаточно квалифицированы для этого. Возможно они и существуют, но все кого я знаю, переходили в программирование и назад в тестеры не возвращались. Ревью дизайна (UI) — не берусь судить.
«тут у тестировщика стоит задача «найти баг»» — чуть выше писал по этому поводу. Если у тестера задача найти баг, то велик соблазн начать заниматься не тем, создавать ситуации которые повторят 0,01% пользователей (при этом не критические для системы), вместо того чтобы проверять как система ведет себя для остальных 99.9% (образно). И получаем конфликт между тестировщиком и программистом, потраченное на этот конфликт время программиста, тестировщика и зачастую менеджера (ну или в вашем случае QA специалиста), и прочие вещи. Мой любимый пример: админка (заточенная под продукт, про cms и подобное не говорим), и прочие вещи которые предназначены для обученного пользователя, который понимает что и зачем делает. Тестер нацеленный на «найти баг» начинает вбивать, ну допустим, в поле email строку не соотвествующую формату email, получает возможность сделать это и пишет багрепорт. Или пытается как то взломать систему. При этому забывает что администратор не будет вводить некорректные данные и ему не нужно ломать систему в админке, если он и так имеет к ней достаточный доступ. Дальнейшее развитие ситуации думаю понятно, много нервов, много переписки, кто-то точно остается недоволен, время потрачено, качество системы не повысилось. Зато одним «багом» меньше (ну или больше) :)
0
По поводу ревью архитектуры: если тестировщик недостаточно подкован, чтобы увидеть потенциальные баги на этом этапе, то как минимум участие в этих сессиях помогает ему лучше понять архитектуру будущего приложения и какие тест кейсы можно придумать для тестирования бэк-енда (у нас часто начинает тестироваться бэк-енд пока над фронт-ендом еще работают).
По поводу последнего полностью согласна. Именно поэтому у нас тест кейсы проходят через ревью/одобрение бизнес-аналитиков, чтобы проверить, что там адекватные вещи тестируются, а не сотня тест кейсов на вбивание различных 'special characters in the login field', а какой-нибудь реальный сценарий — упущен.
По поводу последнего полностью согласна. Именно поэтому у нас тест кейсы проходят через ревью/одобрение бизнес-аналитиков, чтобы проверить, что там адекватные вещи тестируются, а не сотня тест кейсов на вбивание различных 'special characters in the login field', а какой-нибудь реальный сценарий — упущен.
0
Есть и другие способы разрешения этого фундаментального (вообще-то не конфликта), а противоречия. Решение о релизе принимает менеджер, на основании заключения тестировщиков (а может, и последующего заключения аналитиков на его основе), и сам решает что передавать, а что не передавать в разработку.
Тогда: тестировщики измеряют качество ПО, разработчики — устраняют действительно необходимые для исправления дефекты, а менеджер — согласовывает уровень качества с заказчиком (представителем заказчика), в том числе путем расстановки приоритетов.
Для тех, у кого процесс «на выходе тестирования — дефекты — вход для разработчиков» — мое предложение попробовать сначала описанную схему.
А вообще, процесс тестирования и устранения дефектов итеративный (особенно если вспомнить RUP), и с этим можно жить. Главное, чтобы он сходился к нулю (а это задача менеджера и архитектора).
Тогда: тестировщики измеряют качество ПО, разработчики — устраняют действительно необходимые для исправления дефекты, а менеджер — согласовывает уровень качества с заказчиком (представителем заказчика), в том числе путем расстановки приоритетов.
Для тех, у кого процесс «на выходе тестирования — дефекты — вход для разработчиков» — мое предложение попробовать сначала описанную схему.
А вообще, процесс тестирования и устранения дефектов итеративный (особенно если вспомнить RUP), и с этим можно жить. Главное, чтобы он сходился к нулю (а это задача менеджера и архитектора).
0
Так-то это первый принцип "Quality assurance":
Тестирование является частью процесса разработки с самого начала проекта и нацелено на предотвращение.
Поздравляю, что пришли к правильным выводам и смогли их воплотить.
Тестирование является частью процесса разработки с самого начала проекта и нацелено на предотвращение.
Поздравляю, что пришли к правильным выводам и смогли их воплотить.
0
Sign up to leave a comment.
Война миров: программисты vs. тестировщики!