Wednesday, November 21, 2018

Mikro ve Küçük Ölçekli Yazılım Firmaları için Test Stratejileri

24.06.2018'de güncellenen KOBİ tanımına göre Mikro Ölçekli firmalar çalışan personel sayısı 10'dan az olan ve Küçük Ölçekli firmalar da çalışan personel sayısı 50'den az olan firmalardır.

Nakit akışı, yüksek ve düzenli kâr bırakan pazarlara erişim, çalışan motivasyonunu yüksek tutamamak gibi yönetim seviyesi zorluklar bir yana, az sayıdaki personelin pek çok farklı faaliyeti yoğun ve fazla mesai yaparak gerçekleştirmeleri sonucu hatalar yapılabilmekte, bu da nihai ürünün toplam kalitesinde zayıflığa ve müşteri memnuniyetsizliğine sebep olabilmektedir.

Bir soru sorarak başlayalım: 
Mikro ve küçük ölçekli yazılım firmalarının nihai müşteri memnuniyetlerini nasıl yükseltebiliriz?
Şunu belirtmekte fayda var: bu firmaların CMMI, SPICE, ISO 12207 gibi ağır metodolojilere uymaya yetecek kaynakları çoğunlukla olmayacaktır. Hatta bazen çevik yöntemleri bile uygulamakta zorlanabilirler.

Tümdengelim yaparsak; 

  • Müşteriler ne kadar az hata ile karşılaşırlarsa o kadar "Düzelt-Test Et-Yayınla" döngüsü işletilir,
  • Ürünün kullanımı ne kadar kolaysa o kadar az eğitim / kullanım desteği verilmesi gerekecektir,
  • Personel teslimat sonrası ne kadar az hata ve destek ile uğraşırsa, bir sonraki ürünü geliştirmek için daha çok zamanı olacaktır.
"Test Mühendisliğinde Olası Riskler ve Alınabilecek Tedbirler" başlıklı yazımda belirttiğim pek çok durum firmanızın işleri zorlaştırıyor olabilir ancak sorunun özü kısıtlı kaynaklar sebebiyle firmaların Test ve dokümantasyona yeterince zaman harcayamamalarıdır.

Aşağıda, bu sorunu çözmeye katkı sağlayabileceğini düşündüğüm maddeleri veriyorum. Firmanızın kaynaklarına ve yapısına en uygun yöntemi yine kendiniz belirleyebilirsiniz. Bunların uygulanması konusunda veya firmanızın yapısına özel sorularınız olursa da yardımcı olmaya çalışırım.




  • PERSONEL:
    1. İmkanınız varsa, mesleği test mühendisliği olan personel istihdam edin. Yazılımı geliştirenler (ve müşteriler) test yapmaktan genelde hoşlanmaz, bazen üstünkörü yaparlar, genelde de sadece "happy path"i test ederler. 1 kişi bile olsa istihdam edeceğiniz test mühendisi, müşteriden dönme ihtimali olan hataları çok büyük oranda azaltacaktır. Eğitim dokümantasyonu, müşteri desteği vermesi de cabası; çünkü sistemin genelini (çoğu zaman) en iyi bilen kişi test mühendisidir. 
    2. Sürekli olarak test mühendisi istihdam edemiyorsanız, stajyer / yarı-zamanlı çalışacak öğrencilere test yaptırabilirsiniz. Fakat bu personelin "test  mühendisi bakış açısı" olmadığından bu konuda eğitim almaları gerekecektir, bir danışmanın vereceği 2 günlük bir eğitim bile çok fark yaratacaktır. Aksi durumda çok fayda sağlanamayabilir. 
    3. Sürekli veya yarı zamanlı personel istihdamı da sizin için mümkün değilse, yine mesleği test mühendisliği olan bir danışman sadece ihtiyaç zamanlarında size destek verebilir.  Bu ihtiyaç zamanları şunlar olabilir:
      • Projenin ilk aşamasında sözleşme / sistem gereksinimlerinin gözden geçirilmesi ve bir ana test planı / stratejisi hazırlanması,
      • Sistem tasarımı sonrasında sistem seviyesi test senaryolarının ("Öncelikli Senaryo") yazılması,
      • Ara teslimat dönemlerinden önce testlerin koşturulması ("Detaylı Senaryo"),
      • Nihai teslimat öncesinde tüm senaryoların koşturulması.
