Регрессионное тестирование для каждого продукта проводится в своём направлении. В случае обнаружения критичного бага у пользователя должна быть возможность отката до предыдущей версии. Но если в результате такого отката данным будет нанесён урон больший, нежели неудобства новой версии, то считайте такую проблему не просто регрессией, но и фатальной.
Очередной пример вышеописанной регрессии предоставила компания ConquestSS сразу в двух продуктах ClearSQL ver#7.1 и SQLDetective ver#5. Когда в 2015 году для ClearDB персональные данные (пароль к БД) стали шифроваться, то моё замечание о невозможности восстановления паролей через возврат к предыдущей версии восприняли как негативный и нежелательный тест. Разработчик в новой версии добавил кодирование пароля, но не делал конвертацию старых данных. Тогда не было владельцев продукта, готовых обновиться до новой версии. На стороне пользователя потеря паролей не проявилась. Да, соглашусь с мнением, что пароль - это не те данные, которые стоит хранить даже в зашифрованном виде, но у разработчиков ConquestSS и к любым другим настройкам аналогичное отношение. Старые, привычные установки не конвертируются в новую версию, а затираются значениями по-умолчанию без предупреждения. О чём не раз жаловались юзеры. Алгоритм перевода на новые настройки давно известен (сохранить старые, добавить новые параметры, предупредить о новых возможностях и вариантах восстановления прежних), но в среде программистов ConquestSS им напрочь пренебрегают.
Поскольку ни в Online Help, ни в Release Notes ничего не сказано о том, что после апгрейда пропадут данные, то считаю своим долгом тестировщика предупредить текущих пользователей ClearSQL ver#7.0 и SQLDetective ver#4 о необходимости сохранить прямо сейчас ветки реестра "HKEY_CURRENT_USER\Software\ClearSQL\DB Connect" и "HKEY_CURRENT_USER\Software\SQLDetective\Splash\ConnectionHistory" соответственно продуктам или Preferences в файл. Это позволит вам вручную восстановить в предыдущей версии утерянные при апгрейде пароли. Напоминаю, что в ClearSQL ver#7.1 (and higher) и SQLDetective ver#5 пароли к БД, сохранённые в предыдущих версиях, обнуляются при первом же запуске без какой бы то ни было возможности восстановления.
О простоте кодирования паролей в ClearSQL ver#7.0 и SQLDetective ver#4 уже говорилось в статье "Telegram in application with DB connection". Команде разработки потребовалось полтора года после моего напоминания для перенесения алгоритма более серьёзного кодирования паролей из ClearDB ver#4 в ClearSQL ver#7.1 и в SQLDetective ver#5. Так что, перед обновлением до сегодняшних версий не поленитесь и сделайте себе памятку, ведь столь удобная галка "сохранить пароль" может сыграть с вами очень злую шутку - не восстановит значения в новой версии, и даже механическая память рук ничем не поможет.
А всем тестировщикам ПО рекомендую не только проводить тест на обратную совместимость, но и вести профилактическую работу по предотвращению багов. Вроде бы удобство - опция для сохранения и авто-восстановления данных, но не для всех значений она может поддерживать законы безопасности приложения. Ещё одним примером такой юзерской прихоти является отдельная возможность выгрузки в XML файл всех сохранённых на машине коннектов к базе. В своё время мне пришлось потратить немало усилий, чтобы из прикреплений к OSD сообщению удаляли эти записи, потому что они несут персональную информацию, зачастую бесполезную для техподдержки ConquestSS. Но полагаю, что тот же юзер, который предложил сохранять пароли, сам и предложил экспортировать коннекты. А ведь это первый путь к хакерству. Если пользователь меняет комп, то в Online Help есть подробная инструкция по переносу настроек. Насколько часто нужна фича экспорта-импорта всего списка коннектов и кому? Ответ очевиден - только тому, кому временно стал доступен чужой ПК. Да, через сохранение всех настроек (Preferences) в файл тоже быстро можно скопировать все коннекты, но при этом ещё много локальных параметров (ключ лицензии, опции анализатора) придётся корректировать после импорта. Так что, считаю фичу экспорта-импорта коннектов вредной, а не полезной. И рекомендую подобные им новшества пресекать на первоначальном этапе разработки. Тогда не придётся выдумывать "защиту от дурака" в виде излишних шифрований или подтверждений опасных шагов. А владельцы продуктов и особенно администраторы баз должны перестать использовать опцию сохранения паролей, дабы хоть малость усложнить нежелательным элементам доступ к данным. Хотя, подобрать пароль, зная имена схем и баз, можно довольно просто. О чём немало говорили и Pete Finnegan, и Александр Поляков.
Очередной пример вышеописанной регрессии предоставила компания ConquestSS сразу в двух продуктах ClearSQL ver#7.1 и SQLDetective ver#5. Когда в 2015 году для ClearDB персональные данные (пароль к БД) стали шифроваться, то моё замечание о невозможности восстановления паролей через возврат к предыдущей версии восприняли как негативный и нежелательный тест. Разработчик в новой версии добавил кодирование пароля, но не делал конвертацию старых данных. Тогда не было владельцев продукта, готовых обновиться до новой версии. На стороне пользователя потеря паролей не проявилась. Да, соглашусь с мнением, что пароль - это не те данные, которые стоит хранить даже в зашифрованном виде, но у разработчиков ConquestSS и к любым другим настройкам аналогичное отношение. Старые, привычные установки не конвертируются в новую версию, а затираются значениями по-умолчанию без предупреждения. О чём не раз жаловались юзеры. Алгоритм перевода на новые настройки давно известен (сохранить старые, добавить новые параметры, предупредить о новых возможностях и вариантах восстановления прежних), но в среде программистов ConquestSS им напрочь пренебрегают.
Поскольку ни в Online Help, ни в Release Notes ничего не сказано о том, что после апгрейда пропадут данные, то считаю своим долгом тестировщика предупредить текущих пользователей ClearSQL ver#7.0 и SQLDetective ver#4 о необходимости сохранить прямо сейчас ветки реестра "HKEY_CURRENT_USER\Software\ClearSQL\DB Connect" и "HKEY_CURRENT_USER\Software\SQLDetective\Splash\ConnectionHistory" соответственно продуктам или Preferences в файл. Это позволит вам вручную восстановить в предыдущей версии утерянные при апгрейде пароли. Напоминаю, что в ClearSQL ver#7.1 (and higher) и SQLDetective ver#5 пароли к БД, сохранённые в предыдущих версиях, обнуляются при первом же запуске без какой бы то ни было возможности восстановления.
О простоте кодирования паролей в ClearSQL ver#7.0 и SQLDetective ver#4 уже говорилось в статье "Telegram in application with DB connection". Команде разработки потребовалось полтора года после моего напоминания для перенесения алгоритма более серьёзного кодирования паролей из ClearDB ver#4 в ClearSQL ver#7.1 и в SQLDetective ver#5. Так что, перед обновлением до сегодняшних версий не поленитесь и сделайте себе памятку, ведь столь удобная галка "сохранить пароль" может сыграть с вами очень злую шутку - не восстановит значения в новой версии, и даже механическая память рук ничем не поможет.
А всем тестировщикам ПО рекомендую не только проводить тест на обратную совместимость, но и вести профилактическую работу по предотвращению багов. Вроде бы удобство - опция для сохранения и авто-восстановления данных, но не для всех значений она может поддерживать законы безопасности приложения. Ещё одним примером такой юзерской прихоти является отдельная возможность выгрузки в XML файл всех сохранённых на машине коннектов к базе. В своё время мне пришлось потратить немало усилий, чтобы из прикреплений к OSD сообщению удаляли эти записи, потому что они несут персональную информацию, зачастую бесполезную для техподдержки ConquestSS. Но полагаю, что тот же юзер, который предложил сохранять пароли, сам и предложил экспортировать коннекты. А ведь это первый путь к хакерству. Если пользователь меняет комп, то в Online Help есть подробная инструкция по переносу настроек. Насколько часто нужна фича экспорта-импорта всего списка коннектов и кому? Ответ очевиден - только тому, кому временно стал доступен чужой ПК. Да, через сохранение всех настроек (Preferences) в файл тоже быстро можно скопировать все коннекты, но при этом ещё много локальных параметров (ключ лицензии, опции анализатора) придётся корректировать после импорта. Так что, считаю фичу экспорта-импорта коннектов вредной, а не полезной. И рекомендую подобные им новшества пресекать на первоначальном этапе разработки. Тогда не придётся выдумывать "защиту от дурака" в виде излишних шифрований или подтверждений опасных шагов. А владельцы продуктов и особенно администраторы баз должны перестать использовать опцию сохранения паролей, дабы хоть малость усложнить нежелательным элементам доступ к данным. Хотя, подобрать пароль, зная имена схем и баз, можно довольно просто. О чём немало говорили и Pete Finnegan, и Александр Поляков.
Комментариев нет:
Отправить комментарий