Лаборатория Качества

Статья --> https://quality-lab.ru/blog/chto-testirovat-v-pervuyu-ochered-risk-orientirovannoe-testirovanie-po-russki/

Всё так. Да и в регуляторных сферах (финтех, медтех) отчеты тестирования — часть compliance. Та же матрица трассировки в отчете доказывает, что каждый пункт ТЗ верифицирован. Для заказчика это работает на снижение юридических рисков. Потому такие документы мы оформляем как аудиторский след — с привязкой к требованиям, версиям и окружению.

Спасибо за такой развёрнутый материал. Приглашаем в наш блог, мы в последнее время много публикуем о тестировании для веб-студий, уверены, что вам будет интересно)

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

В статье как раз про это и говорим, что важно не только «закрыть задачу», а еще и понимать, для кого и зачем мы её делаем. Use case очень помогает не закопаться в цифрах и не потерять суть.

Узнаю знакомую головную боль :) У нас тоже бывали случаи, когда один тестировщик с "двумя тикетами" вытаскивал проект, находя то, что потом доооолго бы аукалось в проде.

Абсолютно согласна, что количество задач вообще не отражает реальный вклад. Иногда один вовремя найденный баг вытаскивает

Максим, отправили в личку)

Полностью согласны с тезисом о сложности запуска IT-компании с нуля, особенно в условиях динамичного рынка и необходимости быстрого выхода с конкурентным продуктом. Одно из ключевых препятствий, с которым сталкиваются стартапы на этом пути — оперативное построение надежного QA-процесса.
Дальше надо сказать: "И вот тут появляемся мы с аутсорсингом или созданием QA-отдела "под ключ"! - но это и так ясно, поэтому скажем ещё по сути. Ооооочень важна способность быстро выпускать стабильные обновления. Первый релиз — это только начало. Настоящее испытание — когда нужно реагировать на фидбек, быстро добавлять фичи, но при этом не сломать работающий продукт для первых, самых важных пользователей.

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

Удачи всем стартапам на этом непростом, но невероятно увлекательном пути! Главное — быть готовым учиться и адаптироваться каждый день.

Отправили личным сообщением здесь в VC)

да, всегда. Это так же странно, как и очевидно))

Да, таким полезностям самое место в хорошей компании!

Харитон, спасибо за такой развернутый отклик. Действительно, вас задело за живое!

Да-да, всегда же находится что-то "посрочнее"😸😸

Согласны. 90% покрытия - не гарантия, что протестировано всё, что критично. Но и без метрик далеко не уедешь.
Мы в «Лаборатории качества» смотрим на покрытие как на инструмент диалога. Не как на самоцель, а как на способ задать правильные вопросы: где риски?что мы ещё не трогали? почему 10% остались не покрыты?
А если у вас нет картины покрытия, то вы и не знаете, где свет, а где тень. С ней же можно уже обсуждать, какие зоны оставляем сознательно, потому что риск минимален, а какие, наоборот, срочно надо тестировать.
Цифры не заменяют мышление, но помогают структурировать его.
Так что да, процент сам по себе -- не ответ. Но это хороший повод задать правильные вопросы. Вот с этого момента и начинается зрелое тестирование

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

Да, странно. Согласны на 146%. Но, увы, пока это "очевидное для всех в QA" всё ещё неочевидное для многих вне QA. Особенно в проектах, про которые думают, что они простые, типа «мы и так всё сами проверим» или «а можно без тестирования, мы ж хорошо все сделали».
Вот поэтому мы и продолжаем писать об этом, чтобы лишний раз напомнить, что тестирование — это средство снижения репутационных и финансовых потерь. И да, если тестирует сам заказчик — он вдвойне рискует. А исполнитель в 10 степени...

Слепое следование без понимания нюансов определенно приведет к не лучшим результатам. Мы пишем об основах, с которыми работаем, но всегда помним про уникальность каждого проекта. У нас их сотни за плечами и 10+ в работе. Подходы не могут быть одинаковыми ко всем! Так что согласны с вами, Николай. Спасибо за внимание к теме

Точно. Конечно, это так. В нашей работе от людей зависит не меньше! Мы поэтому так "присматриваемся" к людям и работаем со специалистами, у которых не только хард скиллы, но и софты хорошо прокачаны. Плюс между собой у людей в команде должен быть метч. Тогда даже сложные проекты не страшны вообще

В общем, да. Хотя один специалист по тестированию на проекте - тоже практикуется и вполне успешно. Все зависит от проекта. Но! Естественно, что и его работа должна сопровождаться грамотной организацией процессов, методиками и тд, как вы и пишете, Алексей. Как и в любой сфере - мало просто нанять специалиста, нужно ещё обеспечить ему условия

Абсолютно точно. Выгодно или нет, а еще - подходит ли сейчас она для решения текущих задач.

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

ну, дотянемся до 16-го, посмотрим)))

Конечно. Это к психотерапевту можно))

Сами по себе диаграммы прецедентов — штука полезная. Но с ними не всегда просто, самая частая ошибка перегружать их деталями. Например, пытаться сразу заложить технические нюансы, вроде обработки файлов или авторизации, хотя это не уровень Use Case Diagram. Здесь важно фокусироваться на бизнес-процессах и взаимодействии пользователей с системой, а не на том, как их авторизовывать или где хранить данные. Еще одна классика, с которой приходилось сталкиваться, впихивают (то есть пытаются) в диаграмму весь возможный функционал. В итоге вместо карты проекта получается схема метро, притом что-то типа лондонского андеграунда, где не разобрать, что критично для бизнеса, а что просто техническая реализация.
А мое любимое, эт когда делают ДП раз и навсегда, как будто тпребования никогда не будут меняться.

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

Legacy — результат нескольких лет накопленных компромиссов, спешки и так себе решений, которые когда-то казались хорошей идеей. Что у нас еще есть? как всегда, хаотичные изменения под каждый новый дедлайн, и вот уже готова "мину замедленного действия" из кода, которую все боятся трогать (ну, мне точно страшно), а старый стек сам по себе — не проблема, если он не тормозит развитие бизнеса

Из наболевшего - устаревшая документация, до которой никому нет дела ровно до момента, когда "срочно ВЧЕРА все переделайте"
а, еще вот, в достаточно долгом проетке, когда код писал один человек, а поддерживать теперь приходится всей команде, а тот чувак уже и не работает тут...

Прям как будто историю из нашей жизни рассказываете🤣

Настораживает и раздражает) а если тз пишется и корректируется на этапе тестирования (потому что мы часто работаем по shift left), то это отдельный вид садомазоудоводьствиЯ для всех. Спасибочки,что таких заказчиков не очень много🙏🏻

Классика 😸

Полностью поддерживаю. Хотя есть ещё более мерзкий вариант - когда тз нет вообще.
Как тестировщики, мы часто сталкиваемся с тем, что избыточная детализация тривиальных функций в ТЗ не только не помогает, но и создает риски. 20 страниц - это ад для тестового покрытия.
Главный принцип для ТЗ - ясность и фокус на уникальности. Неважно - это для разработчиков или для тестирования. И указание специфики,если она есть.

"Полетать на таком на природе — мечта"
Главное, птицам и насекомым сообщить,чтоб они приостановили свои полёты на время вашего🤣

А статья хорошо написана, интересно)