"PERSONEL" konusunu çözüme ulaştırdıysanız;
  • TEST SÜRECİ
    1. Mutlaka gereksinim yönetimi yapılmalı. Böylece hiçbir istek/gereksinim göz kaçamaz.
    2. Müşterinin en çok önem verdiği, olmazsa olmaz dediği, beklemeye tahammül edemeyeceği işlevlerin neler olduğunu listeleyin. Bu işlevler belirlenirken kullanıcı ile empati kurabilmek çok önemlidir.
    3. Risk temelli test yaklaşımı ile bu listedeki maddelerin tamamını üst seviyede test eden bir senaryo oluşturun ("Öncelikli Senaryo").
    4. Her teslimat öncesi "Öncelikli Senaryo"yu mutlaka çalıştırın.
    5. "Öncelikli Senaryo"yu alt parçalara ayırıp detaylı senaryolar hazırlayın ("Detaylı Senaryo").
    6. Geri kalan kısımlar için "İkincil Senaryolar" oluşturun.
    7. Teslimatları ayda bir yaptığınızı varsayarsak, haftada 1 kere "Öncelikli Senaryo", 2 haftada 1 "Detaylı Senaryo", ayda 1 kere de "İkincil Senaryolar"ı koşturabilirsiniz.
      • "Ürün bitsin, testleri sonra yaparız" diye düşünmeyin, böyle bir yaklaşım kaosa davetiye çıkartmaktır.
    8. Eğer resmi bir "Kabul Testi" yapılacaksa, "Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir" başlıklı yazımda belirttiklerim uygulanmalı.
  • HATA YÖNETİMİ:

    1. Proje ilerledikçe hata sayıları da doğal olarak artacaktır.
    2. Eğer müşteriye bir ara ürün / demo ürünü teslimatı yapılmışsa, önem derecesi ne olursa olsun müşteriden gelen hata bildirimlerine öncelik verin ve en kısa zamanda ilk onları çözün ("ÖNCELİK 1").
      • Bizler için önemsiz gibi görünen hatalar, son kullanıcı gözünde çok önemli olabilir.
    3.  "Öncelikli Senaryo" ve "Detaylı Senaryo"dan bulunan hatalara 2. seviye öncelik verin ("ÖNCELİK 2").
    4. "İkincil Senaryo"dan bulunan hatalara 3. seviye öncelik verin ("ÖNCELİK 3").
    5. Firmanıza daha yüksek katma değer sağlayacak ve müşteri memnuniyetini artıracak hata çözüm sırası da doğal olarak ÖNCELİK 1 > ÖNCELİK 2 > ÖNCELİK 3 şeklindedir.
    6. Jira, Mantis veya diğer bir hata yönetim uygulaması kullanmak şarttır. Mümkünse son kullanıcıların da bu sistem üzerinde hata açabilmelerini sağlamak geri bildirim hızınızı artıracaktır. 

  • DOKÜMANTASYON:
    1. Kod içinde mutlaka "comment"ler ile neyin ne iş yaptığını belirtmek, hata düzeltme ve bakım dönemlerinde hayat kurtarıcı olmaktadır.
    2. Müşteriniz eğer formal test dokümantasyonu istiyorsa (örneğin TÜBİTAK), Mil-Std-498'i kullanabilirsiniz, ücretsizdir.
    3. Uygulamanın kurulumu ve kullanımı ile ilgili kısa da bir belgeyi tercihen web sayfası veya uygulamanın içine entegre olarak hazırlamanız, sonrasında kullanımla ilgili gelecek pek çok sorudan kurtaracaktır sizi.
    4. Ürünün kapsamlı eğitimi gerekiyorsa, ürün olgunlaştıktan sonra eğitim videosu hazırlayarak maliyeti azaltabilirsiniz.

  • ARAÇ KULLANIMI:
    1. Eğer ürününüz test otomasyonuna uygunsa, personelinizin bu konuda deneyimi varsa ve en önemlisi otomasyona alınan testlerin çok sık güncellenmesi gerekmeyecekse, test otomasyonu fayda sağlayacaktır. Ancak uyarmam gerekir: bu iş ayrı bir uzmanlık alanıdır ve kimi zaman faydadan çok zarar da verebilir.
    2. Sadece açık kaynaklı test araçlarından faydalanın. Ticari test araçları genelde fazlasıyla pahalıdır, eğitim / destek maliyeti olabilmektedir, alınan araç âtıl kalabilmektedir.
    3. Test verisi hazırlama ve kaynak kodu sık değişmeyecek kısımlar için otomasyon kodu yazılabilir. Bir kere yaparsınız, proje boyunca sizi tekrarlayan işlerden kurtarır.

