developen

Testlerimizi otomasyon altına alırken yaşadığımız sorunların çözümünde, bazen test otomasyon araçlarının özüne dönmemiz gerekmekte.

Durumu net biçimde görmek için Apodoro incelemenizi tavsiye edebileceğim bir araç. Apodoro henüz emekleme aşamasında bir test otomasyonu aracı. Geliştirme ekibi, kullanım kolaylığından ziyade beceriyi öne aldığı için, arabirim üzerinden uygulamayı çalışırken izleme ve iç yapısını keşfetme şansı elde ediyoruz.

Apodoro’yu çalışırken izlediğinizde –ki bunu yapmak için uygulamayı kurmanıza bile gerek yok, online demo işinizi görecektir – bir test otomasyonu aracının bir GUI nesnesini ne şekilde algıladığını ve bu bilgiyi içerisinde hangi şekilde tasnif ettiğini görebilirsiniz. Kulağınıza şunu da fısıldamak isterim: Devasa HP Mercury QuickTest Professional aracı da – onlarca nefis özellik ile süslenmiş olsa da- GUI nesnelerini aynı mantık ile tasnif etmektedir.

Tüm modern test otomasyonu araçları, GUI nesnelerini tanımlamak için Apodoro’ya benzer biçimde çalışırlar. İşte bazen bu sebeple GUI nesnelerine gerektiğinde aşağıdakine benzer eklentiler yaparız.

// Otomasyon alt yapımız bunun buton olduğunu biliyor ve
// dolayısıyla "Click" edebilir yada "Enabled" özelliği
// "Expected Results" içerisinde kullanabiliriz.
public String sWidgetType = "wgButton";

Yada

// Artık bu butonun hangi buton olduğunu biliyoruz
newAccButton.sWidgetID   = "Home.Accounts.NewAccount.Ok";

Test aktivitelerinin ne şekilde dokümante edilmeli? Yada test aktiviteleri gerçekten dokümante edilmesi gereken aktiviteler midir? Bu soruları çok sık duymakla beraber, bunlar ayrıca meslektaşlarımızın da uzun süredir tartıştiğı sorular.

Ben kendimi dokümantasyon konusunda gayet orta yolcu biri olarak düşünürüm. Faydalarına inanır ama imkansızlıkları da kabullenirim. Bu sebeple kendi yaklaşımımı burada kabaca masaya yatırmak istedim –ki tekrar bu soruyu duyduğumda, soruyu sorana gönderebileceğim bir permalink’im olsun.

Dokümantasyonun fonksiyonel katkilari tabii ki yadsınamaz. Bu sebeple mümkün olan her durumda test aktivitelerinin dokümante edilmesi gerektiğini düşünüyorum.

Özellikle hetorojen bilgi ve deneyime sahip bireylerden oluşan bir ekip ile çalismak durumundaysanız, dokümantasyon, ekibin tümünün büyük resmi görerek aynı hedefe daha net biçimde ilerlemesine yardımcı olacaktır. Ayni şekilde geliştirme ekibinin tümünün de aynı kalite bilincine sahip olması için dokümantasyon iyi bir araçtir.

Diger taraftan dokümante edilmis bir test planı, yazılım yasam döngüsü süresince, test ekipleri gibi yoldan çıkmaya müsait ekipleri dogru yolda tutabilir. Öngörülen riskler ve başlangıçtaki hedeflerimizi birinin gözümüze sokuyor olması, gereksiz test aktivitelerinin engellenmesi için “olmazsa olmaz” dır.

(DEVAM EDIYOR)

Eğer bir hatanın ciddi olduğuna inanıyorsanız, bu hatanın düzeltilmesi için mücadele etmekten çekinmeyin. Bu, bir test mühendisinin yaptığı işe saygısı gereği takınması gereken bir tavırdır. Eğer bir hata düzeltilmeyecek ise, bunun geçerli bir sebebi sunulmalıdır.

Hata durum toplantılarında siz de buna benzer birşeyler duymuşsunuzdur eminim: “Evet bu bir yazılım hatası ama hiçbir kullanıcı bu hatayı tetikleyecek birşey yapmaz!” Yada kahve almaya gittiğinizde karşılaştığınız geliştiriciye, üzerinde çalıştığınız anomaliden söz ederseniz, omuzlarını kaldırıp kaşlarını çatarak “Ah, evet.. Ne olduğunu biliyorum.. Raporlayın bunu, aradan çıkarırız..” derler.

Lafı uzatmaya gerek yok. Geliştiriciler hataları önemsememe eğilimindedirler. Bunu biliyorum, zira bende bir zamanlar onlardan biriydim.

Evet mission critical olmayan her yazılım, bilinen hatalar ile sunulurlar. Ama her hata, yazılım ile birlikte sunulmak zorunda da değildir. Eğer bir hatanın ciddi olduğuna inanıyorsanız, bu hatanın düzeltilmesi için mücadele etmekten çekinmeyin.

Uğruna savaşılacak şeyleri dikkatle seçip, savaşmak gerektiğinde de kazanmak için savaşmak hiç de kötü bir alışkanlık değildir.