[Gelistirici] Test surecleri

[Serbulent UNSAL]

On Sunday 05 October 2008 20:06:21 Erkan Tekman wrote:
> 5 Ekim 2008 Pazar 12:09:07 tarihinde Serbulent UNSAL şunları yazmıştı:
> > Önerim şu; Test deposundaki paketinin yeterli kararlılığa ulaştığını
> > düşünen geliştirici listeye ( sanırım en uygunu geliştirici listesi )
> > mail atar ve test isteğinde bulunur. Test sorumlusu bu isteği yakalar ve
> > paket ile ilgili test sürecini işletir[1]. Test sürecinin sonunda ortaya
> > çıkan sonucu listeye gönderir.
>
> Bu cümle ile test deposunu devel ve hatta playground haline getirmiş
> oluyoruz, kabul edilemez. Test deposuna alınan bir paket, paket sorumlusu
> tarafından testi yapılmış ve daha genel bir entegrasyon / farklı
> senaryo(lar) testi için bu depoya alınmış demektir. Aylardır söylediğimi
> yineleyeceğim: "Ciddi" bir test ve kalite güvence takımı tarafından bu
> paketler (vurgulamak gerekirse test deposundaki güncellenmiş paketler)
> sürekli bir işlevsellik testine tabi tutulmalılar. Bu aşamada test ekibi
> temelde paket sorumluları için çalışmakta...
>

Hayır öyle olmuyoruz. Belki  tam olarak anlatamadım. Şu anki şekilde devam 
edecek test deposuna paket girişi. Merge isteğinde bulunan geliştirici bu 
isteği STABLE deposu için yaptığının bilincinde olacak.

> ACK/NACK süreci ise sürüm yöneticisinin denetim ve yürütmesinde bir hal. Bu
> açıdan düşününce sürüm yöneticisi paket sorumlularına işlevsel testlerin
> yapılıp yapılmadığını soruyor diye anlıyorum, nihai ACK/NACK ise sürüm
> yöneticisi ve test ekibi tarafından sistem genelinde entegrasyon sorunu
> yaşanmadığını garantileyecek şekilde verilmeli. Bu aşamada test ekibi
> temelde sürüm yöneticisi için çalışmalı...
>
> Benim önerim, yine, test işleri ile ACK/NACK bağlantısını biraz koparmak ve
> test deposu üzerinde sürekli işlevsel testleri yürütmek şeklinde.

Bu yaklaşımın pratikte bir takım problemleri olacaktır; Birincisi basit bir 
dosya çevirici programı bile 8-10 farklı şekilde kullanmak mümkünken pek çok 
uygulama onlarca farklı kombinasyon ve özellik ile çalıştırılabiliyor. 

İlk kabul etmemiz gereken şey bütün uygulamaları bütün işlevleri ile test 
etmenin insan gücü ile mümkün olmadığı. Bu bağlamda test/kalite takımı 
tarafından yürütülecek testlerde paketler dağıtım için önemine göre 
gruplanarak, önemine bağlı olarak artan sayıda işlev ile test edilmedir ( ki 
şu anki durum budur ) .  

Paket de yapılan güncellemenin neleri etkileyebileceği hangi paketlerde 
regression a sebep olabileceği paketin sorumlusu ( paketi güncelleyen kişi) 
tarafından takip edilmeli ve buna uygun biçimde test edilmeden merge 
isteğinde bulunulmamalıdır.

İkincisi test işleri ile ACK/NACK bağlantısı kopartılırsa test deposunda olan 
bir paket sürüm yükselttiğinde bu paket yeterince test edilmeden kararlı 
depoya girme riski taşıyor. 


>ACK/NACK aşamasında ise test ekibi bambaşka bir yaklaşımla, işlevsel 
>testlerden çok entegrasyon, tutarlılık ve uyumluluk testleri yapmalı. 

Benim önerdiğim yaklaşımda bunların hiçbirinden taviz içermiyor. Hali hazırda 
uygulamakta olduğumuz testleri "(kararlı depo) + (yeni paketler)" şeklindeki 
depodan yapma politikamız devam ediyor. Buna ek olarak test süreci 
hızlanacağı için kritik güncellemeler dahil hiçbir paket testten geçmeden 
kararlı depoya girmemiş oluyor.


-- 
İyi Çalışmalar;
 
Serbülent