Комментарии

— Модель выделенной команды. Подходит для долгосрочных проектов, требования к которым могут меняться, или для крупномасштабных проектов, где отсутствует необходимый внутренний опыт.
— Модель аутстаффа. Позволяет компаниям расширять свои внутренние команды за счёт найма удалённых специалистов. Внешние специалисты органично вписываются в основную команду и становятся её частью на протяжении всего проекта.
— Модель оффшорного центра разработки (ODC). Предполагает партнёрство с внешним ИТ-подразделением, расположенным в другом регионе. Оффшорная команда обычно погружается в корпоративную культуру клиента и посвящает своё время одному проекту.

Также существуют различные методологии разработки программного обеспечения, например мы у себя в компании перепробовали все основные:

— Waterfall (каскадная модель). 25 Классическая поэтапная методология, в которой каждый следующий шаг начинается только после завершения предыдущего.
— V-образная модель (разработка через тестирование). Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе.
— Scrum. 24 Модель управления разработкой с гибкой организацией работы внутри команды. Scrum позволяет развивать проект в тесном сотрудничестве с заказчиком, постоянно корректируя характеристики продукта и показывая результат на каждом этапе разработки.
— Kanban. 25 Подход к разработке ПО по методике Agile, который подразумевает открытость всех рабочих процессов и постоянное улучшение производительности. Каждый член команды выполняет индивидуальный набор задач.

Так что на мой взгляд, выбор модели участия в разработке программного обеспечения зависит от особенностей компании и команды.

Это верно подмечено, интересно а с какими модялми вы сталкивались или изучали?

В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

Независимо от того, какую методологию выберет ваша команда, жизненный цикл разработки программного обеспечения останется одинаковым и будет выглядеть следующим образом:

Тестировщики обеспечения качества необходимы в команде разработчиков по следующим причинам:

— Обеспечение качества, надёжности и производительности программного обеспечения. Тестировщики выявляют и устраняют недостатки до того, как продукт достигнет конечных пользователей.
— Снижение рисков и предотвращение проблем. Тестировщики помогают выявить потенциальные риски и уязвимости в программных приложениях, проблемы совместимости и узкие места в производительности.
— Это снижает вероятность сбоев, утечки данных или сбоев системы.
— Улучшение пользовательского опыта. В ходе тестирования тестировщики могут предоставлять обратную связь о том, как сделать продукт более привлекательными и удобными для пользователя.
— Обеспечение последовательности и стандартизации в практике тестирования. Тестировщики устанавливают и придерживаются процессов тестирования, методологий и лучших практик. Это гарантирует, что каждая версия продукта соответствует одним и тем же стандартам качества.
— Улучшение сотрудничества и коммуникации. Тестировщики являются мостом между командой разработчиков и другими заинтересованными сторонами. Их участие способствует командной работе и общему пониманию стратегических целей, процедур и стандартов.

Так есть еще и много типов тестировщиков, например тестировщик обеспечения качества, который как я понимаю к разработке не имеет никакого отношения

Разработчики знают в деталях сегмент, который сами доработали, но они не понимают всей системы, того, как поднять тестовое окружение, какие тестовые данные нужны и как они могут искажаться внутри системы. Может даже случится «парадокс пестицида», когда давно не актуализированные тесты перестают находить ошибки.

К тому же, разработчик — это всегда «заинтересованная сторона». Человеку бывает сложно признавать собственные ошибки. Тестировщик же обладает некой степенью объективности.

Но риски есть и здесь. Например, в проекте происходят масштабные итерации, и его необходимо усилить тестировщиками из других команд или аутстафф-специалистами.

Будет ошибкой нанять людей, которые не обладают высокой экспертизой и опытом в необходимом для проекта технологическом и инструментальном стеке, даже если они долго работают в сфере тестирования. Поэтому к выбору новых работников нужно подходить внимательнее.

В таком случае почему тестирование просто нельзя отдать программисту? Как я понимаю тестировщики это те же программисты, или это уже другая специализация?

В каждом проекте тестирование реализуется по-своему, в зависимости от масштаба. Например, в стартапе достаточно договоренностей. Если продукт небольшой или участвует небольшое количество команд, то обычно тестирование проходит гладко, без искажения информации. Здесь специалист в курсе всех доработок и актуального состояния продукта.

В проектах покрупнее составляется конвенция об обеспечении качества на разных этапах, начиная от внутри- и межкомандной работы, заканчивая непрерывным процессом выгрузки обновлений для пользователя.

Самое интересное начинается, когда продукт сложный и есть много распределенных команд. Тут на тестирование возлагается большая ответственность, как на последний рубеж перед выгрузкой обновлений для пользователя. На всем этапе разработки ПО нужно обеспечить качество среди всех участников процесса. И как ни странно, следят за этим именно тестировщики.

А какую роль вообще играет тестировщик в проекте? Все таки это как никак лишняя нагрузка на бюджет, особенно для средних проектов

