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.

No comments: