Thursday, June 1, 2017

Yazılım Projelerinde Müşteri İletişiminin Önemi



Her ne kadar yazılım mühendisliği yoğun teknik bilgiler gerektirse de en nihayetinde yapılan iş bir müşteri / kullanıcı grubunun ihtiyaçlarını karşılamak üzere yapılır. Dolayısıyla ciddi miktarda sosyal beceriler de gerektirir.

Bu sebeple, hem ürünün geliştirilmesi için bütçe ayıran Müşteri ile hem de ürünü kullanacak Son Kullanıcı ile yakın iletişimde olmak, sonradan ortaya çıkabilecek kullanım zorluklarını çok daha erken bir zamanda ortadan kaldırmak için fırsatlar sağlamaktadır.

Bu faydaları şu şekilde sıralayabiliriz:

    • Sözleşme Aşaması: Bu aşamada ihale çağrı dosyasında, müşteri ve son kullanıcı menfaatine olacak olan ancak sözleşmede belirtilmemiş idari ve teknik konularda müşteriye fikir sunulabilir. Örneğin, ürünün hedeflenen performansı, donanım altyapısı, engelli kullanıcıların da sistemi kullanmasını kolaylaştıran erişebilirlik isterleri gibi konularda önerilerde bulunabiliriz. Yine bu aşamada müşteri ve son kullanıcı hakkında mümkün mertebe detaylı bilgi sahibi olmak, nihai ürünün kalitesini artırıcı faydalar sağlayacaktır.
    • Analiz Aşaması: Son kullanıcının nasıl bir ortamda, hangi şartlar altında, hangi işi, nasıl ve neden yaptığı, iş akışının ne olduğu, bu akışta kimlerin hangi sorumlulukları ve sınırlamaları olduğu gibi ürün için son derece önemli olan "kullanım durumları", kullanıcı ile empati kurularak, ortaya çıkarılmış olacaktır.
    • Geliştirme Aşaması: Sözleşmede "Proje İlerleme Raporları" istenmemiş bile olsa, müşteri temsilcilerini projenin gidişatı hakkında bildirmek ve ürün ortaya çıktıkça sunumlar yapmak, müşteri temsilcilerinin projenin sağlıklı bir şekilde ilerlediğini görmeleri bakımından faydalıdır.
    • Kabul Aşaması: Kabul işlemleri öncesinde oryantasyonlar verilerek, kabul sürecine müşteri temsilcilerinin en iyi şekilde hâkim olmaları sağlanır ve akıllarında herhangi bir soru işareti kalmaz.
    • Ürünün Devreye Alınması: Bu aşamada yüklenici şirketin personelinin, son kullanıcı ile yakın çalışması, ürünün kullanıcı tarafından sahiplenilmesi, eski sistemden yeni sisteme geçişin hızlandırılması, ürünün nihai ortamında çalışma performansının yakından takip edilmesi gibi pek çok konuda fayda sağlar. Bu aşamada özellikle dikkat edilmesi gereken konu, kullanıcıdan gelecek olan istek / hata bildirimlerine çok hızlı bir şekilde geri dönüş sağlamak, ürünün kullanımının sekteye uğramasına engel olmaktır.

Sunday, May 28, 2017

Pazarlama Faaliyetlerine Test Mühendisleri Nasıl Destek Verebilir

Test mühendisleri, geliştirilen sistemin / yazılımın ( = ürünün) tüm yeteneklerine hâkim oldukları için gerek fuarlardaki tanıtımlarda, gerek şirkete misafir olan potansiyele müşterilere yapılan sunumlarda, gerekse tanıtım araçlarının oluşturulmasında şirketlerin satış / pazarlama / iş geliştirme bölümlerine ciddi destekler verebilirler.