Не совсем понял про философский камень и мечту. На основании своего опыта могу точно сказать, что озаботившись даже самым простым чек-листом который соответствует специфики команды, вы можете получить значительное увеличение качества того артефакта который будет в итоге реализован. В любом случае мероприятия связанные с качеством будут выполнены, тесты будут написаны, баги буду найдены. Вопрос заключается лишь в том, что вкладываясь в качество, вы получаете тот же самый результат, какой вероятно получите и не вкладываясь в него, но в первом случае это будет дешевле. Именно этот посыл, имеет главное значение. Компаниям не нужны будут тестеровщики, так как это будет просто не выгодно и их место должны будут занять инженеры по обеспечению качества. Я полагаю, что вы согласны, с тем, что цена предотвращенного дефекта, дефекта найденного на этапе обсуждений или на ранних этапах разработки на порядок ниже, чем цена дефекта найденного в готов артефакте?

В рамках этой статьи я не касался вопроса специалистов по тестированию безопасности, это отдельная специфическая тема в которой у меня нет релевантного опыта. Но косвенный опыт все же есть. Опыт это связан, как раз с чек-листами от ИБ специалистов, которые нужны были для предотвращения типовых ошибок в разработке и цель этого была именно увеличить качество поставляемого к ним на тестирование артефакта. Нет требования полного покрытия всего. Работа с качеством не означает, что ты полностью предотвращаешь все проблемы, это не так. И важно понимать, что qa, так же занимается и контролем качества, но предварительно выполняет работу по его обеспечению. Процесс контроля останется, от него уйти или сложно или не возможно, а вот роль, которая занимается только контролем должна будет исчезнуть.

Касательно моего примера, если qa инженер на этапе разбора задачи, хотя бы просто поднимет этот вопрос, то это может привести к положительным результату. Например команда продумает вопрос авторизации заранее, например использовать клиентскую или межсервисную, сразу явно проговорит правила сброса и времени жизни сессий и так далее.

Разумеется мы можем этого не делать и в ходе тестирования готового артефакта найти эти дефекты. Завести баги, потратить время на их исправление, ревью, мерж, сборку. Это и есть работа «тестера» сказать на сколько итоговый артефакт соответствуют явным или не явным требования, а задаче qa, провести ряд мероприятий, может быть даже и самых простых, таких как, просто сказать, «а что с ИБ?» и по возможности предотвратить дефект и помочь всей команде реализовать ожидаемую бизнесом фичу в оговоренный сроки.

Чек-лист качества это мечта уровня философского камня, который будет превращать в золото все что угодно. Но если верить Гёделю, то будучи формальной системой, он окажется либо не полным, либо противоречивым. Со всеми вытекающими последствиями.

Давайте про безопасность. Как на практике. Желание приблизиться к полноте в таком важном вопросе, как безопасность, привела к появлению целого семейства стандартов — на разработку ISO/IEC 27000, и 15408 — на проверку. Крайне популярное и увлекательное чтиво в последнее время, покрывающее вопросы уровня огранизации, людей, физической безопасности и технологий — суммарно около 100 тем из разных областей. Вот пример классического чек-листа, затрагивающего лишь несколько из них github.com/RedHatInsights/secure-coding-checklist. Т е. если подходить к делу ответственно, то получить начальные сертификаты займет несколько месяцев, а внедрить и научиться осмысленно применять — миллионыгоды.

SAST, DAST, MPT, SCA, RE, PTasS, BAS, MAST — просто перечислить акронимы разного вида тестирования, необходимых, чтобы претендовать на соответствие стандартным требованиям — уже целое предложение.

Вы все ещё уверены, что тестировщики в скором времени останутся без работы? Мне кажется у для них с каждым годом работы только прибавляется.

Да, совершенно верно, мнение субъективное. Подача выбрана в таком формате специально, для привлечения внимания тестировщиков :)

В стать речь идет именно о понимание отличия этих двух направлений, касательно практик, там есть пару предложений, они имеет весьма «гигиенический» характер, но могут дать не плохой результат.

Если перейти к реальным кейсам, то могу предоставить примеры из личного опыта.

Работал с командами в которых были исключительно практики контроля качества, как это выглядит. QC не участвует, либо формально участвует в pbr, не погружается в контекст задачи, не понимает и подсвечивает команде возможные риски, сценарии тестирования и критерии успешности фичи. Спринт для такой команды выглядит обычно как waterfall модель. Разработка пишет большую половину спринта код, в конце спринта тестировщики берутся за тестирование. И тут происходит самое интересное, а именно:

— находятся критичные дефекты (так не была проведена работа по определению критичных сценариев и приемочных критериев)

— начинается расхождение того как поняли задача разработчики, тестировщики и что хотел заказчик

— выстреливают критичные риски (ну например сервис не держит нагрузку)

Это разумеется обобщенный и неполный список, но суть заключается в том, что в самом конце цикла разработки мы фиксируем проблемы, которые могли предотвратить. Это как правило ведет к большим потерям времени, так как чем дальше мы ушли в плане разработки, тем дороже выходит исправление найденных проблем.

И я повторюсь, что если работа построена именно в таком русле, то какое бы ни было количество людей, которое в конце спринта нам скажет, что все плохо, не изменит качество и не сделает наш продукт лучше.

