Testing equals solving problems. Imagine yourself as a tester that falls into a project, where you are assigned to test an AEM component. “We have implemented some simple fixes to this Rich Text Editor and we need to be sure that it is okay and we need to know this fast. The customer is waiting for delivery.” So how do you approach this task? How would you test this component? How do you solve that problem?
One way to solve problems is to apply a heuristic - a solution that is not perfect but good enough and satisfactory. And such a satisfactory solution in the presented situation would be applying a CRUD heuristic. Perhaps you are familiar with this term from Software Engineering. CRUD is an abbreviation for Create, Read, Update, Delete - seems like a perfect description of actions that can be undertaken on a component. So how could it be applied?
Create - add a new component to a page. Verify if it is added.
Read - verify that it behaves according to configuration both on Author and on Publish. Edit the component and verify that all properties are saved correctly.
Update - configure the component, edit properties and save.
Delete - delete the component. Verify that it is deleted.
More than that
Of course the aforementioned tests do not cover all scenarios which can be applied. One can do much more with the component: Move it, Copy/Cut and Paste it into other parsys. Also, each particular action can be executed in different ways, for example, one can add component by drag&dropping from sidekick or by double clicking in the target parsys or by right click and selecting “New” option from context menu. One can combine actions, change the order of execution or repeat actions multiple times: Create the new component, configure it, read it, reconfigure, read it again, add a new one, delete the first, and delete the second. Refreshing the page is also a good idea to verify that the changes have been saved to the CRX.
Use CRUD as a heuristic - something that is sufficient for the immediate goals. The tester from the story described in the first chapter of this post could use CRUD to conduct a sanity test before a release, by telling her manager that “it works as designed”. This feedback provides fast and reliable information. We can use CRUD in other situations as well. We could use CRUD as a starter for more deep testing such as when you need to conduct a test against regression during UATs. Or, we can put CRUD on a checklist and have all of your components tested this way through acceptance as a standardized approach.
Using heuristics is simple and tempting but it comes with one problem, CRUD like any other heuristic device does not tell you when to stop testing. But this is another story: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/
- An Introduction to General Systems Thinking - Gerald M. Weinberg
- For more test heuristics see here http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf
We're always looking for new faces to join the Cognifide family. Take a look at our available jobs.