Когда заходит разговор о качестве, люди, как правило, имеют ввиду соответствие каким-либо требованиям. Например тем, что выдвинул заказчик, ПМ, аналитик или кто-то другой. Хуже всего, когда они считаются неоспоримыми и это ведёт к самоцели — удовлетворить требования заказчика, а это в свою очередь негативно влияет на конечный результат — то, что видят пользователи.
Мы в IT Test занимаемся заказным тестированием, и рассматриваем «качество» шире. Это не только соответствие требованиям, но и сами требования, точнее их дополнение своими, ориентированными не на заказчика, а на конечного пользователя. Не стоит забывать, что UX, юзабилити, доступность интерфейса для людей с ограниченными возможностями и т.д. — это тоже «качество».
По сути, качество — это «сделать красиво» со многих сторон: дизайна, разработки, заказчика и конечно же пользователя.
Как это сделать?
Мы всегда начинаем с формирования пула «встроенного» качества.
Качество — это стезя разработки
Почему качество напрямую связывают с тестированием, ведь оно определяется тем, как сделан продукт, а не тем, как он протестирован?
— Просто так сложилось.
За качество отвечает вся команда, и в большей степени разработчики, именно они обязаны быть уверены в том, что новая фича работает. Качества можно добиться двумя способами — технологическим и процессным, в том числе тестированием. Однако важно понимать, что на него нельзя перекладывать всю ответственность.
Устойчивость к изменениям
В долго живущих продуктах, наряду с текущим качеством, важно качество системы и её устойчивость к изменениям, которые всегда неизбежны, ведь для того, чтобы система жила и развивалась, нужны частые изменения.
Никому же не нравятся частые изменения, верно? Их воспринимают как что-то враждебное и исключительное. Как же сделать из них что-то обыденное и рутинное? Очень просто! Необходимо быть уверенным, что изменения ничего не сломают.
Поверьте, с вашей системой явно что-то не так, если в голове периодически появляется мысль «работает — не трогай» или если разработчики не выкидывают уже написанный код.
Кодовая база — это не то, что можно сдать и забыть. Это среда, в которой мы живём, и нужно сделать её удобной для постоянной работы. Изменение, добавление или удаление кода не должно вызывать страх.
Что делать, если нет детальных требований?
Если нет детальных требований, не нужно бежать к заказчику и спрашивать в каком месте должна быть кнопка, однако это не значит, что она может быть в любом месте.
Кроме требований, указанных в ТЗ, не стоит забывать о собственном опыте и чувстве прекрасного. Именно эти навыки нужно постоянно развивать и держать на должном уровне и именно этим навыкам стоит следовать при принятии решений о расположении упомянутой кнопки и любых других.
Отсутствие детальных требований — это не проблема, а возможность сделать максимально хорошо, гибко управляя всем процессом с учетом доступного времени и бюджета, фокусируясь на важном, отбрасывая вторичное.
Конечно же важно понимать, что делается и зачем, однако детальные требования не являются обязательными.
Баги избежны, но не все
Исходя из нашего опыта, многие прикрывают низкое качество разработки словами «баги всё равно неизбежны». Да, баги действительно неизбежны, однако это не означает, что допустимо любое количество багов.
Баги — это нормально, если они быстро чинятся и критические баги, ломающие основные сценарии, возникают крайне редко или не возникают вообще(имхо).
Если каждая задача, отправленная на тестирование, возвращается или при починке одного бага всплывает три новых, значит с качеством что-то не так.
Баги есть и будут всегда
Мы всегда стараемся изменить восприятие заказчиков к багам, подойдя к этому вопросу немного с другой стороны. Количество багов зависит не только от кода, но и от того, что считать багом. В любом ПО, вне зависимости от его качества, можно найти баг, но он не всегда является таковым. Временами его исправление — это просто генерация лишней работы.
Нет, мы не предлагаем игнорировать баги, однако нужно понимать, что важно для проекта, а что нет. Периодически тестировщики закапываются в деталях, тратя на них слишком много времени, которого не остается на проверку сути и следованию общей цели. Лучше проверить основной пользовательский сценарий и сфокусироваться на общей картине качества, чем весь день сверять вёрстку с макетом и возвращать каждую задачу на доработку из-за незначительных мелочей.
Также не следует тестировать и проверять компетентность исполнителя. Если вы проверяете работу одного разработчика больше, чем любого другого только потому, что сомневаетесь в его компетентности, то проблема не в багах, а в доверии или соответствии уровня разработчика сложности задачи. Нужно доверять людям.
Ещё не имеет никакого смысла тестирование дизайн-макетов и написанных требований. Без реализации они не несут никакой ценности пользователям. Проводить ревью, обсуждать и совместно проектировать макеты и требования можно и нужно, однако не стоит тестировать их формально.
Протестировать всё в нашем мире было бы классно конечно, но здесь есть более важные вещи.
А что тестировать?
Главная задача тестировщика — сделать так, чтобы багов было как можно меньше. Т.е. чем меньше багов найдено, тем лучше.
Тестировщик — это нулевой пользователь системы, который отлично знает продукт и снаружи, и внутри. Тестировщик должен обеспечивать корректный UX, а не проверять задачи разработчиков, т.к. тестирование эффективно, когда оно приносит дополнительную ценность, а не компенсирует недостатки разработки, ведь уровень качества задаётся именно на этапе разработки. Когда тестировщик помогает разработчикам закрывать граничные кейсы и писать тесты, повышая тем самым качество разработки и обеспечивая целесообразный уровень покрытия, только тогда получаются действительно «крутые» продукты.
Если вы тратите усилия на компенсацию разработки тестированием, вы лишаете себя возможности направить эти усилия на развитие разработки и, как следствие, качества продукта.
Источник статьи; https://habr.com/ru/post/563146/
Мы в IT Test занимаемся заказным тестированием, и рассматриваем «качество» шире. Это не только соответствие требованиям, но и сами требования, точнее их дополнение своими, ориентированными не на заказчика, а на конечного пользователя. Не стоит забывать, что UX, юзабилити, доступность интерфейса для людей с ограниченными возможностями и т.д. — это тоже «качество».
По сути, качество — это «сделать красиво» со многих сторон: дизайна, разработки, заказчика и конечно же пользователя.
Как это сделать?
Мы всегда начинаем с формирования пула «встроенного» качества.
Качество — это стезя разработки
Почему качество напрямую связывают с тестированием, ведь оно определяется тем, как сделан продукт, а не тем, как он протестирован?
— Просто так сложилось.
За качество отвечает вся команда, и в большей степени разработчики, именно они обязаны быть уверены в том, что новая фича работает. Качества можно добиться двумя способами — технологическим и процессным, в том числе тестированием. Однако важно понимать, что на него нельзя перекладывать всю ответственность.
Устойчивость к изменениям
В долго живущих продуктах, наряду с текущим качеством, важно качество системы и её устойчивость к изменениям, которые всегда неизбежны, ведь для того, чтобы система жила и развивалась, нужны частые изменения.
Никому же не нравятся частые изменения, верно? Их воспринимают как что-то враждебное и исключительное. Как же сделать из них что-то обыденное и рутинное? Очень просто! Необходимо быть уверенным, что изменения ничего не сломают.
Поверьте, с вашей системой явно что-то не так, если в голове периодически появляется мысль «работает — не трогай» или если разработчики не выкидывают уже написанный код.
Кодовая база — это не то, что можно сдать и забыть. Это среда, в которой мы живём, и нужно сделать её удобной для постоянной работы. Изменение, добавление или удаление кода не должно вызывать страх.
Что делать, если нет детальных требований?
Если нет детальных требований, не нужно бежать к заказчику и спрашивать в каком месте должна быть кнопка, однако это не значит, что она может быть в любом месте.
Кроме требований, указанных в ТЗ, не стоит забывать о собственном опыте и чувстве прекрасного. Именно эти навыки нужно постоянно развивать и держать на должном уровне и именно этим навыкам стоит следовать при принятии решений о расположении упомянутой кнопки и любых других.
Отсутствие детальных требований — это не проблема, а возможность сделать максимально хорошо, гибко управляя всем процессом с учетом доступного времени и бюджета, фокусируясь на важном, отбрасывая вторичное.
Конечно же важно понимать, что делается и зачем, однако детальные требования не являются обязательными.
Баги избежны, но не все
Исходя из нашего опыта, многие прикрывают низкое качество разработки словами «баги всё равно неизбежны». Да, баги действительно неизбежны, однако это не означает, что допустимо любое количество багов.
Баги — это нормально, если они быстро чинятся и критические баги, ломающие основные сценарии, возникают крайне редко или не возникают вообще(имхо).
Если каждая задача, отправленная на тестирование, возвращается или при починке одного бага всплывает три новых, значит с качеством что-то не так.
Баги есть и будут всегда
Мы всегда стараемся изменить восприятие заказчиков к багам, подойдя к этому вопросу немного с другой стороны. Количество багов зависит не только от кода, но и от того, что считать багом. В любом ПО, вне зависимости от его качества, можно найти баг, но он не всегда является таковым. Временами его исправление — это просто генерация лишней работы.
Нет, мы не предлагаем игнорировать баги, однако нужно понимать, что важно для проекта, а что нет. Периодически тестировщики закапываются в деталях, тратя на них слишком много времени, которого не остается на проверку сути и следованию общей цели. Лучше проверить основной пользовательский сценарий и сфокусироваться на общей картине качества, чем весь день сверять вёрстку с макетом и возвращать каждую задачу на доработку из-за незначительных мелочей.
Также не следует тестировать и проверять компетентность исполнителя. Если вы проверяете работу одного разработчика больше, чем любого другого только потому, что сомневаетесь в его компетентности, то проблема не в багах, а в доверии или соответствии уровня разработчика сложности задачи. Нужно доверять людям.
Ещё не имеет никакого смысла тестирование дизайн-макетов и написанных требований. Без реализации они не несут никакой ценности пользователям. Проводить ревью, обсуждать и совместно проектировать макеты и требования можно и нужно, однако не стоит тестировать их формально.
Протестировать всё в нашем мире было бы классно конечно, но здесь есть более важные вещи.
А что тестировать?
Главная задача тестировщика — сделать так, чтобы багов было как можно меньше. Т.е. чем меньше багов найдено, тем лучше.
Тестировщик — это нулевой пользователь системы, который отлично знает продукт и снаружи, и внутри. Тестировщик должен обеспечивать корректный UX, а не проверять задачи разработчиков, т.к. тестирование эффективно, когда оно приносит дополнительную ценность, а не компенсирует недостатки разработки, ведь уровень качества задаётся именно на этапе разработки. Когда тестировщик помогает разработчикам закрывать граничные кейсы и писать тесты, повышая тем самым качество разработки и обеспечивая целесообразный уровень покрытия, только тогда получаются действительно «крутые» продукты.
Если вы тратите усилия на компенсацию разработки тестированием, вы лишаете себя возможности направить эти усилия на развитие разработки и, как следствие, качества продукта.
Источник статьи; https://habr.com/ru/post/563146/