Aşağıdaki liste bu noktada aydınlatıcı olabilir:



  • Demo Hazırlığı
    • Geliştirilen ürünün demosunun, potansiyel müşteri gruplarına yönelik verilerini içererek hazırlanması,
    • Demo senaryosunun oluşturulması,
    • Demonun gerçekleştirilmesi  
  • Sunum Hazırlığı
    • Demo, fuar, müşteri ziyareti gibi amaçlara yönelik olarak ürünün genel olarak tanıtımını içeren sunum dosyasının hazırlanması,
    • Sunumda 5N1K sorularına yönelik cevaplar içerilmesi,
    • Potansiyel müşterinin hangi ihtiyaçlarına cevap verdiğinin net olarak belirtilmesi,
  • Pazarlama Araçları Hazırlığı
    • Hazırlanacak broşür için ürünün ekran görüntülerinin alınması,
    • Ekran görüntüleri ile ilişkili olarak ürünün yeteneklerinin listelenmesi,
    • Ürünün uyumlu olduğu standartların belirtilmesi,
    • Ürünün, sektördeki diğer ürünlere göre karşılaştırmalı performansının ölçülmesi,
    • Ürünün demo videosunun hazırlanması.

Wednesday, May 24, 2017

Gereksinim Anlaşılabilirlik Toplantısının Amacı

Her ne kadar gereksinim analizi çalışmaları sonucunda ortaya çıkan gereksinimler mümkün mertebe atomik hale getirilse ve okuyan herkesin aynı şeyi anlaması sağlanmaya çalışılsa da kimi gereksinimler özellikle farklı ekip üyeleri (yazılım mühendisi  - test mühendisi - kalite uzmanı - müşteri temsilcisi) tarafından farklı anlaşılabilmektedir.

Bu nedenle, özellikle gereksinim analizinin hemen ardından, müşteri tensilcilerinin de katılımıyla, (özellikle sistem seviyesi) hangi gereksinimde tam olarak neyin amaçlandığının net bir şekilde tüm ilgili ekip üyeleri tarafından anlaşılması çok önemlidir.

Bu amaçla yapılan toplantıların adı Gereksinim Anlaşılırlık Toplantısı veya Gereksinimleri Anlama Toplantısı'dır.


Tuesday, May 23, 2017

Test Mühendisliğinde Hangi Dokümanlar Üretilir, Amaçları Nedir

Kimi standartlarda ek olarak birkaç başka doküman olsa da, tüm standartlar ve metodolojiler tarafından istenen test dokümanları şunlardır:


  • Sistem Test Planı (STP)
    • Sistem seviyesinde, tüm alt-bileşenleri ve donanımları göz önüne alarak sistem seviyesi gereksinimlerin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı dokümandır.
  • Sistem Test Tanımları (STT)
    • STP'de belirlenen testlerin, detaylı test adımlarının yazıldığı dokümandır.
  • Sistem Entegrasyon Doğrulama Planı (SEDP)
    • Sistem Altsistem Tasarım Tanımları ve Arayüz Gereksinimleri Tanımları dokümanlarında belirtilen arayüz gereksinimlerinin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı  ve sistemi oluşturan modüllerin hangi sıra ile entegre edileceğinin belirtildiği dokümandır.
  • Sistem Entegrasyon Test Tanımları (SETT)
    • SEDP'de belirtilen testlerin detaylı test adımlarının yazıldığı dokümandır.
  • Yazılım Test Plan(lar)ı (YTP)
    • Yazılım seviyesi gereksinimlerin nerede, ne zaman, hangi testlerle, hangi ortamda, kimlerin katılımı ile doğrulanacağının planlandığı dokümandır.
    • Her bir alt-sistem (modül) için ayrı bir yazılım test planı hazırlanabileceği gibi, kimi projelerde tek bir tane YTP de hazırlanabilir.
  • Yazılım Test Tanımları (YTT)
    • YTP'de belirlenen testlerin detaylı test adımlarının yazıldığı dokümandır.
  • Test Raporu (Sistem / Sistem Entegrasyon / Yazılım) (STR - SETR - YTR)
    • Kurulum aşamasından başlayarak hangi işlemlerin yapıldığı, hangi testlerin koşturulduğu, hangi hataların çıktığının belirtildiği dokümandır.

Ek olarak projenin doğasına göre aşağıdaki dokümanlar da hazırlanabilir:
  • Test Mühendisliği Ana Planı
  • Yazılım Doğrulama ve Geçerleme Planı
  • Kabul Testi Tanımları
  • Test Araçları / Simülatör Geliştirme ve Doğrulama Dokümanı
  • Birim ve Birim Entegrasyon Test Tanımları