Именно с этим связана основная мысль, что «тестировщик» должен расширять свою зону компетенций и начинать влиять на качество на всех возможных этапах.

С точки зрения развития себя как QA, я бы посоветовал проанализировать типичные проблемы команды и попробовать внедрить небольшую практику которая помогла бы эти проблемы решить.

Касательно примера выше это было бы:

— придти на PBR с чек-листом обеспечения качества и задать вопросы актуальные для продукта (будут ли проблемы с нагрузкой, нужно ли что-то специфическое по безопасности, нужно ли заранее продумать выход в продуктив и миграции и так далее, зависит от специфики команды)

— вытащить из заказчика четкие формулировки, что для него будет являться «выполненной задачей» и проговорить со всеми членами команды какие кейсы точно должны реализованы

— сразу же подготовить чек-лист основных проверок, придти к разработке и передать этот список, явно проговорил каждый пункт

Вероятнее всего, что мы не решим все наши проблемы, дефекты так же будут появляться, форс мажоры случаться, но заложить качество и помочь команде сразу реализовать именно тот функционал который нам нужен у нас повысится.

Это достаточная большая тема, кажется, что мне вновь не удается передать суть и практики. Но есть литература в которой уже описано :)

Для знакомства мог бы рекомендовать:

Agile-тестирование. Обучающий курс для всей команды Джанет Грегори, Лайза Криспин

Ну а так же все, что есть в интернете на тему shift-left testing, там можно так же подглядеть практики.

Вы подняли интересную тем, но пока это выглядит как субъективое мнение и не понятно как оно привязано к практике. Тут здорово бы смотрелись примеры реальных ситуаций — какие тактики из области QA использовали тестировщики и как это сказалось на проекте и их личной карьере.

Вероятно, я все таки плохо передал основную идею, а заключается она именно в том, что выстраивая любой производственный процесс, в том числе и процесс разработки, вложение в обеспечения качества выгоднее, чем вложение только в контроль качества.

Городить структуру и не нужно, просто нам мой взгляд «тестеры» должны чаще задумываться о добавлении в свою работу практик направленных на работу с качеством, а не только на его контроль, иначе они останутся за бортом.

Не бывает управления без изменения. Тестировщики как раз и выполняют такую функцию. Это основа и она ни куда не денется.

Согласно принципу Эшби, управляющая система должна иметь такое же или большее разнообразие как управляемая. Это значит, что на каждый вариант нежелательного отклонения, со стороны управления должно быть заготовлено соответствующее компенсирующее воздействие.

В самом деле, чем выше надёжность системы, тем меньше разных вариантов нештатных ситуаций и тем проще ей управлять. Но сложность, обусловленная разнообразием возможных проблем, ни куда не девается — она просто переходит в процессы управления качеством.

Как следствие, если QC достаточно уметь измерять результат, то QA должен детально разбираться в процессе, причинах возникновения отклонений и способах их компенсации. По сути такой персонаж должен обладать экспертизой уровня всей команды: разработчиков, менеджеров, архитекторов и всех остальных вместе взятых — чьи действия в своей области могут приводить к дефектам. А иначе, не обладая достаточными компетенциями, он сам станет причиной неверных решений и ошибок. Как вариант, он может решить абстрагироваться от сложных деталей, но тогда его функция становится чисто бюрократической, в роде коучинга.

А вывод такой, что управление качестом разумнее встраивать в существующую иерархию управления (начиная с самых низов — разработчиков, их менеджеров, менеджеров менеджеров и т.п.), а не городить параллельную ей структуру из отдельных QA. Функция контроля QC остаётся в любом случае востребованой на любом уровне.

Существует команда, процессы разработки которой гарантируют нам около 10 дефектов за спринт. Допустим, что эти дефекты, будут приводить к регулярному срыву спринтов. В командах, не умеющих работать с качеством, это вызовет реактивный ответ, который может звучать следующим образом: “Мы постоянно не успеваем протестировать задачи! Что у нас с тестированием?”. Рано или поздно это приведёт к мысли о необходимости увеличения штата “тестировщиков”, так как, именно тестирование не успевает завершить итоговую работу.

Но факт заключается в том что, даже удвоив количество тестировщиков, наша команда и дальше будет производит по 10 дефектов на фичу до тех пор, пока мы не начнём уделять внимание работе с качеством. Количество людей, задействованных в поиске дефектов (тестировщиков), глобально не может изменить ситуацию. Возможно, мы будем находить баги быстрые, но сам факт написания кода содержащего ошибки и сохранение множественных циклов «тест-дефект-фикс-ревью-деплой-тест» останутся.

Далее, вероятно, будут предприниматься попытки исправить ситуацию внедрением автоматизации тестирования, но в отсутствии практик обеспечения качества, это также не может помочь. Если процесс внедрения автоматизации регресса пройдёт успешно (а мы предположим, что будет именно процесс автоматизации регресса, ввиду отсутствия понимания концепции качества), то часть “тестировщиков” будет просто иметь больше свободного времени, ведь написанные скрипты, будут выполнять работу «тестировщиков», но по-прежнему никто не будет занят работой с качеством. В совокупности это одновременно увеличит и ФОТ и размер простоя ресурсов тестирования (сложно сказать, что тестировщики не заняты работой, просто это не всегда нужная работа).

