Thursday, March 26, 2015

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.