Monday, May 22, 2017

Test Hazırlık Gözden Geçirme: Neden Yapılır

Özellikle kabul testleri öncesinde, testlere başlayıp başlamama kararının verildiği toplantıdır.
Bazı şirketlerde dahili testler öncesinde de bu tarz toplantılar yapılabilir.



Bu toplantılarda incelenen ana durumlar şunlardır:
  • Test edilecek ürünün test dokümanları tamamlandı, gözden geçirildi ve bu dokümanlar kullanılarak en az bir kere baştan sona test yapıldı mı,
  • Gereksinim, tasarım ve/veya toplantı tutanaklarına işlenmiş maddeler ilgili dokümanlara yansıtıldı mı ve test dokümanları bunlara göre güncellendi mi,
  • Önceki testlerde çıkan hatalar düzeltildi mi,
    • Şirket içinde yapılan bu testlerde çıkan toplam hata sayısı genelde müşteriye söylenmez, söylenmesi de gereksizdir,
  • Testlerde bulunan fakat düzeltilememiş hatalar var mı,
    • Bunu belirtmek özellikle gereklidir. Çünkü halihazırda, sistemde var olduğunu bildiğiniz bir hata varsa fakat bunu müşteriye önceden söylemezseniz, kabul testi sırasında bu hatanın ortaya çıkması kabule engel bir duruma sebep olabilir.
    • Bilinen fakat henüz düzeltilememiş hatalarla teste başlayıp başlamama kararı, müşteri ile birlikte verilir.
  • Test ortamı kurulumu yapıldı mı ve test ortamı izole edildi mi,
    • Bazı projelerde müşteri, test ortamının tamamen baştan kurulması sürecini de görmek isteyebilir.
  • Testlerin süresi,
  • Test öncesinde müşteriye oryantasyonun nasıl ve nerede verileceği.
Proje ihtiyaçlarına göre bu listeye eklemeler de yapılır.

Sunday, May 21, 2017

Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir



Gerek kamu gerekse özel sektöre yapılıyor olsun, yazılım projeleri bir nihai kabul makamı için geliştirilir. Yani bu projenin bütçesini oluşturan ve ödeme yapacak bir makam için geliştirilir.

Bu makamın görevlendirdiği ekip tarafından bir sözleşme hazırlanır, ihale süreci başlatılır ve bu sözleşmeyi karşılayacak sistem / yazılımı geliştirmeye tâlip şirketler ile görüşüldükten sonra sözleşme nihai haline gelir.

İhale sürecinin sonunda ihaleyi kazanan şirket, sözleşme isteklerine göre ürünü geliştirdikten ve dahili testlerini yaptıktan sonra, müşteri, müşteri temsilcisi ve/veya danışmanlık / müşavir firma katılımı ile, geliştirilen ürünün sözleşme isterleri ile uyumluğunun doğrulandığı kabul testi yapılır.

Kabul testi için, doğrudan sözleşme isterlerini doğrulayan bir Kabul Test Dokümanı kullanılabileceği gibi, müşteri onayı alınması durumunda, Sistem Test Dokümanı da kullanılabilir.

Bu aşamada dikkat edilmesi gerekenler:
  • Kabul testinde kullanılacak test dokümanının, sözleşme isterlerinin tamamını test ettiğinden emin olunmalıdır,
  • Test öncesinde, hatta Test Hazırlık Gözden Geçirme toplantısı öncesinde, müşteri temsilcileri ile ayrı bir toplantı yapıp, test dokümanının detayları, sözleşme maddelerinin hangi testlerle nasıl karşılandığı sunulmalıdır. Böylece, müşteri temsilcileri test dokümanına hâkim olacak, olası eksikler erken aşamada ortaya çıkmış olacak, müşterinin istediği ek testler varsa test dokümanına eklenebilecek ve müşteri temsilcileri sözleşmenin her maddesinin testten geçtiğini göreceği için içleri rahat olacaktır.
    • Bu aşamada, testler öncesinde senaryo akışı anlatılmalı ve üzerinden mutabık kalınmalıdır.
  • Kabul testine gelen kabul heyetinin (müşteri temsilcileri) asıl işlerinin yazılım geliştirme olmadığını düşünürsek, yazılacak test adımlarının yeterince açıklayıcı olması, test ettiği isterin ne olduğu açık olarak belirtilmelidir.

