Araç seçimi sırasında dikkate almamız gereken en büyük faktör, test aracının operatörlerinin veya kullanıcılarının kim olacağıydı. Sonunda belirlenen personel, teknik altyapıdan değil, programlama becerisi olmayan iş odaklı kişilerdi.

Bu temel faktörü göz önünde bulundurarak, bizim için doğru test aracını belirlemek oldukça kolay bir işti, çünkü basit kayıt ve oynatma özelliğine sahip, ancak programlama becerilerine sahip biri tarafından işlevlerinde ince ayar yapma fırsatına sahip bir ürün arıyorduk. Eğer gerekliyse. Bu, süreci olgunlaştırırken bize her iki dünyanın da en iyisini verebilmelidir.

Buna göre, 1992’nin başlarında seçildi ve satın alındı. Belirlenen araç kullanıcıları başlangıç eğitim kurslarına gittiler ve ürünü nasıl kullanacaklarını öğrendiler. Bununla birlikte, işe geri döndüğünüzde, senaryoların kaydedilebilmesi için gereken hazırlık süresinin başlangıçta beklenenden çok daha uzun olduğu kısa sürede anlaşıldı. Sonuç olarak, test aracını düzgün bir şekilde kurmak için projenin süresi doldu. Bu nedenle, daha tanıdık olan manuel teste başvurulmuştur ve test aracı hızla raf yazılımı haline gelmiştir.

O zamanlar, çok karmaşık olduğu için tüm suç test aracına atılırken, gerçekte onu düzgün bir şekilde uygulamak için yeterli zaman ayrılmamıştı. Açıkçası bu senaryo, bir aracın uygulanmasının başarısız olmasının en yaygın nedenidir. Muhtemelen daha uzun vadeli bir görüşün daha kaliteli bir test otomasyon çabasıyla sonuçlanacağını takdir etmek yerine kısa vadeli bir ek yük olarak görüldüğü için hazırlık için yeterli zaman ayrılmıyor.

Planlama, Hazırlık ve Nihai Başarı

İlk geliştirme tamamlandıktan ve test edildikten sonra, sonraki sürümler zaten agresif tarihlerle planlanmıştı. Gerçekleştirilmesi gereken regresyon testi miktarının üstesinden gelmek için özel olarak ayrı bir test ekibinin kurulması gerektiği hissedildi.

Bu noktada, regresyon testi tarafı için özel sorumluluk taşıyan bir ekip kurmam istendi. Bu, her zaman kullanıcı kabul testinden daha zahmetli olarak görülen bir görevdi çünkü diğer test biçimlerinden daha tekrarlayıcı ve daha az ilgi çekiciydi.

Test aracıyla yeniden başlatma

Raf donanımı test aracımızın tozunu silkeleyerek başladım ve onu yükseltmeye ve kullanıma sunmaya başladım. Gerekli faaliyetleri kapsayacak bazı üst düzey planlar hazırladım ve üst düzey insanlardan bu faaliyetler için onay aldım. Bazı alanlarda diğerlerinden daha zordu, ancak bunun nedeni kısmen, testin bir faaliyet olarak asla bir projenin tüm yaşam döngüsü boyunca değil, genellikle test başlamadan birkaç hafta önce dikkate alınmasıydı. Dolayısıyla, genel test disiplini konusunda farkındalığı artırmak için yönetmem gereken bir eğitim süreci de vardı.

Başlangıçta alet satıcısı tarafından eğitilmiş bir kişi vardı, bu yüzden doğru bir şekilde planlamaya başlayabilirdik. İlk hedefimiz, yayına girmiş olan ilk üründen komut dosyaları yüklemekti. Bu sürüm için manuel test komut dosyaları gözden geçirildi ve test aracına yüklenebilecek anahtar olanlara kadar filtrelendi. Ortalama olarak on manuel komut dosyasını tek bir otomatik komut dosyasına sıkıştırabileceğimizi bulduk. Bu bir bonustu ve beklediğimizden daha az senaryo kaydı yapmamız gerektiği anlamına geliyordu.

Yazılım test otomasyon araçları
Yazılım test araçları
Yazılım test otomasyonu nedir
Yazılım test yönetimi
Katalon Studio
Ranorex Nedir

Planlamanın ve Hazırlığın Önemi

Bu erken noktada, planlama çalışması esastır. Harcanan emek için gösterecek çok bir şey yok ama en önemli adımlardan biri. Düzgün veya temiz bir bitişin gerekli olduğu herhangi bir şey gibidir, hazırlık, nihai sonucu yapabilir veya bozabilir. Buradaki anahtar mesaj, testlerin mantıksal bir sıra ve hiyerarşiyi takip edecek şekilde planlanması ve yapılandırılması için yeterli zamanın verildiğinden emin olmaktır.

Sponsorlar bu noktadan önce bu çabanın gösterilmesi gerektiğini kabul etmeli ve çok çabuk geri ödeme beklememelidirler. Sponsorlardan bu desteği alırken onları ilerlemeden haberdar etmelisiniz: “Acı yoksa kazanç da yok”.

Burada planlamaya odaklandığım için özür dilemiyorum, çünkü bu, harcanan çabayı hafife almanın kolay olduğu bir alandır. Bizim durumumuzda, ham yazılım ve araçla başlayıp ilk ürünümüz üzerinde tam bir regresyon testi çalıştırabilmemiz dokuz ayımızı aldı.

Geriye dönüp bakıldığında ve hatalardan ders çıkarıldığında, bu süre muhtemelen yaklaşık üç aya indirilebilirdi. Ancak, bu zaman çizelgesi büyük ölçüde otomatikleştirilen sistemin karmaşıklığına ve dahil olan personelin becerilerine bağlıdır.

Organizasyon ve motivasyon

Ekip, temel olarak iş akışından ve kullandığımız test aracıyla ilgili ayrıntılı bilgiden sorumlu tek kişi olan tek bir Sistem Uzmanı etrafında organize edildi. Bu kişi şirket içi sorun giderici olarak çalışır ve sorular, yükseltmeler vb. durumlarda satıcılarla tek irtibat noktasıdır.

Bu yapıya sahip olarak, test uzmanları ortaya çıktıkça kendi sorunlarını çözmede bir dereceye kadar kendi kendine yeterli olabilirler. Testerlara ek olarak, donanım, LAN, iletişim vb. konularda ortaya çıkabilecek daha ayrıntılı teknik sorunları ele almak için bir teknik destek ekibim de var.

Gerekli teknik becerilerin (çeşitli olan) öğretilebileceğine inanıyorum. Benim alanımda, test uzmanlarının test ettikleri ürünü, üzerinde çalışacağı işletim sistemlerini, ağ yapılandırmalarını, donanım kurulumunu, iletişimleri ve bazı programlama becerilerini bilmesi gerekir. Farklı kuruluşların farklı ihtiyaçları olacaktır, ancak bunlar bizim için değerli olanlardır.

Bununla birlikte, ekip üyelerinin uyum sağlayabilmeleri için test etme konusunda doğru zihniyete sahip olmaları gerekir. Hevesli, hevesli, test etmeye ilgi duyan, düşünen ve kaliteyi göz önünde bulunduran kişiler olmaları ve aynı zamanda tüm geliştirmeyi geliştirmeye çabalamaları gerekir. 

Motivasyon, birçok yönetim kitabında iyi bir şekilde ele alınmıştır ve ana ilkelerin tümü geçerlidir. Bununla birlikte, test çalışmasının tekrarlayan doğası nedeniyle, test uzmanlarının meslektaşlarının saygısını kazanarak yaptıklarının değerini görmelerini sağlamak önemlidir.

Bu, en iyi şekilde, projelerde test sürecinin önemini artırmak ve başarılarını göstermekle sağlanır. Ayrıca, değer en iyi şekilde, bir test aracı ve özel personel mevcut olmadığında alternatifin ne olacağı görülerek anlaşılır.

The post Yazılım Aracı Seçimi first appeared on Akademi Delisi (Tez Yaptırma).

Karşılaştırılacak beklenen sonuç yoksa veya test aracı tarafından bulunamıyorsa, herhangi bir karşılaştırma yapmak mümkün değildir. Bir şeyle karşılaştıramıyorsanız, herhangi bir fark olup olmadığını söyleyemezsiniz ve bu nedenle testin başarılı olup olmadığını, başarısız olup olmadığını veya beklenen bir başarısızlık olup olmadığını söyleyemezsiniz. Bu durumdaki test durumu da bilinmiyordur.

Orijinal kusur düzeltildikten ve yazılım artık doğru olduktan sonra, beklenen başarısız sürüm yerine beklenen sonucun doğru bir sürümünü geri yükleyerek test durumunu Geçti olarak geri yüklememiz gerekir. Beklenen gerçek sonucu geri getirmenin iki yolu vardır. İlki, orijinal beklenen sonucu geri yüklemektir. Şimdi testi çalıştırdığımızda herhangi bir fark yok yani testi geçtik.

Beklenen gerçek sonucun geri yüklenmesini otomatik hale getirebilirsiniz. Beklenen başarısız bir sonuçla karşılaştırma yaptığınızda ve farklılıklar olduğunda, gerçek beklenen sonucu kullanarak karşılaştırmayı yeniden çalıştırın. Şu anda herhangi bir fark yoksa, yazılımın artık doğru olduğunu otomatik olarak onaylayarak ve teste Geçti durumu atayarak kendinize daha fazla zaman kazandırmış olursunuz.

Diğer yol, eğer gerçek beklenen sonuç kaydedilmediyse, gerçek sonucu analiz etmek ve şimdi doğru olup olmadığını kontrol etmektir.

Testin asıl sonucu artık doğruysa, sonucun bu sürümü, bu testin bir sonraki çalıştırılışında beklenen sonuç olması için artık ‘terfi ettirilecektir’. Gerçek sonucun son derece dikkatli bir şekilde kontrol edilmesi çok önemlidir, çünkü bu testin gelecekteki tüm uygulamaları şimdi onunla karşılaştırılacak ve doğruluğuna bağlı olacaktır. Bu adım aceleye getirilirse ve yanlış beklenen sonuçlarla karşılaştırma yapmak zorunda kalırsanız, çok fazla zaman kaybedebilirsiniz.

Ayrıntılı Arıza Durumu

Yukarıda özetlenen dört durum değeri, analiz süresinden tasarruf ederek test otomasyonunu daha verimli hale getirmeye yardımcı olacaktır. Bu bilgilere test aracı veya rejiminiz tarafından kolayca erişilebilir durumdaysa, en çok ilginizi çeken arızalar hakkında daha ayrıntılı bilgilere sahip olunarak daha fazla zaman kazanılabilecek başka yollar da olabilir. Aşağıda birkaç örnek verilmiştir.

Bir test tamamlanamıyorsa, karşılaştırılacak sonuç yoktur veya eksiktir. Olağan test durumlarından herhangi birini atayamayız. Normalde testlerin neden tamamlanmadığını analiz etmek için zaman harcamamız gerekirdi.

Aşağıdaki durumlardan bazılarını otomatik olarak raporlayabilirsek, ilgili testlerin yeniden yapılması gerektiğini hemen anlayabiliriz:

« Ağın bir testin ortasında çökmesi gibi çevresel arıza;
» test için gerekli dosyaların eksik olması gibi ilk kurulum yanlış; test edilecek yazılım eksik veya yanlış sürüm;
»Karşılaştırılacak beklenen sonuçlar olmadığı için karşılaştırma yapılamaz ve test başlamadan önce silinmesi gereken yabancı dosyalar varsa;
» bir şey zaman aşımına uğrar, örneğin bir yazıcı açık değilse ve test bir şey yazdırmaya çalışıyorsa;

Bunlardan herhangi biri (veya çevrenizde sorunlara neden olan diğerleri) rejiminiz tarafından tespit edilebilirse, size çok zaman kazandırabilir. Daha ayrıntılı bir test başarısızlık durumunun yararı, test ortamının kalitesini daha doğru bir şekilde yansıtmasıdır. Aksi halde yazılımın kalitesine kötü yansıyor gibi görünüyor ki bu haksızlık olabilir.

Yazılım test otomasyon araçları
Yazılım test araçları
Test otomasyon araçları
Appium
Yazılım testi
Yazılım test yönetimi
Selenium
Selenium Test Otomasyon

Test Edilebilirlik İçin Yazılım Tasarlama

Test etmek için gereken çaba önemli olabilir. Ancak test edilmesi kolay olacak şekilde tasarlanmamış yazılımları test etmek, olması gerekenden çok daha zordur. Örneğin, sistem, tüm Veri Kümesini bir veritabanına veya başka bir sisteme göndermeden önce, kullanıcı girişlerini doğrulayarak ve değerleri çapraz kontrol ederek karmaşık bir veri kümesi oluşturursa, bu Veri Kümesini kontrol edebilmek yararlı olabilir.

Bunun nedeni, gönderildikten sonra tüm verileri veritabanının çeşitli bölümlerinden alarak kontrol etmenin çok daha zor olabilmesidir. Bu ara sonuçlara erişim, hem manuel testlerde hem de otomatik testlerde çok yararlı olabilir. Hatalar bulunursa, hatanın veriler gönderilmeden önce mi yoksa sonra mı ortaya çıktığını biliyorsanız, örneğimiz için analiz süresi önemli ölçüde kısalır.

Ara sonuçlara erişim, genellikle yazılıma ‘test kancaları’ eklemek olarak adlandırılır. Bu tür test kancalarının sayısı ve ayrıntı düzeyi, yazılımın ne kadar test edilebilir olduğunu belirler. Herhangi bir test kancası tarafından sağlanan bilgi miktarını belirtebilmek de yararlıdır. Bazı testler için yalnızca minimum düzeyde bilgi gerekebilir; Eğer büyük miktarda bilgi mevcutsa tek seçenek bu durumda test verimsiz olacaktır.

Test edilen uygulama, otomatikleştirilmiş testi kolaylaştırmak için de geliştirilebilir. Örneğin, uygulama, girdilerin ekran yerine bir dosyadan alındığı bir “test modu” içeriyorsa, uygulama kendi test dosyasında ayarlanan testlerden kendini test edebilir.

Test edilebilirliği geliştirmenin en iyi yolu, uygulama tasarlanırken ve yazılırken nasıl test edileceğini düşünmektir. Neyin test edilmesi gerektiğini ve nasıl test edilebileceğini düşünmek, daha kaliteli tasarım ve yazılımla sonuçlanacak ve geliştiricilere yazılımda hata ayıklamaya geldiklerinde yardımcı olacaktır.

Senkronizasyon

Otomatik testlerin test edilen yazılımla senkronizasyonu, herkes için bir sorun olmasa da, test otomasyonu için büyük bir sorun olabilir.

Sorun şu ki, bir test yürütme aracı, test edilen yazılıma girdileri, bir insan kullanıcının testleri çalıştırabileceğinden çok daha hızlı bir şekilde ateşleyebilir. İnsan test cihazı bir kullanıcı arayüzü ile etkileşime girdiğinde, test cihazı yazılıma ayak uydurur. Örneğin, test cihazı bir dosyanın açılmasını isteyebilir. Pencere ekranda görünene kadar o dosyanın verilerini yazmaya çalışmaz.

Ancak test otomatikleştirildiğinde, araç kendisine açıkça söylenmediği sürece bir şeyin gerçekleşmesini beklemesi gerektiğini fark etmez (ekranda pencere açılır ve odaklanır).

Araç, belirli sistem olaylarıyla eşitlenebilir veya olmayabilir. Olayı tanımlayamazsa, belirli bir süre beklemesi söylenebilir, ancak bu bazı durumlarda yeterli olmayabilir ve testin adımdan çıkmasına neden olabilir.

Garip dosya adlarına sahip olmanın veya bir test tarafından oluşturulan bir dosyayı bulamamanın senkronizasyon sorunlarından kaynaklanması şaşırtıcı olabilir. Ancak, test Farklı Kaydet menü seçeneğini isterse ve bununla senkronize olmazsa, dosya adı olarak gönderilen ilk üç karakter kaybolabilir. Bu, garip bir dosya adı verecektir ve bir sonraki test, bu test tarafından oluşturulmuş olması gereken dosyayı bulamayacaktır.

Tüm bir karakter dizisi kaçırılırsa, uygulama sonunda karakter beklediği duruma gelir ve bir miktar karakter gelene kadar orada kalır. Sonraki test girişleri bir seçenek seçimiyse, uygulama metin bekliyorsa bunlar geçersiz olabilir, bu nedenle bunlar da göz ardı edilir. Otomatikleştirilmiş test, çok geçmeden yapması gereken şeyle tamamen ilgisiz hale gelebilir.

The post Karşılaştırma Araçları  first appeared on Akademi Delisi (Tez Yaptırma).