Bugzilla:QA: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Update to reference Github)
 
(45 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== QA team ==
== QA team ==
Since July 11, 2005, [http://www.bugzilla.org/news two days] after the release of Bugzilla 2.18.3, the QA team has been created to improve the quality of future releases. [http://www.bugzilla.org/releases/2.20/ Bugzilla 2.20] has been our most stable version ever released, with many security bugs fixed. This result has been possible partly thanks to the hard work done by the QA team. But all the testing has been done manually, which required both a lot of time and a lot of people (the QA team has 9 members) to test the most important features of Bugzilla.
The QA team was created on July 11, 2005, two days after the release of Bugzilla 2.18.3, to improve the quality of future releases. [http://www.bugzilla.org/releases/2.20/ Bugzilla 2.20], which was released two months later, became our most stable version ever released, with many security bugs fixed. This result has been possible partly thanks to the hard work done by the QA team which found several tens of bugs. But all the testing has been done manually, which required both a lot of time and a lot of people (the QA team had less than 10 members) to test the most important features of Bugzilla.


As repeating the same tests manually again and again for each new release quickly became rather boring, we tried to automate the process as much as possible. To help us in this task, the QA team is now working on a [http://www.openqa.org/selenium/index.html Selenium] installation on [http://landfill.bugzilla.org/selenium/bugzilla/index.html landfill] which can either be run from a web browser or from a Perl script directly.
As repeating the same tests manually again and again for each new release quickly became boring, we decided to automate the process as much as possible using [http://seleniumhq.org/ Selenium]. The QA team uses [https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=tree;f=xt;hb=HEAD Perl Selenium scripts].


== Writing Selenium scripts ==
== How to contribute? ==
Scripts executed from a web browser and those called from a Perl script use a different syntax, the first ones being pure HTML, the second ones being written using Perl language.
As Selenium cannot do everything, and because someone has to write these scripts anyway, we are always looking for new testers. If you are interested in helping us making Bugzilla better and more stable, feel free to join us. The best way to start is to join us in the [irc://irc.mozilla.org/bugzilla #bugzilla] channel on IRC telling us that you are interested in contributing. Of course, you can also report bugs you discover to [https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla b.m.o] directly. If you want to help with automated tests, you are highly encouraged to read below, and download our existing test scripts.


=== Scripts run from a web browser ===
== Running Selenium scripts ==
This is the easiest way to use Selenium. After having downloaded and untar'ed the tarball (we still use version 0.6.0 despite 0.8.1 is out, for compatibility issues), scripts simply consist of a table with three columns (command, field, value). A template is available in [https://bugzilla.mozilla.org/show_bug.cgi?id=317695 bug 317695] (template.html), as well as a useful Javascript file for most common actions (user-extensions.js).
A read-only copy of the current Selenium scripts can be downloaded using git:
git clone https://github.com/bugzilla/bugzilla.git


[http://openqa.org/selenium-ide/ selenium-IDE] ([https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&category=Newest&numpg=10&id=2079 amo], formerly [http://seleniumrecorder.mozdev.org/ Selenium Recorder]) is a Firefox extension which writes scripts for you. It records your actions and converts them into a valid Selenium script. If you decide to install this extension, you don't need to install Selenium separately; everything is included in the XPI package (samples and docs are not included though).
A read/write copy can also be downloaded:
git clone git@github.com:bugzilla/bugzilla.git


=== Scripts called by a Perl program ===
A script named <em>xt/config/generate_test_data.pl</em> will automatically populate new installations, allowing the Selenium and WebService tests to be executed.
The installation and configuration are a bit harder. First download and install [http://search.cpan.org/~lukec/Test-WWW-Selenium/ Test::WWW::Selenium]. In case you still use version 0.03, the following modules are required too:


requires:
'''Note 1:''' The Bugzilla installation to test must already exist, and must already have its important parameters configured (i.e. ''urlbase'', ''cookiepath'', and ''mail_delivery_method''). It is recommended that ''mail_delivery_method'' be set to '''Test''', unless "actual" bug mail is desired.
  Alien::Selenium
  Frontier::Client
  Frontier::RPC2
  LWP v5.8
  POE v0.29
  POE::Component::Client::UserAgent
  POE::Component::Server::HTTP
  Test::LongString
build_requires:
  HTTP::Daemon
  Test::More v0.47


When all these modules are installed, you will also need the SeleniumTest.pm module available in [https://bugzilla.mozilla.org/show_bug.cgi?id=317695 bug 317695] which is a simplified version of the one given with the Test-WWW-Selenium tarball. An example of a test script - 012qa.t - is also provided, which can e.g. be executed with runtests.pl, a Perl script available in the Bugzilla distribution.
'''Note 2:''' Before executing <em>generate_test_data.pl</em>, make sure the parameters in <em>xt/config/selenium_test.conf</em> are set correctly. This configuration file must match the Bugzilla configuration, especially the ''urlbase'' parameter and the path to the browser. If ''mail_delivery_method'' is set to '''Test''', fake user accounts can be defined in the config file.


For newer versions of Test::WWW::Selenium, requirements are different and SeleniumTest.pm is no longer required. Note that your old scripts running on 0.03 won't run on newer versions anymore.
Once the DB is populated, start the Selenium server and execute the scripts in xt/selenium. To start the Selenium server, type:
java -jar /path/to/selenium-server-standalone-2.x.x.jar


As you can see, the syntax is different between HTML and Perl scripts, but the commands remain mostly the same. Make sure to end all your commands by "_ok" to generate an output on your screen. The format is now $test->command_name_ok('field', 'value', 'description'), where $test is the test object created by SeleniumTest.pm and which will do the interface between your test script and the web installation.
The Selenium Server can be downloaded from the [http://seleniumhq.org/download/ Selenium] website. To execute the scripts, go into the t/ directory and enter:
prove -v --timer *.t


The description is optional, but gives very useful information. A typical output is of the form:
-v will make the output verbose and --timer will display the time it takes to execute each script. Both options are optional. Note that the [http://search.cpan.org/~lukec/Test-WWW-Selenium/ Test::WWW::Selenium] Perl module must be installed in order for the scripts to execute.  It is the interface between Perl and Selenium!


t/012qa....1..7
== Writing Selenium scripts ==
ok 1 - Load query.cgi
The fastest way to write new Selenium scripts is to use the [http://seleniumhq.org/download/ Selenium IDE] extension for Firefox (note that [http://release.seleniumhq.org/selenium-ide/1.0.12/selenium-ide-1.0.12.xpi Selenium IDE 1.0.12] is the last version to export Selenium scripts to the Perl language! Starting with version 1.1.0, the Perl exporter is no longer available). It records all your actions and converts them into a valid Selenium script. You can also write Selenium scripts manually with a text editor, but this is longer and can be pretty painful.
ok 2 - Check title
ok 3 - Enter and check input in the short_desc field
ok 4 - Recheck the input (using a different method)
ok 5 - Submit request (-> buglist.cgi)
ok 6 - Check title
ok 7 - Make sure that no bug is returned (0 bug found)
ok
All tests successful.


What you can read here are the descriptions given for each command of the script. This makes debugging much easier!
Each command is of the form $sel->command_name_ok('field', 'value', 'description'), where $sel is the test object created by Test::WWW::Selenium. The description is optional, but may give some useful information. All available commands are listed [http://search.cpan.org/~mattp/Test-WWW-Selenium/lib/WWW/Selenium.pm here], and are fully documented.
 
== How to contribute? ==
As Selenium cannot do everything, and because someone has to write these scripts anyway, we are always looking for new testers. If you are interested in helping us making Bugzilla better and more stable, feel free to join us. The best way to start is to join us in the [irc://irc.mozilla.org/qa-bugzilla #qa-bugzilla] channel on IRC, or to write to [mailto:qa@bugzilla.org qa@bugzilla.org] telling us that you are interested. Of course, you can also report bugs you discovered to [https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla b.m.o] directly.


Since mid-2006, we use a [http://landfill.bugzilla.org/bugzillaqa Testopia installation] to track testing progress and to let us easily manage remaining tests to do. See e.g. [http://landfill.bugzilla.org/bugzillaqa/tr_list_runs.cgi?plan_id=3 tests we did on October 2006] when we released 2.18.6, 2.20.3, 2.22.1 and 2.23.3. That's another way to help us efficiently, avoiding testing what has already been tested.
There are [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIXED+testcase%3F many bugs] which need a test. You can pick one of them and write a test, either by improving one of the existing tests, or by writing a completely new one. There are also some other [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=prod%3ABugzilla+comp%3AQA existing scripts] which need improvements. If you want to submit a script, please file it [https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=QA%20Test%20Scripts here].


As we are still doing some tests manually as mentioned above, you can either do manual tests or choose one of the two approaches described previously to write automated tests. In the latter case, and if you don't want to install all the required modules or cannot get them working, writing HTML scripts is probably what you want to do. One day, we will probably write a conversion tool, allowing us to write scripts in HTML and convert them in Perl and vice versa.


[[category:Bugzilla]]
[[category:Bugzilla|QA]]


[http://www.bugzilla.jp/bzwiki/bz/Bugzilla:QA Ja]
[http://www.bugzilla.jp/bzwiki/bz/Bugzilla:QA Ja]

Latest revision as of 13:08, 5 August 2016

QA team

The QA team was created on July 11, 2005, two days after the release of Bugzilla 2.18.3, to improve the quality of future releases. Bugzilla 2.20, which was released two months later, became our most stable version ever released, with many security bugs fixed. This result has been possible partly thanks to the hard work done by the QA team which found several tens of bugs. But all the testing has been done manually, which required both a lot of time and a lot of people (the QA team had less than 10 members) to test the most important features of Bugzilla.

As repeating the same tests manually again and again for each new release quickly became boring, we decided to automate the process as much as possible using Selenium. The QA team uses Perl Selenium scripts.

How to contribute?

As Selenium cannot do everything, and because someone has to write these scripts anyway, we are always looking for new testers. If you are interested in helping us making Bugzilla better and more stable, feel free to join us. The best way to start is to join us in the #bugzilla channel on IRC telling us that you are interested in contributing. Of course, you can also report bugs you discover to b.m.o directly. If you want to help with automated tests, you are highly encouraged to read below, and download our existing test scripts.

Running Selenium scripts

A read-only copy of the current Selenium scripts can be downloaded using git:

git clone https://github.com/bugzilla/bugzilla.git

A read/write copy can also be downloaded:

git clone git@github.com:bugzilla/bugzilla.git

A script named xt/config/generate_test_data.pl will automatically populate new installations, allowing the Selenium and WebService tests to be executed.

Note 1: The Bugzilla installation to test must already exist, and must already have its important parameters configured (i.e. urlbase, cookiepath, and mail_delivery_method). It is recommended that mail_delivery_method be set to Test, unless "actual" bug mail is desired.

Note 2: Before executing generate_test_data.pl, make sure the parameters in xt/config/selenium_test.conf are set correctly. This configuration file must match the Bugzilla configuration, especially the urlbase parameter and the path to the browser. If mail_delivery_method is set to Test, fake user accounts can be defined in the config file.

Once the DB is populated, start the Selenium server and execute the scripts in xt/selenium. To start the Selenium server, type:

java -jar /path/to/selenium-server-standalone-2.x.x.jar

The Selenium Server can be downloaded from the Selenium website. To execute the scripts, go into the t/ directory and enter:

prove -v --timer *.t

-v will make the output verbose and --timer will display the time it takes to execute each script. Both options are optional. Note that the Test::WWW::Selenium Perl module must be installed in order for the scripts to execute. It is the interface between Perl and Selenium!

Writing Selenium scripts

The fastest way to write new Selenium scripts is to use the Selenium IDE extension for Firefox (note that Selenium IDE 1.0.12 is the last version to export Selenium scripts to the Perl language! Starting with version 1.1.0, the Perl exporter is no longer available). It records all your actions and converts them into a valid Selenium script. You can also write Selenium scripts manually with a text editor, but this is longer and can be pretty painful.

Each command is of the form $sel->command_name_ok('field', 'value', 'description'), where $sel is the test object created by Test::WWW::Selenium. The description is optional, but may give some useful information. All available commands are listed here, and are fully documented.

There are many bugs which need a test. You can pick one of them and write a test, either by improving one of the existing tests, or by writing a completely new one. There are also some other existing scripts which need improvements. If you want to submit a script, please file it here.

Ja