Thursday, May 18, 2017

Bir Regresyon Testi Yaklaşımı Önerisi

Regresyon testi, tanımı gereği, test edilmiş ve doğrulanmış bir ürüne yeni bir özelliğin eklenmesi ve/veya var olan özelliklerdeki bir hatanın düzeltilmesi sonrasında, testten geçmiş ürünün bu değişikliklerden olumsuz etkilenmediğini doğrulamak amacıyla yapılır.

Adı geçen bu değişiklikler kullanıcı arayüzü üzerindeki kozmetik değişiklikler olabileceği gibi, bir modülün çalışma şekline müdahale eden bir değişiklik de olabilir. Dolayısıyla yapılan bu değişikliğin halihazırdaki ürünü bozmadığından emin olmak gerekir.

Bir projenin yaşamı süresince ortaya çıkabilecek bazı regresyon testi ihtiyaçlarını ve neler yapılması gerektiğini aşağıdaki şemada örneklendirdim:



Peki nasıl bir test yaklaşımı ile regresyon testlerini planlamak gerekir?
Geliştirilen ürünün yapısına bağlı olarak farklı yaklaşımlar ortaya çıkacaktır. Ancak genel bir yaklaşım olarak şöyle bir yöntem izlenebilir (burada verilen yaklaşımlar örnektir, kendi proje ihtiyaçlarınıza göre çeşitlendirebilirsiniz):



Kozmetik Değişiklik


Ne Yapıldı?


Yazım Hatası Düzeltildi


Resim, İkon, Konum Değiştirildi


Font Değiştirildi

Nasıl Doğrulanacak?


Ürünü farklı platformlarda çalıştır (İşletim sistemi, internet gezgini, mobil cihaz)


Yapılan değişikliğin istendiği gibi göründüğünü doğrula


Yapılan değişikliğin aynı kullanıcı arayüzündeki diğer nesneleri bozmadığını doğrula
Yetenek Üzerinde Değişiklik


Ne Yapıldı?


Kullanıcı Arayüzünde Bir Nesne Silindi / Eklendi


Modüller Arası Arayüze Yeni Yetenek Eklendi / Varolan Silindi


Bir sınıfın çalışma mantığı değiştirildi


Veritabanı sorguları değiştirildi


Rapor şablonu değiştirildi


Kullanılan donanımlar değiştirildi


...

Nasıl Doğrulanacak?


Kullanıcı arayüzünü test et, istenen sonuçta olduğunu doğrula


Kullanıcı arayüzünü çağıran diğer arayüzleri test et, istenen sonuçta olduğunu doğrula


Arayüzü kullanan modülleri test ederek, iletişimde bulunan modüllerin istenen girdi ve çıktıları sağladığını doğrula


Değişiklik yapılan sınıfı birim test ile doğrula, bu sınıfı kullanan diğer sınıfları birim entegrasyon testi ile doğrula


Veritabanına atılan sorguyu gözden geçir


Ekran arayüzü üzerinden test yaparak veritabanına atılan sorguda doğru parametrelerin kullanıldığını doğrula


Farklı sayıda girdiler kullanarak farklı sayıda sayfa içeren raporlar üret, içeriğin istenen sonuçları içerdiğini doğrula


Donanıma özel olarak geliştirilmiş yeteneklerin olması durumunda, ilgili yeteneğin testlerini baştan sona tekrarla
Yaklaşım



Test mühendisi, deneyimine dayanarak hangi yeteneklerin etkilenmiş olabileceğinin listesini hazırlar, liste üzerinden tüm ilgili yetenekleri test eder,


Proje ekibi (en az 1 yazılılm mühendisi ve 1 test mühendisi), tasarım ve kod üzerinden etkilenmiş olabilecek yeteneklerin listesini çıkarır, birim seviyesi ve üst seviye testler tekrar edilir,


Test otomasyonu varsa, değişiklikten etkilenen testler güncellenir ve (tercihen, zaman varsa tüm) testler tekrarlanır