Скорость нашей доставки, предсказуемости и качества будут оставаться прежними, вплоть до момента внедрения практик работы с качеством.

Думаю, что такой эволюционный путь рано или поздно приведёт большинство компаний, к более рациональному использованию ресурсов и построению процессов, связанных с обеспечением, а не контролем качества.

Короткий ответ на вопрос почему, сто́ит изучать практики QA:

— рост профессионализма и осознанности

— повышение эффективности работы команды

— поддержание разумного отношения тестировщиков и разработчиков

— возможность оценивать качество и влиять на качество

Отличие “Обеспечения качества” и “Контроля качества”

Для знакомства с процессами “Обеспечения и контроля качества” я бы хотел прибегнуть к примерам из производства, а лишь затем провести аналогии с разработкой в IT.

Чтобы понять, что представляет тот или иной процесс, мы будем использовать модели. В роли моделей у нас выступят два завода по производству кирпичей.

Контроль качества. Завод А.

Действующие лица:

— директор завода

— заказчик

— производство

— контроль качества

Процесс работы нашего завода:

— от заказчика поступает заказ на производство 20 паллетов кирпича

— директор оценивает, что заказ достаточно простой, ему всё понятно, завод постоянно изготавливает “красные” кирпичи, срок выполнения 10 рабочих дней

— директор формирует заказ и передаёт на производство, в заказе не указаны технические условия использования кирпичей

— производство на основании полученного заказа, изготавливает по 2 палета красных кирпичей в день и отправляет их на склад

— контроль качества дожидается, пока на склад прибудет 20 паллетов красного кирпича

— на 10-ый день, контроль качества проверяет сформированный заказ: открывает паллеты, смотрит на цельность, количество, цвет, форму и другие характеристики, которыми должен обладать красный кирпич

— в ходе проведения процесса контроля качества обнаружено, что 2 паллета имеют сколы и отличия в оттенке, продукция возвращается на исправление

— заказчик прибывает на склад для осуществления приёмки

— директор сообщает, что 2 паллета пришлось вернуть в последний момент, но заказ будет готов через 1 день

— заказчик дожидается новой поставки и проверяет выполненную работу

— все кирпичи одинаковые, но они не того размера, а также ожидалось, что будут изготовлены, серые шлакоблоки, все шлакоблоки должны были быть выполнены с учётом использования под водой

— заказ отменяется директором и формируется новый

— 18 паллетов лежат на складе и занимают место

— заказ отменён, но ещё 2 палета было произведено, так как информация об отмене пришла слишком поздно, теперь кирпичи лежат на заводе, перевозить их на склад дорого и не имеет смысла

Что мы видим из нашей модели?

— Производство успешно справилось с задачей, соблюдая поставленные сроки.

— Контроль качества выполнен, все кирпичи ровные и красные, именно так, как это указано в заказе, кирпичи со сколами найдены и отправлены на исправление.

— Заказ не выполнен, завод 2 недели делал ненужную работу.

— Дополнительные издержки связанные с хранением продукции

Контроль качества. Завод Б.

Для простоты восприятия и чтения мы не будем повторно описывать весь процесс, но выделим мероприятия, которые могли бы помочь улучшить положение нашего завода:

— директор уточняет у заказчика, какие в точности кирпичи необходимо изготовить, возможно, показывает ряд схожих изделий, фиксирует пожелания и называет ориентировочный срок готовности

— директор собирает бригаду, которая будет занята в производстве, обсуждает поступивший заказ и его детали

— инженеры обеспечения качества фиксируют ожидания

— бригада озвучивает дату изготовления, либо предлагает обсудить изменения требований к продукту, для уменьшения сроков

— работа и сроки согласовываются между заказчиком и заводом

— инженеры по обеспечению качества в явном виде передают производственные требования на каждым этап производства

— каждые два готовых паллета, проверяются на заводе, проводится оценка соответствия требованиям, лишь после этого они отправляются на склад, для итогового сбора заказа и контроля качества, так как мы должны быть уверены, что были изготовлены, те самые кирпичи

— инженеры по обеспечению качества предоставляют директору/заказчику промежуточные итоги

Разумеется, реальный мир разительно отличается от наших моделей, редко встречаются ситуации, когда мы выполняем категорически “не ту работу”, но в то же время мы сталкиваемся с похожими явлениями хоть и в меньшем масштабе, но значительно чаще, чем нам может показаться.

Хороший пример — это дефекты, заведённые по существующим приёмочным критериям, предположим что в рамках фичи у нас 20 приёмочных критериев и 2 дефекта по этим критериям.

