Thursday, February 23, 2017

TestRail İncelemesi

TestRail bir test yönetim aracıdır.

Ürünün Web Sitesi: TestRail
Deneme Sürümü (Ücretsiz Üyelik): https://secure.gurock.com/customers/testrail/trial/

Öne çıkan özellikleri; web üzerinden erişilebiliyor olması, içerdiği alanların konfigüre edilebiliyor olması (yeni alanlar eklenebilmesi) ve hata takip araçları ile entegre olabilmesi.

Özellikle yöneticilerin / liderlerin testlerin ilerleyişini takip edebilmeleri için faydalı. Ayrıca test geliştiricilerinin de düzenli ve hızlı şekilde test oluşturmalarına imkan sağlıyor.

Ben deneme sürümünü kullanma fırsatı yakalayabildim, burada yazdığım değerlendirme de bu deneme sürümüne yönelik.
Diğer test yönetim araçları ile arasında bir karşılaştırma yapmadım bu değerlendirmede.

Sonda söyleyeceğimi başta söyleyim:
TestRail, kullanımı ve yönetimi gayet kolay bir araç. Benim, aracın büyük çoğunluğuna hâkim olmam yaklaşık 2 saatimi aldı.
Kullanmaya başlamadan önce ilk olarak "Administration" sekmesinin içeriğini detaylıca kontrol etmekte fayda var, çünkü olmadığını düşündüğüm pek çok özelliğin aslında var olduğunu "Customizations" alt-sekmesinde gördüm.
Kurumunuzun ihtiyaçlarına yönelik olarak test durumlarının içerdiği alanları özelleştirmekten tutun, piyasada yaygın olarak kullanılan hata takip araçlarına entegrasyona kadar pek çok yetenek dahil edilmiş.
Ben sanırım 2 sene önceki bir sürümünü kullanmıştım, pek hoşuma gitmemişti. Fakat şu anki hali gerçekten şaşırttı beni. Gereksinim izlenebilirlik aracı ile entegrasyon da olduğu söylenmiş ama onu deneyemedim.

Bu aracı şirket içinde yaygınlaştırma kararı vermek isteyenlerin, şirketin ilerde ortaya çıkabilecek ihtiyaçlarını da düşünerek gereksinim yönetim araçları ile entegrasyon, raporlama yetenekleri, TestRail'da yazılan testlerin diğer bir uygulamaya aktarılması gibi yetenekleri de sorgulaması faydalı olacaktır.

Olumsuz Tarafları:
  • Test adımları içine tablo ekleme biraz karışık olmuş.
  • Test durumları içine yeni alanlar eklenebiliyor fakat bu eklenen alan üzerinden rapor alabilme yeteneği (gördüğüm kadarıyla) yok. Örneğin test durumu içine "İlgili Ekran" şeklinde bir alan eklenirse, rapor olarak ' "İlgili Alan" alanı boş olan test durumlarını raporla' veya '"Giriş Sayfası" ekranını test eden test durumlarını listele" şeklinde bir rapor alamadım.
  • Oluşturulan testlerin hepsinin nihai hali olduğunu düşünmüşler sanırım. Bir testin henüz geliştirilmesi devam ediyorsa, durumunun taslak olarak belirtilmesi gibi bir yetenek yok. Evet, "Test Runs" oluşturulurken test durumları seçilebiliyor ancak binlerce test durumunun olduğu bir projede, bir test durumu eklerken öncesinde bir süzme yapmak gerekiyor. Süzgeç koymuşlar fakat "Test Case Status" gibi bir alan olmadığından henüz geliştirilmesi bitmemiş bir test durumunu da "Test Runs" içine yanlışlıkla dahil edebiliriz.
  • "Overview" sekmesinde, projenin / ürünün kaç tane test olması gerekiyordu, bunların %de kaçını yazdık, test geliştirme açısından ne kadar gerideyiz, gibi sorulara bir cevap veren bir mekanizma göremedim.
  • Proje planlama araçları ile bir entegrasyon (gördüğüm kadarıyla) yok.


Olumlu Tarafları:
  • En başta, testlerin yazımı ve test koşularının genel durumunu göstermesi açısından faydalı bir ürün. Pek çok firmanın ihtiyacını karşılar nitelikte.


  • "Todo" Sekmesi
    • "Todo" sekmesinde bir kişinin veya tüm ekibin yapması gereken test koşularının listesi verilmiş.
    • Test koşularının sonuçlarına (Passed, Failed, Untested, Blocked, Retest) göre filtreleme yapmak da mümkün.
  • "Milestones" Sekmesi
    • "Milestones" sekmesinde projenin iterasyonlarına ait bilgiler giriliyor ve bu iterasyonlara testler dahil ediliyor.
  • "Test Cases" Sekmesi:
    • Test durumları yazılırken test adımlarının hepsi bir alanda, beklenen sonuç(lar) da bir alanda olacak şekilde yazabiliyorsunuz. Ayrıca, standartlarda beklenen "Adım - Beklenen Sonuç" ikilisi şeklinde de test adımları yazılabiliyor.
    • Test adımları içine "PrintScreen - CTRL+V" tuş kombinasyoları ile ekran görüntülerini eklemek mümkün. Ayrıca bu ekran görüntüleri hem adım hem de beklenen sonuç alanlarına eklenebiliyor.
    • Yine test durumu içine, ekranın sağındaki alandan herhangi bir türde dosya eklemek mümkün.
    • Yine "Test Cases" sekmesinde bir test durumunun detayları, hangi test koşularının içinde olduğu, hangi hataların açıldığı ve test durumu üzerinde daha önce yapılan değişikliklerin tarihçesi de görülebiliyor; gayet güzel.
    • "Print" düğmesine tıklanarak istenen test durumlarının PDF çıktısı alınabiliyor.
  • "Test Runs" Sekmesi
    • "Test Runs" sekmesinde bir test koşusunda hangi testlerin koşacağı planlanıyor. Bu test koşuları, bir "Test Plan"a dahil edilebiliyor, test planının konfigürasyonu (hangi işletim sistemleri, web gezginleri, donanım tipleri, gibi) ayarlanabiliyor. Güzel bir özellik. Böylece, test koşularının her bir test konfigürasyonunda tekrar edilebilmesi, takip edilmesi ve raporlanması da sağlanmış.
    • Test planlarının görünümü Durum, Aktivite, İlerleme ve Hatalar'a göre ayarlanabiliyor, böylece testin ilerleyişine farklı açılardan bakmak mümkün oluyor.
    • Test planlarının raporları farklı ihtiyaçlara göre oluşturulabiliyor. Öyle sanıyorum ki deneme sürümündeki bu rapor sayısı, ücretli TestRail sürümünde çok daha fazladır.




  • "Reports" Sekmesi
    • Bir rapor oluşturulurken ("Reports" sekmesi) hangi tür testler veya hangi test durumları dahil edilecek, hangi test koşularının / test planlarının sonuçları raporlanacak, rapora kimler erişebilir, bu rapor ne zaman ve hangi periyotlarda üretilecek, rapor üretilince kimlere e-posta gönderilsin gibi gayet güzel özellikler içeriyor.
    • Deneme sürümündeki kullanılabilecek rapor şablonları şöyle:




  • "Administration" Sekmesi
    • Bu sekme, TestRail'ın yönetimi için kullanılıyor. Aşağıda görülen alanlarda ayarlamalar yapılabiliyor.




Thursday, February 16, 2017

Test Mühendisliğinde Olası Riskler ve Alınabilecek Tedbirler

Bir proje / ürün geliştirmesi sürecinde test mühendisliği açısından pek çok risk bulunmaktadır. Aşağıdaki resimde örnek bir risk listesi bulunmaktadır:


Bu liste, proje / ürün bazında daha da detaylandırılabilir.

Test faaliyetlerinden sorumlu lider mühendisin, bu tarz bir risk yönetimi yapmasının faydası, ilerde ortaya çıkabilecek sorunlara karşı önceden hazırlık yaparak (proaktif bir yaklaşım ile) süreci yönetmesidir. Bu risklerin bazısı ürün yaşam döngüsü (SDLC) boyunca hiç gerçekleşmeyebilir de, ancak hazırlıklı olmak her zaman faydalıdır.

Aşağıdaki listeye isteğe bağlı olarak Olasılık ve Etki (Önem) sütunları da eklenebilir. "Risk yönetimi nedir, nasıl yapılır" diye daha detay bilgi arayanlar "IEEE-STD-1540-2001-Risk management" standardına bakabilirler.

Ana Başlık Risk Alınabilecek Eylem
Değişiklik Alanları


Gereksinimlerde / Arayüzlerde Değişiklik - Değişiklik ihtiyacının müşteri (iç müşteri) ile koordine edilmesi,
- Değişiklikten etkilenecek alt ürünlerin (tasarım maddesi, ekran, doküman, testlerin) belirlenmesi,
- Değişikliğin tüm alt ürünlere uygulanması ve gözden geçirilmesi,
- Değişiklikten etkilenen testlerin ve entegrasyon testlerinin yeniden koşturulması.

Testten Geçmiş Modüllerde Kod Değişikliği (Hata düzeltme veya gereksinim / arayüz değişiklikleri olması durumunda)
- Kod değişikliğinin etkilediği fonksiyonların belirlenmesi,
- Bu fonksiyonları doğrulayan testlerin belirlenmesi,
- Testlerin tekrar koşturulması
Test Ortamı Altyapısı


Kurulum Hataları - Kurulum dokümanı / ürünündeki hatanın tespiti,
- Kurulumun tekrarlanması,
- İlgili testlerin tekrar koşturulması.

