Bugzilla:QA: Difference between revisions

873 bytes removed ,  5 August 2016
Update to reference Github
m (The QA mailing-list no longer exists)
(Update to reference Github)
 
(4 intermediate revisions by one other user not shown)
Line 2: Line 2:
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.
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 boring, we decided to automate the process as much as possible using [http://seleniumhq.org/ Selenium]. For Bugzilla 2.20.x, 2.22.x and 3.0.x, we used test installations on landfill, which were running HTML Selenium scripts. Since Bugzilla 3.2 RC1, the QA team uses [http://bzr.mozilla.org/bugzilla/qa/ Perl Selenium scripts], which offer many advantages over their HTML equivalent.
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].


== How to contribute? ==
== How to contribute? ==
Line 8: Line 8:


== Running Selenium scripts ==
== Running Selenium scripts ==
Prior to Bugzilla 3.2, Selenium tests were all written in HTML and executed from a web browser. As of Bugzilla 3.2 RC1 they have been converted to Perl, allowing more flexibility and control.
A read-only copy of the current Selenium scripts can be downloaded using git:
git clone https://github.com/bugzilla/bugzilla.git


A read-only copy of the current Selenium scripts can be downloaded using bzr with:
A read/write copy can also be downloaded:
  bzr co bzr://bzr.mozilla.org/bugzilla/qa/4.0
  git clone git@github.com:bugzilla/bugzilla.git


A read/write copy can also be downloaded with:
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.
bzr co bzr+ssh://''login''@bzr.mozilla.org/bugzilla/qa/4.0
where ''login'' is your LDAP account. All available releases are listed [http://bzr.mozilla.org/bugzilla/qa/ here].
 
'''Note:''' The HTML scripts available in 3.0 and below won't work as is. They were based on a particular landfill installation which contained specific user accounts, products, components and parameters.  Thus, they will not run on a fresh test installation. They have been removed from 3.2.
 
As of Bugzilla 3.2, a script named <em>config/generate_test_data.pl</em> 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 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 <em>generate_test_data.pl</em>, make sure the parameters in <em>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 ([http://seleniumhq.org/download/ Selenium RC 2.0] works with Firefox 5 and IE9). If ''mail_delivery_method'' is set to '''Test''', fake user accounts can be defined in the config file.
'''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.


Once the DB is populated, start the Selenium server and execute the scripts in t/. To start the Selenium server, type:
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
  java -jar /path/to/selenium-server-standalone-2.x.x.jar


Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits