Bugzilla

All bugs in the MediaWiki software should be reported at bugzilla.wikimedia.org. This is also the place to request new features or enhancements to the software.

What is Bugzilla?

For more information, see the Wikipedia article on Bugzilla.

Bugzilla is an on-line bug-tracking tool, developed by the Mozilla Foundation, and is the system we use to track all open issues with MediaWiki.

The reason we use Bugzilla is that it allows the developers to easily find, track and discuss issues, to spot duplicates and ultimately to resolve them.

The Wikimedia Bugzilla site is sometimes referred as Mediazilla.

Reporting a bug

Go to bugzilla.wikimedia.org.

# Use the search box on the main page to see if your bug has already been submitted. You can also perform more advanced searches on the search page.

If you are sure that your issue has not already been reported then click enter a new bug in the toolbox on the left. You will be prompted to log in if you have not already done so (see 'Why must I register?', below).
Select 'MediaWiki' as the product.
Fill in the following boxes (the rest can be left blank):
- Component (if you don't know, select 'General/Unknown')
- Summary - a short one-sentence summary of the issue
- Description - full details of the issue, giving as much detail as possible
Click 'Commit'

That's it! For maximum chance of your bug being fixed, you are advised to read the bug writing guidelines first. See also: How to Report Bugs Effectively by Simon Tatham

Requesting a feature

Before making a feature/enhancement request:

Consider whether a custom extension would be more appropriate.
If the request is specific to a Wikimedia wiki, please discuss the issue on that wiki first. Devs will usually ask you for a link showing a community consensus.

Then follow the same directions as above, except you probably need to select 'Wikimedia' instead of 'MediaWiki' as the product.

What syntax can I use?

Bugzilla comments are plain text, you cannot use HTML. However, Bugzilla will automatically make hyperlinks for certain type of text in comments:

most types of URLs, e.g. http://bugzilla.wikimedia.org/
bug 12345
comment 7
bug 23456, comment 53
attachment 4321

MediaWiki-style internal links are also supported, by default they point to English Wikipedia. It seems like some interwiki or project prefixes are supported as well, but you cannot specify the text for the link (i.e. the name part is not supported).

Why must I register?

We need you to register in order to use Bugzilla. This is primarily so that we can contact you if there are further questions regarding your bug submission. For example, if a developer is unable to replicate your problem they will ask for more information.

Registering is free and easy. Simply click the 'create account' link at the top right of the page, enter your e-mail address (and optionally your real name) and click 'create account'. Then simply log in using the password you receive in the confirmation e-mail (which can be changed in your preferences once you have logged in).

Once logged in, you can change your preferences to specify what kinds of e-mail Bugzilla sends you (with the option of turning off all e-mail). To do this click 'my preferences' in the top right and select the 'email settings' tab.

Please note that (unlike on Wikimedia projects) your email address will be visible to everyone. Some people prefer to set up a separate e-mail account (using a free webmail service) for working with Bugzilla.

Why can't I report bugs here?

You can. You can also report by writing them in chalk on the pavement. However, if you want a developer to act on it then you need to put it somewhere they are likely to see it, namely Bugzilla.

How do I link to a bug?

If you want to create a link from a page on MediaWiki.org to a Bugzilla bug, use [[bugzilla:XXX]], where XXX is the bug number you want to link to. For example [[bugzilla:4198]] will result in the following output: bugzilla:4198.

Adhoc Testing

Guidance Notes for Ad Hoc Testing

General

For each application, try to cover both linguistic and functionality issues as detailed as possible. All applications should be tested in spite of short testing time. In order to meet target:

1.) concentrate to main areas of each application, test ‘use cases’ which are easy to meet by the end user.
2.) Priority 1 apps are more important than priority 2 apps, thus you can spend more time testing of priority 1 apps than priority 2 apps. In other words test priority 1 apps more detailed than priority 2 apps. In other words in all apps you should have a brief look of the UI – that it’s still translated with the correct language but in priority 1 apps you should use more time to test main functionality than in priority 2 apps.

In terms of functionality:

Pay attention to
1.) sorting orders and
2.) encodings when ever possible!
3.) Don’t forget to use special characters of target language when testing search.
4.) Use special characters of target language in every input field you can. E.g. in Scandinavian languages we use letters such as ‘ä, ö, å’ which are not used in other languages and thus can be called as ‘special’ characters for Scandinavian languages.
5.) Locales
6.) Try to cover all basic functionality of the device e.g.

a. deleting, creating files & emails,

b. sending, receiving emails with and without attachments

c. browsing

d. listening to radio etc.

7.) Try to provoke errors by entering unacceptable inputs, such as letters in numeric/date fields, or values outside of the valid range for a particular field.

In terms of localization:
1.) Try to view as many of the screens and dialogs as possible.
2.) Pay attention to correctness of terms used in the device. Two aspects:

a) We don’t want to use any terms which might be politically risky. E.g. our use case in Sputnik was Chess, terms used for player were not correct for some languages. Made Nokia to look racist.

b) Terms we used should be the ones which are commonly used on mobile devices & PCs, thus commonly accepted and intelligible.

3.) During ad hoc testing, always ensure that items & strings are displayed properly.
If you find a defect during ad hoc testing, you should still ensure that it is reproducible and generate clear steps to reproduce.