- Kullanılan kütüphane ve ek uygulamaların versiyonlarının doğru olmasının sağlanması için bu ürünlerin sadece proje kütüphanesinden alınması (bu kütüphane konfigürasyon yönetim uzmanı kontrolünde olmalı).

Donanım Bozulmaları - Bellek, sabit disk gibi OEM parçaların bozulma ihtimaline karşı risk bütçesi belirlenmesi,
- Tedarik sürelerinin göz önüne alınarak test planlamasının yapılması.

Son Kullanıcı Ortamı ile Farklılık - Son kullanıcı / müşteri ortamının detaylı olarak incelenmesi,
- Test ortamının müşteri ortamına göre kurulması,
- Farklılık olması durumunda, farklılıklardan kaynaklanabilecek sorunlara karşı, müşteri ortamında en erken zamanda kontrollerin yapılması.

Yetersiz Donanım Sayısı - Test mühendislerinin ihtiyacından az donanım olması durumunda ve bu donanımın tedarik edilmesi mümkün değilse, test koşturma takviminin buna göre planlanması veya vardiya usulü çalışma,
- Geliştiricilerin hata izolasyon yapabilmeleri için test ortamının bir kopyasının sanal sunuculara kopyalanması veya test ortamı kullanım zamanlarının geliştirici ihtiyaçlarına da uygun olarak planlanması.

Test Sırasında Ortama Dışardan Müdahale Edilmesi - Test ortamına veri / ürün aktarımının konfigürasyon yönetim uzmanı / kalite güvence uzmanı eşliğinde yapılması,
- Test ortamının izole edilmesi (ağ bağlantılarının sökülmesi, gerekirse USB bellek, CD/DVD takılmasının engellenmesi)
Test Faaliyetleri


Test Dokümantasyonunda Hatalar - Test dokümanlarının mutlaka lider mühendis ve geliştiriciler tarafından gözden geçirilmesi.

Test Mühendislerinin Hataları - Testlerin tasarlanması, yazılması ve koşturulması süreçlerinin lider mühendisin yakın kontrolü altında yapılması.

Test Mühendislerinin Yetkinliklerinin Az Olması - Proje süresince kullanılacak ürün, standartlar ve teknikler açısından test mühendislerinin bir eksiği varsa, bunların şirket içi / dışı eğitimlerinin proje başında planlanması ve yeterli bir süre öncesinde verilmesi.

Testlerin Bütçesini / Süresini Aşması - Gecikmeler olabileceği düşünerek, doğrulama faaliyetine en erken aşamada (gereksinim analiz aşamasında) başlanması,
- İterasyonlar bazında testlerin koşturulması,
- Test planından sapma olması durumunda, fazla çalışma veya ek personel takviyesi ile gecikmenin (ileride daha fazla sapmaya neden olmasına izin vermeden) ortadan kaldırılması.

Testlere Geç Başlanmış Olması - Geliştirici bilgisayarında, test mühendisi tarafından testin yapılıp, kodun “commit”lenmesi öncesinde mümkün olduğu kadar çok hatanın tespit edilmesi ve düzeltilmesi, böylece hata akışı yaşam döngüsünün süresinin azaltılması.

(Çeşitli sebeplerle testlere geç başlanması gerekmişse)
- Teslimat tarihlerinin ötelenmesi,
- Eğer öteleme imkanı yoksa, ek destek personeli ile testlerin paralel koşturulması (tabii bunun için yedek bir test ortamı olması gerekecek),
- Vardiya usulü ile çalışma (bu yöntemin çok sayıda olumsuz tarafı var).

Test - Gereksinim - Fonksiyon / Ekran İzlenebilirliğinde Eksikler - Her bir gereksinim, tasarım maddesi, müşteri isteği, toplantı tutanacağı maddesi ve ekranların en az bir test tarafından kapsandığının periyodik olarak kontrol edilmesi.
Müşteri / Son Kullanıcı Tarafı


Koordinasyon Eksiği - Proje sistem mühendisi / ürün sorumlusunun müşteri temsilcileri ile haftalık koordinasyon toplantıları yapması, ilerleme ve gecikmeler hakkında erken zamanda bilgi vermesi,
- Son kullanıcılar ile yakın iletişim içinde bulunarak hatalı / zor kullanılan yeteneklerin, kullanıcıda bir hassasiyet oluşmaya başlamadan ortadan kaldırılması.

Test / Kabul İçeriğinin Eksik Aktarılmış Olması - Her bir test / kabul aşamasında, tüm projenin kabule temel teşkil eden yeteneklerinden nelerin test edileceği kabul heyetine aktarılmalı,
- Kabule girecek müşteri temsilcilerinin ürün yeteneklerin hakim olmalarının sağlanması için test öncesinde oryantasyon verilmesi.

Kabul Ekibinin Değişmesi - Kabul ekibinin değişmesi durumunda oryantasyonların tekrar edilmesi,
- Oryantasyondan kaynaklanacak gecikmelerin teslimat süresine eklenmesi gerektiğinin müşteri ile koordine edilmesi.