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