Test Mühendisliği Açısından Konfigürasyon Yönetiminin Önemi

Gerek gayri-resmi (kabul öncesi) testler gerekse resmi testlerde test edilen ürünün versiyon bilgisinin "doğru" olması hayatı önem taşımaktadır.

Burada "doğru" tanımını biraz detaylandırmak gerekirse;

• Yazılımın oluşturma (build) süreci sonrasında her seferinde tekil (daha önce kullanılmamış) bir değeri olmalı,
• Bu değer her seferinde ardışık olarak artmalı; 1.0, 1.1, 1.2, gibi.

Yazılım şirketlerindeki konfigürasyon yönetimi uzmanları, yazdıkları Konfigürasyon Yönetim Planı (KYP) içerisinde hangi ürünün versiyonlamasının hangi yöntem ile yapılacağını detaylı olarak belirtirler.

Test edilmek amacıyla konfigürasyon kütüphanesi / "build" ortamından alınan yazılımın versiyonunun "doğru" ve KYP'ye uygun olduğunun "her seferinde" kontrol edilmesi, bir test mühendisi için gerekli ve şarttır.

Çünkü hata açılan ürünün versiyonu bilinmiyorsa / yoksa / yanlışsa, hem yazılım geliştirici hatayı tespit etmekte zorlanacaktır, hem de geriye dönük süreç denetlemelerinde (özellikle müşteri tarafındaki kalite uzmanlarının yaptığı denetlemelerde) sorunlar çıkacaktır (testlerin tekrar edilebilirliği konusunda).

Örneğin müşteriden şöyle bir istek gelmesi durumunda, daha önceden versiyon belirterek açtığımız hataları, yine aynı versiyonlu üründe tekrar edebiliyor olmamız gerekiyor:

"3.0 versiyonlu uygulamayı konfigürasyon kütüphanesinden indirin, temiz bir ortama kurun, testleri baştan sonra tekrarlayın, 3.0 versiyonuna girilmiş tüm hataları tekrarlayın".

Böylece müşteri / müşteri kalite temsilcisi, test planlarınızı / prosedürlerini şirket kalite prosedürlerinizde belirttiğiniz gibi yaptığınızı görecek ve güven duyacaktır; aksi durumda kendilerini yanıltmaya çalıştığınızı düşünebilirler.

Testlerde Hata Bildiriminde Dikkat Edilmesi Gereken Girdiler

Testlerde bulunan hataları yazılım geliştirme ekibine "Hata Takip Aracı" (Mantis, Jira, gibi) üzerinden iletirken dikkat edilmesi gereken başlıkları aşağıda listeledim; bu liste amaca göre daha da detaylandırılabilir.

Hata bildirirken dikkat edilecek temel konular:

• Hata tanımını okuyan herkesin, bu tanımda ne belirtmek istediğinizi anlayabileceği kadar açık ve net yazılmış olmalı,
• Yazılım geliştiricinin koddaki hatayı tespit etmesini kolaylaştırmak üzere hatanın nerede, ne yaparken, hangi ortamda, (varsa) hangi dosya / eklenti ile çalışırken ortaya çıktığı belirtilmeli.

Başlıklar halinde ele alırsak:

1. Kısa Açıklama / Başlık
2. Hatanın detaylı açıklaması: Tam olarak hangi ekranda, ne yaparken ne oldu bilgisi.
3. Test dokümanı ile test yaparken bulunan bir hata ise;
1. Test dokümanı ismi, revizyonu, test durumunun ismi, hatanın bulunduğu adım no.
4. Test edilen uygulamanın versiyonu,
5. (Eğer web uygulaması ise) Kullanılan internet gezgini ismi ve versiyonu,
6. Hatanın önem derecesi (sisteme etkisi),
7. Hatanın öncelik derecesi (testlerin devamına engel ise öncelikli),
8. Kullanılan işletim sistemi ve versiyonu,
9. Hatanın ekran görüntüsü,
10. Eğer testte bir dosya / betik kullanıldıysa, hata tanımına ek olarak verilmeli.
11. Eğer varsa, sunucu kayıt dosyasındaki hata kaydı (error.log, server.log) gibi.

Eğer daha standart bir liste arıyorsanız, "IEEE-STD-1044-2009-Standard Classification for Software Anomalies" standartını kullanabilirsiniz.

Yazılım Test Araçları

Yıllar içerisinde kullandığım test araçlarını burada liste haline getirdim. Bunun dışında test mühendisliği kariyeriniz boyunca gelişiminize faydası olabilecek konferans / toplulukların videolarını da fırsat buldukça ekliyorum.

Fonksiyonel Test Araçları:
Selenium - Web temelli ürünlerin fonksiyonel testlerinin otomasyona alımında kullanılabilecek bir araç. Üç adet bileşeni var; IDE, WebDriver, Grid.
IDE bir Firefox eklentisi. Kaydet-Oynat mantığında çalışan bir uygulama. Bazı basit testleri bu IDE'yi kullanarak yapabilirsiniz. Fakat detaylı iş akışları, kontroller, tekrarlar, vs. gerektiren testleri yazmak için WebDriver ile kod yazmanız gerekmektedir. IDE'nin faydası, bir testi kaydedip sonrasında bunu WebDriver kodu olarak dışarı aktarabilmektir. Kod yazım zamanını oldukça kısaltıyor. WebDriver'ın kullandığı betik dilinin adı Selenese, öğrenmesi çok zor değil, Java'ya benziyor. Programlama dillerine aşina iseniz, hızlıca öğrenebilirsiniz. Grid ise yazılan testlerin pek çok farklı internet gezgininde (Chrome, Firefox, Safari, IE, ...) çalıştırılmasını sağlamaktır.

Ranorex - Bu ürün görece yeni bir araç. Kaydet-Oynat mantığında çalışıyor, fakat RanoreXPath özelliği ile kaydedilen testler daha etkin bir hale getirilebiliyor. Şurada kısa bir incelemesini yapmıştım. Benim hoşuma gitti açıkçası bu ürün.

IBM Rational Functional Tester - Bu ürünü birkaç senedir kullanmadım. Temelde bu da Ranorex gibi bir ürün. Geniş bir protokol desteği var. Dezavantajı pahalı olması.

SoapUI - Web servislerinin testleri için vazgeçilmez bir araç. Pro versiyonunda ekstradan kolaylıklar da sağlanmış, manuel yapılan işlemleri kolaylaştırmışlar. Ama ücretsiz versiyonu da işinizi fazlasıyla görecektir. Bir de kardeş ürünü var LoadUI, web servislerine yük testi yapmak için kullanılıyor.

Performans Test Araçları:
Jmeter - Apache firmasının geliştirdiği vazgeçilmez bir araç. İlk başlarda alışmanız biraz zaman alabilir ancak oldukça güçlü ve ücretli ürünlerden aşağı kalır bir yanı yok. Eklentiler ile raporlama yetenekleri de oldukça geliştirildi.

OpenSTA - Web ürünlerinin performans testlerinde kullanılır. Birkaç senedir güncellenmiyor, o yüzden artık bu ürünü tavsiye edemem.

Güvenlik Test Araçları:
OWASP ZAP - Open Web Application Security Project Zed Attack Proxy. 
Wireshark
FindBugs

Sharkfest:
http://www.youtube.com/results?search_query=sharkfest

Riverbed Channel: 
http://www.youtube.com/user/RiverbedTechnology/videos

Hackathon:
http://www.youtube.com/results?search_query=hackathon