Ana içeriğe atla

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


Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde (1, 2) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki:
“Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler, Sistem (Proje kapsamını belirtir), Use Caseler ve bunlar arasındaki ilişkiler. Şekil…

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Amaç, diyagramın sadece belirli k…

Cluster ve clustering nedir? Cluster oluşturmanın faydaları nelerdir? (Bölüm I)

Cluster, basit anlamda benzer bir amaç için belirli bir konfigürasyon yapılarak aynı görevi birlikte ya da yedekli çalışmasını sağlayan servistir. Cluster farklı amaçlarla oluşturulabilir fakat son kullanıcı tarafından her zaman tek bir bilgisayar gibi gözükecektir. Bir cluster oluşturmak için en azından iki adet sunucuya ihtiyaç vardır ve bir cluster içindeki her bir sunucu “node” olarak adlandırılır. İhtiyaç olan hizmete göre çeşitli sayıda nodelar bir araya gelerek clusterları oluşturmaktadır. Bir cluster oluşturmak için gerekli sebepler daha fazla performans ihtiyacı, yüksek erişilebilirlik (high availability) ya da her ikisi birlikte olabilir. Şimdi cluster çeşitlerini çok fazla ayrıntıya girmeden biraz daha yakından inceleyelim. Yüksek erişilebilirlik (High-availability) clusterlarıBu tip cluster yapısında öncelik erişilebilirliği arttırmadır. Bunu tek bir sunucunun görevini herhangi bir donanım yada yazılım problemi oluştuğunda diğer bir sunucunun otomatik olarak devralması olara…