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 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

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

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 ara