Если вернуться к «Заводу А», то для нас данный пример выглядел бы, как 2 паллета «дефектных» кирпичей, сорванные сроки заказа, потери времени и денег. Так же стоит отметить, что вся информация приходит к нам фактически, уже при завершении процесса, большую часть времени мы уверены, что все наши действия верны. Вероятнее всего сделать выводы и предотвратить данную ситуацию в будущем, для нас будет являться задачей, за пределами наших текущих процессов и компетенций.

А вот для «Завода Б» это могло бы значить, что уровень качества производства и соответствия ожиданиям составляет 90%. Часть продукции также была произведена неверно, как и на «Заводе А». Но с того момента, как мы получаем возможность измерить уровень качества, у нас появятся возможность и повлиять на него. Мы в силах определить меры предотвращений ошибок, а цена их исправления, становится для нас ниже (кирпичи все еще на заводе)

Каждый раз, когда на этапе контроля качества, мы получаем продукт, который заведомо не соответствует ожиданиями, это ведёт к дополнительным издержкам и вероятно является сигналом о проблемах в процессе обеспечения качества (но не всегда, это тема для отдельной статьи).

Так или иначе, используя информацию выше, мы сформулируем определения “Контроля качества” и “Обеспечения качества”

Контроль качества – это процесс, сверки реализованного продукта с имеющимися к нему требованиями, фиксация результатов и предоставление обратной связи.

Важно отметить, что контроль качества, никак не влияет на само качество, а только помогает дать оценку, насколько реализованный продукт соответствует имеющимся критериям. То есть не существует разницы 5 или 10 инженеров проверяет наши кирпичи на складе, так как они уже изготовлены неверно. В этом и заключается причина почему, контроль качества не может влиять на само качество!

И что более важно, если ваша задача повысить уровень качества реализуемых продуктов или уменьшить накладные расходы разработки, то не одно из мероприятий, связанных с контролем качества, вам с большой долей вероятности не помогут.

Обеспечение качества – это ряд мероприятий, направленных на увеличение вероятности производства продукта соответствующего заявленным требованиям. Задача QA это не проверить, что кирпич красный, а выполнить все необходимые действия для того, чтобы этот кирпич был произведён красным, а также своевременно убедиться, что заказчик хотел именно этого.

Важно понимать, что контроль качества, это одна из составляющих процесса его обеспечения. Существуют продукты и процессы, где практики QA могут оказаться бесполезными или даже приносить вред.

Примером может быть Legacy система, в которую редко, но все же требуется вносить изменения. Зачастую изменения в таких системах производятся в уже реализованном и запутанном коде и задача сводится к поиску одного-единственный метода и изменения его логики. В таком случае, сколько бы ни было потрачено времени на определение критериев успеха или другие мероприятия, всё это может оказаться бесполезно. В подобных случаях задачей QA является опознать эту ситуацию и сосредоточиться на контроле качества или других подходящих практиках.

Если по какой-то причине вы сознательно не хотите применять подходы “Обеспечения качества”, то подумайте, насколько это подходящий выбор для вашего продукта и процесса разработки, в большинстве случаев, пропуская этап QA, мы всё равно выполняем весь скоуп связанных работ, но это происходит позже, чем требуется и с увеличенными затратами. Примером могут быть такие ситуации, как:

— подготовка тестовых сценариев после тестирования/реализации

— уточнение требований на этапе тестирования

— уточнение реализации на этапе тестирования

— изменений требований на этапе тестирования

— автоматизация тестирования после проведения ручного тестирования

— подготовка к UAT

— подготовка тестовых данных

— UP's забыли про нагрузку

— etc

— Покончите с зависимостью от контроля качества. Устраните потребность в массовых проверках, прежде всего встраивая качество в продукцию. Качество создается не в результате проверки, а благодаря улучшению производственного процесса.

— Деминг, Уильям Эдвардс

О той пользе, которую может получить команда, используя подходы QA

— делает процесс разработки более предсказуемым

— зачастую делает работу проще и осознаннее

— помогает выстраивать коммуникации и отношение сотрудничества внутри команды

— улучшает взаимодействие с бизнесом, ведёт к взаимному интересу и уважению интересов

— возможность явного управления скоупом работ, уровнем качества и ожиданиями

— ведёт к развитию процессов автоматизации (тут мы этого не касались)

Какие базовые кейсы можно решать познакомившись с подходами «Обеспечения качества»:

— недостижение цели спринта по причине нехватки времени на проведение тестирования

— переезд целей спринта в рамах исправления дефектов или тестирования на следующий спринт

— отсутствие тестовой документации

— неконтролируемый рост сроков реализации фичей

— и т.д

На мой взгляд, даже беглое знакомство с отличиями в процессах, может дать представление о том насколько, в действительности процессы QA могут быть шире, полезнее и интереснее “Контроля качества”.

А тут несколько мероприятий, которые я бы предложил попробовать инженерам и командам:

— формулируйте, фиксируйте и согласовывайте ваши приёмочные сценарии или критерии приёмки вместе с менеджерами/аналитиками и разработчиками на ваших PBR

— не завершайте PBR, пока все однозначно не поймут, какого результата требуется достичь и что будет считать выполненной задачей

— проводите дополнительные встречи в формате 3 Amigo

— формируйте приёмочные тест-кейсы параллельно или до разработки, обсуждайте сценарии с командой

— передавайте тест-кейсы разработчикам и делайте это в удобной для них форме, все участники команды должны знать, что нереализованное требование/тест-кейс — это дефект

— договариваться о промежуточных сборках, закрывающих часть критериев

— проводите приёмочное тестирование вместе с заказчиком по обговорённым кейсам, вероятно вы научитесь лучше понимать друг друга, после нескольких UAT

Главный вывод, который хочется сделать звучит просто и многим известен — «Легче предотвратить, чем исправить».

Адаптивный способ

Обычный адаптив

Название говорит само за себя. Это чистый адаптивный дизайн, который меняет отображение на разных экранах с помощью CSS media queries.

HTML на всех устройствах единый, а за отображение элементов отвечают CSS-стили. Дополнительно возможно использовать JavaScript, который может менять отображение и поведение страницы в зависимости от устройства. Подход mobile first подразумевает использование именно этой технологии: вы проектируете, верстаете сначала для мобильных, а затем добавляете стили для декстопов.

Как реализовать: согласитесь с mobile first подходом, прочитайте книгу Responsive Web Design и начинайте процесс создания нового сайта (или редизайна) с ширины экрана айфона — 320 px. Когда у вас будет готова вёрстка для этой ширины, добавьте media query для следующей ширины экрана (допустим, 768 px) и так далее, пока не будете удовлетворены результатом.

Кому-то хватает двух брейкпоинтов: для смартфонов и десктопов. Кто-то хочет предусмотреть и планшеты вплоть до разного отображения в вертикальном и горизонтальном положении. Если вы используете JS, то эти файлы также загрузятся для всех пользователей, а уже внутри JavaScript возможно выполнять различные функции в зависимости от устройства.

Динамический JS

В этой конфигурации (Dynamically-served JavaScript) все устройства загружают одинаковый HTML-код, который содержит ссылку на внешний JS файл. В зависимости от юзер-агента JS файл выполняет ту или иную функцию, то есть работает динамически. Например, если устройство — смартфон, то выполнится функция изменения порядка блоков в HTML-коде или удаления неиспользуемого в мобильной версии контента.

Этот подход мы используем в eskimobi при адаптации сайтов. Мы выбрали именно его, поскольку он позволяет получить контроль над DOM-ом сайта ещё до этапа рендеринга в браузере. Благодаря этому подходу вы можете полностью менять отображение декстопного сайта на мобильном устройстве при сохранении оригинального HTML. Более подробно все преимущества подхода динамического JS описаны здесь.

Как реализовать: изучите документацию библиотеки mobify.js, которая позволяет манипулировать DOM-ом сайта в зависимости от юзер-агента или обратитесь ко мне за консультацией.

Динамический показ

Плагин

В зависимости от CMS принцип работы может отличаться, но на практике плагин — это детектор мобильных устройств, который заменяет шаблон темы на специально адаптированную версию. Контент при этом может быть единый, либо отличаться — всё зависит от настроек, которые вы установите. Это, пожалуй, самое популярное решение ввиду простоты его применения.

Как реализовать: если у вас Wordpress, установите WP touch или Mobile Pack или Mobile Edition. Попробуйте каждый, чтобы найти самый удобный и подходящий вариант.

Для других CMS есть другие плагины, но суть сводится к тому, чтобы максимально облегчить процесс мобилизации, сделав минимум усилий. Мобильный сайт будет открываться на субдомене (m.site.ru) или без редиректа, всё зависит от настроек.

Разные URL

В эту группу включены решения, которые не используют единый HTML основной версии сайта. Это позволяет получить больший контроль над видом и функционалом мобильной версии, но в некоторых случаях может вызвать сложности при внедрении и поддержке.

Отдельная CMS

Отдельный сайт со своей системой управления (если у вас DST Platform то она уже сразу в коробке поддерживает мобильные решения), оптимизированный только для мобильных устройств. Сокрушительный минус решения в том, что это ещё один сайт, который нужно отдельно обновлять. Но для кого-то это будет подходящим решением для создания мобильного UX.

Как реализовать: создайте поддомен m.site.ru и разместите там систему управления для мобильного сайта. Учтите, что это сайт только для мобильных устройств, поэтому все стили и контент должны быть оптимизированы именно для смартфонов.

Когда сайт будет готов, включите определение мобильных устройств и перенаправление на другой домен. Вот готовое решение для этой задачи, просто скачайте версию в нужном языке программирования и вставьте в шаблон основного сайта сразу после . Замените последнюю строку редиректа на адрес вашего мобильного сайта.

API

Это оболочка, которая получает контент основного сайта по API и отображает в совершенно другом дизайне мобильную версию. Такой метод использует крупные проекты — «Фейсбук», «Твиттер», «ВКонтакте» и все, кому нужен полный контроль над мобильной версией с сохранением единого контента.

Это самый сложный способ реализации и поддержки, его используют только те, кто точно понимает, что хочет получить в итоге.