Wednesday, November 14, 2018

Fonksiyonel Olmayan Gereksinimler: Uygunluk

Kullanıcıların, "normal çalışma zamanlarında" sistemin çalışabilir olduğuna güvenme derecesidir. Diğer bir deyişle, kullanıcılar normal çalışma saatlerinde sistemi kullanmak istediklerinde sistemin kullanıcı isteklerine cevap verebiliyor olması gerekmektedir.

Örnekleyecek olursak;

  • Çevrimiçi Ödeme Sistemi saat 06 ile 23 arasında kullanıma uygun olmalıdır.
  • Çevrimiçi Ödeme Sistemi 100 saatlik MTBF (Mean Time Between Failures - Arızalar Arasındaki Ortalama Süre) değerine sahip olması gerekmektedir.
  • Çevrimiçi Ödeme Sistemi, kullanıcıların isteklerinin %95'ine 15 saniye içinde cevap verebilmelidir. Geri kalan zamanlarda 20 saniye içinde cevap verebilmelidir.
  • ATM cihazı hafta içi günlerde saat 06 ile 23 arasında %99 oranında uygun olmalıdır. 
  • Sistemin yeni bir kurulumu, kurulum işlemi başlatıldıktan sonra 24 saat içinde ilk kullanıma hazır olmalıdır.
  • Sistem kullanıma kapatıldıktan sonra sistemin veritabanı yedeği 15 dakika içinde alınabilmelidir.
  • Sisteme kapatma komutu gönderildikten sonra 3 dakika içinde sistem kapanmış olmalıdır.
  • Acil durum veri silme komutu gönderildiğinde 15 saniye içinde her 3 sabit diskteki tüm veri geri kurtarılamaz şekilde silinmelidir. 

Tuesday, November 13, 2018

Fonksiyonel Olmayan Gereksinimler: Hayatta Kalabilirlik

Bir sistem arızası ortaya çıktığında yazılım sisteminin kendini toparlaması ve çalışmaya devam etmesinin ölçüsüdür.

Örnekleyecek olursak;

  • Denetleme yazılımı arıza sonrası kapanırsa kullanıcının sözleşme dosyasında yaptığı değişiklikler kurtarılmalı ve dosya arıza oluşumundan bir dakika öncesindeki duruma gelmeli.
  • Yazılımın güncellenmesi sırasında bir arıza ortaya çıkarsa yapılan tüm veri ve güncellemeler geri alınmalı ve yazılım eski haline dönmelidir.
  • Bir arıza durumu sonrasında işletime devam edilirken kullanıcıya yazılımın "güvenli mod"da çalıştığı ve tüm verinin salt okunur durumda gözden geçirmeye hazır olduğunun bilgisi verilmelidir.
  • Sistem, arızalı olduğu tespit edilen yeteneklere erişimi engellerken diğer tüm yeteneklere erişime izin vermelidir.
  • Montaj hattındaki tüm donanım bileşenleri yedekli olmalıdır, böylece herhangi bir donanım bileşeni arızalandığında montaj hattının durması engellenmelidir.

