The pitfalls in system testing of modules for Magento
the Three previous years I worked as a tester-a chiropractor for a company that very successfully develops modules for Magento. During this period I managed to accumulate quite a large list of various pitfalls, which the tester (and programmer) should never be forgotten.
Honestly, this is not some nobody known "pitfalls" about which nobody knows, or about that module in combat never stumble. It is rather all known features and places of the most Magento, in the interaction module which POPs up a lot, ahem, bugs. And these bugs very critical.
Non-base currency support
A lot of modules work with the prices — from a simple display in their units, to form part of the (discount, taxes, Chipinge) and/or the amount of the order, send the amount on the payment system. So be sure to configure in the store another currency and look carefully. Sometimes there are bugs with rounding when translating from one currency to another.
It is recommended this case to automate. However, without a personal audit there is still not enough, especially since the price of failure is very high.
Big Database
We have sample-data, which we called the "XXL" — tens of thousands of generated customers, products and orders. Practice shows that very many of the modules on these "stores" bare your failed implementation. Most often, this translates into a huge increase loading time of pages.
Multi-store
There is a view of support of various website/store/store-view — of different option values for different locales "Stora" (not)display some of the locale redirects when you change the locale on the frontend.
It is recommended this case to automate.
Single-store
Sometimes developers forget that the store can have only one Store View ID and it can be different from 1.
It is recommended this case to automate.
HTTPS
This files most often meet the following problems:
— breaks the javascript/AJAX module
— when a module adds a tab to My Account, then often there is not used https in the URL
requests are sent from https to http and Vice versa
— you can still do Store c Base Unsecure Url to https (so that the whole stor used on frontend https)
It is recommended this case to automate.
Multi-Address Checkout
Out of the box in Magento is the checkout page that allows you to place an order to multiple addresses. So if your module somehow interacts with the checking out code — do not forget about the multi-address checkout.
Checkout as Guest
A very important area. The number of different test scenarios is simply huge: from the process of order entry before processing custom discounts and created by the guests of the warrants.
Register at Checkout
If the module somehow works with login or registration, do not forget that the checkout page also has a form to login/register.
This could include possible problems with the CAPTCHA.
Require Email Confirmation
In the backend there is an option "Require Email Confirmation", which includes the need to verify your email upon registration. Proper work with this feature, important for modules that work with the event registering a new user. This is especially critical for various referral systems.
Backend Admin Permissions (ACL)
Probably your module adds some menu items in the backend. You must ensure that administrators who should not have access to these menu items do not have access to them. The passage is checked for a direct link. Still need to pay attention to the "hidden" links, such as store/admin/promo_catalog/delete/id/1 — this link will delete the Catalog Price Rule with ID=1. Such links will also need to consider who is involved.
It is recommended this case to automate.
Cross-Browser compatibility
Here everything is simple. Test the frontend in different browsers. Pay attention to vertico and the testing of scripts.
It is recommended this case to automate.
Themes
It will not hurt to put your module on some frontend theme (preferably close to "combat" the online store) and make sure there's nothing broken.
Full Page Cache
FPC will bring much trouble to the developer, believe me. Important for modules that are showing on the frontend, blocks whose contents can change.
CSV Translations
In the folder app/locale/xx_XX/ are csv files that respond to the translated text. Make sure that your module has such a file that all the labels and messages of the module are in the file, and change this file "translates" the labels on the front-end.
It is recommended this case to automate.
Update from previous version
When refactoring or the restructuring of tables in the database module will check update from a previous version.
Check integrity
What happens with your module if you remove a user, or other entity that you are working with your module?
Product is out of stock
Don't forget that products can be or become out of stock.
Slow connection speed
Sometimes developers forget that the connection is not always pleased with its quality. To emulate a slow connection, you can use Fiddler, for example.
Database prefix
And developers sometimes forget that the tables in the database are prefixes. This bug will drop the entire module. Or even the entire "store".
Compilation
Recent bugs related to compilation (Backend>Tools>Compilation) a new module was noticeably less. It seems that our programmers don't like to step on a rake twice.
Flat category / product
Just enable these options in the System > Configuration > Catalog, make reindex and go to the category or product. Typical bug.
Store code to URL's / SEO Optimization
These options affect the URLs. Where the URLs are there and these options.
Special symbols & Injections
Check the module in the resistance to scripts and other XSS/SQL-injections, for the display and processing of special characters to substitute values in a form, etc.
Locale / Timezone
Everything to do with localization: the format of dates and prices, is on display in the store settings, timezone, etc.
Form Save after Error
It is good practice to save the entered values in the form, in case the server when saving/submitting the form will return an error.
Create Order From Backend
The order can be create from the admin panel. This is too often overlooked.
Create Customer From Backend
Similar to the previous paragraph.
W3C Validation
Check the robots page on the validity of the layout. You can argue about some points of this validation, but the fact remains — consumers of your module will become your headache if you do not care about this issue in advance.
Article based on information from habrahabr.ru
Honestly, this is not some nobody known "pitfalls" about which nobody knows, or about that module in combat never stumble. It is rather all known features and places of the most Magento, in the interaction module which POPs up a lot, ahem, bugs. And these bugs very critical.
Non-base currency support
A lot of modules work with the prices — from a simple display in their units, to form part of the (discount, taxes, Chipinge) and/or the amount of the order, send the amount on the payment system. So be sure to configure in the store another currency and look carefully. Sometimes there are bugs with rounding when translating from one currency to another.
It is recommended this case to automate. However, without a personal audit there is still not enough, especially since the price of failure is very high.
Big Database
We have sample-data, which we called the "XXL" — tens of thousands of generated customers, products and orders. Practice shows that very many of the modules on these "stores" bare your failed implementation. Most often, this translates into a huge increase loading time of pages.
Multi-store
There is a view of support of various website/store/store-view — of different option values for different locales "Stora" (not)display some of the locale redirects when you change the locale on the frontend.
It is recommended this case to automate.
Single-store
Sometimes developers forget that the store can have only one Store View ID and it can be different from 1.
It is recommended this case to automate.
HTTPS
This files most often meet the following problems:
— breaks the javascript/AJAX module
— when a module adds a tab to My Account, then often there is not used https in the URL
requests are sent from https to http and Vice versa
— you can still do Store c Base Unsecure Url to https (so that the whole stor used on frontend https)
It is recommended this case to automate.
Multi-Address Checkout
Out of the box in Magento is the checkout page that allows you to place an order to multiple addresses. So if your module somehow interacts with the checking out code — do not forget about the multi-address checkout.
Checkout as Guest
A very important area. The number of different test scenarios is simply huge: from the process of order entry before processing custom discounts and created by the guests of the warrants.
Register at Checkout
If the module somehow works with login or registration, do not forget that the checkout page also has a form to login/register.
This could include possible problems with the CAPTCHA.
Require Email Confirmation
In the backend there is an option "Require Email Confirmation", which includes the need to verify your email upon registration. Proper work with this feature, important for modules that work with the event registering a new user. This is especially critical for various referral systems.
Backend Admin Permissions (ACL)
Probably your module adds some menu items in the backend. You must ensure that administrators who should not have access to these menu items do not have access to them. The passage is checked for a direct link. Still need to pay attention to the "hidden" links, such as store/admin/promo_catalog/delete/id/1 — this link will delete the Catalog Price Rule with ID=1. Such links will also need to consider who is involved.
It is recommended this case to automate.
Cross-Browser compatibility
Here everything is simple. Test the frontend in different browsers. Pay attention to vertico and the testing of scripts.
It is recommended this case to automate.
Themes
It will not hurt to put your module on some frontend theme (preferably close to "combat" the online store) and make sure there's nothing broken.
Full Page Cache
FPC will bring much trouble to the developer, believe me. Important for modules that are showing on the frontend, blocks whose contents can change.
CSV Translations
In the folder app/locale/xx_XX/ are csv files that respond to the translated text. Make sure that your module has such a file that all the labels and messages of the module are in the file, and change this file "translates" the labels on the front-end.
It is recommended this case to automate.
Update from previous version
When refactoring or the restructuring of tables in the database module will check update from a previous version.
Check integrity
What happens with your module if you remove a user, or other entity that you are working with your module?
Product is out of stock
Don't forget that products can be or become out of stock.
Slow connection speed
Sometimes developers forget that the connection is not always pleased with its quality. To emulate a slow connection, you can use Fiddler, for example.
Database prefix
And developers sometimes forget that the tables in the database are prefixes. This bug will drop the entire module. Or even the entire "store".
Compilation
Recent bugs related to compilation (Backend>Tools>Compilation) a new module was noticeably less. It seems that our programmers don't like to step on a rake twice.
Flat category / product
Just enable these options in the System > Configuration > Catalog, make reindex and go to the category or product. Typical bug.
Store code to URL's / SEO Optimization
These options affect the URLs. Where the URLs are there and these options.
Special symbols & Injections
Check the module in the resistance to scripts and other XSS/SQL-injections, for the display and processing of special characters to substitute values in a form, etc.
Locale / Timezone
Everything to do with localization: the format of dates and prices, is on display in the store settings, timezone, etc.
Form Save after Error
It is good practice to save the entered values in the form, in case the server when saving/submitting the form will return an error.
Create Order From Backend
The order can be create from the admin panel. This is too often overlooked.
Create Customer From Backend
Similar to the previous paragraph.
W3C Validation
Check the robots page on the validity of the layout. You can argue about some points of this validation, but the fact remains — consumers of your module will become your headache if you do not care about this issue in advance.
Комментарии
Отправить комментарий