Priority 1 Applications Priority 1 applications are: Start up wizard
Web Browser
Multimedia
Connectivity
Locales
Language change functionality
VoIP
Chat
IVC
Internet Radio
News Reader
Search
Email

All other applications are priority 2.

Start up wizard When testing the Startup wizard, you should check the 'Out of the box' readiness when users start up the device for the first time. Web browser
When testing Web browser, you should try the top 10 websites for the target language, and some English websites. Try to provoke error conditions by entering invalid web addresses. Also test Internet radio functionality.
Note use case in browser related to special characters. In case URL contains Scandinavian characters it cannot be edited anymore from bookmarks – at least not very easily. So try to find one working URL which contains special characters of target language and test it.

Multimedia Testing of Multimedia should cover Audio Player and Video Player. Testing should include as many file formats as possible, and include streaming media from remote sources.

Connectivity When testing connectivity, you should connect through wireless LAN, and through phones using Packet data and Data call settings. Errors can be generated by disrupting the connection, e.g. by switching the phone off or disabling Bluetooth.

Locales When testing Locales you should check all locale specific data such as date/time formats and number formats. Date/time formats can be checked in areas such as Browser History, or file details (e.g. in File Manager and email). Number formats can be checked in Calculator.

Email When testing Email, you should test as many different combinations of settings as possible, and test with a variety of mail types and attachment types.

News reader When testing News reader, you should test with a variety of feeds from a variety of sources.

VoIP, Chat, IVC Test as many scenarious as possible on the available time.

Search Search strings including language specific characters. Examples of search scenarious: searching files in mediapalyer, File Manager, searching words inside dcuments.

Localisation

What is Software Localisation?

Localisation is the process of adapting the software:

To make it suitable and understandable to the linguistic, cultural and technical requirements of a specific locale/region, or a specific target market

Using local terms, units of measurement and conventions in order to give a good user experience

It’s not simply translation of text

Focal Points in Localisation: What we test

Language Translation

Alphabets/scripts; different systems of numerals; left-to-right script vs. right-to-left scripts.

National varieties of languages (adapting the language for specific region: local customs & local content)

Spelling variants for different countries where the same language is spoken, e.g. localization (American English) vs. localisation (British English)

Date/time format, including use of different calendars

Formatting of numbers (decimal points, positioning of separators, character used as separator)

Weights and measures

Computer-encoded text

Symbols

Order of sorting

Aesthetics

Images and colours: issues of comprehensibility and cultural appropriateness

Cultural values and social context

Time zones (GMT/UTC in internationalised environments)

Any other aspect of the product or service that is subject to regulatory compliance

Localisation testing coverage

Linguistic:
Verify the translation to ensure if everything is contextually accurate, grammatically correct and culturally appopriate

Cosmetic:
Validates the User Interface (UI) for missed translations, truncated strings / dialogue boxes, layout problems and visual design

Functional:
Ensures that the localisation process hasn’t introduced any functional defects

Testing Overview

What is Testing?

Testing is a technical investigation done to expose quality-related information about the product under test.

Technical: we use technical means: experimentation, logic, mathematics, models & tools (testing support programmes, measuring instruments, etc.)

Investigation: an organised and thorough search for information. This is an active process of inquiry, we ask hard questions and look carefully at the results

Expose quality-related information: build confidence in the product, minimise technical support and post-release fixing, verify that the product conforms to the specifications

Product under testing: Software or Hardware (in our case, SW)

Languages:

[[::Bugzilla|English]] (temp debug: Bugzilla/af) (temp debug: Bugzilla/ar) (temp debug: Bugzilla/az) (temp debug: Bugzilla/bcc) (temp debug: Bugzilla/bg) (temp debug: Bugzilla/br) (temp debug: Bugzilla/ca) (temp debug: Bugzilla/cs) (temp debug: Bugzilla/da) (temp debug: Bugzilla/de) (temp debug: Bugzilla/el) (temp debug: Bugzilla/es) (temp debug: Bugzilla/fa) (temp debug: Bugzilla/fi) (temp debug: Bugzilla/fr) (temp debug: Bugzilla/gl) (temp debug: Bugzilla/gu) (temp debug: Bugzilla/he) (temp debug: Bugzilla/hu) (temp debug: Bugzilla/id) (temp debug: Bugzilla/it) (temp debug: Bugzilla/ja) (temp debug: Bugzilla/ko) (temp debug: Bugzilla/ksh) (temp debug: Bugzilla/ml) (temp debug: Bugzilla/mr) (temp debug: Bugzilla/ms) (temp debug: Bugzilla/nl) (temp debug: Bugzilla/no) (temp debug: Bugzilla/oc) (temp debug: Bugzilla/pl) (temp debug: Bugzilla/pt) (temp debug: Bugzilla/ro) (temp debug: Bugzilla/ru) (temp debug: Bugzilla/si) (temp debug: Bugzilla/sk) (temp debug: Bugzilla/sq) (temp debug: Bugzilla/sr) (temp debug: Bugzilla/sv) (temp debug: Bugzilla/ta) (temp debug: Bugzilla/th) (temp debug: Bugzilla/tr) (temp debug: Bugzilla/uk) (temp debug: Bugzilla/vi) (temp debug: Bugzilla/yue) (temp debug: Bugzilla/zh) (temp debug: Bugzilla/zh-hans) (temp debug: Bugzilla/zh-hant)