Monday, November 12, 2018

Testler Ne Zaman Biter?

Yazılım sektöründe bir süre çalışanların çok iyi bildiği gibi, yazılım ve sistem projelerinin karmaşıklık sebebiyle, test edilebilecek patikaların sayısı neredeyse sonsuzdur. Ve proje yöneticilerinin en sık sorduğu sorulardan biri "testler ne zaman biter"dir.

Öncelikle testlerin sayısının neden çok olabileceğini inceleyelim.

Örnek olarak E-Devlet giriş sayfasını kullanabiliriz.



Uygulayabileceğimiz testleri listeleyelim:

  1. T.C. Kimlik No alanı ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
  2. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
  3. T.C. Kimlik No alanını boş bırak ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  4. T.C. Kimlik No alanına boşluk karakteri gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
  5. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
  6. T.C. Kimlik No alanına boşluk karakter gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  7. T.C. Kimlik No alanına 500 adet karakter gir ve e-Devlet Şifresi alanına 500 adet karakter gir, "Sisteme Giriş Yap" düğmesine tıkla,
  8. T.C. Kimlik No alanına Kopyala-Yapıştır ile 10 karakterlik değer gir ve e-Devlet Şifresi alanına Kopyala-Yapıştır ile 10 karakterlik değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  9. 1-8 arasındaki testleri tekrarla, "Sisteme Giriş Yap" düğmesine tıklamak yerine klavyedeki ENTER tuşuna bas,
  10.  T.C. Kimlik No alanına geçerli bir değer gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,

Yukarıda tanımlanan 10 (aslında 17) adet teste daha pek çok test eklenebilir. 
Görüldüğü üzere sadece 2 tane alan için bile bu kadar test tanımlanabiliyorken, yüzlerce ekran ve binlerce veri giriş alanı / kontrol düğmesi içeren, birden fazla yazılım ve donanımın entegre olduğu, yedekli veritabanı sistemleri, yük dengeleyiciler, CBS yazılımları, masaüstü / web / mobil arayüzleri olan devasa bir sistemde, yapılabilecek testlerin sayısı (sonsuz olmasa bile) on binlere ulaşabilir.

Peki soru şu: Testler ne zaman biter?
  1. Atanan efor / süre bittiğinde: Proje takviminde test için ayrılan süre bittiğinde,
  2. Test durumları belirli bir başarı yüzdesine ulaştığında,
  3. Hata oranı belirli bir yüzdenin altına indiğinde,
  4. Tüm gereksinimler %100 doğrulandığında
    • Gereksinimlerin %100 doğrulanmış olmasının, geçilebilecek tüm patikalardan geçildiği anlamına gelmediğini de belirteyim.
Anlaşıldığı üzere, bir sistemi %100 test etmek hem ekonomik değil hem de kimi durumlarda mümkün değildir.
Bunun istisnası, görev-kritik yazılımlardır; hata yapması durumunda insan yaşamına ve ülke güvenliğine ciddi zararları olabilecek yazılımlar için yazılan birim testlerin %100 kapsama oranına sahip olması beklenmektedir.

Peki, madem sistemi %100 test etmek ekonomik / mümkün değil, o zaman "nasıl bir test stratejisi izlersek hem sistemi yeterli derecede test etmiş oluruz hem de hataların büyük kısmını müşteri ortamına kurulum yapılmadan önce tespit etmiş oluruz?".

Bu da bir başka yazının konusu: En Uygun Test Stratejisini Nasıl Belirleriz?