Как реализовать: нет единого рецепта, но порядок действий в любом случае начинается с проектирования и дизайна мобильной версии. После того, как вы определите важный контент, можно думать над тем, как его синхронизировать с основным сайтом с помощью API.

Конструктор

Самый простой способ получить мобильную версию сайта. Конструктор анализирует структуру основного сайта, расположение меню, цветовую схему и контент. После этого формирует уникальный шаблон, который вы можете настроить по своему усмотрению.

Прелесть решения в том, что удобный drag and drop интерфейс конструктора позволяет с лёгкостью управлять внешним видом мобильной версии и добавлять такие уникальные элементы, как гео-локация, click-to-call для звонка в одно нажатие, интерактивные галереи и многое другое.

Как реализовать: просто скармливаете конструктору адрес своего сайта и через пару секунд… получаете готовый мобильный сайт и синхронизированный контент. Для завершения установки потребуется лишь установить одну строчку кода в head основного сайта и оплатить подписку.

Правильный выбор

Выбор технологии зависит от исходных данных: если у вас уже есть сайт и вы с минимальными усилиями хотите сделать его мобильным, используйте плагин для вашей CMS или конструктор.

Если вы планируете редизайн или создаёте новый сайт, используйте адаптивный дизайн.

Если вы не планируете создавать новый сайт в ближайшее время и вам важно быстро получить качественную полнофункциональную мобильную версию, изучите подход «Динамический JS».

Будете работать с подрядчиком? Независимо от выбранной технологии, перед началом сотрудничества убедитесь, что исполнитель хорош и способен решить вашу задачу:

1. Изучите портфолио мобильных сайтов (желательно не менее 10). Именно сайтов, а не одностраничных лендингов. Обязательно посетите все сайты из портфолио. Если какой-то из сайтов недоступен, вероятно подрядчик вводит вас в заблуждение и преувеличивает свои заслуги. Обратите внимание на скорость работы и дизайн сайтов из портфолио. Много ли там практических ошибок? (Смотрите ниже раздел о ошибках дизайна.)

2. Попросите подрядчика рассказать о способах адаптации, которые ему известны. Почему он использует тот или иной способ, аргументы «за и против».

3. Зафиксируйте в договоре сроки создания мобильного сайта и предусмотрите штрафные санкции в случае просрочки. При этом старайтесь всегда быстро предоставлять обратную связь, если она требуется исполнителю для продолжения работы.

4. Оговорите формат и условия дальнейшей технической поддержки. Начало работы с мобильной аудиторией — это ответственный шаг и, вероятно, новый для вас. Важно, чтобы поддержка оказывалась вовремя и не вносила хаос в ваши устоявшиеся процессы. Однако, успех внедрения и развития мобильной версии будет зависеть и от того, насколько хорошо вы усвоили подход mobile first.

Я считаю, что для большинства задач подход «обычный сайт плюс мобильная версия» является путем наименьшего сопротивления, благо современные CMS позволяют резко минимизировать расходы на создание второго сайта.

Адаптивный способ

Обычный адаптив

Название говорит само за себя. Это чистый адаптивный дизайн, который меняет отображение на разных экранах с помощью CSS media queries.

HTML на всех устройствах единый, а за отображение элементов отвечают CSS-стили. Дополнительно возможно использовать JavaScript, который может менять отображение и поведение страницы в зависимости от устройства. Подход mobile first подразумевает использование именно этой технологии: вы проектируете, верстаете сначала для мобильных, а затем добавляете стили для декстопов.

Как реализовать: согласитесь с mobile first подходом, прочитайте книгу Responsive Web Design и начинайте процесс создания нового сайта (или редизайна) с ширины экрана айфона — 320 px. Когда у вас будет готова вёрстка для этой ширины, добавьте media query для следующей ширины экрана (допустим, 768 px) и так далее, пока не будете удовлетворены результатом.

Кому-то хватает двух брейкпоинтов: для смартфонов и десктопов. Кто-то хочет предусмотреть и планшеты вплоть до разного отображения в вертикальном и горизонтальном положении. Если вы используете JS, то эти файлы также загрузятся для всех пользователей, а уже внутри JavaScript возможно выполнять различные функции в зависимости от устройства.

Динамический JS

В этой конфигурации (Dynamically-served JavaScript) все устройства загружают одинаковый HTML-код, который содержит ссылку на внешний JS файл. В зависимости от юзер-агента JS файл выполняет ту или иную функцию, то есть работает динамически. Например, если устройство — смартфон, то выполнится функция изменения порядка блоков в HTML-коде или удаления неиспользуемого в мобильной версии контента.

Этот подход мы используем в eskimobi при адаптации сайтов. Мы выбрали именно его, поскольку он позволяет получить контроль над DOM-ом сайта ещё до этапа рендеринга в браузере. Благодаря этому подходу вы можете полностью менять отображение декстопного сайта на мобильном устройстве при сохранении оригинального HTML. Более подробно все преимущества подхода динамического JS описаны здесь.

Как реализовать: изучите документацию библиотеки mobify.js, которая позволяет манипулировать DOM-ом сайта в зависимости от юзер-агента или обратитесь ко мне за консультацией.

