Comments 16
Существует такая вещь, как исчерпывающее тестирование. Берёте agda/idris да и доказываете корректность кода на всём множестве значений.
Значений чего?
Всех функций в коде.
Конкретно с idris я даже близко не работал, а вот https://github.com/viperproject/prusti-dev позволяет доказывать свойства кода.
Спасибо! Статья вполне логичная. Но понятно, что её легко обобщить до простой мысли о контрпродуктивности поиска виноватых, а не причин. Что слова "человеческий фактор" не более чем способ снять с себя ответственность и ничего не делать. В любой ситуации вплоть до крушения самолетов. Но немного обидно за разработчиков, так как они в любом случае, как правило чувствуют свою ответственность за баги, самым естественным образом, будучи авторами кода.
Ошибки непреднамеренно создаются разработчиками
Это тоже такая же ошибочная фраза. Правильнее сказать, что ошибки появляются в процессе разработки. Причем надо помнить, что разработка начинается со сбора требований, и на этом этапе так же могут закрасться ошибки как и на этапе непосредственной реализации.
А вообще описаная проблема встречается там где есть выделеная роль тестировщика. Или еще чего лучше, за эту роль отдельно платит заказчик. Заказчик, разумеется спрашивает себя «за что я плачу деньги?». И единственное, что тестировщик может предоставить "в свое оправдание" это список найденых им ошибок до релиза. В случае с автоматизацией регрессионного тестирования - количество регрессионных случаев.
В качестве метрики можно еще смотреть на соотношение исправленных багов из тестирования к общему количеству найденых багов в тестировании. Если эта цифра меньше 100%, значит заказчик имеет не полный приоритет по закрытию найденых в тестировании багов.
Кстати формулировка «Почему мы не нашли эту ошибку?» тоже сильно отдает поиском виноватых. Правильнее было бы спрашивать: «Что мы должны были сделать, чтобы найти эту ошибку?» Или «Что нам нужно сделать, чтобы увеличить вероятность обнаружения подобных ошибок в будущем».
Не лишним было бы воспользоваться методом пяти почему. Правда я за 8 лет работы в трех проектах и шести командах ни разу не видел, чтобы кто-то проводил причинный анализ. Все ретроспективы делаются "в стол". Хотя все методы обеспечения качества давно успешно придумали до нас и доказали их действенность на практике. Мы похоже просто нифига не пользуемся этими знаниями.
В промышлености тоже есть "контроль качества". И там тоже проходили через етап "отлов брака", но давно. (можно погуглить "six-sigma").
Для прома, "контроль качества" означает, что при определенном уровне отклонения параметров останавливают конвеер и ищют причину. Так как "отлов брака" дорого обходится.
Что получается, IT все еще в основном "ловит брак"?
>«Готовы ли мы к продакшену?» и «Вы (QA) одобряете релиз?»
Да и да. Тесты пройдены, все фичи работают, шоустопперов не обнаружено.
Нет и нет. Есть вот такой список критичных багов, и вот такие фичи ещё не протестированы.
QA не гарантирует полное отсутствие неизвестных багов. QA гарантирует что софт пригоден к использованию.
Почему мы не нашли - варианта в целом два:
Забыли это протестировать
Сознательно решили что это тестировать не будем, из экономии ресурсов/времени.
Тестирование констатирует текущее состояние продукта. Всё! Без «да» и «нет».
Решение релизить остается на менеджерах.
Тестирование (не QA) не гарантирует отсутствие багов. QA не гарантирует, что софт пригоден к использованию, это система практик, направленных на производство качественного ПО. ПО без багов не значит, что ПО делает, что надо, даже если оно это «не то, что надо» делает хорошо.
Вы же понимаете разницу между тестированием и QA? Зачем вы мешаете всё в кучу здесь?
Вариантов сильно больше. Это как минимум могут быть еще и неправильные требования, неправильная интерпретация требований при инплементации, несоблюдение процесса производства, проёбы планирования разработки и тестирования, благодаря которым в последний момент мёржат фичи в конце регрессионного тестирования и т.д.
В стартапе «забыли протестировать» и «решили не тестировать из экономии ресурсов» еще могут быть, в более или менее стабильных компаниях такого не может быть, там другие причины. Производство ПО не сводится к написанию кода и тестированию.
Вот именно, QA Managerы и констатируют:
>Да и да. Тесты пройдены, все фичи работают, шоустопперов не обнаружено.
>Нет и нет. Есть вот такой список критичных багов, и вот такие фичи ещё не протестированы.
А более высокие менеджеры не будут читать весь багтрекер, им нужен небольшой набор параметров. Если у кого-то фобия брать на себя ответственность, можно конечно не говорить "да-нет" (а ещё лучше в срочный отпуск свалить перед проблемным релизом, свалив рискованное решение на плечи исполняющих обязанности замов) и дать чуть (но именно чуть) больше информации.
А после высокие менеджеры обычно и принимают решения уровня "а и пофиг на эти ваши баги, у нас дедлайн, объявим релиз, и дотестируем на пользователях"
>Вариантов сильно больше.
Вы просто подробнее расписали два моих глобальных подмножества.
>в более или менее стабильных компаниях такого не может быть
В крупных компаниях конечно будет тонна словоблудия про "другие причины", чтобы не дай бог не взять лишнюю ответственность и не подставиться. Но фундаментально (и в приватном общении) всё это сводится к двум озвученным - не учли (по любым причинам) такой вариант, или не нашли (начальство не одобрило выделение) ресурсов на его проверку.
Более высокие менеджеры — это кто? Релиз менеджер?
Да, при наличии дэдлайнов может быть принято решение релизить с багами, для этого делают оценку рисков по результатам тестирования. Мало людей в своём уме просто говорят «пофиг на баги».
Вот это вот, — «чтобы не дай бог не взять лишнюю ответственность и не подставиться», — это махровый совок, который в современных компаниях на самом деле «неважно, кто накосячил, это общая проблема, давайте подумаем, как сделать, чтобы в следующий раз такого не было». Выяснение причин не происходит для того, чтобы найти козла отпущения, оно происходит для предотвращения подобной ситуации в будущем. Если баг попал в продакшен, это значит, что облажались все.
Почему мы не нашли — варианта в целом два:
1. Забыли это протестировать
2. Сознательно решили что это тестировать не будем, из экономии ресурсов/времени.
В какое место здесь укладывается отсутствие требований на определённый пользовательский сценарий, если вы четко написали «забыли это ПРОТЕСТИРОВАТЬ» и «ТЕСТИРОВАТЬ не будем»? Я не вижу тут глобальных подмножеств, это явно про непосредственное тестирование, которое совсем не обязательно являтся вариантом, о чем я выше и написал. А «протестировали неправильно» в какой из двух пунктов? Вам, наверное, стоит перефразировать как-то. Тем более, что в такой формулировке оба пункта решаются планированием тестирования.
Совок это универсальное объяснение, которое ничего не объясняет. Если вам нравится этот термин - пожалуйста - многие, очень многие "современные" компании скатываются в махровый совок. Тут роль скорее играет размер компании, чем год на календаре.
Идеал вы верно описали, мы все вместе, не щадя живота и не обвиняя товарищей, ищем причины, устраняем и бодро шагаем в светлое будущее. А на практике выходит так что важнее свою попу прикрыть
Забыли составить требование, составили требование неправильно, криво написали сценарий по требованию - это всё тоже "забыли". Требования не с марса прилетают, за них тот же самый QA в ответе. Не надо тестирование сводить до кнопкодавства низкоинтеллектуальными исполнителями по спущенным с небес сценариям.
Эй, QA! Почему вы не нашли этот баг?