Комментарии 41
Одна из причин (на мой взгляд) в том, что многие работают (как в одной из тем тут сказали)
Точнее как — есть высокоуровневые хотелки, но никто, ни заказчик, ни исполнитель, ни интегратор не знает как именно мы будем реализовывать хотелки. То есть функционал описывается и документируется прямо по ходу разработки. Если ещё больше упрощать — мы делаем демо, показываем заказчику, а он говорит что дальше — то ли оставляем, то ли выбрасываем и делаем всё с нуля.
или
Но мы работаем Т&М, потому что иногда все хотелки сразу и максимально не собрать. Сделали какую-то функцию, смотрим на нее, ага. Вот тут лучше было бы так сделать, а вот это вообще убрать.
Т.е. люди берутся за работу, не понимая что они хотят и не представляя как должен выглядеть конечный результат.
Естественно, что в таких условиях нормального результата не получить в принципе.
Намного более стабильный результат получается когда присутствует "бюрократия" (по мнению некоторых) - сначала бизнес-требования от заказчика (BRD). По ним рисуется ОТАР (организационно-техническое архитектурное решение), которое согласуется архитекторами и ответственными за системы, которые это решение затрагивает. Согласованное решение уже не меняется. Только откатом на начало процесса целиком.
Дальше пишется ТЗ ( FSD). По нему разработка.
Потом тесты - компонентные (на соответствие FSD) - тут юниттесты, автотесты, ручное тестирование отдельных кейсов, бизнес (на соответствие BRD), интеграционные, нагрузочные, техтест (тестовое развертывание на копии промсреды). И только после всего этого внедрение.
Понятно, что тут не получится быстро-весело "херак-херак и в продакшн". Но зато стабильность результата намного выше в итоге.
Понятно, что тут не получится быстро-весело "херак-херак и в продакшн". Но зато стабильность результата намного выше в итоге.
только это бизнесу не особо нужно, бизнесу нужен timetomarket
вообще подавляющую часть времени работал с аджайлом, а тут попал в оутсорс проект где BRD-FSD… и с точки зрения продукта и дедлайнов это вообще жесть
согласования BRD может занимать месяцы, потом в процессе реализации изменения в требованиях это очередной виток совещаний на 20 человек, матюгов и прочее, потом после релиза оказывается что чтото не сделали (не учли в требованиях, оказалось что то как реализовано — не юзабельно)… и начинается многомесячный поиск виноватых, кто где нетак запятую в требованиях поставил и кто будет платить за доработки, а кто будет работать бесплатно… создание новых требований на исправление… опять совещания… а на проде всё это время полурабочий сервис
жесть та еще....(ненавижу оутсорс по этой причине)...
только это бизнесу не особо нужно, бизнесу нужен timetomarket
Бизнес бывает разный. Бывают ситуации, когда за каждый баг в первую очередь платит бизнес. Деньгами, репутацией. И если деньги потом можно регрессировать на исполнителя, то репутацию никак.
Т.е. тут опять все упирается в то, насколько бизнесу нужен ваш продукт. Если это mission или хотя бы business critical, это одно, а если "у всех есть и мне надо чтобы было" - это совсем другое.
В первом случае бизнес готов поступиться TTM лишь бы потом дерьмо полной ложкой хлебать не пришлось. Когда быстрый TTM несет в себе повышенные риски внеплановой проверки регулятора и потенциальные штрафы со многими нулями или вообще лишение лицензии - фиг с ним с быстрым TTM, сделайте надежно и без багов.
согласен
хотя репутация в РФ штука такая себе, это отлично видно на примере всяких очень крупных и известных систем
Да и не в РФ собственно тоже, продукты всяких ораклов и IBM полноценно поддерживаются только если вы тратите ярды баксов, а если нет то утретесь со своими багами
я видел как глючит банковский софт с остановкой онлайна на часы, с глюками в цифрах, с потерями данных… и… и вендору плевать на это, потому что "куда вы денетесь с подводной лодки"/вы слишком мало нам платите чтобы мы для вас чтото фиксили вне стандартных релизов (исправление заявленного бага в плане через два года)
так что это всё, с моей точки зрения, утопичные схемы, в реальности всё гораздо печальнее и TTM зачастую, даже если это "хочу как у соседей" гораздо важнее — потому что TTM — это показатель для инвесторов и акционеров, а количество багов в трекере это просто кличество багов в трекере… их инвесторы/акционеры не видят
Когда быстрый TTM несет в себе повышенные риски внеплановой проверки регулятора и потенциальные штрафы
а это вообще нечто, у меня прям глаз дергается, помоему все, буквально все поставщики софта который делает то что проверяет регулятор — выпускают фичи за 1-2 дня до дедлайна по срокам сдачи отчетов… и при этом это яростно глючит… и я это не только про 1С… недавно бился с одним банком который решил заапдейтить свой интерфейс в конце квартала и выкатил недоделанную версию отправки отчетов (ну не то что недоделанную, а с урезанным функционалом) при этом не забыв отключить старую… я почти несколько висел на созвоне с техподдержкой чтобы сначала донести до них что мы не можем ничего сделать… а штраф нам вкатят уже послезавтра
а репутация? а что репутация. большинство бизнесов не может просто взять и поменять банк, потому что там кредитная линия железобетонно их держит… или какойнить отчет в профильное ведомство… репутация
я видел как глючит банковский софт с остановкой онлайна на часы, с глюками в цифрах, с потерями данных… и… и вендору плевать на это, потому что "куда вы денетесь с подводной лодки"/вы слишком мало нам платите чтобы мы для вас чтото фиксили вне стандартных релизов (исправление заявленного бага в плане через два года)
Ну я вообще-то в банке. И как раз на уровне серверов центральных.
Поверьте - такие вещи автоматически (у нас) тянут за собой комиссию по инцидентам и выводы соответсвующие.
И по дефекту промсреды такого уровня разработчика могут ночью из постели выдернуть.
И проектные поставки - это одно. Дефекты промсреды - это совсем иная сущность, она идет вне плана и исправляется максимально быстро.
А время недоступности отдельных систем исчисляется минутами. Дальше уже регулятор (ЦБ) обращает внимание и начинаются штрафы.
И да, у нас были инциденты с недоступностью оплаты картами в период пиковых нагрузок. И сопровождение в мыле переключалось на резерв, останавливало модули которые были причиной проблемы, откатывало поставки... И разборки потом были очень серьезные кто что как и почему так получилось.
Но это на уровне центральных серверов - там 90% того что крутится - mission critical.
А вот где "молодые-креативные" (мобильное приложение, сайт) - там все может быть совсем иначе. Там запросто могут глюки на прод выкатить чтобы "быть первыми".
Но разница в том, что у нас это случилось один раз (после чего были сделаны выводы и предприняты меры), а те же госуслугии вставали колом на протяжении нескольких лет подряд когда зимой начиналась запись детей в школы...
И по дефекту промсреды такого уровня разработчика могут ночью из постели выдернуть.
конечно, я до сих пор помню ночные созвоны по 2-3 часа с лежащим онлайном и ремонтом на ходу
И да, у нас были инциденты с недоступностью оплаты картами в период пиковых нагрузок. И сопровождение в мыле переключалось на резерв, останавливало модули которые были причиной проблемы, откатывало поставки… И разборки потом были очень серьезные кто что как и почему так получилось.
ну я тоже такое помню, даже помню как ехал на работу и встрял на заправке когда не смог заправится из-за лежащего процессинга… который я ехал чинить
комиссия конечно проводится и выводы… помню тогда вводили строгий регламент техработ, многоуровневые тесты и прочее прочее… тем не менее стабильно всё падало раз в два-четыре месяца, зачастую из-за обновлений софта вендора
И вендору было, явно плевать на такое.
помню их фразу с тех времен "ну в Сбере у нас всё работает, значит и у вас должно, разбирайтесь сами" (с)
история правда уже давнишняя, может чтото и поменялось в лучшую сторону, но тотже сбер также привычно падал в даты апдейтов уже в конце 10х, когда я работал совсем в другом месте… но при падении сбера обрывали техподдержку совсем не связанных с ним сервисов, просто потому "а у вас карты не проходят" — а не проходят карты сбера, потому что он лежит… и звонить им надо, но звонили нам..
p.s. я в Сбере не работал, но из-за его размера и из-за того что некоторый софт был аналогичен ихнему, подобные инциденты касались и нас, хотябы просто мимолетом
Не обязательно для того, чтобы получить нормальный результат, нужно уходить в бюрократию. Мы, как уже сказали, проводим предпроектную аналитику, которая помогает собрать все требования к продукту. Понятно, что по ходу разработки заказчику может что-то прийти в голову, это нормально. Аналитики опять же проверяют идею на адекватность, поэтому не бывает такого, что "люди берутся за работу, не понимая что они хотят и не представляя как должен выглядеть конечный результат"
Жил я в большом проекте, который работал по описанной вами бюрократии:
- Выделен ключевой пользователь-заказчик в области
- Поговорили
- Превратили интервью в требования, составили документ архитектурный
- Утвердили
- Разработали ТЗ для разработчиков
- Утвердили
- Разработали
- Ответственный уволился, пошел на повышение или еще что-то произошло за полгода с 2 до 7. У нового отсетственного новые мысли, начинай с начала.
Это же Спольски писал лет 20 назад. Что можно отловить все баги, оптимизировать продукт, чтобы все летало - но за это время конкуренты с теми же усилиями обрастут кучей новых фич и убегут далеко вперед. А ты будешь сидеть с идеальным продуктом, который устарел и без пользователей. Утрирую, конечно, но всегда в реальном продукте, где ресурсы не бесконечны, это компромисс, куда их потратить.
Плюс на этапе проверки ТЗ и бэклога можно заранее увидеть и решить проблемные места.
Проверки чего?) У нас ведь agile: херак херак mvp, загружаем в докер и в прод, вместо поддержки подкручиваем багтрекер - и тестировщики не нужны. А если что - то и упадёт, то у нас же кластер - тупо подменим новым инстансом.
Статья началась с многообещающего "почему много багов", а 85% просто некое описание, как мы тестируем :)
А конце рекомендация "дайте больше денег".
Начнем с конца. Месседж "мы облажались, но если вы нам дадите больше денег - мы исправимся" в реальной жизни редко работает. Обычно облажавшиеся получают пендаль, а не деньги. Причина проста. Надо очень внятно объяснить, как и почему облажались, и как вы исправитесь :).
Смотрим что в статье :)
Причина первая. 80/20 - сорян, но у багов есть критичность. Они не одинаковы. Если команда этого не знает и пишет про 80 на 20 - это "черный" шарик. Есть простой способ, начинайте с более важных/критичных вещей и большемне пишите про 80/20. Тем более выходит, что вы тратите 80% бюджета тестирования на лютую фигню. По хорошему, уже в этом месте можно заносить ногу для пендаля
Причина номер два. А если комбинаций триллион? Несерьезно. Действительно техник много и ими стоит пользоваться. В том числе чтобы не тестить 100 раз по сути одну и ту же фичу. Тут нога уже начинает движение :)
Дальше причин вроде нет, но нудноватый рассказ, что мы делаем. Условному человеку с деньгами это вообще не интересно и нога завершила движение :)
Я серьезнл. Лид команды тестирования, который мне бы это начал скармливать, имел бы очень бледный вид после встречи и возможно она была бы последней
Первое. Главный вопрос, на который отвечает тестировшик. Это база. Вы не ищете баги. Еще раз. Вы не ищете баги. Кто ищет баги - прлучает лекцию о том, щачем он вообще нужен в команде и если не испоавляется - идет на выход.
Вы проверяете реализацию на соответствие требования. Это ПРИНЦИПИАЛЬНЕЙШИЙ момент. Когда условный лид докладывает статус тестирования и начинает и заканчивает с числа и характеристики найденных багов, хочется взять что-то тяжелое и ввалить. Ваш прогресс оценивается теми требованиями, которые вы проверили.
Т.е. есть список требований. Их классификация и приоритеты. Также есть зависимости. Отчет о тестировании - это этот список, и возле каждого требования: все ок, есть баги, блокер и т.д. И так, и только так можно:
Понять прогресс
Понять где проблемы
Выставить приоритеты
Все. Если вы не начинаете с этого и не живете этим каждый день - вы бесполезное звено.
Из этого вытекает очевидное решение, как бороться с багами в релизе.
Видно прогресс и можно принимать меры заранее, если вижно что не успеваем
Можно хоть каждый день принимать решение о том, на чем стоит сосредоточистся, чтобы MVP продукта точно был ок, а всякая лабуда типа подсказок или интерфейса локального администратора пилилась в конце
Это реально жесть. На собеседовани куча тестировщиков на вопрос "в чем ваше added value" отвечают мы ищем баги. Люди работают, но не знают зачем. Понятно при такой постановке процесс тестирования "встал и вышел".
Грустно
тут на самом деле, ваше видение это сферическовакуумный проект, я пока еще ни разу не видел ни одного проекта чтобы там были четко описаны требования, прям настолько четко чтобы QA тупо проходился про ним и проверял _только_то_что_тамнаписано
и чем больше проект тем хуже с этими требованиями обстоят дела, потому что в какойто момент начинают пересекатся требования совершенно разных модулей и в реальной жизни может не хватит сил даже отдела аналитиков всё это скомпилировать в требования так чтобы это было так как вы предлагаете
по этому QA конечно проверяют заявленный функционал, и да, ищут баги в процессе этой проверки, потому что если после релиза фичи (которая соответствует требованиям) отсохла половина сервиса — это баг и его надо обнаружить, а не написать отписку что "в требования не написано что остальные сервисы после релиза должны работать, за это другой департамент отвечает" (у меня целый пласт история от таких дельцов, которые "как попросили так и сделали, а вы там хоть умрите" — руки повырывать хочется)
Я работал в проекте где был огромный монолит, сотня микросервисов, пять департаментов и около 500 программистов… которые все одновременно писали в общую кодовую базу которой было около 15 лет, там подавляющая часть кода написана людими которые не работают в компании уже много лет
Если описывать проект так как вы говорите, релизы фич будут выходить раз в год, а то и в два.
последние лет 5-10 многие проекты переходят на безрелизные схемы… и игра в "свали свои комсяки на аналитика/ПМ-а/архитектора который не там запятую поставил" уже не такая однозначная
Не нужно описывать требования. Нужно для начала иметь из список. Это есть всегда, сорян. Даже в виде сторек из Jira.
Дальше QA команда:
Пишет стратегию, как они это будут тестить. Виды тестирования, как именно тестить, тулы и т.д
Каждое требование покрывается тест кейсами, которые собираются в сценарии. Как именно - это вопрос QA команды
И идет работа
Главное, работа идет по списку требований. Они могут быть связаны, собраны в группы, релизы. Это уже детали. Но ... всем начиная с ПМа интересно статус работ по тестированию в разрезе требований. Если QA этого не может дать - он идет далеко и прямо.
А аот по этому списку уже можно работать. Например:
Срезать скоуп релиза, оставив только то, что ПРОТЕСТИРОВАНО
Обратить внимание на проблемнве требования
Увидеть влияние багов на другие требовантя по связке требований
Планировать работы, так как прогрес измерим и явно видет
Дополнительно. Про большой проект. Да по фиг. В роли ПМа я ожидаю получить от QA ответ по списку:
Это протестировано и готово
Это в работе, вот список багов
Это покрывается тестами
Это вообще ХЗ что, будем покрывать
Где взять этот список - это мой вопрос. Возьму аналитика за жабры и заставлю написать. Не важно. Список будет. Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Потому что любой проект/релиз - это конечная и описанная активность. Либо в виде требований, либо в виде бэклога. Не важно.
Еслм что-то не описано, как например "ковыряние овна мамонта", значит оно есть на столе именно в таком виде. Но тогда QA туда соваться еще рано
Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
ну тут согласен, такого быть явно не должно
Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Вы когда-нибудь работали именно на таких проектах? Как бы вы решили эту проблему (я так понимаю, что вы пм)?
Ну, я работал и чистым ПМом, но объективно это не моя основная специальность
Вообще, выше я написал. QA команда работает, покрывая тестами и собственно тестируя требования/фичи, в зависимости от релизной политики. На коротких релизах это фичи, на длинных - требования. Так они имеют цель и смвсл жизни в команде.
Периодически QA готовят отчет, где мы в части готовности к проду. Т.е. что и скоупа готово, а что нет. Что не готово, обязательно классифицируется по тяжести багов. Так все знают текущий статус, включая заказчика.
Оперативно, часто с помощью жопомера и иных потусторонних сил, оценивается, насколько много шансов успеть к дедлайну и пора ли "паниковать" (резать скоуп, добавлять ресурсы, менять приоритеты). Также, если идентифицированы проблемы (тикеты не закрываются, появляются новые, переоткрываются старые), надо собраться и устранить корень возникновения проблемы.
Иногда надо QA помочь, так как уровень их технических знаний обычно невелик и багальное "я сейчас расскажу, как можно автоматизировать это штуку" может сильно ускорить процесс
В целом ничего уникального. В проекте должна быть цель, путь и движение к цели по этому пути, которое измеримо. И ежедневное вджобывание :)
Про БОЛЬШОЙ проект ... хз, кому что большое. У меня самый большой это Интернет банкинг, где одновременно трудилось до 10 команд в разных точках решения. Но он принципиально не отличается. Подходы те же. Просто надо ж понимать, что если условно он еще больше, то на проекте желательно иметь больше одного ПМа. Т.е. ничего страшного нет в том, что на большом проекте и лбдей больше, в том числе "с погонами".
В статье основная проблема и возможно, корень ее в том, что тестирование идет от требований, а не от багов.
Из опыта кстати, именно командам QA приходится чаще всего вставлять пистоны и проводить лекции на тему, как стать лучше. Некоторые воспринимают и дело идет на лад, с некоторыми приходится расставаться, иногда после жесткой беседы, так как иные методы не сработали :(
У багов есть критичность, это понятно. Посыл был рассказать, почему 100% багов не убрать и что можно сделать, чтобы их было меньше. А не упарываться в детали, уводя читателя от сути. Ну и логично было дополнить тем, что делают QA, чтобы багов было меньше. "мы облажались, но если вы нам дадите больше денег - мы исправимся"
Не совсем понятно, где и кто облажался. Речь шла о том, что можно сделать, чтобы багов было меньше: выделить больше ресурсов и провести предпроектную аналитику. Но так как предпроектную аналитику мы проводим практически на всех проектах, то и нет такого, что "мы облажались, дайте нам больше деняк, исправимся"
Дело в том, что избранная мера в виде количества багов глубоко вторична по отношению к мере готовности приложения к проду в виде списка фич/требований.
Как следствие, ориентированность команды QA на поиск багов, а девов на их фикс в реальности приводит к расфокусировке от важных вещей
Команда должна быть сфокусирована на фичах и их готовности к проду. Тогда релизы будут иметь смысл, так как будут состоять из протестированных фич, которые наиболее важны.
Это как 10 стаканов. Я не успеваю наполнить все 10 объективно? ОК, я наполню 7 самых важных, а на 3 забью. Если я фокусируюсь на багах, я могу получить 3 полных, и 7 почти полных. И даже в первом случае может быть условно 5 критикалов и 25 медиум, а во втором 2 критикала, и 12 медиумов. Но первый релиз выглядит намного лучше второго
Поэтому QA НЕ ИЩЕТ БАГИ. Он проверяет ГОТОВНОСТЬ ФИЧ, начиная с самых важных. А если продолжает искать баги и не исправляется, значит идет за борт :)
Даже сейчас ты пишешь про задачу, которая не имеет смысла. В проде не выходит отсутствие багов. В прод выходят одобренные фичи. И именно количество фич - мерило успеха команды.
Отдельный вопрос, если фича задекларирована как готовая, а в пподе вылез баг. Это повод для ретроспективного анализа и работы над техниками, взаимодействием и т.д. Но если команда изначально ориентирована не туда - она уже неэффективна
Ну или еще. QA находит баги. Много, мало ... это хорошо или плохо? ХЗ. Ну реально. Может багов и правда мало, а может и много. Это не важно. Важно мерять работу QA по количеству фич, которые он либо одобрил к выходу в прод, либо протестил и выкатил список багов. Тогда легко понять продуктивность команды и все остальное. И легко проверить качество работы тестировщика. Если окажется, что в готовой фиче есть баги (которые нашел клиент) или в "протестированной" фиче нашлись новые баги без изменения кода - это повод устроить QA команде разбор полетов
На собеседовани куча тестировщиков на вопрос "в чем ваше added value" отвечают мы ищем баги.
А с другой стороны практически все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Вот и выходит ситуация, когда одни ищут баги, а вторые ждут пока джун нанятый по остаточному принципу на последней стадии разработки выправит качество продукта.
> все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Ну, не совсем. QA подтверждает, что разработанный продукт соответствует требованиям к нему в рамках своих компетенций. QA не может сделать продукт качественнее. Он только указывает на дефекты. Поэтому формально формулировка неверна. Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
А что до ситуации ... ну так если ПМ ни черта не делает, чуда тоже не произойдет. Да длинном проекте можно увидеть достаточно признаков заоанее, что есть проблемы и заняться их исправлением до того, как подкрадется песец.
Но основная мысль в том, что если QA ищет баги, это уже проблема :) QA, как и DEV - закрывает фичи, только по своему
Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
Это несложно. Они вкладывают в это простой смысл: «Хочу чтобы кто-то улучшил качество проекта, желательно без особых вложений».
Если очень сильно загрубить, то работа тестировщика - вовремя предоставить информацию для контроля поставленной задачи. И я за свои 15 лет в тестировании пришел к неутешительному выводу: основная проблема тестирования в том, что большинство ПМ неспособны внятно поставить задачу и вообще не занимаются контролем исполнения. Поэтому и QA нанимают руководствуясь магической формулой:
Нанимаем QA
…
Качество улучшилось
Я обычно работал в организациях, где либо есть стандартны качества, либо люди и так понимают зачем. Вариаент без QA - только когда есть маленькая команда и можно просто кросс чекать друг друга
Про поставить задачу. Взгляд с другой стороны :) Я ПМ, или частично вывполняю его функции. У меня есть QA, или даже команда. Я нанимаю кого-то с опытом 15 лет. Блин, какая постановка задачи ожидается?
Во-первых. На большом проекте может быть 5+ команд разработчиков, разномастный заказчик с 7 говорящими головами, 2+ спонсора, куча мерзких запрещалок, контракты с тремя поставщиками, 2 из которых из-за бугра. Куча доки, которую надо вести. 10 встреч каждый день, 100+ писем, и много-много другого. ПМ нанял в команду QA команду с лидом, чтобы тратить время на постановку задачи?
Реально на это физически нет времени. Для этого и берется лид, который не просит поставить задачу, а организует процесс тестирования. Да, именно так. Ожидается, что человек с опытом знает как построить свой процесс и ему нужен ПМ для решения орг. вопросов. Конечно, я лично еще не встречал QA, которые бы не просили помощи в технических вопросах, так где сложно, но это нормально. Точнее они есть, те кто могут сами, но стоят дорого, и сразу фиг дадут.
Поэтому, подытоживая. Да, спец с опытом знает, зачем он в проекте и ему надо только уточнить детали, как именно в будет тут. Бэби ситтингом никому заниматься не интересно, кроме удовлетворения преподавательского зуда.
По контроль - да, это пичалька. Если первый вопрос тестировщику на совеседовании "какой ваш added value", то вот ПМа стоит спросить в целом по каждой роли и "что вы выносите с утренних стенд-апов". Ответ на последний часто удручает :(
Но тогда есть надежда на то, что в команде будет сильный аналитик/архитектор/тимлид, которые тут подстрахуют
Вы от команды чего хотите получить? Чего должно быть сделано? К какому сроку? Критерии успешности есть?
Вы когда нанимаете человека, вы же говорите ему чего от него хотите?
В целом, основная задача ПМ - принимать управленческие решения. Остальное - это сопутствующие развлечения.
Человек берется в команду в идеале после собеседования, на котором проверяется наличие hard/soft скилов, а также обычно кандидата знакомят с проектом и задачами
Также очевидно, что если есть конкретные ожидания, например к решению есть требования по производительности, которые надо будет проверит, то они озвучиваются.
Но в рамках экспертизы QA ПМ не должет ставить детальные задачи. Как и другим ролям. Но может контролировать. К примеру, начинается большой проект. Есть до головы QA лида не дошла светлая мысль, которая заключаеться в необходимости начать работу над тестовой стратегией, то ПМ вполне может спросить, а почему лид все еще занимает положение "сижу на жопке" ровно? Ну и походу стоит попросить другого спеца посмотреть, чего лид туда написал и не написал. И найти экспертов которые помогут туда вписать все что нужно. Это нормально, еж птица гордая и инфантильная.
Но в целом, мне не очень понятно в чем суть. Человек с опытом ЗНАЕТ, что надо делать. Ему нужны детали/нюансы конкретного проекта, либо бебиситер в виде лида. Еслм лиду нужен бебиситер - то лиду точно пора на выход. Тут все просто.
Про то, что делает ПМ - да очень много чего, не только управленческие решения. Как минимум очевидно, что чтобы чего то принимать, надо убедится, что есть достаточно вводных.
А для этого, как раз нужна ориентация QA на фичи, а не на баги
Пример. Утренний ответ на стандартные вопрос от QA.
Закончил покрытие тестов к фиче 111, возьму покрытие фича 222 и протестирую фичу 333. Планирую сделать за день. Отлично
Написал 20 тест кейсов к фиче XYZ, нашел 5 багов в фиче ABC. Очень плохо :)
Задача ПМ в таком случае трансформировать инфу и фокус QA с нижнего варианта ответа на верхний :)
А чем в целом изначально я и талдычу :) Как и о практической бесполезности измерения работы, качественно и количественно багами
Сроки и бюджет — всегда щепетильная тема.
С одной стороны, бюджет проекта обычно нулевой, поэтому тестирование проходит только в самых необходимых местах. Здесь перед QA встаёт совсем иной вопрос: тестировщик должен скрыть недостатки, чтобы вред от недоделок стал незаметным.
С другой же стороны, за счёт MVP заказчик ничего не заработает. На ноль делить нельзя, поэтому MVP нельзя оценивать по отношению расхода к доходу, а только по общественной полезности.
Скрывать недостатки, чтобы их просто не было видно? ಠ_ಠ
При ограниченном бюджете внимание уделяется больше критичным местам, это да, но и о не критичных тоже нельзя забывать. Это как минимум не профессионально.
При ограниченном бюджете
При ограниченном бюджете нельзя забывать. А при нулевом бюджете дело обстоит иначе.
Нулевых бюджетов не бывает. Все равно некая команда пилит разработку и поддержку и получает зарплату. Просто то что не делает один выделенный специалист — совмещает другой. Иногда более высокооплачивемый. У меня перед глазами после нескольких косячных релизов обязательства по проверке перед сдачей брал на себя лично гендир подрядчика. (что он там в итоге после делал хз конечно)
Да, я согласен. Можно взять свою зарплату и с неё нанять QA-специалиста. Но тогда не останется денег на коммунальные платежи.
Принимаю ваше замечание и уточняю: нулевой бюджет — это в бюджете заложена не более 1 заработная платы, с которой оплачиваются все расходы. Есть варианты, когда в бюджет заложена ½ заработной платы или 0 заработной платы.
Моя мысль была в другом, при некоторой низкой численности команды можно обойтись без QA специалистов, но нельзя без QA процессов. Так что бюджет (на проект) всегда есть, иначе с чего бы кто-то требовал результатов. И он будет эффективнее использован, если "борьба за качество" будет идти планомерно с инструкцией понятной всем, а не стихийно "вы все спецы с 15 летним опытом работы, делайте как хотите, но чтобы было хорошо"
Есть еще проблема стандартов, подходов и методологий. Начиная с дизайна и заканчивая разработкой и интеграциями. Документацию мало кто пишет, макеты дизайна, без слез не взглянешь (это хорошо, если есть). И вот клиент решивший сэкономить приходит на поддержку и развитие и получается, что дешевле заново сделать!
Сам не в теме, но вредный совет 8 - это не тестирование белого ящика?
Норма — когда багов мало
Норма - это когда разработчик думает. За 11 лет в разработке десктопного ПО я большей частью видел именно безалаберность. И чем ближе по времени к текущему дню, тем её больше.
«Это не фича, это — баг». Почему IT продукты выходят на рынок сырыми?