[DRAFT]

Testing

This is an important part in the development which many times is left apart. In this page, there will be overall hints and guidelines to CKEditor testing. Specific Test cases would be included in CKTester.

Preparing environment for testing

Before testing begins, testing environment should be prepared, so it would simulate real user activities.

CKEditor version

When code is frozen for testing, selected version should be downloaded.

• Testing should be done on release version, created with CKReleaser.
• The release version has entirely different loading sequence and different codes because of packing.
• The release versionn should be loaded into webserver so it would run as normal web application.
• HTTP and SSL protocals on the page should be tested, this indicate that CKEditor must be loaded on a http server with ssl support
• Note that some CKEditor samples depend on PHP, it would be useful when webserver will have PHP suport

Browsers

Version under test, should be run on all supported browsers. Browsers should be run with default configuration or in safe mode.
Usually, a tester, will have one, or set of browsers assigned.
Browsers should be run with and without error console enabled. Note that this is:

• the usual way how developers using CKEditor are working
• An easy way to find errors that happen, but are not that easy to spot because the editor seems to be working fine.

Testing phase

When environment is ready, testing could be run.

Manual Tests

1. Check all the tickets closed in current milestone to find the list of things where there is a higher chance of finding a bug. Note that everything should be tested anyway, but this may help in catching even more bugs.
2. Different editor configurations should be tested.
   • HTML samples distributed with CKEditor should be launched and tested, including different skins and UI language direction.
   • Every button in toolbar should be checked
   • Every dialog window should be checked, whether it loads proper data
   • Every dropdown list should be checked if it contains set of items, as in plugin configuration file.
3. Switching views between WYSIWYG and Source Code should be tested if the code is properly interpreted
   • By entering content in Source mode and switching to WYSIWYG, and then back.
   • By entering content in WYSIWYG and switching to Source
4. Inserting content should be tested
   • Image plugin and Flash plugin: if the dialog window loads proper data and preview
   • Insert Table plugin: does it create table as expected, and if table properties dialog loads right data.
5. Copy/Paste
   • Copy/Paste between different editor instances should be tested,
   • Copy/paste between editors running in different browsers should be tested,
   • Copying and pasting content from external editor (like MS Word)should be checked,
   • Copy paste with keyboard shortcut and context menu should be tested
6. Drag and Drop should be tested
7. Context menu should be checked, if it is working properly, according to selection
8. BIDI options: Check if editing works properly when RTL editing direction is set.

CKTester

CKTester could be used to verify existing design tests and ticket tests for regressions automatically, but not a priority.

Reporting Issues

When bug has been found:

• Make sure in which version of CKEditor the error that you have found appeared for the first time. It is important to check whether it is a regression or an old bug. Previous versions of CKeditor could be downloaded from here.
• Our revision server (​http://rev.ckeditor.com) could be used to checking the exact revision that introduced the issue. Binary search can be used if it's of a large unsure commit range.
• Bug identified on a particular browser may also affect others, great to check if the problem is generic.
• Fill the bug ticket according to TicketSpecs
• When new tickets are opened for bugs seen, don't start work on the tickets immediately. Waiting for others to confirm, we will have a separate period time for fixing them.
• If the bug looks critical, notify the team asap (i.e. if fixing it may cause that the testing phase will have to be restarted, usually even a trivial change may cause unexpected problems).