Yazılamayan “Test Otomasyonu” yazısı

Yıllar önce şöyle bir şey duymuştum: Satın aldıkları ürünü beğenen tüketiciler memnuniyetlerini 2-3 kişiye söylerken memnun olmayanlar en az 10 kişiyle şikâyetini paylaşırmış.

Bu yazıyı hazırlamadan önce, bu sözü doğru hatırladığımdan emin olmak için internette kısa bir tur yaptım ve tabii fazlasını buldum.

Mesela Pete Blackshaw adında biri şöyle bir kitap yazmış: “Mutlu müşteriler 3 arkadaşına söyler, kızgın müşteriler 3000”. Bir diğeri gül kondurmuş: “Mutlu müşteriler 3 arkadaşına söyler, kızgın müşteriler Google’a söyler”

Kendinizi düşünün, arkadaş sohbetlerinizde satın aldığınız bir ürünle ilgili daha çok memnun olduğunuz vakaları mı anlatıyorsunuz yoksa şikâyetlerinizi mi?

Demek ki, öncelikle müşteriye sorunsuz ürün vermek gerekiyor. Müşteri memnun olduğunu arkadaşlarıyla paylaşmasa da çok önemli değil. Önemli olan müşteri için şikâyet etmesini gerektirecek bir durum oluşmasını engellemek. Başka bir deyişle, odaklanmamız gereken şey, müşteriye “mutluyum” dedirtmek değil, “mutsuzum” dedirtmemek.

Elbette yazılım dünyası da farklı bir noktada değil ve elbette her sektörde olduğu gibi yazılım dünyasında da mutlu müşteri tesadüfen oluşmuyor. Yazılım geliştirirken özenle, sabırla nakış işler gibi çalışmıyorsanız müşteri sadakati sizin için hayalden öteye gitmeyecektir.

“Bir zincir en zayıf halkası kadar güçlüdür” derler. Bizim zincirimiz ürettiğimiz yazılımdır, halkalarımız da yazılım süreçlerimizdir; ihtiyaç belirleme, analiz, geliştirme ve elbette test.

Bunlardan sonuncusu, yani test prosesi şüphesiz kodlanmanın başladığı ilk günden itibaren sürecin kaçınılmaz bir parçası olmuştur. Buna rağmen, toplam yazılım geliştirme süreci içinde, kaynak, yöntem (metodoloji), kapsam ve derinlik bakımından yeri en zor tanımlanabilen element olmaya devam etmektedir.

Aşağıdaki soruları zaman zaman kendine sormayan yazılım şirketi yoktur sanırım :

• Saha hatalarının birinci derecede sorumlusu test bölümü müdür?
• Yazılım geliştirme ekibi ile test ekibi personel sayıları arasındaki oran ne olmalıdır?
• Yazılım geliştirme ve test süreçleri 2 ayrı süreç mi olmalıdır yoksa içiçe geçmiş tek bir süreç mi olmalıdır?
• Hangi durumlarda yapılan geliştirmeye (veya hataya) özgü özel test yapılmalı, hangi durumlarda sistemin bütünü test edilmelidir?
• Bu hafta test ekibi çok hata yakalamış. Acaba bu, test ekibinin iyi çalıştığının göstergesi midir, yoksa yazılım ekibinin kötü çalıştığının göstergesi midir?
• Önceki hafta test ekibi çok az hata yakalamış. Acaba bu, yazılım ekibinin iyi çalıştığının göstergesi midir, yoksa test ekibinin kötü çalıştığının göstergesi midir?
• Ya diğer testler: İhtiyaç, analiz, kod geliştirme çalışmaları olması gerektiği yöntem ve kapsamda yapıldığını test etmeli miyiz?
• Mevcut test politikamızın beraberinde getirdiği riskleri biliyor muyuz? Test sıklığı, kapsamı,  derinliği konusunda sınır değerlerimiz ne olmalıdır?
• Test otomasyonu uygulamasına başlamalı mıyız?

Soru sormak iyidir. “Soru” bizi bir yerden bir yere taşıyacak ilk adımdır. Soru sormayan, sorgulamayan kişi bulunduğu yerden memnun demektir, bir anlamda statükocudur. Hiçbir şeyin birbiriyle aynı olmadığı ve her şeyin sürekli değişim halinde olduğu bu evrende uzun süre barınması mümkün gözükmemektedir.

Bu arada bilmeyenler için hatırlatalım: Son maddede bahsettiğimiz “Test otomasyonu” özetle bir yazılımın (yani ürünün) başka bir yazılım tarafından (yani test otomasyonu yazılımı tarafından) otomatik test edilmesi işlemidir.

Ve aslında bu yazının konusu test otomasyonu konusunda edindiğimiz tecrübeleri okurla paylaşmak olacaktı. Gelgelelim havadan-sudan bahsederken test otomasyonu için yerimiz kalmadı.

Belki de, blog yazarlarını “test eden” bir mekanizma olmadığından bu duruma düşmüş olabiliriz.

Gelecek yazımızda test otomasyonu konusunu hakkıyla irdeleyeceğimiz sözü vererek müsaadenizi isteyelim.

Seyit BALKUV