Pardus Testing Team

From PardusWiki
(Difference between revisions)
Jump to: navigation, search
(Test Deposu Adresleri)
(Upgrade Tests)
Line 45: Line 45:
 
====Upgrade Tests====
 
====Upgrade Tests====
  
Bu süreç için öncelikle, test edilen kararlı sürüm ( örneğin Pardus-2007 ) ve o ana kadar çıkmış ara sürümlerin her birinin ( örneğin 2007.1 , 2007.2 , 2007.3 ) yeni kurulmuş birer versiyonuna sahip olmamız gerekir. Her bir testin ardından tekrar bu temiz kurulumlara ihtiyaç duyacağımızdan bu sürümleri sanal görüntü olarak kurmak ( misal VirtualBox ile ;) ) sağlık ve de sıhhat açısından faydalıdır. Bu sanal görüntüleri güncelleme testlerinde kullanacağız.
+
For that kind of testing mechanism, you should have a freshly installed version of both the stable release ( e.x. Pardus-2007 ) and interim versions of this release ( e.x. 2007.1 , 2007.2 , 2007.3 ). After every Test process, as we are going to need a fresh version of these installations, installing these systems as a virtual image (e.x. using VirtualBox) is useful for your own health :) We are going to use these images in update tests.
  
Ayrıca her güncelleme sonrasında kararlı depodan güncellediğimiz düzenli güncellenen bir sanal imaja da ihtiyaç vardır.
+
Besides, we need another virtual image that is periodically upgraded from the stable repository after every repo updates.
  
Süreç genel hatları ile şöyle işler; Test sorumlusu test deposunda bekleyen paketler için bir onay süreci başlatır. Geliştiriciler tarafından onaylanan paketler o anki kararlı depo ve onay alan yeni paketlerden oluşan bir geçici depoya aktarılırlar. Temiz kurulmuş sürümlere bu deponun adresi verilerek sürümler güncellenir.
+
The Process generally works in that way: Testing Team Responsible starts an ACK process for the packages waiting in testing repository. The packages that receive ACK from the developers are merged to the current stable repository and to a temporary repository consisting of newly ACK'ed packages. Freshly installed releases are given the address of this temporary repository and being upgraded from this repository.
  
Her güncellenmiş sürüm yeniden başlatılarak temel sistemlerin sağlıklı işleyip işlemediği kontrol edilir. Ardından revdep-rebuild komutu ile ters bağımlılıklardaki kırık paylaşımlı kütüphane dosyalarının varlığı denetlenir.
+
Every upgraded release is being tested after restarting the system, in order to learn whether system is capable of doing basic things or not. After this, it is checked with ''revdep-rebuild'' command to control if any broken distributed library files in reverse dependencies are missing.
  
 
====Function Tests====
 
====Function Tests====

Revision as of 23:30, 11 September 2008

Contents

Pardus Testing Team

For every product or service that are produced by human beings, it is inevitable to contain bugs or errors. That's why quality assurance policies are needed for every product to decrease the rate of malfunctions.

The aim of Pardus Testing Team is to minimize the rate of malfunctions before the releases and after the releases. Another aim is to support the fix of bugs as soon as possible.

Contribution

Free Softwares are not developed and maintained by only the developers but also by the people who volunteers to make translations, help bug-fixing, test, contribute in terms of graphics and package the software. Testing is a good starting point to begin to contribute free software as it does not require much technical information and besides, helps in learning the softwares that are being tested.

How Can I Be a Member of Pardus Testing Team

We are expecting you to isolate the testing environment from your daily usage. You can ensure this via virtual machines, for testings inside Releases(packages, interim releases..etc.) However for testing the actual releases, testings before the releases, you definitely need a machine dedicated to this job.

Besides; you are expected to have basic skills of knowledge about Linux and Pardus. Although you are not expected to have a developer level of knowledge, questions like "What is your wireless card's name and its' vendor id?", "can you add the repo at the address xxxxxx, and then upgrade the system" should not sound unfamiliar to you.

