Comments 15
Почему ошибаются программисты?Потому, что они — люди.
зачем выносить отдельно в цитату тот же самый текст? Он от этого станет ценее?
зачем выносить отдельно в цитату тот же самый текст?
Господи, сколько воды По делу буквально пара абзацев.
Люди делают ошибки потому что им плевать на последствия, или этих послествий вообще не следует. В худшем случае, они не осознают последствий.
А кто эти люди: программисты или таксисты - дело десятое.
Задача QC — искать нетривиальные баги
Чем отличаются тривиальные и нетривиальные баги?
Приведите свои примеры, связанные непосредственно с конкретной разработкой. Примитивы которые вы приводили в начале текста, думаю никому не нужны.
Я со своей стороны тоже вот расскажу. Написал на php код, который генерирует динамические страницы. Но при попытке открыть их через браузер выходит ошибка. Оказалось, что файлам присваиваются (код работает в убунте) не те права.
Это по моему нетривиальная ошибка. То есть чтобы её найти, нужна компетенция в другой области.
Страничка не открывается — это тривиальная ошибка, которая должна быть замечена ещё на этапе отладки. В крайнем случае, на смок-тесте. Отсутствие 404 и 500 страницы — это тривиальные ошибки. Невыполнение основных сценариев — тривиальная ошибка.
Нетривиальная ошибка, это когда вы открываете ленту событий, подгружаете ещё два блока данных, вставляете комментарий со спецсимволом, и при загрузке четвёртого блока данных у вас вёрстка разъезжается. То есть сценарий воспроизведения сложный и неочевидный.
при передаче задачи на тестирование программист проводит демонстрацию работыМне кажется, плохая идея. Лучше, чтобы другой человек посмотрел незамыленным взглядом и дал обратную связь, насколько легко тут разобраться без инструкции. Бывает, что все люди начинают работы с кнопки А, и это кажется естественным, а программист расчитывал, что начинать надо с кнопки Б. Показывая «как правильно» пользоваться своей программой, он делает тестировщиков предвзятыми. Тестировщики начинают думать, что кнопка Б это правильно и другие варианты неестественны. То есть, мы сразу отбрасываем некоторый класс тестовых сценариев, показывая «как надо».
Здесь основной момент в том, что человек готовит демонстрацию, прогоняет сценарии для неё перед тем, как показать другим. Это организационный приём, чтобы убедиться, что человек при отладке выполнил основные сценарии, а не просто послал задачу на тестирование без смок-теста.
Можно показывать не QA, а менеджеру. Воспитательный эффект будет тот же.
В целом не так страшно. Задачи декомпозируются по пользовательским сценариям, поэтому получается не так уж много демонстраций. Плюс, мы предпочитаем поэтапную сдачу проектов. Каждый этап демонстрируется заказчику менеджером.
За счёт таких демонстраций и подготовки к ним, повышается качество и ускоряется разработка. Люди привыкают заканчивать свои задачи целиком, и не попадать в ситуации, когда проект закончен на 95%, а времени нужно на него потратить ещё столько же, сколько потратили.
Программистов скорее всего не учат тому чтобы доказать что код работает как надо и его решение правильно. Это трудно, но их должны были бы научить покрывать код тестами, хотя бы минимальными, вроде краевых условий, ввод не того типа данных, длинных последовательностей символов. И всё это выводить в файл или консоль, потом потратить время на проверку и вообще уметь напечатать класс тест в котором аргументами будут перечисленные выше тесты и сам класс приложения. Но эти же программисты такие же бездари как и тестировщики которые что-то там смогли усвоить и пройти собеседование и работать, но не хотят потратить время на эти долбанные юнит тесты. Хотя бы часик в день, я конечно не знаю сколько строк они добавляют за день работы, один раз напечатав такой класс тест избавит от неприятностей в будущем.
Почему ошибаются программисты? Часть 1/2