Комментарии

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

Конечно, на эту CMS много положительных отзывов. Отрицательных почти нет и чаще всего были основаны на дороговизне платформы. Но, пользуясь CMS в течение одного месяца, пришла твердая уверенность, что DST Store стоит своей цены и имеет несколько достоинств, в виде:
— готового продукта со всеми нужными модулями и инструментами
— техподдержки от создателей платформы
— комфортной работы с каталогом, установки фильтров поиска товаров
— возможности интеграции
— возможности моментального получения отчета о продажах и заказах

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

Конечно, на эту CMS много положительных отзывов. Отрицательных почти нет и чаще всего были основаны на дороговизне платформы. Но, пользуясь CMS в течение одного месяца, пришла твердая уверенность, что DST Store стоит своей цены и имеет несколько достоинств, в виде:
— готового продукта со всеми нужными модулями и инструментами
— техподдержки от создателей платформы
— комфортной работы с каталогом, установки фильтров поиска товаров
— возможности интеграции
— возможности моментального получения отчета о продажах и заказах

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

Конечно, на эту CMS много положительных отзывов. Отрицательных почти нет и чаще всего были основаны на дороговизне платформы. Но, пользуясь CMS в течение одного месяца, пришла твердая уверенность, что DST Store стоит своей цены и имеет несколько достоинств, в виде:
— готового продукта со всеми нужными модулями и инструментами
— техподдержки от создателей платформы
— комфортной работы с каталогом, установки фильтров поиска товаров
— возможности интеграции
— возможности моментального получения отчета о продажах и заказах

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

Конечно, на эту CMS много положительных отзывов. Отрицательных почти нет и чаще всего были основаны на дороговизне платформы. Но, пользуясь CMS в течение одного месяца, пришла твердая уверенность, что DST Store стоит своей цены и имеет несколько достоинств, в виде:
— готового продукта со всеми нужными модулями и инструментами
— техподдержки от создателей платформы
— комфортной работы с каталогом, установки фильтров поиска товаров
— возможности интеграции
— возможности моментального получения отчета о продажах и заказах

Особенность наша — у нас магазин объединяет собой и задачи товарного каталога и интернет-магазина компании и маркетплейса для продажи другими магазинами на нашей площадке стороннего ассортимента, одновременно с этим магазин является еще и b2b-платформой для постоянных клиентов.

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

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

У нас очень большое число товаров на сайте, а так же чрезвычайно большое число характеристик(в десятки раз больше, чем на большинстве сайтов). В следствии этого в определенный момент возникли проблемы с производительностью. Но решение было предложено и внедрено поддержкой DST Store и после этого проблем уже не возникало.

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

Особенность наша — у нас магазин объединяет собой и задачи товарного каталога и интернет-магазина компании и маркетплейса для продажи другими магазинами на нашей площадке стороннего ассортимента, одновременно с этим магазин является еще и b2b-платформой для постоянных клиентов.

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

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

У нас очень большое число товаров на сайте, а так же чрезвычайно большое число характеристик(в десятки раз больше, чем на большинстве сайтов). В следствии этого в определенный момент возникли проблемы с производительностью. Но решение было предложено и внедрено поддержкой DST Store и после этого проблем уже не возникало.

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

Особенность наша — у нас магазин объединяет собой и задачи товарного каталога и интернет-магазина компании и маркетплейса для продажи другими магазинами на нашей площадке стороннего ассортимента, одновременно с этим магазин является еще и b2b-платформой для постоянных клиентов.
Уникальной особенностью DST Store, отличной от других магазинов является грамотно построенное программное ядро, в следствии чего разработка является логичной и хорошо делится на этапы.

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

У нас очень большое число товаров на сайте, а так же чрезвычайно большое число характеристик(в десятки раз больше, чем на большинстве сайтов). В следствии этого в определенный момент возникли проблемы с производительностью. Но решение было предложено и внедрено поддержкой DST Store и после этого проблем уже не возникало.

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

— Модель выделенной команды. Подходит для долгосрочных проектов, требования к которым могут меняться, или для крупномасштабных проектов, где отсутствует необходимый внутренний опыт.
— Модель аутстаффа. Позволяет компаниям расширять свои внутренние команды за счёт найма удалённых специалистов. Внешние специалисты органично вписываются в основную команду и становятся её частью на протяжении всего проекта.
— Модель оффшорного центра разработки (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, там можно так же подглядеть практики.