Pitfalls in the system testing modules for Magento
Three previous years I worked as a tester-manual at a company that very successfully develops modules for Magento . During this period, I was able to accumulate a fairly large list of various pitfalls, which the tester (and the programmer) should never forget.
To be honest, these are not some unknown “pitfalls” that no one knows about or that the module will never stumble about in combat conditions. These are rather well-known features and places of Magento itself, in which the module interacts with which a lot of bugs pop up, khe-khe. And these bugs are very critical.
Non-base currency support
A lot of modules work with prices - from a simple display in their blocks, to the formation of parts (discounts, taxes, shipping) and / or order amounts, sending the amount to payment systems. Therefore, be sure to set up another currency on the store and carefully look. Sometimes there are bugs with rounding when transferring from one currency to another.
It is recommended to automate this case. However, without personal audit there is still not enough, especially since the price of a mistake is very high.
Big database
We have sample-data, which we called "XXL" - tens of thousands of generated custom, products and orders. Practice shows that very many modules in such “stores” expose their unsuccessful implementation. Most often this is expressed in huge increases in page load time.
Multi-store
Here we mean the support of various website / store / store-view - different option values ​​for different locales of “Store”, (not) display on some locales, redirects when changing locale on the frontend.
It is recommended to automate this case.
')
Single-store
Sometimes developers forget that there can be only one Store View on the side and its ID can differ from 1.
It is recommended to automate this case.
Https
The most common problems are:
- javascript / AJAX module breaks down
- when a module adds a tab to My Account, it often does not use https in the URL
- requests from https are sent to http, and vice versa
- you can still do the Store Base Unsecure Url with https (so that the whole stop uses https on the frontend)
It is recommended to automate this case.
Multi-Address Checkout
"Out of the box" in Magento is a checkout that allows you to place an order for several addresses. So if your module somehow interacts with checkout - do not forget about multi-address checkout.
Checkout as Guest
Very important site. The number of different test scenarios here is simply huge: from the process of creating an order, to processing custom discounts and orders created by guests.
Register at Checkout
If the module somehow works with a login or registration, then do not forget that the checkout also has a login / register form.
This may also include possible problems with CAPTCHA.
Require Email Confirmation
The backend has the option “Require Email Confirmation”, which includes the need to confirm your email when registering. Proper operation with this feature is important for modules that work with a new user registration event. This is especially critical for various referral systems.
Backend Admin Permissions (ACL)
Surely your module adds some menu items in the backend. You must make sure that administrators who do not need access to these menu items do not really have access to them. It is checked by a direct link. You also need to pay attention to the "hidden" links, for example store / admin / promo_catalog / delete / id / 1 - this link will remove the Catalog Price Rule with ID = 1. Such links should also take into account who follows them.
It is recommended to automate this case.
Cross-Browser compatibility
Everything is simple here. We test frontend in various browsers. Pay attention to vertsku and working out scripts.
Backend problems with cross-browser are very rare, so it’s enough to test the backend under Firefox and Chrome.
It is recommended to automate this case.
Themes
It doesn’t hurt to put your module on any frontend theme (better on an online store close to a combat one) and make sure that nothing is broken there.
Full Page Cache
FPC will bring a lot of trouble to the developer, believe me. This is relevant for modules that show blocks on the front end, the contents of which may vary.
CSV Translations
The app / locale / xx_XX / folder contains csv files that respond to text translation. Make sure that your module also has such a file that all labels and module messages are in this file, and that changing this file "translates" the labels on the frontend.
It is recommended to automate this case.
Update from previous version
When refactoring or changing the structure of the module tables in the database, we must check the update from the previous version.
Data integrity check
What will happen to your module if you delete a user, product or other entity with which your module works?
Product is out of stock
Do not forget that products can be or become out of stock.
Slow speed connection
Sometimes developers forget that the connection does not always please with its quality. To emulate a slow connection, you can use the Fiddler program, for example.
Database prefix
And developers sometimes forget that tables in the database have prefixes. Such a bug will definitely drop the entire module. Or even the whole "Stor."
Compilation
Recently, the compilation-related bugs (Backend> Tools> Compilation) in new modules have become noticeably smaller. It seems that our programmers do not like to step on a rake at all twice.
Flat category / product
Simply enable these options in the System> Configuration> Catalog, re-index and go to the category or to the product. Typical bug.
Store code to URL / SEO Optimization
These options affect URLs. Where urly, there are these options.
Special symbols & Injections
We check the module for resistance to scripts and other XSS / SQL injections, to display and process special characters, to substitute values ​​in the form, etc.
Locale / Timezone
Everything related to localization: the format of dates and prices, whether the timezone set in the store settings is taken into account, etc.
Form Save after Error
It is a good idea to save the values ​​entered into the form, in case the server returns an error when saving / sending the form.
Create Order From Backend
The order can also be created from the admin panel. This is also often forgotten.
Create Customer From Backend
Similar to the previous paragraph.
W3C Validation
Check the pages available for robots for the validity of the layout. You can argue about some points of this validation, but the fact remains that the buyers of your module will become your headache if you do not take care of this issue in advance.
To be honest, these are not some unknown “pitfalls” that no one knows about or that the module will never stumble about in combat conditions. These are rather well-known features and places of Magento itself, in which the module interacts with which a lot of bugs pop up, khe-khe. And these bugs are very critical.
Non-base currency support
A lot of modules work with prices - from a simple display in their blocks, to the formation of parts (discounts, taxes, shipping) and / or order amounts, sending the amount to payment systems. Therefore, be sure to set up another currency on the store and carefully look. Sometimes there are bugs with rounding when transferring from one currency to another.
It is recommended to automate this case. However, without personal audit there is still not enough, especially since the price of a mistake is very high.
Big database
We have sample-data, which we called "XXL" - tens of thousands of generated custom, products and orders. Practice shows that very many modules in such “stores” expose their unsuccessful implementation. Most often this is expressed in huge increases in page load time.
Multi-store
Here we mean the support of various website / store / store-view - different option values ​​for different locales of “Store”, (not) display on some locales, redirects when changing locale on the frontend.
It is recommended to automate this case.
')
Single-store
Sometimes developers forget that there can be only one Store View on the side and its ID can differ from 1.
It is recommended to automate this case.
Https
The most common problems are:
- javascript / AJAX module breaks down
- when a module adds a tab to My Account, it often does not use https in the URL
- requests from https are sent to http, and vice versa
- you can still do the Store Base Unsecure Url with https (so that the whole stop uses https on the frontend)
It is recommended to automate this case.
Multi-Address Checkout
"Out of the box" in Magento is a checkout that allows you to place an order for several addresses. So if your module somehow interacts with checkout - do not forget about multi-address checkout.
Checkout as Guest
Very important site. The number of different test scenarios here is simply huge: from the process of creating an order, to processing custom discounts and orders created by guests.
Register at Checkout
If the module somehow works with a login or registration, then do not forget that the checkout also has a login / register form.
This may also include possible problems with CAPTCHA.
Require Email Confirmation
The backend has the option “Require Email Confirmation”, which includes the need to confirm your email when registering. Proper operation with this feature is important for modules that work with a new user registration event. This is especially critical for various referral systems.
Backend Admin Permissions (ACL)
Surely your module adds some menu items in the backend. You must make sure that administrators who do not need access to these menu items do not really have access to them. It is checked by a direct link. You also need to pay attention to the "hidden" links, for example store / admin / promo_catalog / delete / id / 1 - this link will remove the Catalog Price Rule with ID = 1. Such links should also take into account who follows them.
It is recommended to automate this case.
Cross-Browser compatibility
Everything is simple here. We test frontend in various browsers. Pay attention to vertsku and working out scripts.
Backend problems with cross-browser are very rare, so it’s enough to test the backend under Firefox and Chrome.
It is recommended to automate this case.
Themes
It doesn’t hurt to put your module on any frontend theme (better on an online store close to a combat one) and make sure that nothing is broken there.
Full Page Cache
FPC will bring a lot of trouble to the developer, believe me. This is relevant for modules that show blocks on the front end, the contents of which may vary.
CSV Translations
The app / locale / xx_XX / folder contains csv files that respond to text translation. Make sure that your module also has such a file that all labels and module messages are in this file, and that changing this file "translates" the labels on the frontend.
It is recommended to automate this case.
Update from previous version
When refactoring or changing the structure of the module tables in the database, we must check the update from the previous version.
Data integrity check
What will happen to your module if you delete a user, product or other entity with which your module works?
Product is out of stock
Do not forget that products can be or become out of stock.
Slow speed connection
Sometimes developers forget that the connection does not always please with its quality. To emulate a slow connection, you can use the Fiddler program, for example.
Database prefix
And developers sometimes forget that tables in the database have prefixes. Such a bug will definitely drop the entire module. Or even the whole "Stor."
Compilation
Recently, the compilation-related bugs (Backend> Tools> Compilation) in new modules have become noticeably smaller. It seems that our programmers do not like to step on a rake at all twice.
Flat category / product
Simply enable these options in the System> Configuration> Catalog, re-index and go to the category or to the product. Typical bug.
Store code to URL / SEO Optimization
These options affect URLs. Where urly, there are these options.
Special symbols & Injections
We check the module for resistance to scripts and other XSS / SQL injections, to display and process special characters, to substitute values ​​in the form, etc.
Locale / Timezone
Everything related to localization: the format of dates and prices, whether the timezone set in the store settings is taken into account, etc.
Form Save after Error
It is a good idea to save the values ​​entered into the form, in case the server returns an error when saving / sending the form.
Create Order From Backend
The order can also be created from the admin panel. This is also often forgotten.
Create Customer From Backend
Similar to the previous paragraph.
W3C Validation
Check the pages available for robots for the validity of the layout. You can argue about some points of this validation, but the fact remains that the buyers of your module will become your headache if you do not take care of this issue in advance.
Source: https://habr.com/ru/post/215025/
All Articles