You must register every computer you are going to use by filling the form at this adress and then send it to psts@ @.pngpardus.org.tr. An example fulfilled form can be seen from here.

How are the things going on for Testing Team before a Pardus Release

Before every main release, a form is sent to the Pardus Testing Team Members, and they provide hardware information of the machines which they plan to use as a testing machine. For every system a number is assigned.

With every testing release, Pardus Testing Team Members make a fresh installation and fill in the form they are provided according to the test results in the form. After that, they send these forms to the tester list when the forms are wanted.

If any bugs appear, they are entered to the bugzilla and being tracked by the reporter and the Testing Team Responsible till the bug is closed.

Pardus Testing Team Members answer to the feedbacks from Testing Team Responsible in a certain period of time and keep on doing these things till the stable release is announced.

Reporting Before Release Tests

After the release announcement, Pardus Testing Team starts testing with the help of the guide they are provided. The succesful steps are signed as

1.1 Yes
1.2 Yes
1.3 Yes

but the steps that are failed should be written in details as much as possible and be added to the final report. The final report is send to the tester list via e-mail as a "plain-text" . The header of the post should be in the form of "Test No:NN Sistem-XXX" .

How about the Tests during a Release

Tests during a Release is different from Before-The-Release Tests as this kind of tests start at the beginning of the new stable release and goes on till the release is maintained officially. That kind of Tests are seperated into two groups: "Upgrade Tests" and "Function Tests"

Upgrade Tests

For that kind of testing mechanism, you should have a freshly installed version of both the stable release ( e.x. Pardus-2007 ) and interim versions of this release ( e.x. 2007.1 , 2007.2 , 2007.3 ). After every Test process, as we are going to need a fresh version of these installations, installing these systems as a virtual image (e.x. using VirtualBox) is useful for your own health :) We are going to use these images in update tests.

Besides, we need another virtual image that is periodically upgraded from the stable repository after every repo updates.

The Process generally works in that way: Testing Team Responsible starts an ACK process for the packages waiting in testing repository. The packages that receive ACK from the developers are merged to the current stable repository and to a temporary repository consisting of newly ACK'ed packages. Freshly installed releases are given the address of this temporary repository and being upgraded from this repository.

Every upgraded release is being tested after restarting the system, in order to learn whether system is capable of doing basic things or not. After this, it is checked with revdep-rebuild command to control if any broken distributed library files in reverse dependencies are missing.

Function Tests

İşlev testi içinse, en son kararlı sürümün güncel hali test deposundan güncellenir ve güncellenen her bir program tek tek test edilir.


Resim:Surum ici1.jpg


VirtualBox veya benzeri bir sanal Makine ile bir defa kurulum yaptıktan sonra kararlı depoya her güncellediğinizde makinanızın bu noktadan görüntüsünü alabilir ve bir sonraki testi bu noktadan yapabilirsiniz. Böylece aynı paketleri her defasında kurmanız gerekemez.


Güncellenmiş kararlı sürüm yeniden başlatılarak temel sistemlerin sağlıklı işleyip işlemediği kontrol edilir. Ardından revdep-rebuild komutu ile ters bağımlılıklardaki kırık paylaşımlı kütüphane dosyalarının varlığı denetlenir.


Testçinin bütün program ve kütüphaneleri bütün özellikleri ile test etmesi bilgi, tecrübe ve zaman açısından mümkün görülmediği için test edilecek olan paketler 4 ana kategoriye ayrılmıştır. Bu kategoriler; Detaylı olarak test edilmesi gereken paketler , Standart biçimde test edilmesi gereken paketler ,Yalnız kurulum testine tabi tutulacak paketlerdir

Testing Repository Adresses

For Pardus 2007 : http://paketler.pardus.org.tr/testci-2007/pisi-index.xml.bz2

For Pardus 2008 : http://paketler.pardus.org.tr/testci-2008/pisi-index.xml.bz2

Hataları Raporlamadan Önce

Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox