İlk geliştirmesinden sonra aracın kendisinde bazı teknik gelişmeler oldu. Otomatik test artık kendileriyle iletişim kurmak için mesaj gönderilmesini gerektiren programlarla daha kolay başa çıkabilir. Ağ arızaları gibi beklenmeyen olaylardan kaynaklanan sorunların üstesinden gelmek için bir dizi testin sonunda başarısız olan tüm testleri otomatik olarak yeniden çalıştırabilir.

Çok ilginç bir teknik gelişme, manuel testleri yarı otomatik hale getirmek için özel olarak yazılmış bir gösteri aracıyla (Dramatix olarak adlandırılır) Autotest’in kullanılmasıdır. Otomatik test, test ortamını ayarlamak için kullanılır, yani yazılımın ve veri dosyalarının doğru sürümünün bulunduğundan emin olun, test verilerini başlatın, vb.

Test edilen yazılım daha sonra çağrılır ancak kontrol, manuel test için test komut dosyasını görüntüleyen Dramatix’e verilir. Manuel test cihazı daha sonra, tüm bağlantıları korurken nesnelerin hareket ettirilip ettirilemeyeceğini kontrol etmek gibi (doğrulamanın görsel doğası nedeniyle otomatikleştirilmesi pratik olmayan) işlemleri gerçekleştirir. Test cihazı daha sonra Başarılı veya Başarısız durumunu kaydeder. Testin sonunda, Otomatik test tüm temizleme işlemlerini gerçekleştirir ve standart şekilde işlemek için Başarılı/Başarısız bilgilerini toplar.

Teknik Problemler

Ayrıca yıllar içinde, örneğin serbest bırakma prosedürlerine entegrasyonu daha verimli hale getirmek gibi bazı küçük geliştirmeler de yapılmıştır. Artık konfigürasyon yönetim sistemine tek bir komut kaynak kodunu kopyalayacak, yapıyı gerçekleştirecek ve otomatikleştirilmiş testleri çalıştıracaktır.

Hâlâ karşılaşılmakta olan birkaç teknik sorun var. Birincisi, beklenen sonuçların yaklaşık %1’inin aslında yanlış olmasıdır. Bunlar zamanla keşfedilir ve bulunduklarında düzeltilir, ancak muhtemelen Test Paketlerinde bazı yanlış beklenen sonuçlar vardır.

Zaman zaman meydana gelen bir domino etkisi de vardır. 10 test vakası başarısız olursa ve bir düzeltmenin bunu düzeltmesi gerekiyorsa, yeni yazılım gerçekte 90 testte başarısız olabilir. Bu cesaret kırıcı olabilir.

Bazı manuel testler hala gereklidir. Örneğin, işlev tuşu düzenleri farklı platformlar için farklıdır. Bu, en az bir kez manuel olarak test edilmeleri gerektiği anlamına gelir. Manuel testten x olayları saklanırsa, işlev tuşu düzeninin değişiklikten etkilenmemesi koşuluyla, değişiklikler yapıldığında testi tekrarlamak için yeniden oynatılabilirler.

Yazılım test Süreçleri
Yazılım test teknikleri
Yazılım test Çeşitleri
Manuel test Örnekleri
Otomasyon testi Nedir
Yazılım test araçları
Kara Kutu test Teknikleri
Manuel test ve otomasyon test

Değişiklikler ve Avantajlar

En çarpıcı fayda, bu kadar geniş bir test setini bu kadar sık çalıştırabilmenin garanti ettiği ürünlerin kalite düzeyidir. Tüm düzeltmeler, yamalar ve değişiklikler, yalnızca bir kez değil, her aşamada tamamen gerileme testine de tabi tutulur.

Testlerin tümü ‘son’ düzeltmeden sonra yeniden çalıştırılabilir, böylece müşterilere gönderilen yazılımın çok yüksek kalitede olduğunun bilinmesi de sağlanır. Otomatik testler gerçekten de kalite sisteminin merkezinde de yer alır.

Yönetim açısından en büyük etki, herhangi bir iş için tahmin edilen sürenin artık her zaman tam bir regresyon testi çalıştırma süresini içermesidir. Önceden, geliştirme tahminleri, yeterli test için harcanan zamanı dahil etmeyi hatırlama eğiliminde olmayan (iyimser?) geliştiriciler tarafından da veriliyordu.

Örneğin, yeni bir özelliği test etmek için süreyi dahil etmiş olabilirler, ancak regresyon testlerini veya mevcut testlerin bakımını dahil etmemiş olabilirler. Bu, geliştirmenin sonunda “yakalanmaya” yol açtı ve zamanın uzatılması gerekti. Örneğin, bir geliştirme projesi için on hafta tahmin ediliyorsa, hiç kimse testin ne kadar süreceğini ve hatta kaç test yapılması gerektiğini doğru bir şekilde de tahmin edemez.

Bu nedenle, geliştirme çalışması olması gerektiği kadar öngörülebilir değildi. Kültürdeki en büyük tek değişiklik, bitiş tarihlerinin artık çok iyi bir doğrulukla tahmin edilebilmesidir. Bu, planlamanın güvenle yapılabileceği ve tüm sürecin çok daha iyi yönetilebileceği anlamına da gelir.

Elbette süreç mükemmel değil, bu nedenle ara sıra küçük bir kayma oluyor, ancak genel olarak işler çok daha öngörülebilir. Bunun bir örneği, bir müteahhit sözleşmesini yakın zamanda bitirdiğinde işi yeniden tahsis edebildi ve etkinin beş ay sonra ne olacağını bildi. Önceden, birkaç hafta ileride bir etki görmek oldukça iyi kabul ediliyordu. Otomatikleştirilmiş test sistemi olmadan, bu doğrulukla ve şimdiye kadarki geleceği tahmin etmek de oldukça zor olurdu.

Otomatikleştirilmiş test rejiminin bir diğer önemli avantajı, Windows NT’ye geçmemizdi. Bu, şimdiye kadar desteklenen UNIX platformlarından tamamen farklı bir mimariye sahiptir. Otomatik test çok yardımcı oldu; aslında, onsuz NT’ye bağlantı kurmak muhtemelen mümkün olmazdı. Ürün hattının %95’ini NT’ye taşıdık ve mümkün olan yerlerde de mevcut testler yapıldı.

Taşıma işi, QA görmeden önce geliştirme aşamasında yapılır. Platformun son KG’si yapıldığında, otomatik testten geçen programlarda çok az kusur bulundu. Bulunan kusurlar temel olarak NT’nin benzersiz özelliklerinde, örneğin işlemciler arasındaki boru iletişimindeydi.

Müşteriler için pek çok küçük değişiklik olduğunda başka bir fayda ortaya çıkar. Çok sayıda şeyle uğraşırken küçük değişiklikleri gözden kaçırmak çok kolaydır. Otomatik test, hepsini hatırlayıp hatırlamadığınızı öğrenmenin de harika bir yoludur.

Karmaşık karşılaştırmalarda filtrelerden yararlandık. Örneğin, bir resim yeniden çizildiğinde, elemanların çizim sırasına bakılmaksızın kullanıcıya aynı görünmelidir. Araç, çizim talimatlarının sıralamasında farklılıklar bulabilir, ancak karşılaştırma yapmadan önce sırayı sıralayabiliriz. Bu özellik aslında yakın zamanda ortaya çıkan bir yenilik değil, zamanla geliştirildi. Ayrıca, 64 bitlik bir platforma (Alfa) geçerken bir miktar yuvarlama hatası toleransı oluşturmayı da faydalı bulduk.

Ne kadar küçük olursa olsun, herhangi bir yama için tüm testleri yeniden yapmak politikamızdır. Bu çok faydalı oldu. Geçen yıl, bir düzeltmeyle getirilen bir dizi kusur bulundu. Bu, müşteri açısından en kötü şeydir; bir kusuru yalnızca bir başkasıyla değiştirmek için de rapor ederler.

The post Otomatik Test Teknikleri first appeared on Akademi Delisi (Tez Yaptırma).

Kayıt ve oynatmanın dezavantajları, yalnızca aracı zamanla kullanmaya başladığınızda ortaya çıkar. Kayıt tekrarı, ilk gösterildiğinde her zaman çok etkileyici görünür, ancak verimli, uzun vadeli bir test otomasyonu rejimi için iyi bir temel değildir.

Senaryo, kaydedildiği şekliyle, sonradan eline alan biri için pek okunabilir olmayabilir. Otomatik bir testin tek değeri yeniden kullanılmasıdır. Ham kaydedilmiş bir komut dosyası, neyin test edildiği veya testin amacı hakkında hiçbir şey açıklamaz.

Bu tür yorumların, kayıt yapılırken (tüm araçlar buna izin vermez) veya kayıt bittikten sonra komut dosyası düzenlenerek test uzmanı tarafından eklenmesi gerekir. Bu bilgiler olmadan herhangi bir bakım görevi en iyi ihtimalle zor olacaktır.

Ham kaydedilmiş bir komut dosyası, kaydedilen şeyin ayrıntılarına da çok sıkı bir şekilde bağlıdır. Araca bağlı olarak, ekrandaki nesnelere, belirli karakter dizilerine ve hatta ekran bitmap konumlarına bağlı olabilir. Yazılım değişirse düzeltme: yazılım değiştiğinde – sıkı bir şekilde bağlı olduğu herhangi bir şey değiştiyse, orijinal komut dosyası artık doğru çalışmayacaktır.

Çoğu zaman, betiğin kendisini güncelleme çabası, testi manuel olarak yeniden çalıştırırken betiği yeniden kaydetmekten çok daha fazladır. Bu genellikle herhangi bir test otomasyonu avantajı sağlamaz. Örneğin, kaydedilen girdilerin değerleri girildiği şekliyle kesin ve ayrıntılı değerlerdir, ancak bunlar artık komut dosyasına ‘sabit kodlanmıştır’.

Kayıt, yalnızca eylemlerden ve test girişlerinden oluşur. Ancak genellikle bir test çalıştırmanın nedeni, uygulamanın doğru şeyi yapıp yapmadığını görmek için test sonucuna bakmaktır. Test girdilerinin basitçe kaydedilmesi, sonuçların herhangi bir şekilde doğrulanmasını içermez.

Bir test yapmak için kayıtlı herhangi bir komut dosyasına doğrulama eklenmelidir. Araca bağlı olarak, bu ek işi kayıt sırasında (ancak ek zaman ve çaba gerektirir) veya ilk yeniden oynatma sırasında yapmak mümkün olabilir, aksi takdirde kaydedilen komut dosyasını düzenlemek gerekecektir.

Testi yalnızca kaydederek otomatikleştirmeyin. Hedeflerine uygun verimli ve etkili bir test otomasyon rejimi uygulamak her profesyonel test kuruluşunun amacı olmalıdır.

Yalnızca manuel testlerin kaydedilmesi, aşağıdaki nedenlerden dolayı bunu başaramaz:

• Senaryosuz (ad hoc) testler genellikle çok etkili değildir (sistemi iyi bilen ve önceki sürümlerin zayıflıklarını deneyimlemiş veya yazılımın nasıl çalıştığını iyi anlamış bir kişi varsa, bazı durumlarda etkili olabilir) çalışır ve olası kusurlu alanları belirleyebilir). Ad hoc testi otomatikleştirmek, en iyi ihtimalle daha hızlı, ancak yine de çok etkili olmayan testlerle sonuçlanacaktır.
• Yalnızca girişin kaydedilmesi, otomatik bir testle sonuçlanmaz. Bir testin sonuçlarının beklendiği gibi olduğundan emin olmak için kontrol edilmesi gerekir; bu otomatik değilse, bu otomatik bir test değildir, yalnızca otomatik girdidir.
• Yazılım değiştiğinde yeniden kayıt yapmak verimsizdir. Yazılımın kullanıcı arayüzündeki hemen hemen her değişiklik, test girdilerinde veya sıralarında veya her ikisinde de değişikliklere neden olacaktır. Kayıtlı komut dosyalarını düzenlemek ne kolay ne de hoştur. Testi basitçe yeniden kaydetmek genellikle daha kolay ve daha hızlıdır, ancak bu genellikle kabul edilemeyecek kadar yüksek bir maliyete neden olur.

Şu anda yalnızca ad hoc manuel test gerçekleştiriyorsanız, test sürecinizi otomatikleştirmeye çalışmaktan çok daha fazla fayda elde etmenizi öneririz. Örneğin, test tekniklerinin kullanılması, testinizin etkinliğini ikiye katlayabilir. Bu, etkisiz testleri daha hızlı çalıştırmaya çalışmaktan çok daha fazla para tasarrufu sağlayacak ve daha kaliteli yazılımlara yol açacaktır.

Manuel test nedir
Manuel test araçları
Manuel test Örnekleri
Otomasyon testi Nedir
Manuel test ve otomasyon test
Manueltest tc sorgu
Item test ne demek
Automation tester Nedir

Manuel Doğrulama ile Otomatik Yürütme

Halihazırda, manuel olarak gerçekleştirilen örnek test durumumuzun kaydedilmesiyle oluşturulmuş bir komut dosyamız var ve bu artık test aracımız tarafından istediğimiz sıklıkta tekrar oynatılabilir. Ancak, otomatikleştirdiğimiz tek şey test girdileridir.

Test senaryosunun doğru sonuçları üretip üretmediğini belirlemek için, yine de beklenen sonuçları manuel olarak kontrol etmemiz gerekiyor. Araç henüz bizim için herhangi bir kontrol yapmayacak çünkü biz ona bunu yapması talimatını vermedik; şimdiye kadar, yalnızca bir test girdisi setinin nasıl girileceğini biliyor, yani bizim tek test durumumuzun girdileri önemlidir. 

Özellikle ilk başta sizin için girdileri yazan bir araca sahip olmanın belirli bir yenilik değeri vardır. Ekranın etrafında ‘kahve partileri’ toplanma eğilimi var. ‘Keşke o kadar hızlı yazabilseydim’ gibi sözler kulak misafiri olabilir.

Bununla birlikte, testi yapanlar testin işe yaradığını (ya da çalışmadığını) doğrulamak için hala orada oturup testi izlemeleri gerektiğini fark ettiklerinde, yenilik kısa sürede etkisini yitirecektir. Otomasyon henüz bu aşamaya geldiyse, bir gecede ve hafta sonu test etme fikri, test uzmanları arasında popüler olmayacaktır.

Test senaryomuzun düzgün çalışıp çalışmadığını manuel olarak kontrol etmek, araç komut dosyasını yeniden yürütürken ekranı izlemeyi gerektirebilir. Verilerin ekranda göründüğü gibi kaydedildiğinden emin olmak için, test yürütüldükten sonra düzenlenen belgeye (country2.dcm) bir göz atmak da iyi bir fikir olacaktır.

Otomatik testlerimiz var mı? Pekala, biraz otomasyonumuz var: giriş otomatikleştirildi. Bununla birlikte, yazılımın doğru şeyi yapıp yapmadığını kontrol etmek için hâlâ manuel bir sürecimiz var.

Test Sonucu Karşılaştırmasını Otomatikleştirme

Genellikle pratik ve gereksiz olduğu için, bir test senaryosunun tüm sonucunun (yalnızca neyin değiştiğini değil aynı zamanda değişmeyen her şeyi de içerecek şekilde) karşılaştırılacağı pek olası değildir. Genellikle, yalnızca en önemli veya en önemli yönlerin karşılaştırılması gerekir.

Ekran çıktıları gibi bazı çıktılar test yürütülürken gerçekleştirilebilir, bu dinamik karşılaştırma olarak bilinir. Bir dosyaya veya veritabanına bazı çıktılar gibi diğer sonuçlar ancak test senaryosunun yürütülmesi tamamlandıktan sonra karşılaştırılabilir, bu yürütme sonrası karşılaştırma olarak bilinir.

Otomatik bir testin, dinamik ve yürütme sonrası karşılaştırmaların bir kombinasyonunu kullanması gerekebilir. Otomatik karşılaştırmanın nasıl uygulanacağına karar verirken alınması gereken bir dizi tasarım kararı vardır. 

The post Manuel Testleri Kaydetmek first appeared on Akademi Delisi (Tez Yaptırma).

Örnek Test Durumu

Örnek uygulamamızın adı Scribble. Değinmek istediğimiz noktaları göstermek amacıyla kullanılan çok basit bir kelime işlemcidir. Gerçek uygulamalar çok daha karmaşık olacak ve bu, testlerini otomatikleştirme sorunlarını da buna bağlı olarak daha karmaşık hale getirecek.

Karalama’nın bir özelliği, bir belgenin Liste olarak bilinen bir yapı içerebilmesidir. Bu bölümde kullandığımız örnek test durumu, bazı Liste düzenleme işlevlerini kullanır.

Listede (Hollanda) yalnızca bir öğe bulunan ilk durumdan başlayarak, Listenin sonuna eklenen yeni bir öğe olan Belçika’yı (Öğe Ekle işlevini kullanarak) ekliyoruz. Ardından, iki öğenin sırasını değiştiren Listeyi sıralarız.

Üçüncü öğeyi (Danimarka) eklediğimizde, artık sıralanmamış değil sıralanmış bir Liste olduğu için Listeye doğru yere eklenir. Son olarak, Listedeki (Belçika) ilk öğeyi, Öğeyi sil’i seçip konum numarasını girerek siliyoruz.

Bir Karalama Listesi Testi

Artık uygulamamızı (manuel olarak) test etmeye hazırız. Ülkeler adlı bir belgede bir Listenin düzenlenmesini test edeceğiz (‘dcm’ soneki ‘belge’ anlamına gelir). Başlangıç durumu, üç öğeden oluşan sıralanmış bir Listedir.

Test durumu aşağıdakileri gerçekleştirecektir:

• sıralanan listeye iki yeni öğe ekleyin;
• bir öğeyi hareket ettirin (bu, Listeyi sıralanmamış hale getirir);
• sıralanmamış listeye bir öğe ekleyin;
• bir öğeyi silin;
• orada olmayan bir öğeyi silmeye çalışın (geçersiz konum numarası).

Bu çok titiz bir test durumu değil ve elbette bu işlevselliği yeterince test etmek için başkaları da gerekecek. Ancak, yukarıdaki test durumunu amaçlarımız için makul olarak seçtik. Test senaryosunun yürütülmesi bir dizi ekran görüntüsünde gösterilmektedir.

Test Girdisi Nedir?

Yukarıdaki test durumunda, uygulamayı ilk çalıştırmadan tamamlamaya götürmek için girdi girdik ve test senaryosunu gerçekleştirmek için belirli verileri girdik. Gerçekleştirdiğimiz belirli tuş basmaları ve/veya fare eylemleri gösterilir.

Eylemlerimizi fiziksel konumları yerine ekrandaki mantıksal öğeler açısından tanımladığımıza dikkat edin, örneğin ‘bit konumu’ yerine ‘Liste menüsü’. Listelenen tüm fare tıklamalarının sol fare düğmesi olduğunu da unutmayın.

Yazılım test otomasyon araçları
Test otomasyon araçları
Yazılım test otomasyonu nedir
Test otomasyon Eğitimi
Manuel test ve otomasyon test
Otomasyon testi Nedir
Test otomasyon Çeşitleri
Test otomasyonu

Manuel Test Süreci

Yukarıdaki örnekte az önce manuel olarak gerçekleştirdiğimiz test durumu, şimdi bir tekrar yakalama aracı kullanarak otomatikleştirmeye çalışacağımız test durumudur. Tek bir test senaryosunu otomatikleştirmek için harcanan çabanın miktarı birçok şeye bağlıdır ve büyük ölçüde değişir.

Deneyimli otomatörler, genellikle testi manuel olarak çalıştırmak için gereken çabanın 2 ila 10 katı gerektiğini bildirir ve ara sıra raporlar bunun manuel test çabasının 30 katına kadar çıktığını söyler.

Bu nedenle, manuel olarak yarım saat süren bir test senaryosunun otomatikleştirilmesi 1 ila 5 saat arasında sürebilir, ancak 15 saate kadar da sürebilir. Otomatikleştirmeye başladığınızda, bir testi otomatikleştirmenin, manuel olarak çalıştırmaya göre en az beş kat daha uzun sürmesini bekleyin.

Bir test senaryosunu otomatikleştirmek için gereken çaba miktarını etkileyen şeylerden bazıları şunlardır:

» Kullanılan araç. Araçlar, otomatikleştirilmiş testler oluşturmayı kolaylaştırmak için tasarlanmış çeşitli kolaylıklar ve özellikler sağlar ve test uzmanlarının kayıt sırasında testin yeniden oynatılırken nasıl davranması gerektiği konusunda daha fazla belirlemesine giderek daha fazla olanak tanır.

« Test otomasyonuna yaklaşım. Otomatikleştirilmiş testler oluşturmak için kullanabileceğimiz birkaç farklı yaklaşım vardır, ancak çoğu kişinin kullandığı ilk yaklaşım manuel olarak gerçekleştirilen testi kaydetmek ve ardından bu kaydı yeniden oynatmaktır.

Diğer yaklaşımlar, kaydedilen komut dosyalarını değiştirmek veya komut dosyalarını manuel olarak hazırlamak için ek çaba gerektirir. Bu başlangıçta daha uzun sürse de, fikir yeni testlerin uygulanmasını kolaylaştırmak ve bakım maliyetlerini azaltmaktır.

» Test otomatının deneyim düzeyi. Açıkçası, bir test aracını kullanmaya çok aşina olan kişiler, onu daha hızlı ve daha az hatayla kullanabilecektir. Ayrıca iyi çalışmayan uygulamalardan kaçınabilmeli ve işe yarayanlara konsantre olabilmelidirler.

” Çevre. Test edilecek yazılımın, test için tam olarak çoğaltılmasının zor olduğu belirli ortamlarda çalıştığı durumlarda, testi otomatikleştirmek daha zor olabilir. Örneğin, gömülü yazılımlar ve gerçek zamanlı yazılımlar, ticari olarak temin edilemeyen özel araçlar veya özellikler gerektirebileceğinden özellikle zahmetlidir.

» Test edilen yazılım. Toplu programlar gibi kullanıcı etkileşimi olmayan yazılım uygulamalarının testlerinin otomatikleştirilmesi, yürütüldükleri ortamın yeniden üretilebilmesi koşuluyla çok daha kolaydır. Bunun nedeni, kullanıcı etkileşiminin ‘programlanmış’ olması gerektiğidir ve bu çok fazla iş gerektirebilir.

Bu kayıt altına alınabilse de uzun vadede uygun maliyetli bir çözümle sonuçlanmamaktadır. Bir toplu programın kullanıcı etkileşimi yoktur, ancak çağrıldığında veya yürütme sırasında dosyalardan veya veritabanlarından okunduğunda kendisine iletilen bilgilerle denetlenir.

Testi ve özellikle otomatik testi daha zor hale getirebilen yazılım uygulamalarının birçok yönü de vardır. Yazılım uygulamalarını tasarlarken dikkate alınması gereken birçok test sorunu vardır.

Ve genellikle, otomatikleştirme testini yapacak veya bozacak olan, yazılımın kendisinin tasarımıdır.

• Mevcut test süreci. Testi otomatikleştirirken, açıklandığı gibi test sürecini oluşturan beş aktiviteden bazılarını (test koşullarının belirlenmesi, test durumlarının tasarımı, testleri oluşturma, yürütme ve beklenen sonuçların gerçek sonuçlarla karşılaştırılması) otomatik hale getiriyoruz. Bunun sonuçları bir sonraki tartışma noktamız.

Mevcut test sürecinin, testi otomatikleştirmek için gereken çaba üzerindeki etkisi çok büyüktür. Test senaryoları belgelenmemişse ancak test uzmanları bunları gerektiği gibi oluşturuyorsa, test senaryolarının otomatikleştirilmesi, bunların tasarlanmasını da içerecektir. Diğer uçta ise, test durumları her girdi ve karşılaştırma not edilecek şekilde çok ayrıntılı olarak belgelenirse, bunları otomatikleştirmek daha az çaba gerektirecektir.

Aşağıdaki alt bölümlerde, test sürecinin üç geniş kategorisini açıklıyoruz: test senaryolarının tasarlanmadığı veya belgelenmediği geçici test, test senaryolarının belgelendiği ancak tüm detayların belirtilmediği belirsiz manuel komut dosyaları ve her girdinin ve karşılaştırmanın not edildiği ayrıntılı kılavuz metinleri söz konusudur. Kendi test süreçleriniz, aşağı yukarı bu kategorilerin bir veya daha fazlasına uymalıdır.

The post Test Otomasyonunun Tekrarı first appeared on Akademi Delisi (Tez Yaptırma).