Три предыдущих года я работал тестировщиком-мануальщиком в компании, которая очень успешно разрабатывает модули под Magento. За этот период я смог накопить достаточно большой список различных подводных камней, о которых тестировщику (да и программисту) никогда нельзя забывать.
Честно говоря, это не какие-то никому не известные «подводные камни», о которых никто не знает, или о которые модуль в боевых условиях никогда не столкнётся. Это скорее всем известные фичи и места самой Magento, в взаимодействии модуля с которыми всплывает очень много, кхе-кхе, багов. Причём баги эти очень даже критичны.
Non-base currency support
Очень много модулей работают с ценами — от простого отображения в своих блоках, до формирования частей (дискаунты, таксы, шипинги) и/или суммы ордера, отправки amount на платёжные системы. Поэтому обязательно настраиваем на магазине еще одну валюту и внимательно смотрим. Еще иногда бывают баги с округлением при переводе из одной валюты в другую.
Рекомендуется этот кейс автоматизировать. Однако без личного аудита тут всё же не обойтись, тем более что цена ошибки очень велика.
Big Database
У нас есть sample-data, которую мы обозвали «XXL» — десятки тысяч сгенерированных кастомеров, продуктов и ордеров. Практика показывает, что очень многие модули на таких «сторах» обнажают свою неудачную реализацию. Чаще всего это выражается в огромных приростах времени загрузки страниц.
Multi-store
Здесь имеется ввиду поддержка различных website/store/store-view — различные значения опции для разных локалей «стора», (не)отображение на некоторых локалях, редиректы при смене локали на фронтенде
Рекомендуется этот кейс автоматизировать.
Single-store
Иногда разработчики забывают о том, что на сторе может быть только один store view и id его может отличать от 1.
Рекомендуется этот кейс автоматизировать.
HTTPS
Чаще всего встречаются следующие проблемы:
— ломается javascript/AJAX модуля
— когда модуль добавляет вкладку в My Account, то часто там не используется https в URL
— запросы с https отправляются на http и наоборот
— еще можно сделать Store Base Unsecure Url c https (чтобы весь стор использовал на фронтенде https)
Рекомендуется этот кейс автоматизировать.
Multi-Address Checkout
«Из коробки» в Magento есть чекаут, который позволяет оформить ордер на несколько адресов. Так что если ваш модуль как-то взаимодействует с чекаутом — не забывайте про multi-address checkout.
Checkout as Guest
Очень важный участок. Количество различных тестовых сценариев здесь просто огромное — от процесса создания ордера, до обработки кастомных дискаунтов и созданных гостями ордеров.
Register at Checkout
Если модуль как-то работает с логином или регистрацией, то не забывайте, что чекаут также имеет форму login/register.
Сюда можно отнести также возможные проблемы с CAPTCHA.
Require Email Confirmation
В бекенде есть опция «Require Email Confirmation», которая включает необходимость подтвердить свой email при регистрации. Правильная работа с этой фичей важна для модулей, которые работают с событием регистрации нового пользователя. Особенно критично это для различных реферальных систем.
Backend Admin Permissions (ACL)
Наверняка ваш модуль добавляет какие-то пункты меню в бекенде. Необходимо убедиться, что администраторы, которые не имеют доступа к этим пунктам меню, действительно не имеют доступа. Проверяется проходом по прямой ссылке. Еще нужно обратить внимание на «скрытие» ссылки, например store/admin/promo_catalog/delete/id/1/ — эта ссылка удалит Catalog Price Rule c id=1. Такие ссылки также должны учитывать то, кто по ним проходит.
Рекомендуется этот кейс автоматизировать.
Cross-Browser compatibility
Здесь всё просто. Тестируем фронтенд в различных браузерах. Обращать внимание на вертску и отработку скриптов.
В бекенде проблемы с кросс-браузерностью очень редки. Достаточно протестировать под Firefox и Chrome.
Рекомендуется этот кейс автоматизировать.
Themes
Не помешает поставить свой модуль на какую-нибудь фронтенд-тему (лучше на приближенный к «боевому» интернет-магазин) и убедиться, что там ничего не сломалось.
Full Page Cache
FPC доставит много хлопот разработчику, уж поверьте. Актуально для модулей, которые показывают на фронтенде блоки, содержимое которых может изменяться.
CSV Translations
В папке app/locale/xx_XX/ лежат csv-файлы, которые отвечают на перевод текста. Убедитесь, что ваш модуль также имеет такой файл, что все лейблы и сообщения модуля имеются в этом файле, и что изменение этого файла «переводит» лейблы на фронтенде.
Рекомендуется этот кейс автоматизировать.
Update from previous version
При рефакторинге или изменении структуры базы данных обязательно проверяем апдейт с предыдущей версии.
Проверка на целостность данных
Что будет с вашим модулем, если удалить пользователя, продукт или другую сущность, с которой работает ваш модуль?
Product is out of stock
Не забывайте о том, что продукты могут быть или стать out of stock.
Slow speed connection
Иногда девелоперы забывают о том, что коннект не всегда радует своим качество. Для эмуляции медленного коннекта можно использовать программу Fiddler, например.
Database prefix
А еще девелоперы иногда забывают, что у баз данных бывают префиксы. Такой баг обязательно уронит весь модуль. Или даже «стор».
Compilation
В последнее время багов связанных с компиляцией (Backend>Tools>Compilation) в новых модулях стало совсем мало. Видимо наши программисты совсем не любят наступать на грабли дважды.
Flat category / product
Просто включите эти опции в System > Configuration > Catalog, сделайте реиндекс и пойдите в категорию или на продукт. Типичный баг.
Store code to URL / SEO Optimization
Эти опции влияют на URLы. Там где урлы, там и эти опции.
Special symbols & Injections
Проверяем модуль на устойчивость к скриптам и прочим XSS/SQL-инъекциям, на отображение и обработку специальных символов, на подмену значений в форме и т.д.
Locale / Timezone
Все что связано с локализацией: формат дат и цен, учитывается ли выставленная в настройках магазина таймзона, и т.д.
Form Save after Error
Хорошим тоном является сохранение введенных в форму значений, на случай если сервер при сохранении/отправке формы вернёт ошибку.
Create Order From Backend
Ордер можно создать также и из админки. Об этом тоже часто забывают.
Create Customer From Backend
Аналогично предыдущему пункту.
W3C Validation
Проверьте доступные роботам страницы на валидность вёрстки. Можно спорить о некоторых моментах этой валидации, но факт остаётся фактом — покупатели вашего модуля будут вашей головной болью, если вы не позаботитесь об этом вопросе заранее.
Автор: stanislav_golodov