Динамический показ

Плагин

В зависимости от CMS принцип работы может отличаться, но на практике плагин — это детектор мобильных устройств, который заменяет шаблон темы на специально адаптированную версию. Контент при этом может быть единый, либо отличаться — всё зависит от настроек, которые вы установите. Это, пожалуй, самое популярное решение ввиду простоты его применения.

Как реализовать: если у вас Wordpress, установите WP touch или Mobile Pack или Mobile Edition. Попробуйте каждый, чтобы найти самый удобный и подходящий вариант.

Для других CMS есть другие плагины, но суть сводится к тому, чтобы максимально облегчить процесс мобилизации, сделав минимум усилий. Мобильный сайт будет открываться на субдомене (m.site.ru) или без редиректа, всё зависит от настроек.

Разные URL

В эту группу включены решения, которые не используют единый HTML основной версии сайта. Это позволяет получить больший контроль над видом и функционалом мобильной версии, но в некоторых случаях может вызвать сложности при внедрении и поддержке.

Отдельная CMS

Отдельный сайт со своей системой управления (если у вас DST Platform то она уже сразу в коробке поддерживает мобильные решения), оптимизированный только для мобильных устройств. Сокрушительный минус решения в том, что это ещё один сайт, который нужно отдельно обновлять. Но для кого-то это будет подходящим решением для создания мобильного UX.

Как реализовать: создайте поддомен m.site.ru и разместите там систему управления для мобильного сайта. Учтите, что это сайт только для мобильных устройств, поэтому все стили и контент должны быть оптимизированы именно для смартфонов.

Когда сайт будет готов, включите определение мобильных устройств и перенаправление на другой домен. Вот готовое решение для этой задачи, просто скачайте версию в нужном языке программирования и вставьте в шаблон основного сайта сразу после . Замените последнюю строку редиректа на адрес вашего мобильного сайта.

API

Это оболочка, которая получает контент основного сайта по API и отображает в совершенно другом дизайне мобильную версию. Такой метод использует крупные проекты — «Фейсбук», «Твиттер», «ВКонтакте» и все, кому нужен полный контроль над мобильной версией с сохранением единого контента.

Это самый сложный способ реализации и поддержки, его используют только те, кто точно понимает, что хочет получить в итоге.

Как реализовать: нет единого рецепта, но порядок действий в любом случае начинается с проектирования и дизайна мобильной версии. После того, как вы определите важный контент, можно думать над тем, как его синхронизировать с основным сайтом с помощью API.

Конструктор

Самый простой способ получить мобильную версию сайта. Конструктор анализирует структуру основного сайта, расположение меню, цветовую схему и контент. После этого формирует уникальный шаблон, который вы можете настроить по своему усмотрению.

Прелесть решения в том, что удобный drag and drop интерфейс конструктора позволяет с лёгкостью управлять внешним видом мобильной версии и добавлять такие уникальные элементы, как гео-локация, click-to-call для звонка в одно нажатие, интерактивные галереи и многое другое.

Как реализовать: просто скармливаете конструктору адрес своего сайта и через пару секунд… получаете готовый мобильный сайт и синхронизированный контент. Для завершения установки потребуется лишь установить одну строчку кода в head основного сайта и оплатить подписку.

Правильный выбор

Выбор технологии зависит от исходных данных: если у вас уже есть сайт и вы с минимальными усилиями хотите сделать его мобильным, используйте плагин для вашей CMS или конструктор.

Если вы планируете редизайн или создаёте новый сайт, используйте адаптивный дизайн.

Если вы не планируете создавать новый сайт в ближайшее время и вам важно быстро получить качественную полнофункциональную мобильную версию, изучите подход «Динамический JS».

Будете работать с подрядчиком? Независимо от выбранной технологии, перед началом сотрудничества убедитесь, что исполнитель хорош и способен решить вашу задачу:

1. Изучите портфолио мобильных сайтов (желательно не менее 10). Именно сайтов, а не одностраничных лендингов. Обязательно посетите все сайты из портфолио. Если какой-то из сайтов недоступен, вероятно подрядчик вводит вас в заблуждение и преувеличивает свои заслуги. Обратите внимание на скорость работы и дизайн сайтов из портфолио. Много ли там практических ошибок? (Смотрите ниже раздел о ошибках дизайна.)

2. Попросите подрядчика рассказать о способах адаптации, которые ему известны. Почему он использует тот или иной способ, аргументы «за и против».

3. Зафиксируйте в договоре сроки создания мобильного сайта и предусмотрите штрафные санкции в случае просрочки. При этом старайтесь всегда быстро предоставлять обратную связь, если она требуется исполнителю для продолжения работы.

4. Оговорите формат и условия дальнейшей технической поддержки. Начало работы с мобильной аудиторией — это ответственный шаг и, вероятно, новый для вас. Важно, чтобы поддержка оказывалась вовремя и не вносила хаос в ваши устоявшиеся процессы. Однако, успех внедрения и развития мобильной версии будет зависеть и от того, насколько хорошо вы усвоили подход mobile first.