İyi bir aracın kullanım dışı kalmasının nedenleri ve öğrenilen nihai dersler, testi başarılı bir şekilde otomatikleştirmek isteyen herkes için büyüleyici bir okumadır.

Bu vaka çalışması ilk olarak 1992’de yazılmış ve Marnie Hutcheson’ın o sırada çalışmakta olduğu Prodigy’deki deneyimlerini anlatıyor. Kısmen bu örnek olay incelemesinde anlatılan deneyimlerinin bir sonucu olarak mükemmel test yönetim yöntemi MIT’leri (En Önemli Testler) geliştirmiştir.

Şu anda Prosys ve Ideva adında iki şirketi yönetiyor; birincisi test danışmanlığı, ikincisi ise internet ve intranet geliştirme ve eğitim.Bu bölüm ilk olarak Dokuzuncu Uluslararası Bilgisayar Yazılımını Test Etme Konferansı’nın (ITEA ve ASQC) tutanaklarında yayınlanmıştır.

Bu bölümde açıklanan araç artık mevcut değil. Test ettiği online alışveriş sistemi uygulamasının yerini internet teknolojisi aldı. Ancak, alınan dersler hala geçerli.

Birçok farklı platformda çalışması gereken çok çeşitli yazılımlar geliştirdi. Sonuç olarak, PRODIGY hizmetini test etmek için birçok türde yazılım ve donanım test aracı kullanıldı.

Gremlin Otomatik Test Sistemi, 1988 yılında, öncelikle PRODIGY hizmetindeki uygulamaları test etmek için kullanılan bir dizi PC tabanlı test komut dosyası otomasyon aracı olarak başladı. Sonunda, tekrarı yakalamanın yanı sıra birçok test görevini otomatikleştirmek için geliştirildi ve Prodigy ağı genelinde birçok yazılım türünü test etmek için kullanıldı. Hem test sisteminde hem de düşüncemizde birçok değişiklik uygulandı.

Muhtemelen bu süreçte öğrenilen en önemli ders, test otomasyonunun başarılı olması için test araçlarından çok daha fazlasının gerekli olduğudur. Yapılan testin kalitesinden emin olmak için araçları kullanmak için bazı güvenilir yöntemler bulunmalıdır.

Hizmetine ilişkin ilk finansal uygulamanın geliştirilmesi ve test edilmesi bir yıl sürdü. Yönetim, sonraki dört mali başvurunun 16 ay içinde tamamlanmasını ve çevrimiçi olmasını istedi. Program, uygulamaların uygulanmasında ve test edilmesinde önemli ölçüde örtüşmeyi gerektiriyordu.

Bir betik otomasyon test sistemi olan, testçilerin programa uymasını sağlamak için altı ayda geliştirildi. Araç seti, mümkün olduğunda mevcut dahili yakalama yeniden oynatma ve görüntü yakalama teknolojisini kullandı.

Sistem, test edilen uygulamayla aynı makinede çalışan, müdahaleci olmayan bir operatör emülatörü olarak işlev gördü ve kullanıcıların şunları yapmasına izin verdi:

• tuş vuruşlarını ve ekran görüntülerini yakalayın;
• yakalanan anahtar izleme betiklerinden paketler oluşturun;
• Test Paketlerini yeniden çalıştırın ve test görüntülerini yakalayın;
• test görüntülerini ana görüntülerle karşılaştırın ve bir rapor yazın (uyumsuz piksel sayısını gösteren).

Ek olarak, kullanıcının önce yakalanan ana görüntüyü, ardından yakalanan test görüntüsünü ve son olarak ana görüntünün üzerine bindirilen test görüntüsünü görüntülemesine izin veren bir görüntü görüntüleyici geliştirildi. Bindirme görüntüsü, ana ve test görüntüleri arasındaki farkları vurguladı ve eşleşen alanları kararttı.

Yazılım Nedir
Bilgisayar yazılımları Nelerdir
Yazılım sistemleri Nelerdir
Sıfırdan yazılım öğrenme
Uygulama yazılımları
Bilgisayar yazılımları
Bilgisayar yazılım programları
Bilgisayar yazılımı Nedir

Finansal uygulamalar test grupları, testlerinin %80’ini Gremlin sistemiyle otomatikleştirmeyi başardı. Gremlin, müşteri finans kurumlarına verildi ve çoğu durumda bunu hem sistem testi çabasında hem de kullanıcı kabul testi çabasında kullandılar. Otomatik test, bir finansal uygulama için sistem test döngüsünü bir aya indirdi. Prodigy ve finans müşterisi için tüm test döngüsü üç aydan daha kısa bir süreye indirildi.

Yeni finansal uygulamaların testi zamanında tamamlanmakla kalmadı, test uzmanının başka işlerle uğraşırken regresyon testi yapması da mümkün oldu. Canlı hizmetinde mevcut uygulamaların sağlığını izlemek için Gremlin sistemini kullanmak da mümkün oldu.

Genel olarak çalışanları ve müşterilerinin kullanımına sunuldu. Tanıtılmasından sonraki sekiz ay içinde, otomatik test sisteminin 56 kayıtlı dahili kullanıcısı ve 15 harici kullanıcısı vardı. Kullanıcı, geliştirme grupları, Sistemler ve Uygulama Testi grubu ve kullanıcı kabul testi gerçekleştiren çeşitli teknik olmayan gruplar arasında neredeyse eşit olarak bölündü.

Ancak 18 ay sonra, kayıtlı 71 kullanıcısından 20’den azının testlerinde sistemi kullanmaya devam ettiği keşfedildi. Aktif kullanıcıların çoğu grubundaydı. Sistemin başlangıçta kendisi için geliştirildiği geliştirme grubu bile artık sistemi finansal uygulamaları test etmek için kullanmıyordu. Eski kullanıcılar, Gremlin sistemini başka otomasyon araçlarıyla değiştirmemişti; görünüşe göre test otomasyonunu kullanmayı yeni bırakmışlardı.

Kullanımındaki düşüşün nedenleri

Gremlin 1 kullanıcıları ve eski kullanıcıları arasında bir anket yapıldı. Kullanımdaki düşüşün nedenleri iki ayrı gruba ayrıldı: genel olarak testle ilgili olanlar ve araç işlevleriyle ilgili olanlar.

Ankete katılanların çoğu, aşağıdakiler gibi genel test sorunları hakkında endişeliydi:

» Nereden Başlarım?
» Test komut dosyalarımı nasıl1 tasarlarım?
» Neyi test edeceğimi nasıl bilebilirim?
«Yeterince test ettiğimi nasıl anlarım?

Araçların bu sorulara yanıt vermesi beklenmiyordu, ancak bunlar insanların mücadele ettiği sorunlardı. Bu biraz şaşırtıcıydı ve yazılım testini bir disiplin olarak öğretmek için bir tür eğitime veya sınıfa ihtiyaç duyulduğunu açıkça gösterdi. Bu bulgunun gerçek önemini henüz anlamadık.

Sistem/Araç Eksiklikleri

Ayrıca Gremlin 1’de bir dizi teknik sorun tespit edildi. O zamanlar çok yeni olan teknolojinin ilk sürümü için bu şaşırtıcı değil.

Ankette şu eksiklikler tespit edildi:

• Arayüz sorunları. Fareyle çalıştırılan bir grafik kullanıcı arabirimi yerine metin tabanlıydı. Kullanıcıların yazması gerekiyordu
birçok yolları olan hatırlaması zor dosya adları. Bir hata yaparlarsa, o operasyona baştan başlamak zorunda kaldılar.
• Uygulamamı kullanamıyorum. Gremlin, anahtar izlerini yalnızca PRODIGY sisteminin kullanıcı arabirimi aracılığıyla sürdürebilirdi.
• Doğrulama. Gremlin 1 yalnızca ekran görüntüsü karşılaştırması yaptı ve ekran alanlarının maskelenmesine veya dosyaların veya mesajların karşılaştırılmasına izin vermedi.
• Çevre. Kurulum ve temizlemenin manuel olarak yapılması gerekiyordu. Örneğin, her komut dosyasının başlangıcında belirli bir dosyanın belirli bir dizinde olması gerekiyorsa, test uzmanının otomatikleştirilmiş test çalıştırılmadan önce ve benzer şekilde temizleme görevleri için onu manuel olarak oraya yerleştirmesi gerekir. Bu tür işlemler yalnızca zaman alıcı olmakla kalmıyor, aynı zamanda belgelenmesi de zor oluyordu ve kolayca gözden kaçıyordu. Doğru ortam mevcut değilse, bir Test Paketinin tüm çalıştırması boşa gidebilir.
• Düzenlemesi zor test komut dosyaları. Test uzmanlarının, bir anahtar izini düzenleyebilmeleri için her bir tuş vuruşunun ve fare hareketinin ne yaptığını bilmesi gerekiyordu. Komut dosyaları, hem anımsatıcılarda hem de komutlarda doğru sözdizimi ve büyük/küçük harf gerektiriyordu. Düzenlenen herhangi bir komut dosyasının daha sonra test edilmesi ve hatalarının ayıklanması gerekiyordu.
• Anahtar izlerin test belgelerine dahil edilmesi zordur. Test uzmanlarının, anahtar izleme komut dosyalarını belgelerine dahil etmek için biçimlendirmesi ve manuel olarak kopyalaması gerekiyordu.
• Test komut dosyaları hızla güncelliğini yitirir. Menü seçeneği numaraları gibi pek çok öğe komut dosyalarına ‘sabit kodlanmıştır’ ve bu onlara kısa bir ömür beklentisi vermiştir. Bu, anahtar izlerin ‘tek kullanımlık’ olduğu ve belgelemeye veya korumaya değmediği görüşünü destekledi. Sonuç olarak testçiler, anahtar izleri yeniden oynatmak yerine sürekli olarak yeniden yazıyorlardı.
• Bu anahtar izleme neyi test eder? Tipik olarak, bir anahtar izini oluşturan testçi dışında hiç kimse, onu kullanmak için geçerliliğine yeterince güvenmiyordu. Açıklayıcı ‘yorumlar’ bir anahtar iz olarak düzenlense bile, herhangi bir belgede kolaylıkla yeniden üretilemezler.

The post Yazılım Sisteminin Evrimi first appeared on Akademi Delisi (Tez Yaptırma).