По каким критериям можно оценить качество приложения
ГОСТ Р ИСО/МЭК 9126-93
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ
Характеристики качества и руководства по их применению
Information technology. Software product evaluation. Quality characteristics and guidelines for their use
Дата введения 1994-07-01
Предисловие
1 ПОДГОТОВЛЕН И ВНЕСЕН Техническим комитетом по стандартизации (TK 22) "Информационная технология"
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28 декабря 1993 г. N 267
3 Стандарт подготовлен на основе применения аутентичного текста международного стандарта ИСО/МЭК 9126-91* "Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению"
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
3 ВВЕДЕН ВПЕРВЫЕ
4 ПЕРЕИЗДАНИЕ. Ноябрь 2004 г.
1 Область применения
Настоящий стандарт определяет шесть характеристик, которые с минимальным дублированием описывают качество программного обеспечения. Данные характеристики образуют основу для дальнейшего уточнения и описания качества программного обеспечения. Руководства описывают использование характеристик качества для оценки качества программного обеспечения.
Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402.
Примечание - Предложения по определению комплексных показателей приведены в приложении А.
Определения характеристик и соответствующая модель процесса оценки качества, приведенные в настоящем стандарте, применимы тогда, когда определены требования для программной продукции и оценивается ее качество в процессе жизненного цикла.
Эти характеристики могут применяться к любому виду программного обеспечения, включая программы ЭВМ и данные, входящие в программно-технические средства (встроенные программы).
Настоящий стандарт предназначен для характеристик, связанных с приобретением, разработкой, эксплуатацией, поддержкой, сопровождением или проверкой программного обеспечения.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ИСО/МЭК 2382-20-90 Информационная технология. Словарь. Часть 20. Разработка системы
ИСО 8402-86 Качество. Словарь
Примечание - До прямого применения данных международных стандартов в качестве Государственных стандартов Российской Федерации они могут быть получены по запросам из ВНИИКИ Госстандарта России.
3 Определения
В настоящем стандарте применяются следующие термины.
3.1 оценка (assessment): Действие по применению конкретного задокументированного критерия оценки к конкретному программному модулю, пакету или продукции с целью обусловленной приемки или выпуска программного модуля, пакета или продукции.
3.2 признаки (показатели) (features): Признаки, определяющие свойства программной продукции, которые могут быть отнесены к характеристикам качества.
Примечание - Примеры признаков включают длину маршрута, модульность, структуру программы и комментарии.
3.3 программно-аппаратные средства (firmware): Технические средства, содержащие компьютерную программу и данные, которые не могут изменяться средствами пользователя. Компьютерная программа и данные, входящие в программно-аппаратные средства, классифицируются как программное обеспечение; схемы, содержащие компьютерную программу и данные, классифицируются как технические средства.
3.4 уровень качества функционирования (level of performance): Степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.
3.5 измерение (measurement): Действие по применению показателя качества программного обеспечения к конкретной программной продукции.
3.6 качество (quality): Весь объем признаков и характеристик продукции или услуги, который относится к их способности удовлетворять установленным или предполагаемым потребностям (ИСО 8402).
Примечание - В сфере контракта потребности определены, тогда как в других сферах предполагаемые потребности должны быть установлены и определены (ИСО 8402, примечание 1).
3.7 ранжирование (рейтинг) (rating): Действие по отнесению измеренного значения к соответствующему уровню ранжирования. Используется для определения уровня ранжирования программного обеспечения по конкретной характеристике качества.
3.8 уровень ранжирования (rating level): Диапазон значений в масштабе, позволяющем классифицировать (ранжировать) программное обеспечение в соответствии с установленными или предполагаемыми потребностями. Соответствующие уровни ранжирования могут быть связаны с различными представлениями о качестве, то есть для пользователей, руководителей или разработчиков. Данные уровни называются уровнями ранжирования.
Примечание - Данные уровни ранжирования отличны от "классов", определенных ИСО 8402.
3.9 программное обеспечение (software): Программы, процедуры, правила и любая соответствующая документация, относящиеся к работе вычислительной системы.
3.10 программная продукция (softwarе product): Программный объект, предназначенный для поставки пользователю.
3.11 качество программного обеспечения (software quality): Весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.
3.12 критерии оценки качества программного обеспечения (software quality assessment criteria): Набор определенных и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретной программной продукции. Качество представляется набором установленных уровней, связанных с программной продукцией.
3.13 характеристики качества программного обеспечения (software quality characteristics): Набор свойств (атрибутов) программной продукции, по которым все качество описывается и оценивается. Характеристики качества программного обеспечения могут быть уточнены на множестве уровней комплексных показателей (подхарактеристик).
3.14 метрика качества программного обеспечения (software quality metric): Количественный масштаб и метод, которые могут быть использованы для определения значения признака, принятого для конкретной программной продукции.
4. Характеристики качества программного обеспечения
Качество программного обеспечения может быть оценено следующими характеристиками.
4.1 Функциональные возможности (Functionality)
Набор атрибутов, относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности.
1 Данный набор атрибутов характеризует то, что программное обеспечение выполняет для удовлетворения потребностей, тогда как другие наборы, главным образом, характеризуют, когда и как это выполняется.
2 В данной характеристике для установленных и предполагаемых потребностей учитывают примечание к определению качества (см. 3.6).
4.2 Надежность (Reliability)
Набор атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.
1 Износ или старение программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок в требованиях, проекте и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ.
2 В определении ИСО 8402 "надежность - способность элемента выполнять требуемую функцию". В настоящем стандарте функциональная возможность является только одной из характеристик качества программного обеспечения. Поэтому определение надежности расширено до "сохранения своего уровня качества функционирования" вместо "выполнения требуемой функции" (см. также 3.4).
4.3 Практичность (Usability)
Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей.
1 "Пользователи" могут интерпретироваться как большинство непосредственных пользователей интерактивного программного обеспечения. Круг пользователей может включать операторов, конечных пользователей и косвенных пользователей, на которых влияет данное программное обеспечение или которые зависят от его использования. Практичность должна рассматриваться во всем разнообразии условий эксплуатации пользователем, которые могут влиять на программное обеспечение, включая подготовку к использованию и оценку результатов.
2 Практичность, определенная в данном стандарте как конкретный набор атрибутов программной продукции, отличается от определения с точки зрения эргономики, где рассматриваются как составные части практичности другие характеристики, такие как эффективность и неэффективность.
4.4 Эффективность (Efficiences)
Набор атрибутов, относящихся к соотношению между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
Примечание - Ресурсы могут включать другие программные продукты, технические средства, материалы (например, бумага для печати, гибкие диски) и услуги эксплуатирующего, сопровождающего или обслуживающего персонала.
4.5 Сопровождаемость (Maintainability)
Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).
Примечание - Изменение может включать исправления, усовершенствования или адаптацию программного обеспечения к изменениям в окружающей обстановке, требованиях и условиях функционирования.
4.6 Мобильность (Portability)
Набор атрибутов, относящихся к способности программного обеспечения быть перенесенным из одного окружения в другое.
Примечание - Окружающая обстановка может включать организационное, техническое или программное окружение.
5 Руководство по применению характеристик качества
5.1 Применяемость
Настоящий стандарт применяется для установления требований к качеству программного обеспечения и оценивания (измерения, ранжирования и оценки) программных продуктов, включая:
- определение требований к качеству программной продукции;
- оценивание технических требований к программному обеспечению при контроле за тем, чтобы требования качества были удовлетворены в процессе разработки;
- описание признаков и свойств (атрибутов) внедренного программного обеспечения (например, в руководствах пользователя);
- оценивание разработанного программного обеспечения перед его поставкой;
- оценивание программного обеспечения перед приемкой.
Существуют только несколько общепринятых метрик для характеристик, описанных в настоящем стандарте. Организации и группы по стандартизации могут устанавливать свои собственные модели процесса оценивания и методы формирования и проверки метрик, связанных с этими характеристиками, для охвата различных областей применения и стадии жизненного цикла. В тех случаях, когда соответствующие метрики отсутствуют и не могут быть разработаны, иногда пользуются словесными описаниями или " приблизительными методами".
При использовании шести характеристик качества в целях описания и оценивания также необходимо установить уровни ранжирования и критерии конкретно для данной организации или для данного применения, или для того и другого.
Должны быть установлены метрики, уровни ранжирования и критерии применительно к оценке качества, когда обмениваются результатами оценивания.
Хотя отсутствует общепринятая система классификации программного обеспечения, имеется несколько общепринятых классов программного обеспечения. Важность каждой характеристики качества меняется в зависимости от класса программного обеспечения. Например, надежность наиболее важна для программного обеспечения боевых критичных систем, эффективность наиболее важна для программного обеспечения критичных по времени систем реального времени, а практичность наиболее важна для программного обеспечения диалога конечного пользователя.
Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения.
5.2 Представления о качестве программного обеспечения
Имеется несколько представлений о качестве, некоторые из которых обсуждаются ниже.
По данным Statista, количество приложений на базе Android на конец третьего квартала 2020 года достигло 2,87 млн, на базе iOS — 1,96 млн. Но насколько качественны эти приложения? Евгений Лобанов, исполнительный директор AGIMA, собрал полезные подходы и инструменты, которые помогут владельцам продуктов и разработчикам ответить на этот вопрос.
Для начала определимся с тем, что такое качество. Согласно стандарту ISO, качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя. То есть качество можно измерить объективными и субъективными метриками.
Например, представим, что у вас есть приложение в ecommerce-сегменте, и его используют тысячи пользователей ежедневно. Может случится так, что приложение соответствует требованиям контролирующих органов, но его цвет и интерфейс не нравится конкретному пользователю. Или приложение сверстано по стандартам всемирной организации W3C и проходит валидацию, но пользователь путается в навигации по интерфейсу, поэтому тратит на решение своих задач втрое больше времени, чем мог бы.
Понятие «качество» учитывает также стоимость обслуживания/поддержки приложения, улучшения его функциональности и другие технические аспекты развития.
Контроль качества — это периодическая проверка материалов и процессов при изготовлении продукта. Инспекция качества — непрерывное наблюдение и проверка для полного соответствия регламентам и стандартам продукции. Контроль и инспекция качества помогают быстрее монетизировать продукт, поднять лояльность аудитории и сэкономить на стоимости развития.
Контроль качества можно разделить на две части — технический надзор и продуктовый (бизнес) надзор.
Оценка качества бывает субъективной (ее дает пользователь или эксперт) и объективной (стандарт качества, применяемого на проекте или в компании). Для того чтобы дать объективную оценку качества приложения, нужно описать процессы сбора метрик.
Мы отделяем процедуры инспекции качества приложений от инспекции качества самого продукта. Оба направления инспекции необходимо применять при разработке любого проекта.
Инструментами технического надзора могут выступать чек-листы, код-ревью, юнит-тесты и многое другое. Инструменты бизнес-надзора можно разделить на количественные (например, построение конверсионных воронок по целевым действиям пользователя) и качественные (например, качественные исследования: глубинные интервью, окулография (eye tracking), качественные опросы и т.д.).
Инспекция качества — это не только тестирование
Чтобы исключить ошибки при создании ИТ-решений, разработчики сервисов проводят инспекцию качества. Она включает в себя функциональное, регрессионное, нагрузочное тестирование, а также тестирование на уязвимости.
Функциональное тестирование должно быть позадачным, то есть каждая функциональность (например, авторизация в личном кабинете или восстановления пароля) должна тестироваться отдельно.
Для каждой сборки приложения, которая готовится к выпуску в промышленную среду, нужно проводить регрессионное тестирование.
Но есть и неочевидные нюансы процедуры надзора и инспекции. Процедура технической инспекции качества веб- или мобильного приложения должна включать:
Чек-лист для каждого процесса на проекте - требование к паспорту проекта, формат документирования, требования к формату проведения спринтов и ретроспектив или же требования к формату обработки change request’ов и т. д..
Чек-лист для каждого артефакта на проекте - требования к вёрстке, стандарты кодирования, гайдлайны для разработки дизайна и т. д..
1. pagespeed или аналоги (желательно минимум два инструмента);
2. нагрузочное тестирование приложения;
3. статический анализ кода приложения;
4. pen-тестирование (проверка на уязвимости).
Метрику легко измерить показателем аптайма, как физических серверов, так и функциональной бесперебойности по определенной сетке автотестов в продуктивной среде.
- Измерение довольства пользователя на уровне приложения (Важно! не всего продукта или сервиса, об этом расскажем дальше). Например, оценки мобильного приложения в сторах, замеры количества фидбеков по формам обратной связи на веб-приложениях и т. д.
- Обязательное наличие документации по приложению: архитектура, функциональные требования, ПМИ, документирование кода и т.п.
- Авторский надзор со стороны системной аналитики/архитектора по реализации той или иной функциональности + код-ревью. Метрикой может являться отклонение от квотируемого бюджета на поддержку и развитие системы.
По мере необходимости список можно дополнять инструментами и метриками. Например, инспекцией по полноте и срокам доставки в промышленную эксплуатацию тех или иных новых «фич».
Инспекция качества продукта должна включать:
Измерение продуктовых метрик (конверсия пользователей по шагам воронки к целевому действию, сокращение стоимости того или иного процесса и т. д.).
Измерение того, насколько пользователь доволен продуктом и сервисом. Например, с помощью индекса потребительской лояльности (NPS) и индекса удовлетворенности клиентов (CSI).
Показатели веб-аналитики на всех шагах воронки (возможно, дашборды).
CAC (Customer Acquisition Cost) — ваши затраты на привлечение пользователя.
Метрики продуктовой инспекции тоже можно дополнить. Например, хорошая практика при использовании продуктовой инспекции качества — сделать релиз новой функциональности на маленькую часть аудитории и провести сплит-тест.
Обеспечение качества — часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены.
На первых этапах планирования разработки диджитал-продукта нужно определиться с ролями, которые будут выполнять надзор и нести ответственность за свою часть менеджмента качества:
- За процедуры технической инспекции выпускаемого продукта часто отвечает тимлид или архитектор).
- За процедуры продуктовой инспекции сервиса — владелец продукта или продюсер).
За глобальный контроль всех процессов по принятым стандартам —независимый специалист надзора QA-службы или руководитель проекта.
Если продукт разрабатывается инхаус, то одного уровня контроля на каждом этапе достаточно.
На что обратить внимание владельцу продукта или бизнеса при работе с подрядчиками?
Самая критичная ошибка компании — не вовлекаться в процесс разработки продукта. Такой подход приводит к срывам запуска из-за неудовлетворительных показателей качества.
Если компания делегирует разработку подрядчикам, лучше продублировать слои инспекции качества: убедиться, что все три типа надзора закрыты со стороны подрядчика конкретными специалистами, а также назначить и определить зоны ответственности по менеджменту качества продукта внутри.
При работе с подрядчиками используйте дополнительные меры контроля качества в своей команде:
Требуйте от подрядчиков выполнения жестких фиксированных стандартов качества. Кроме того, закрепите их внутри своей компании.
Формализуйте критерии приёмки (конкретные метрики успеха, конкретные тест-кейсы и т. д.), включая ограничения на итерации приёмки, входящие в оценку и передайте подряду.
Как правильно выстроить процесс контроля и инспекции качества в функциональных и продуктовых командах?
Настройка процесса и сам процесс инспекции и контроля качества не зависят от типа команды, которая занимается разработкой продукта. В первую очередь, они зависят от бизнес-модели продукта и методологии управления проектом.
Однако тип команды влияет на некоторые нюансы в сути процесса. Например, есть более пяти типов продуктовых команд в зависимости от цели компании: одни ориентируются на пользовательские метрики, другие на дизайн (основное внимание уделяется wow-составляющей продукта), третьи на функции и т.д.
Работа функциональной команды должна содержать следующие этапы:
Предпроектное исследование (на выходе: ограничения и вижн-системы).
Работа продуктовой команды включает те же этапы. При этом учитывается кроссфункциональность специалистов, количественные и качественные замеры необходимых метрик в зависимости от того, на что на что ориентирована продуктовая команда.
Чем сложнее процесс инспекции и контроля качества, тем дороже его внедрить в процессы разработки продукта.
Стоимость технической инспекции составляет от 30 до 50% стоимости всей разработки.
При внедрении продуктовой инспекции рекомендуем измерять эффективность всех изменений и своевременно корректировать свои затраты. Стоимость такой инспекции зависит от типа продукта и многих других факторов. Мы тратим на инспекцию качества на постоянно растущих проектах примерно 750 тыс. руб. в месяц без учёта стоимости времени команды проекта. При этом статистически отток денег за 2018 и 2019 год составил 340 млн руб. После внедрения процедур инспекции качества значение оттока относительно всего годового оборота уменьшилось на 12%.
Процедуры контроля качества, техническая и продуктовая инспекции гарантируют успешность любого digital-продукта. Замеряйте стоимость инспекции, эффективность от введенных изменений и выпускайте качественные digital-продукты.
От качества мобильных приложений зависит удобство его использования для пользователей и популярность среди целевой аудитории приложения, рейтинг, количество установок, отзывы.
Мобильное приложение должно быть удобным целевой аудитории и выполнять ту цель, которая была поставлена при создании. Помимо этих основных аспектов мобильное приложение должно быть качественно сделано и быть не хуже приложений конкурентов, а возможно даже лучше. Оценку качества лучше выполнять по чётко сформулированным критериям.
1. Графический дизайн
Требования к дизайну мобильных приложений постоянно растут. Существуют популярные сейчас направления в дизайне и при разработке это надо учитывать, но при этом восприятие пользователем приложения не должно ухудшаться. Дизайн должен соответствовать целевой аудитории приложения.
Искажения в графическом дизайне могут возникнуть при использовании мобильного приложения на каких-то моделях смартфонов (особенно на устаревших моделях), поэтому постарайтесь протестировать приложение на этих устройствах.
2. Удобство для пользователей
Мобильное приложение может иметь множество экранов связанных между собой. Очень важно правильно организовать переходы между экранами, чтобы пользователю была интуитивна понятна логика работы мобильного приложения. На удобство использования сказывается удачное размещение активных элементов управления, например таких как кнопки или иконки, при нажатии на которые происходит переход на соответствующие экраны. Понятно ли назначение кнопок и смысл иконок?
Нужно обратить внимание на процесс ввода текста и цифр в поля на экранах. Понятно ли работает выход из режима ввода текста?
Удобство использования мобильного приложения может иметь существенные отличия для Android и iOS-устройств, поэтому для точного оценки этого критерия необходимо тестирование мобильного приложения на обоих платформах.
3. Функциональность
Количество и полнота функционала мобильного приложения. Проверяйте функционал по списку функций технического задания. Не возникает ли у пользователя необходимости в дополнительном функционале или в добавлении дополнительных возможностей в уже существующих функциях?
При оценке функциональности прежде всего надо обратить внимание на отсутствие сбоев в работе. Не создает ли реализация конкретной функции мобильного приложения ощущение у пользователя, что в данном месте приложение работает с ошибкой?
Могут быть нюансы в работе функций мобильного приложения при использовании телефонов разных моделей, поэтому проведите тестирование на как можно большем количестве различных моделей телефонов.
4. Степень агрессивности к пользователю
Агрессивность приложения может выражаться в избыточных требованиях к пользователю, которые могут излишне напрягать или заставлять пользователя делать действия, которые не имеют существенного значения. Например, избыточное количество полей для ввода, не обоснованное обязательность ввода значений в поля на экране.
Приложение может быть агрессивно, когда для того, чтобы сделать какое-либо действие пользователь должен открыть слишком много подряд идущих экранов или по используемой цветовой гамме.
4. Ценность
Для кого и для чего создано мобильное приложение и какую ценность оно несёт пользователю? Смогло ли мобильное приложение выполнить цель, поставленную перед его созданием?
4. Производительность и стабильность работы
Оцените скорость работы мобильного приложения. Не слишком ли долго загружаются экраны? Необходимо посмотреть, как будет работать приложение через день, неделю не возникнет ли проблем со стабильностью его работы?
Тестирование мобильного приложения
К качеству программного обеспечения (ПО) предъявляются высокие требования. Критерии качества, касающиеся надежности и эффективности, можно выполнить лишь при «серьезном» тестировании продукта (качественной верификации).
Качество ПО – продукт эффективного тестирования
Даже у самого лучшего программиста, по статистике, в тысяче строк программы может встречаться хоть одна ошибка, поиск и устранение которой потребует много временных, интеллектуальных и вычислительных ресурсов. Здесь есть над чем думать тестировщику (на программистском жаргоне – «тестеру»), специалисту по разработке тестов и тестированию ПО.
Система тестов должна быть минимальной, но достаточной для обнаружения всех ошибок или, как говорят, «всех, без последнего»: в любом сложном ПО возможна такая скрытая ошибка, обнаруживаемая лишь при эксплуатации.
Тестируемые характеристики ПО
Стандартом и опытом разработчиков определены следующие тестируемые характеристики ПО:
- функциональность;
- производительность (обычно пиковая);
- системность (совместимость в системе);
- надежность (отказостойкость, самовосстанавливаемость);
- защищенность (управление вероятными уязвимостями, отказами);
- дружественность (простота, легкость, комфортность при работе);
- модифицируемость (тестируемость, документированность);
- адаптивность (переносимость, кросс-платформенность).
Характеристики везде различные, с разными критериями оценивания. Например, мерой отказоустойчивости может быть вероятность безотказной работы, интенсивность отказов замеряется по наблюдениям, и др. Можно классифицировать критерии качества по отношению к разработчику, заказчику или пользователю: внутренние (относящиеся к логике программного кода), внешние (восстанавливаемость при сбоях) и интерфейсные (дружественность, документированность).
Задачи тестировщика
Специалист, ответственный за тестирование, в процессе тестовых испытаний ПО выявляет ошибки проектировщиков и программистов. Он выполняет ревизию логических связей всего комплекса. Но не кода – напрямую к коду у этого специалиста часто (и справедливо) нет доступа.
Но у него есть расширенные, больше чем у рядового пользователя, полномочия доступа. «Тестер» как пользователь проверяет программу, например, пошаговым исполнением, анализом контрольных узлов и др., применяя свой опыт и искусство составления тестов. От него все ждут тщательности, точности, скрупулезности.
Тестирование проводят автоматизированно или вручную, но всегда на основе оптимизированного («минимально-достаточного») набора тест-кейсов.
Обязанности тестировщика
- владеть тест-инструментарием;
- учитывать функциональность приложения;
- систематизировать и документировать процесс тестирования;
- убедительно (как для заказчика, так и для разработчика) объяснять причину сбоя, превентивные меры и др.
Компетенции тестировщика
Обязанностями продиктованы профессиональные качества «тестера»:
- знание (понимание) на уровне прикладного (хотя бы) программирования ряда языков (ряда языков C++, Java, Python и др.);
- применение баг-трекинга (систем отслеживания ошибок);
- владение инструментарием (программами) тестирования;
- опыт описания проведенного тестирования.
Важно знать английский язык (на уровне Intermediate+ и выше). Высоко востребованы умения взаимодействовать с другими участниками процесса создания ПО, видеть всё и сразу в программе, работать в команде, абстрагироваться от мелочей.
Тестирование – задача не менее сложная и важная, чем написание кода, и требующая внимания на всем жизненном цикле ПО.
Читайте также: