Прибыль:
- Возможность различать, где искусственный интеллект экономит реальное время в процессе контроля качества, а где решения по качеству, такие как «готовность к публикации», оставляются на усмотрение людей, в зависимости от уровня риска задачи.
- Способность распознавать риск ложных проходов и внедрять дисциплину проверки, которая проверяет каждый тест ИИ путем преднамеренного взлома кода.
- Способность защищать тестовые данные, личные данные и ключи, а также приобретать привычку выполнять тестирование безопасности только в рамках авторизации и в защитных целях.
Рассмотрим ночь релиза. Были проведены сотни тестов, все они получили зеленый свет, команда успокоилась, и программное обеспечение было запущено. На следующее утро клиент сообщил, что экран оплаты сломался. Тесты были зелеными, но он не увидел ошибки. Это самый коварный кошмар профессии специалиста по обеспечению качества (QA), то есть дисциплины, которая систематически гарантирует, что программное обеспечение имеет желаемое качество: тест, который светится зеленым, но на самом деле ничего не подтверждает. Когда искусственный интеллект (ИИ — программное обеспечение, которое извлекает закономерности из исторических данных и генерирует текст и код) входит в эту профессию, происходит как огромное ускорение, так и усиление именно этого кошмара. Первоначальный посыл этого модуля ясен: искусственный интеллект — это помощник по тестированию, генератор проектов и умножитель идей; Вы — тестер, который подписывает решение «готово ли это программное обеспечение к выпуску».
В этом первом разделе мы сосредоточимся на дисциплине, а не на инструменте. Вы узнаете, где ИИ экономит реальное время в процессе контроля качества, где это опасно, почему обманчивый зеленый так называемый «ложный проход» представляет собой самый большой риск, как проверять каждый результат и какие данные вы можете передать какому инструменту. Без закладки этого фундамента последующие подразделения останутся в воздухе.
Где ИИ может пригодиться в процессе тестирования?
Давайте разделим задания по тестированию на два больших кластера. Первый кластер: повторяющиеся, производственные, черновые работы. Составление тестового сценария на основе требования, составление списка точек останова, написание скелета кода автоматизации для экрана, преобразование сложного случая ошибки в аккуратный отчет об ошибках, обобщение сотен строк файлов журналов, извлечение схемы из ответа API. В этих задачах ИИ сокращает минуты до секунд и не устает.
Второй кластер: решения, результатом которых является качество, доверие и ответственность. Такие решения, как «может ли эта версия быть запущена в эксплуатацию», «является ли эта ошибка критичной или ее можно отложить», «достаточно ли это тестовое покрытие», «охватывает ли этот сценарий реальный риск пользователя» и т. д. требуют контекста, знания продукта и ответственности. Здесь ИИ генерирует варианты, черновики — а вы решаете «пройти/не пройти» и «пройти/не пройти».
Давайте проясним разницу в одном предложении: ИИ силен в том, «какие ситуации можно протестировать и как написать код, который это проверяет»; Решение за вами, когда дело доходит до вопроса «Действительно ли это программное обеспечение работает и кто за это ручается?»
Совет: прежде чем передать задание ИИ, спросите: «Что произойдет, если этот вывод неправильный, и я не замечу?» Если ответ «Я потеряю несколько минут», делегируйте легко. Если ответ — «неисправное программное обеспечение вводится в эксплуатацию», позвольте ИИ создать черновик, а вы примете решение и проверите его.
Неверный проход: риск номер один, связанный с искусственным интеллектом в обеспечении качества
Когда тест горит зеленым, это может означать две вещи: либо программное обеспечение действительно работает правильно, либо оно не видит ошибки, потому что тест был написан неправильно. Второй называется ложным прохождением — тест говорит «пройден», но на самом деле ничего не подтверждает. Этот риск значительно возрастает в тестах, созданных с помощью ИИ, поскольку ИИ очень успешно пишет беглые, гладкие, но пустые тесты.
Три наиболее распространенные формы псевдопрохода: (1) Тестирование без утверждений — код выполняется, не содержит утверждений и всегда проходит успешно. (2) Тест самопроверки — ожидаемое значение теста рассчитывается на основе выходных данных тестируемого кода; То есть, что бы ни выдал код, тест воспринимает как «правильный». (3) Тест, который проверяет неправильную вещь — утверждение существует, но проверяет что-то тривиальное (например, «ответ не равен нулю»), а не фактическое бизнес-правило.
Внимание: зеленая тестовая панель не является доказательством качества; В лучшем случае там говорится: «Написанные нами элементы управления сейчас не нарушены». Не утешайтесь, увидев «пройденный» тест, который производит ИИ — реальный вопрос заключается в следующем: станет ли этот тест красным, если я намеренно нарушу код? Если он не вращается, то тест — украшение.
Золотое правило, которое повторяется на протяжении всего этого модуля: проверяйте каждый тест ИИ, намеренно взламывая код. Если тест по-прежнему зеленый, этот тест не работает. (Мы углубим эту идею в виде мутационного тестирования в модуле 10.)
Дисциплина проверки: три шага
ИИ говорит уверенно; Это не значит, что это правда. Выработайте трехэтапный рефлекс, применимый к каждому результату:
- Привяжите это к требованию. Каждый тестовый пример и утверждение, которое производит ИИ, должны основываться на реальных требованиях или критериях приемки (условиях, которым работа должна соответствовать, чтобы считаться «выполненной»). «Какое правило подтверждает этот сценарий?» просить.
- Смотри красный. Запустите сгенерированный тест один раз, нарушив код. Если он не станет красным, тест недействителен. Это не подлежащий обсуждению шаг в тестировании ИИ.
- Пропустите его через контекстный фильтр. Соответствуют ли результаты тому, что вы знаете о поведении продукта, архитектуре и реальном потоке пользователей? Ваши знания предметной области — это последний фильтр.
Конфиденциальность и безопасность данных: что и куда?
Данные, с которыми вы работаете в тестовой среде, часто бывают конфиденциальными: реальные записи клиентов, копии производственных баз данных, ключи API, внутренние системные адреса, еще не анонсированные функции. Проведем простую классификацию: открытые данные (документированные, общедоступные) могут попасть в любое транспортное средство. Внутренние данные (фрагменты исходного кода, внутренняя документация) только для одобренных агентством инструментов. Конфиденциальные данные (реальные данные клиента, идентификационная информация, сведения об уязвимостях, ключи) поступают только в контрактные инструменты учреждения, данные которых не поступают в обучение модели, желательно в замаскированном виде.
В контексте тестирования безопасности существует дополнительное ограничение: все, что изучается в этом модуле, предназначено для защитных целей — для авторитетного тестирования безопасности вашего собственного продукта. Использование ИИ для проникновения в чужую систему без разрешения, использования реальных уязвимостей в качестве оружия или тестирования системы, на которую у вас нет полномочий, является одновременно неэтичным и преступным. Никакое оскорбительное тестирование не будет проводиться без разрешения (объема и разрешения).
Совет: используйте синтетические (искусственно созданные) тестовые данные вместо реальных данных о клиентах. Попросив ИИ «сгенерировать реалистичные, но полностью вымышленные тестовые данные», можно одновременно сохранить конфиденциальность и разнообразить крайние случаи.
три мини-кейса
Случай 1 — Экономия времени в нужном месте. Тестировщик команды Ekomerce потратил 6 часов вручную на создание сценария тестирования из 30-страничного документа с требованиями для каждого выпуска. Он передал документ (часть, не содержащая коммерческой тайны) YZ и попросил структурированный проект сценария; Время сократилось до 90 минут. Сэкономленное время он посвятил самостоятельной проверке добавления крайних случаев бизнес-правил, которые ИИ пропустил. ИИ убрал повторяющуюся работу, оставив решение человеку.
Случай 2 — Обнаружен фейковый пас. Разработчик поручил ИИ написать 12 модульных тестов для вычислительной функции; они все были зеленые. Тестер реализовал шаг «видеть красный»: намеренно менял знак сложения внутри функции на умножение. Только 3 из 12 тестов дали красный цвет. Остальные девять тестов не дали реального подтверждения; Там просто написано "ошибки не было". Было удалено 9 декоративных тестов и вместо них написано 5 реальных тестов.
Случай 3 — Возврат после нарушения конфиденциальности. Стажер вставил журнал ошибок, содержащий реальные электронные письма клиентов и последние четыре цифры карты из производственной базы данных, в общедоступный инструмент и сказал: «Объясните эту ошибку». Вмешался руководитель отдела контроля качества: это вышли из-под контроля персональные данные и было нарушено КВКК (Закон о защите персональных данных). Та же самая работа была проделана на одобренном учреждением автомобиле, скрывая личные зоны и оставляя только следы.
Четыре копируемых шаблона
1) Оценка пригодности к работе:
Ваша роль: старший руководитель отдела контроля качества. Я опишу вам работу по тестированию. Скажите мне (1) является ли эта работа работой по составлению/анализу, которую можно безопасно делегировать ИИ, или качественным решением, которое должен принять человек, (2) потенциальная цена неправильного результата, (3) проверка, которую я должен сделать перед делегированием. Работа: [вставьте задание здесь]
2) Псевдопропускной контроль:
Посмотрите тест ниже. Скажите мне: - Какое поведение подтверждает этот тест? (одно предложение) – Как я могу сломать тестируемый код, чтобы тест стал КРАСНЫМ? – Есть ли слабость, из-за которой этот тест может всегда проходить успешно (отсутствует утверждение, самопроверка, тривиальная проверка)? Тест: [вставьте тест здесь]
3) Контроль маскировки тестовых данных:
Журнал/данные, которые я вам предоставлю, могут содержать личные или конфиденциальные поля (электронная почта, имя, карта, ключ, внутренний адрес). Сначала перечислите поля, которые необходимо замаскировать; Я замаскирую его и отправлю еще раз. Не анализируйте все как есть.
4) Генерация синтетических тестовых данных:
Создайте 20 строк полностью вымышленных, реалистичных тестовых данных для [следующей структуры поля]. Не используйте данные реального человека/организации. Также включите крайние случаи: пустое пространство, слишком длинный текст, предельные значения, недопустимый формат.
Слабая подсказка / Сильная подсказка
Слабое: «Напишите тесты для этого кода».
Сильный: «Вычислите это. Напишите модульные тесты для функции скидки. Критерии приемки функции: скидка 10 % на сумму более 1 000 турецких лир, скидка 20 % на сумму более 5 000 турецких лир; отрицательная сумма должна вызывать ошибку. Укажите в строке комментария, какое правило вы проверяете для каждого теста. Проверьте предельные значения (999, 1000, 1001, 5000, 0, -1) отдельно. Используйте реальные утверждения, которые станут красными. если я сломаю код; пусто или не напишу тривиальное утверждение».
Мощная подсказка; Он предоставляет критерии приемки, предельные значения, ожидания проверки и явные инструкции по борьбе с подделкой. Слабая подсказка предлагает ИИ написать декоративный тест.
Распространенные ошибки
- Доверяясь зеленому. Думая, что прохождение теста является доказательством. Реальный вопрос: становится ли он красным, когда вы нарушаете код?
- Запрос на тестирование без объяснения причин. ИИ проводит общие, часто бесполезные тесты, не зная, что именно нужно проверить.
- Пропуск проверки. Сказать: «Это написал ИИ, возможно, это правда». Ответственность лежит на лице, использующем результат.
- Вставка реальных/конфиденциальных данных в инструмент. Работа с производственными данными, ключами или персональными данными.
- Несанкционированное тестирование безопасности. Попытка наступательного тестирования без возможности и разрешения.
- Использование ИИ для делегирования принятия решений. Задавая вопрос «Можно ли выпустить эту версию?» к ИИ и поставив ответ в подпись.
В итоге
ИИ — мощный помощник в процессе контроля качества, который ускоряет повторяющуюся и продуктивную работу; Но ответственность за качественное решение лежит на человеке. Риск номер один, связанный с ИИ в этой профессии, — это псевдопрохождение: зеленые тесты, которые выглядят аккуратно, но ничего не подтверждают. Проверяйте каждый тест ИИ, намеренно взламывая код; Если он не покраснел, то тест – украшение. Привяжите его к требованию, увидите красный цвет, пропустите через контекстный фильтр. Маскируйте конфиденциальные данные, выполняйте тестирование безопасности только в авторизованных и защитных целях.
Задача приложения
Возьмите 5 модульных тестов, созданных ИИ (или сгенерированных ИИ), из вашего собственного проекта. Для каждого из них: (1) запишите в одном предложении, какое поведение он проверяет, (2) намеренно сломайте и запустите тестируемый код и отметьте, сколько из них станет красным, (3) отметьте те, которые не становятся красными, как «тесты декора» и перепишите их с реальным утверждением. Поместите результат в таблицу: имя теста/правило, которое оно проверило/было ли оно нарушено при нарушении/действие.
контрольный список
- [ ] Прежде чем сдать работу, я задал вопрос «что я потеряю, если что-то пойдет не так?»
- [ ] Я тестировал каждый тест ИИ, взламывая код; Я заменил тот, который не покраснел, на настоящий тест.
- [ ] Я связал тестовые примеры с фактическими требованиями/критериями приемки.
- [ ] Я замаскировал конфиденциальные/реальные данные, не передавая их инструменту; По возможности я использовал синтетические данные.
- [ ] Я рассматривал тестирование безопасности только в рамках полномочий и в защитных целях.
- [ ] Решение о том, будет ли выпущена версия, я оставил себе, а не ИИ.