На сайте не работает форма? Это не баг, а фича, так задумано.
Шутки шутками, но хотелось бы понять, почему сайты и приложения выходят с багами. Тестировщики совсем обленились? Сейчас все объясним.
Откуда столько багов?
Ситуация такая, что и без того сложные проекты сейчас становятся сложнее → а чем сложнее становятся проекты, тем больше в них функций → а чем больше функций, тем больше ресурсов нужно потратить на проверку. Это не всегда возможно. В тестировании срабатывает принцип Парето — «20% усилий дают 80% результата». И наоборот, 80% усилий дают всего 20% результата.
На практике это выглядит так — пока тестировщики тестируют основной пользовательский путь, они тратят 20% времени, убивая 80% багов. Но чтобы отловить оставшиеся 20% багов, они идут извилистыми путями, тратя 80% усилий. А это дополнительные деньги и время. А сроки и бюджет — всегда щепетильная тема.
Это первая причина.
О второй причине расскажет наш QA-специалист Анастасия.
«Сейчас я тестирую функцию создания лота на сервисе онлайн аукциона автомобилей. Слежу, чтобы все параметры подгружались корректно. Проблема в том, что у каждого автомобиля куча показателей — марка, модель, пробег, коробка передач и так далее. Физически ВСЕ эти комбинации проверить невозможно, на это уйдет времени больше, чем на саму разработку. Почему? Потому что марок автомобилей свыше 100, на каждую марку приходится 20-50 моделей. То есть, чтобы проверить все комбинации, нужно запустить минимум 20 тысяч проверок. Да, в таких ситуациях помогают техники тест-дизайна. Но и они не гарантируют 100-процентной исчерпывающей проверки»
Анастасия Заборская, тестировщик Pyrobyte
Другой пример. Чтобы протестировать форму заполнения платежных реквизитов, нужны:
3 платежных системы (Visa, MasterCard и Мир);
3 вида ОС (Windows, macOS, Android);
3 платформы (Десктоп, планшет, смартфон);
4 браузера (Google Chrome, Microsoft Edge, Opera, Safari).
По этим критериям получаем минимум 108 разных сценариев. А если форм больше, а платежных систем не 3, а 23, как было у нас при разработке обменника, то количество вариантов проверки стремится к бесконечности.
Именно поэтому как все скороговорки не перескороговорить, так и все баги не выловить ¯\_(ツ)_/¯
НО!
Это не значит, что баги — норма. Норма — когда багов мало, а если количество ошибок выше допустимого, это значит, что:
Над продуктом работала некомпетентная команда. Например, низкобюджетная студия или QA без опыта;
На тестирование выделили мало времени и денег. Или приоритет был на быстром запуске;
Продукт разрабатывался в сжатые сроки.
Тут тоже не все так однозначно, потому что ситуации бывают разными:
У клиента мало денег → он жертвует качеством, чтобы выпустить хотя бы что-то → зарабатывает на этом деньги → выпускает обновления без ошибок.
У клиента много денег, а времени мало. Ему нужно успеть выпустить свой продукт до того, как это сделают конкуренты. Актуально для игровой индустрии и вообще любой конкурентной области.
Когда приходится выбирать между первым и вторым — запустить продукт с ошибками и занять рынок ИЛИ полировать код и запустить продукт, когда потребность в нем исчезнет, лучше выбрать первое.
Теперь пройдемся по этапам разработки, в которых участвуют quality assurance специалисты или просто QA. Посмотрим, чем они там занимаются.
Когда начинаются тесты
Почти с самого начала. Чем раньше QA начнут работать, тем меньше времени уйдет на исправления.
Сориентироваться в этапах разработки поможет наша первая статья. В ней последовательно описаны все работы.
После планирования спринта тестировщик вместе с разработчиком пишут тест-кейсы и чек-листы для проверки работы основного функционала.
Тест-кейс — это алгоритм, по которому тестировщик будет проверять уже написанную программу. Форма тест-кейса четкая и строгая, с конкретной структурой.
После того, как документ готов, тестировщик берется за дело.
Что касается чек-листов, то мы подготовили для вас пример по тестированию дизайна сайта. Вы можете посмотреть его (и скачать), кликнув сюда.
Сперва тестирует прототип и дизайн
Если он перехватит баг до того, как он уйдет в разработку, его будет проще исправить.
Тестировщик оценивает удобство UI/UX. Следит, чтобы дизайн смотрелся хорошо на разных устройствах, а расположение блоков совпадало на всех экранах. Проверяет кнопки, поля ввода, меню, цвета, шрифты, размеры, пропорции и другие элементы. Оценивает, как они откликаются на действия пользователя. Проверяет навигацию экранов на удобство, интуитивность.
Дальше — ТЗ и бэклог
QA проверяет документы на логические ошибки, смотрит, насколько корректно описаны функции и будут ли они понятны разработчикам. Изменить пару строк проще, чем вмешиваться в код. Плюс на этапе проверки ТЗ и бэклога можно заранее увидеть и решить проблемные места.
После проверяет верстку
Проверяет, чтобы она соответствовала дизайну. Если это не проконтролировать, могут быть проблемы:
Со шрифтами. В разных браузерах они будут отображаться по-разному. Где-то тоньше, где-то жирнее;
С макетом. Могут съехать изображения или измениться толщина границ.
Проверяется это через плагин Pixel Perfect.
А уже в конце — работоспособность и читаемость кода
Чтобы выявить ошибки в работе программы и исправить их до запуска. Речь идет и о мелких, и о критических багах, которые могут все испортить.
Супер важный момент!
Тестировщик должен быть в курсе всех событий. Бывает, что после созвона с клиентом в проект вносятся изменения, которые до этого не были прописаны в ТЗ. Если тестировщик будет знать о них заранее, а не по факту проверки (как это обычно бывает), то у него будет меньше вопросов почему, например, изначально серые кнопки вдруг стали синими.
Что делают QA, чтобы багов было действительно меньше
Проверяют сайты, сервисы и приложения вручную.
Тестируют черный ящик
Это когда они не знают, как продукт устроен изнутри. У них нет доступа к коду, работа программы проверяется по чек-листу.
Технический опыт здесь не важен. Суть в том, чтобы перейти на сторону пользователя, подумать его мозгами и посмотреть его глазами. И в этом большой плюс — дефекты и несоответствия можно выявить на ранней стадии.
Тестируют белый ящик
Здесь они вникают во внутреннее устройство программы — перепроверяют код за разработчиком (несмотря на то, что программисты сами проверяют друг за другом код). Здесь им надо найти и улучшить нерабочие или не оптимизированные куски кода.
Плюс белого ящика в том, что к нему можно приступать почти сразу. Не надо ждать, пока создастся пользовательский интерфейс.
Тестируют серый ящик
Золотая середина. QA сначала проверяют код, а потом смотрят на продукт глазами пользователя.
Нюанс в том, что у тестировщика нет знаний разработчика. Он смотрит на простейшие вещи — тип данных у значения, настройки полей. В итоге он вроде понимает, как все устроено, но не до конца. Поэтому перепроверяет по черному ящику.
Серый ящик считается оптимальным вариантом — баги можно и в коде поискать, и со стороны пользователя отловить, и по ТЗ все проверить.
Когда проект согласован с заказчиком и ему больше не к чему придраться, тестировщик возвращается к проекту и устраивает дымовое тестирование — проверяет, чтобы при переносе на домен не сломался основной функционал — заказ товаров, корзина, фильтры, личный кабинет.
Способы и виды зависят от конкретного продукта.
Какие еще виды тестирования может проводить студия? И зачем?
Код ревью, например
Если есть проблемы, проверяющий отправляет дорабатывать код, если все ок — отправляет его тестировщику.
Зачем это нужно? Так как задача проверяется двумя разработчиками, баги уничтожается еще до того, как дойдут до QA. Коду тоже хорошо — у него повышается качество и читаемость, он становится понятен не одному, а сразу нескольким людям. Если разработчик уйдет с проекта, ничего страшного не случится — его задачи легко подхватят другие программисты, так как они уже знают код.
Бета-тестирование
Это когда продукт отдается на растерзание реальным пользователям, чтобы получить отзывы о его качестве. Число этих пользователей ограничено.
Но самый ответственный момент — приемочное тестирование
Перед тем, как сдать продукт клиенту, надо убедиться, что все работает.
Если на этом этапе найдутся недочеты, придется все переписывать. Иногда это мелкие фиксы, которые занимают пару часов. А иногда целые разделы. Страдает от этого и репутация студии, и время разработчиков, и карман заказчика.
Избежать таких проблем помогает предпроектная аналитика.
Она прорабатывает пользовательские пути и структуру, которая в будущем поможет избежать логических несостыковок в продукте;
Баг — это не обязательно то, что не работает. Баг может означать то, что что-то работает не так, как надо. Предпроектная аналитика учитывает ожидание аудитории от продукта, и делает так, чтобы все функции работали «как надо».
Подытожим
После того, как продукт запущен, на него приходят реальные пользователи. И в этот момент тестировщиками становятся пользователи.
Вспомните Cyberpunk 2077
Пользователей бесит не сюжет или персонажи, а баги. Куча багов! Совершая неявные действия, они находят ошибки, которые не были выявлены опытным путем.
Вот и получается, что степень проработанности продукта зависит от ресурсов. Чем больше времени и денег выделяется на тесты, тем больше багов будет поймано в процессе.
Но все равно получить 100% чистый продукт не получится ¯\_(ツ)_/¯
Некоторые баги могут всплывать не со стороны разработчиков, а со стороны сервисов, с которыми настраивается интеграция.
Еще раз
Убрать баги на 100% нельзя (если мы не говорим о лендинге), но можно уменьшить их количество ↓
a) Выделить больше времени и денег на тестирование;
b) Провести предпроектную аналитику.
Со своей стороны мы делаем все, чтобы багов было меньше. Проводим тестирование каждого спринта в несколько этапов: запускаем автотесты → проверяем программу на ошибки вручную → передаем тестирование разработчикам, потом снова тестировщикам → дальше цепочку завершает менеджер. Это выжимает из проверки максимум.
А теперь закрепим тестирование на вредных советах :)
Передавайте разработчику один и тот же баг. Пусть знает, что у вас совершаются серьезные открытия!
Удалите базу данных во время тестирования, чтобы проверить, насколько быстро продукт восстановится.
Запустите все тесты одновременно — быстрее протестируете, быстрее выпустите!
Не тестируйте в разных браузерах и на разных операционках, ведь пользователи все равно используют только одну определенную комбинацию.
Не выписывайте баги и не сообщайте их разработчикам — просто делайте вид, что ничего не произошло.
Задавайте коллегам загадочные вопросы и говорите, что это — часть процесса тестирования.
Вместо проверки безопасности системы станьте для нее источником угроз.
При тестировании залезьте в код разработчика, чтобы найти ответы на вопросы. В конце концов, именно для этого же он его писал?
Забудьте указать в чек-листе важные шаги — проведите эксперимент и посмотрите, насколько хорошо разработчики читают ваши мысли.
Передайте ответственность за поиск багов пользователю. Они найдут любую ошибку и сообщат вам о нем!
***
Если остались вопросы — задавайте их в комментариях.
Если хотите заказать разработку с минимальным количеством багов — пишите! Подготовим для вас красивое КП :)
Где можно посмотреть на нас:
Комментарии (39)
ganzmavag
17.08.2023 08:44+3Это же Спольски писал лет 20 назад. Что можно отловить все баги, оптимизировать продукт, чтобы все летало - но за это время конкуренты с теми же усилиями обрастут кучей новых фич и убегут далеко вперед. А ты будешь сидеть с идеальным продуктом, который устарел и без пользователей. Утрирую, конечно, но всегда в реальном продукте, где ресурсы не бесконечны, это компромисс, куда их потратить.
pyrobyte Автор
17.08.2023 08:44+2Да! Поэтому если стоят 2 крайности — запустить продукт с некритичными багами и занять рынок или вычищать баги до последнего и запустить продукт, когда потребности в нем уже не будет, лучше выбрать первое, конечно
Abobcum
17.08.2023 08:44+2Плюс на этапе проверки ТЗ и бэклога можно заранее увидеть и решить проблемные места.
Проверки чего?) У нас ведь agile: херак херак mvp, загружаем в докер и в прод, вместо поддержки подкручиваем багтрекер - и тестировщики не нужны. А если что - то и упадёт, то у нас же кластер - тупо подменим новым инстансом.
Batalmv
17.08.2023 08:44+6Статья началась с многообещающего "почему много багов", а 85% просто некое описание, как мы тестируем :)
А конце рекомендация "дайте больше денег".
Начнем с конца. Месседж "мы облажались, но если вы нам дадите больше денег - мы исправимся" в реальной жизни редко работает. Обычно облажавшиеся получают пендаль, а не деньги. Причина проста. Надо очень внятно объяснить, как и почему облажались, и как вы исправитесь :).
Смотрим что в статье :)
Причина первая. 80/20 - сорян, но у багов есть критичность. Они не одинаковы. Если команда этого не знает и пишет про 80 на 20 - это "черный" шарик. Есть простой способ, начинайте с более важных/критичных вещей и большемне пишите про 80/20. Тем более выходит, что вы тратите 80% бюджета тестирования на лютую фигню. По хорошему, уже в этом месте можно заносить ногу для пендаля
Причина номер два. А если комбинаций триллион? Несерьезно. Действительно техник много и ими стоит пользоваться. В том числе чтобы не тестить 100 раз по сути одну и ту же фичу. Тут нога уже начинает движение :)
Дальше причин вроде нет, но нудноватый рассказ, что мы делаем. Условному человеку с деньгами это вообще не интересно и нога завершила движение :)
Я серьезнл. Лид команды тестирования, который мне бы это начал скармливать, имел бы очень бледный вид после встречи и возможно она была бы последней
Первое. Главный вопрос, на который отвечает тестировшик. Это база. Вы не ищете баги. Еще раз. Вы не ищете баги. Кто ищет баги - прлучает лекцию о том, щачем он вообще нужен в команде и если не испоавляется - идет на выход.
Вы проверяете реализацию на соответствие требования. Это ПРИНЦИПИАЛЬНЕЙШИЙ момент. Когда условный лид докладывает статус тестирования и начинает и заканчивает с числа и характеристики найденных багов, хочется взять что-то тяжелое и ввалить. Ваш прогресс оценивается теми требованиями, которые вы проверили.
Т.е. есть список требований. Их классификация и приоритеты. Также есть зависимости. Отчет о тестировании - это этот список, и возле каждого требования: все ок, есть баги, блокер и т.д. И так, и только так можно:
Понять прогресс
Понять где проблемы
-
Выставить приоритеты
Все. Если вы не начинаете с этого и не живете этим каждый день - вы бесполезное звено.
Из этого вытекает очевидное решение, как бороться с багами в релизе.
Видно прогресс и можно принимать меры заранее, если вижно что не успеваем
-
Можно хоть каждый день принимать решение о том, на чем стоит сосредоточистся, чтобы MVP продукта точно был ок, а всякая лабуда типа подсказок или интерфейса локального администратора пилилась в конце
Это реально жесть. На собеседовани куча тестировщиков на вопрос "в чем ваше added value" отвечают мы ищем баги. Люди работают, но не знают зачем. Понятно при такой постановке процесс тестирования "встал и вышел".
Грустно
DMGarikk
17.08.2023 08:44тут на самом деле, ваше видение это сферическовакуумный проект, я пока еще ни разу не видел ни одного проекта чтобы там были четко описаны требования, прям настолько четко чтобы QA тупо проходился про ним и проверял _только_то_что_тамнаписано
и чем больше проект тем хуже с этими требованиями обстоят дела, потому что в какойто момент начинают пересекатся требования совершенно разных модулей и в реальной жизни может не хватит сил даже отдела аналитиков всё это скомпилировать в требования так чтобы это было так как вы предлагаете
по этому QA конечно проверяют заявленный функционал, и да, ищут баги в процессе этой проверки, потому что если после релиза фичи (которая соответствует требованиям) отсохла половина сервиса — это баг и его надо обнаружить, а не написать отписку что "в требования не написано что остальные сервисы после релиза должны работать, за это другой департамент отвечает" (у меня целый пласт история от таких дельцов, которые "как попросили так и сделали, а вы там хоть умрите" — руки повырывать хочется)
Я работал в проекте где был огромный монолит, сотня микросервисов, пять департаментов и около 500 программистов… которые все одновременно писали в общую кодовую базу которой было около 15 лет, там подавляющая часть кода написана людими которые не работают в компании уже много лет
Если описывать проект так как вы говорите, релизы фич будут выходить раз в год, а то и в два.последние лет 5-10 многие проекты переходят на безрелизные схемы… и игра в "свали свои комсяки на аналитика/ПМ-а/архитектора который не там запятую поставил" уже не такая однозначная
Batalmv
17.08.2023 08:44+2Не нужно описывать требования. Нужно для начала иметь из список. Это есть всегда, сорян. Даже в виде сторек из Jira.
Дальше QA команда:
Пишет стратегию, как они это будут тестить. Виды тестирования, как именно тестить, тулы и т.д
Каждое требование покрывается тест кейсами, которые собираются в сценарии. Как именно - это вопрос QA команды
-
И идет работа
Главное, работа идет по списку требований. Они могут быть связаны, собраны в группы, релизы. Это уже детали. Но ... всем начиная с ПМа интересно статус работ по тестированию в разрезе требований. Если QA этого не может дать - он идет далеко и прямо.
А аот по этому списку уже можно работать. Например:
Срезать скоуп релиза, оставив только то, что ПРОТЕСТИРОВАНО
Обратить внимание на проблемнве требования
Увидеть влияние багов на другие требовантя по связке требований
-
Планировать работы, так как прогрес измерим и явно видет
Batalmv
17.08.2023 08:44Дополнительно. Про большой проект. Да по фиг. В роли ПМа я ожидаю получить от QA ответ по списку:
Это протестировано и готово
Это в работе, вот список багов
Это покрывается тестами
-
Это вообще ХЗ что, будем покрывать
Где взять этот список - это мой вопрос. Возьму аналитика за жабры и заставлю написать. Не важно. Список будет. Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Потому что любой проект/релиз - это конечная и описанная активность. Либо в виде требований, либо в виде бэклога. Не важно.
Еслм что-то не описано, как например "ковыряние овна мамонта", значит оно есть на столе именно в таком виде. Но тогда QA туда соваться еще рано
Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
DMGarikk
17.08.2023 08:44Но вот что точно будет, так это пендаль QA, который на проекте занимается "сврбодным" поиском багов.
ну тут согласен, такого быть явно не должно
Abobcum
17.08.2023 08:44Иначе НИКТО НЕ БУДЕТ ЗНАТЬ ГДЕ МЫ И ЧТО МЫ ДЕЛАЕМ.
Вы когда-нибудь работали именно на таких проектах? Как бы вы решили эту проблему (я так понимаю, что вы пм)?
Batalmv
17.08.2023 08:44+2Ну, я работал и чистым ПМом, но объективно это не моя основная специальность
Вообще, выше я написал. QA команда работает, покрывая тестами и собственно тестируя требования/фичи, в зависимости от релизной политики. На коротких релизах это фичи, на длинных - требования. Так они имеют цель и смвсл жизни в команде.
Периодически QA готовят отчет, где мы в части готовности к проду. Т.е. что и скоупа готово, а что нет. Что не готово, обязательно классифицируется по тяжести багов. Так все знают текущий статус, включая заказчика.
Оперативно, часто с помощью жопомера и иных потусторонних сил, оценивается, насколько много шансов успеть к дедлайну и пора ли "паниковать" (резать скоуп, добавлять ресурсы, менять приоритеты). Также, если идентифицированы проблемы (тикеты не закрываются, появляются новые, переоткрываются старые), надо собраться и устранить корень возникновения проблемы.
Иногда надо QA помочь, так как уровень их технических знаний обычно невелик и багальное "я сейчас расскажу, как можно автоматизировать это штуку" может сильно ускорить процесс
В целом ничего уникального. В проекте должна быть цель, путь и движение к цели по этому пути, которое измеримо. И ежедневное вджобывание :)
Про БОЛЬШОЙ проект ... хз, кому что большое. У меня самый большой это Интернет банкинг, где одновременно трудилось до 10 команд в разных точках решения. Но он принципиально не отличается. Подходы те же. Просто надо ж понимать, что если условно он еще больше, то на проекте желательно иметь больше одного ПМа. Т.е. ничего страшного нет в том, что на большом проекте и лбдей больше, в том числе "с погонами".
В статье основная проблема и возможно, корень ее в том, что тестирование идет от требований, а не от багов.
Из опыта кстати, именно командам QA приходится чаще всего вставлять пистоны и проводить лекции на тему, как стать лучше. Некоторые воспринимают и дело идет на лад, с некоторыми приходится расставаться, иногда после жесткой беседы, так как иные методы не сработали :(
pyrobyte Автор
17.08.2023 08:44У багов есть критичность, это понятно. Посыл был рассказать, почему 100% багов не убрать и что можно сделать, чтобы их было меньше. А не упарываться в детали, уводя читателя от сути. Ну и логично было дополнить тем, что делают QA, чтобы багов было меньше.
"мы облажались, но если вы нам дадите больше денег - мы исправимся"Не совсем понятно, где и кто облажался. Речь шла о том, что можно сделать, чтобы багов было меньше: выделить больше ресурсов и провести предпроектную аналитику. Но так как предпроектную аналитику мы проводим практически на всех проектах, то и нет такого, что "мы облажались, дайте нам больше деняк, исправимся"
Batalmv
17.08.2023 08:44Дело в том, что избранная мера в виде количества багов глубоко вторична по отношению к мере готовности приложения к проду в виде списка фич/требований.
Как следствие, ориентированность команды QA на поиск багов, а девов на их фикс в реальности приводит к расфокусировке от важных вещей
Команда должна быть сфокусирована на фичах и их готовности к проду. Тогда релизы будут иметь смысл, так как будут состоять из протестированных фич, которые наиболее важны.
Это как 10 стаканов. Я не успеваю наполнить все 10 объективно? ОК, я наполню 7 самых важных, а на 3 забью. Если я фокусируюсь на багах, я могу получить 3 полных, и 7 почти полных. И даже в первом случае может быть условно 5 критикалов и 25 медиум, а во втором 2 критикала, и 12 медиумов. Но первый релиз выглядит намного лучше второго
Поэтому QA НЕ ИЩЕТ БАГИ. Он проверяет ГОТОВНОСТЬ ФИЧ, начиная с самых важных. А если продолжает искать баги и не исправляется, значит идет за борт :)
Даже сейчас ты пишешь про задачу, которая не имеет смысла. В проде не выходит отсутствие багов. В прод выходят одобренные фичи. И именно количество фич - мерило успеха команды.
Отдельный вопрос, если фича задекларирована как готовая, а в пподе вылез баг. Это повод для ретроспективного анализа и работы над техниками, взаимодействием и т.д. Но если команда изначально ориентирована не туда - она уже неэффективна
Ну или еще. QA находит баги. Много, мало ... это хорошо или плохо? ХЗ. Ну реально. Может багов и правда мало, а может и много. Это не важно. Важно мерять работу QA по количеству фич, которые он либо одобрил к выходу в прод, либо протестил и выкатил список багов. Тогда легко понять продуктивность команды и все остальное. И легко проверить качество работы тестировщика. Если окажется, что в готовой фиче есть баги (которые нашел клиент) или в "протестированной" фиче нашлись новые баги без изменения кода - это повод устроить QA команде разбор полетов
GpeG
17.08.2023 08:44На собеседовани куча тестировщиков на вопрос "в чем ваше added value" отвечают мы ищем баги.
А с другой стороны практически все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Вот и выходит ситуация, когда одни ищут баги, а вторые ждут пока джун нанятый по остаточному принципу на последней стадии разработки выправит качество продукта.
Batalmv
17.08.2023 08:44> все ПМ, которых я опрашивал, уверены, что тестировщик отвечает за качество продукта.
Ну, не совсем. QA подтверждает, что разработанный продукт соответствует требованиям к нему в рамках своих компетенций. QA не может сделать продукт качественнее. Он только указывает на дефекты. Поэтому формально формулировка неверна. Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
А что до ситуации ... ну так если ПМ ни черта не делает, чуда тоже не произойдет. Да длинном проекте можно увидеть достаточно признаков заоанее, что есть проблемы и заняться их исправлением до того, как подкрадется песец.
Но основная мысль в том, что если QA ищет баги, это уже проблема :) QA, как и DEV - закрывает фичи, только по своему
GpeG
17.08.2023 08:44Что при этом вкладывают эти ПМ в эти слоаа я догадаться не могу, сорян
Это несложно. Они вкладывают в это простой смысл: «Хочу чтобы кто-то улучшил качество проекта, желательно без особых вложений».
Если очень сильно загрубить, то работа тестировщика - вовремя предоставить информацию для контроля поставленной задачи. И я за свои 15 лет в тестировании пришел к неутешительному выводу: основная проблема тестирования в том, что большинство ПМ неспособны внятно поставить задачу и вообще не занимаются контролем исполнения. Поэтому и QA нанимают руководствуясь магической формулой:
Нанимаем QA
…
Качество улучшилось
Batalmv
17.08.2023 08:44Я обычно работал в организациях, где либо есть стандартны качества, либо люди и так понимают зачем. Вариаент без QA - только когда есть маленькая команда и можно просто кросс чекать друг друга
Про поставить задачу. Взгляд с другой стороны :) Я ПМ, или частично вывполняю его функции. У меня есть QA, или даже команда. Я нанимаю кого-то с опытом 15 лет. Блин, какая постановка задачи ожидается?
Во-первых. На большом проекте может быть 5+ команд разработчиков, разномастный заказчик с 7 говорящими головами, 2+ спонсора, куча мерзких запрещалок, контракты с тремя поставщиками, 2 из которых из-за бугра. Куча доки, которую надо вести. 10 встреч каждый день, 100+ писем, и много-много другого. ПМ нанял в команду QA команду с лидом, чтобы тратить время на постановку задачи?
Реально на это физически нет времени. Для этого и берется лид, который не просит поставить задачу, а организует процесс тестирования. Да, именно так. Ожидается, что человек с опытом знает как построить свой процесс и ему нужен ПМ для решения орг. вопросов. Конечно, я лично еще не встречал QA, которые бы не просили помощи в технических вопросах, так где сложно, но это нормально. Точнее они есть, те кто могут сами, но стоят дорого, и сразу фиг дадут.
Поэтому, подытоживая. Да, спец с опытом знает, зачем он в проекте и ему надо только уточнить детали, как именно в будет тут. Бэби ситтингом никому заниматься не интересно, кроме удовлетворения преподавательского зуда.
По контроль - да, это пичалька. Если первый вопрос тестировщику на совеседовании "какой ваш added value", то вот ПМа стоит спросить в целом по каждой роли и "что вы выносите с утренних стенд-апов". Ответ на последний часто удручает :(
Но тогда есть надежда на то, что в команде будет сильный аналитик/архитектор/тимлид, которые тут подстрахуют
GpeG
17.08.2023 08:44Вы от команды чего хотите получить? Чего должно быть сделано? К какому сроку? Критерии успешности есть?
Вы когда нанимаете человека, вы же говорите ему чего от него хотите?
В целом, основная задача ПМ - принимать управленческие решения. Остальное - это сопутствующие развлечения.
Batalmv
17.08.2023 08:44Человек берется в команду в идеале после собеседования, на котором проверяется наличие hard/soft скилов, а также обычно кандидата знакомят с проектом и задачами
Также очевидно, что если есть конкретные ожидания, например к решению есть требования по производительности, которые надо будет проверит, то они озвучиваются.
Но в рамках экспертизы QA ПМ не должет ставить детальные задачи. Как и другим ролям. Но может контролировать. К примеру, начинается большой проект. Есть до головы QA лида не дошла светлая мысль, которая заключаеться в необходимости начать работу над тестовой стратегией, то ПМ вполне может спросить, а почему лид все еще занимает положение "сижу на жопке" ровно? Ну и походу стоит попросить другого спеца посмотреть, чего лид туда написал и не написал. И найти экспертов которые помогут туда вписать все что нужно. Это нормально, еж птица гордая и инфантильная.
Но в целом, мне не очень понятно в чем суть. Человек с опытом ЗНАЕТ, что надо делать. Ему нужны детали/нюансы конкретного проекта, либо бебиситер в виде лида. Еслм лиду нужен бебиситер - то лиду точно пора на выход. Тут все просто.
Про то, что делает ПМ - да очень много чего, не только управленческие решения. Как минимум очевидно, что чтобы чего то принимать, надо убедится, что есть достаточно вводных.
А для этого, как раз нужна ориентация QA на фичи, а не на баги
Пример. Утренний ответ на стандартные вопрос от QA.
Закончил покрытие тестов к фиче 111, возьму покрытие фича 222 и протестирую фичу 333. Планирую сделать за день. Отлично
Написал 20 тест кейсов к фиче XYZ, нашел 5 багов в фиче ABC. Очень плохо :)
Задача ПМ в таком случае трансформировать инфу и фокус QA с нижнего варианта ответа на верхний :)
А чем в целом изначально я и талдычу :) Как и о практической бесполезности измерения работы, качественно и количественно багами
PereslavlFoto
17.08.2023 08:44+1Сроки и бюджет — всегда щепетильная тема.
С одной стороны, бюджет проекта обычно нулевой, поэтому тестирование проходит только в самых необходимых местах. Здесь перед QA встаёт совсем иной вопрос: тестировщик должен скрыть недостатки, чтобы вред от недоделок стал незаметным.
С другой же стороны, за счёт MVP заказчик ничего не заработает. На ноль делить нельзя, поэтому MVP нельзя оценивать по отношению расхода к доходу, а только по общественной полезности.pyrobyte Автор
17.08.2023 08:44Скрывать недостатки, чтобы их просто не было видно? ಠ_ಠ
При ограниченном бюджете внимание уделяется больше критичным местам, это да, но и о не критичных тоже нельзя забывать. Это как минимум не профессионально.PereslavlFoto
17.08.2023 08:44При ограниченном бюджете
При ограниченном бюджете нельзя забывать. А при нулевом бюджете дело обстоит иначе.
Ndochp
17.08.2023 08:44Нулевых бюджетов не бывает. Все равно некая команда пилит разработку и поддержку и получает зарплату. Просто то что не делает один выделенный специалист — совмещает другой. Иногда более высокооплачивемый. У меня перед глазами после нескольких косячных релизов обязательства по проверке перед сдачей брал на себя лично гендир подрядчика. (что он там в итоге после делал хз конечно)
PereslavlFoto
17.08.2023 08:44Да, я согласен. Можно взять свою зарплату и с неё нанять QA-специалиста. Но тогда не останется денег на коммунальные платежи.
Принимаю ваше замечание и уточняю: нулевой бюджет — это в бюджете заложена не более 1 заработная платы, с которой оплачиваются все расходы. Есть варианты, когда в бюджет заложена ½ заработной платы или 0 заработной платы.
Ndochp
17.08.2023 08:44Моя мысль была в другом, при некоторой низкой численности команды можно обойтись без QA специалистов, но нельзя без QA процессов. Так что бюджет (на проект) всегда есть, иначе с чего бы кто-то требовал результатов. И он будет эффективнее использован, если "борьба за качество" будет идти планомерно с инструкцией понятной всем, а не стихийно "вы все спецы с 15 летним опытом работы, делайте как хотите, но чтобы было хорошо"
PereslavlFoto
17.08.2023 08:44Результат требуют в силу должностной инструкции и трудового договора.
Бюджет есть на оклад.
В остальном вы правы.
Verno
17.08.2023 08:44Есть еще проблема стандартов, подходов и методологий. Начиная с дизайна и заканчивая разработкой и интеграциями. Документацию мало кто пишет, макеты дизайна, без слез не взглянешь (это хорошо, если есть). И вот клиент решивший сэкономить приходит на поддержку и развитие и получается, что дешевле заново сделать!
koresh_builder
17.08.2023 08:44Сам не в теме, но вредный совет 8 - это не тестирование белого ящика?
pyrobyte Автор
17.08.2023 08:44Если есть понимание, что этот код значит, то да, белый. Если этого понимания нет, то можно всякого наворотить.
SpiderEkb
Одна из причин (на мой взгляд) в том, что многие работают (как в одной из тем тут сказали)
или
Т.е. люди берутся за работу, не понимая что они хотят и не представляя как должен выглядеть конечный результат.
Естественно, что в таких условиях нормального результата не получить в принципе.
Намного более стабильный результат получается когда присутствует "бюрократия" (по мнению некоторых) - сначала бизнес-требования от заказчика (BRD). По ним рисуется ОТАР (организационно-техническое архитектурное решение), которое согласуется архитекторами и ответственными за системы, которые это решение затрагивает. Согласованное решение уже не меняется. Только откатом на начало процесса целиком.
Дальше пишется ТЗ ( FSD). По нему разработка.
Потом тесты - компонентные (на соответствие FSD) - тут юниттесты, автотесты, ручное тестирование отдельных кейсов, бизнес (на соответствие BRD), интеграционные, нагрузочные, техтест (тестовое развертывание на копии промсреды). И только после всего этого внедрение.
Понятно, что тут не получится быстро-весело "херак-херак и в продакшн". Но зато стабильность результата намного выше в итоге.
DMGarikk
только это бизнесу не особо нужно, бизнесу нужен timetomarket
вообще подавляющую часть времени работал с аджайлом, а тут попал в оутсорс проект где BRD-FSD… и с точки зрения продукта и дедлайнов это вообще жесть
согласования BRD может занимать месяцы, потом в процессе реализации изменения в требованиях это очередной виток совещаний на 20 человек, матюгов и прочее, потом после релиза оказывается что чтото не сделали (не учли в требованиях, оказалось что то как реализовано — не юзабельно)… и начинается многомесячный поиск виноватых, кто где нетак запятую в требованиях поставил и кто будет платить за доработки, а кто будет работать бесплатно… создание новых требований на исправление… опять совещания… а на проде всё это время полурабочий сервис
жесть та еще....(ненавижу оутсорс по этой причине)...
SpiderEkb
Бизнес бывает разный. Бывают ситуации, когда за каждый баг в первую очередь платит бизнес. Деньгами, репутацией. И если деньги потом можно регрессировать на исполнителя, то репутацию никак.
Т.е. тут опять все упирается в то, насколько бизнесу нужен ваш продукт. Если это mission или хотя бы business critical, это одно, а если "у всех есть и мне надо чтобы было" - это совсем другое.
В первом случае бизнес готов поступиться TTM лишь бы потом дерьмо полной ложкой хлебать не пришлось. Когда быстрый TTM несет в себе повышенные риски внеплановой проверки регулятора и потенциальные штрафы со многими нулями или вообще лишение лицензии - фиг с ним с быстрым TTM, сделайте надежно и без багов.
DMGarikk
согласен
хотя репутация в РФ штука такая себе, это отлично видно на примере всяких очень крупных и известных систем
Да и не в РФ собственно тоже, продукты всяких ораклов и IBM полноценно поддерживаются только если вы тратите ярды баксов, а если нет то утретесь со своими багами
я видел как глючит банковский софт с остановкой онлайна на часы, с глюками в цифрах, с потерями данных… и… и вендору плевать на это, потому что "куда вы денетесь с подводной лодки"/вы слишком мало нам платите чтобы мы для вас чтото фиксили вне стандартных релизов (исправление заявленного бага в плане через два года)
так что это всё, с моей точки зрения, утопичные схемы, в реальности всё гораздо печальнее и TTM зачастую, даже если это "хочу как у соседей" гораздо важнее — потому что TTM — это показатель для инвесторов и акционеров, а количество багов в трекере это просто кличество багов в трекере… их инвесторы/акционеры не видят
а это вообще нечто, у меня прям глаз дергается, помоему все, буквально все поставщики софта который делает то что проверяет регулятор — выпускают фичи за 1-2 дня до дедлайна по срокам сдачи отчетов… и при этом это яростно глючит… и я это не только про 1С… недавно бился с одним банком который решил заапдейтить свой интерфейс в конце квартала и выкатил недоделанную версию отправки отчетов (ну не то что недоделанную, а с урезанным функционалом) при этом не забыв отключить старую… я почти несколько висел на созвоне с техподдержкой чтобы сначала донести до них что мы не можем ничего сделать… а штраф нам вкатят уже послезавтра
а репутация? а что репутация. большинство бизнесов не может просто взять и поменять банк, потому что там кредитная линия железобетонно их держит… или какойнить отчет в профильное ведомство… репутация
SpiderEkb
Ну я вообще-то в банке. И как раз на уровне серверов центральных.
Поверьте - такие вещи автоматически (у нас) тянут за собой комиссию по инцидентам и выводы соответсвующие.
И по дефекту промсреды такого уровня разработчика могут ночью из постели выдернуть.
И проектные поставки - это одно. Дефекты промсреды - это совсем иная сущность, она идет вне плана и исправляется максимально быстро.
А время недоступности отдельных систем исчисляется минутами. Дальше уже регулятор (ЦБ) обращает внимание и начинаются штрафы.
И да, у нас были инциденты с недоступностью оплаты картами в период пиковых нагрузок. И сопровождение в мыле переключалось на резерв, останавливало модули которые были причиной проблемы, откатывало поставки... И разборки потом были очень серьезные кто что как и почему так получилось.
Но это на уровне центральных серверов - там 90% того что крутится - mission critical.
А вот где "молодые-креативные" (мобильное приложение, сайт) - там все может быть совсем иначе. Там запросто могут глюки на прод выкатить чтобы "быть первыми".
Но разница в том, что у нас это случилось один раз (после чего были сделаны выводы и предприняты меры), а те же госуслугии вставали колом на протяжении нескольких лет подряд когда зимой начиналась запись детей в школы...
DMGarikk
конечно, я до сих пор помню ночные созвоны по 2-3 часа с лежащим онлайном и ремонтом на ходу
ну я тоже такое помню, даже помню как ехал на работу и встрял на заправке когда не смог заправится из-за лежащего процессинга… который я ехал чинить
комиссия конечно проводится и выводы… помню тогда вводили строгий регламент техработ, многоуровневые тесты и прочее прочее… тем не менее стабильно всё падало раз в два-четыре месяца, зачастую из-за обновлений софта вендора
И вендору было, явно плевать на такое.
помню их фразу с тех времен "ну в Сбере у нас всё работает, значит и у вас должно, разбирайтесь сами" (с)
история правда уже давнишняя, может чтото и поменялось в лучшую сторону, но тотже сбер также привычно падал в даты апдейтов уже в конце 10х, когда я работал совсем в другом месте… но при падении сбера обрывали техподдержку совсем не связанных с ним сервисов, просто потому "а у вас карты не проходят" — а не проходят карты сбера, потому что он лежит… и звонить им надо, но звонили нам..
p.s. я в Сбере не работал, но из-за его размера и из-за того что некоторый софт был аналогичен ихнему, подобные инциденты касались и нас, хотябы просто мимолетом
pyrobyte Автор
Не обязательно для того, чтобы получить нормальный результат, нужно уходить в бюрократию. Мы, как уже сказали, проводим предпроектную аналитику, которая помогает собрать все требования к продукту. Понятно, что по ходу разработки заказчику может что-то прийти в голову, это нормально. Аналитики опять же проверяют идею на адекватность, поэтому не бывает такого, что "люди берутся за работу, не понимая что они хотят и не представляя как должен выглядеть конечный результат"
Ndochp
Жил я в большом проекте, который работал по описанной вами бюрократии: