Test yönetimi araçlarının yardımcı olabileceği bir alan, testlerle ilgili bilgilerin düzenlenmesi ve testlerin gereksinimlere ve yazılıma göre izlenebilirliğinin sağlanmasıdır. Bazı test yönetimi araçları, test sürecinin yönetiminden çok testlerin yönetimiyle ilgilenir.

Diğer test yönetimi araçları, test sürecinin yönetimini desteklemeye yardımcı olur. Proje yönetimi araçları, test yürütme gibi birden çok kez tekrarlanan etkinliklerin karşılanmasında sorunlar olabilmesine rağmen, testlerle ilgili yönetim düzeyindeki bilgileri takip etmek için de kullanılabilir.

Ancak, belgelenen bilgiler iyi organize edilmemişse, testler veya test süreci hakkındaki bilgileri belgelemek için yalnızca bir araç kullanmak yardımcı olmayacaktır. Mevcut test belgeleriniz hantalsa, bu belgelerin biçimi ve içeriği ele alınmalıdır. Belki de test koşullarının test durumlarından net bir ayrımı yoktur.

Hangi testlerin yapıldığının raporlanması, bir kelime işlemci tablosunda veya elektronik tabloda testlerin bir listesinin olması ve testin uygulama tarihinin şimdiye kadar olduğundan daha sadık bir şekilde kaydedilmesiyle geliştirilebilir.

Hangi testlerin yapılıp yapılmadığını takip etmek için bir kişiyi test ‘tazısı’ olarak atamak, bu sorunu minimum maliyetle pekala aşabilir. Manuel dokümantasyonun kalitesini artırmak, yeni bir test aracı sunmaktan daha hızlı, daha ucuz ve daha etkili olabilir.

Yazılımın ne kadarının test edildiğini bilmiyoruz. Bir test yürütme aracı, raporlama iyi organize edilmişse, size tanımlanmış bir dizi testin çalışıp çalışmadığı hakkında bilgi verecektir, ancak bu, aslında size yazılımı ne kadar kapsamlı bir şekilde uyguladığınızı söylemez.

Test kapsamı araçları, belirli bir test seti tarafından çeşitli ‘kapsam öğelerinin’ yüzde kaçının uygulandığı hakkında size bilgi verebilir. Ancak, bazı satıcılar hem yürütme hem de kapsam araçlarını içeren araç takımları sunsa da, kapsam araçları genellikle test yürütme araçlarıyla birlikte paketlenmez.

Kapsama alanı manuel olarak da ölçülebilir, ancak bu en iyi şekilde yüksek bir seviyede yapılır. Örneğin, sistemdeki iş kurallarının, ekranların veya menü öğelerinin toplam sayısını listelerseniz, listelenen tüm öğelerin bir dizi test kapsamında olup olmadığını manuel olarak kontrol edebilir ve kapsamı genişletmek için yeni testler tasarlayabilirsiniz.

Testte bulunan kusurlar daha önce bulunmuş olmalıdır; kullanıcılar tarafından bulunan kusurlar, test sırasında bulunmuş olmalıdır, yani test, kusur bulma konusunda yeterince etkili değildir. Bu sorunun test otomasyon araçlarıyla çözülebileceği bazı durumlar vardır.

Örneğin, kusurların ağdan kayıp gitmesinin nedeni, planlanan tüm testleri manuel olarak çalıştırmak için yeterli zamanın olmamasıysa, o zaman bir araç yardımcı olabilir.

Manuel test araçları
Hermenik test modeli
Fonksiyonel test Araçları
Test otomasyon programları
Testcomplete nedir
Ranorex Nedir

Bununla birlikte, testlerin kendileri etkisizse, yani kullanıcıların bulduğu kusurlara yönelik değilse, o zaman onları nasıl çalıştırırsanız çalıştırın (otomatik veya manuel), testler bu kusurları bulmayacaktır. Hata bulmada ne kadar iyi olduklarını belirleyen testlerin kalitesidir. Testleri otomatikleştirmenin, testlerin kalitesi üzerinde hiçbir etkisi yoktur; otomasyon verimliliği etkiler.

Bazı kusur türlerini bulmaya yardımcı olacak bazı araç türleri (test yürütme araçları değil) vardır. Statik analiz araçları, ölü kod, sonsuz döngüler ve depolanan ancak kullanılmayan veya başlatılmadan önce kullanılmayan veri öğeleri gibi bazı kusur türlerini testler yapılmadan önce algılar. Dinamik analiz araçları, bellek sızıntılarını ve diğer bazı kaynak sorunlarını algılar ve testler yapılırken ve hatta işlem sırasında koddaki bu kusurları bulmaya yardımcı olabilir.

Testleri daha etkili hale getirmenin en iyi yolu, kusurları bulmayı amaçlayan ‘hata merkezli’ test tekniklerini kullanmaktır. Test tekniklerinin doğru kullanımı, kusurları bulmada testlerin etkinliğini kolayca ikiye katlayabilir. Test tekniklerini daha fazla veya daha az derecede kapsayan birkaç kitap var. Yazarların web sitesinde bir bibliyografya tutulur.

Yazılım incelemesi, yalnızca koda değil, herhangi bir yazılı belgeye uygulanabilen ve tüm inceleme süreçleri arasında en etkili olduğu gösterilen güçlü bir kusur algılama ve kaldırma (ve kusur önleme) tekniğidir. (Denetim, mevcut kusurların %80’e kadarını tek bir geçişte, %95’ini veya daha fazlasını birden çok geçişte bulabilir.)

Araç Seçiminin Zamanlaması

Mevcut test problemlerinizi değerlendirdikten ve bir test aracının uygun bir çözüm olacağı sonucuna vardıktan sonra (belki diğerlerine ek olarak), araç seçiminde bir sonraki adım, bunun doğru zaman olup olmadığını değerlendirmektir. Bir test aracı seçmeye çalışmak için doğru ve yanlış bir zaman da vardır. Zaman doğru değilse, dünyanın en iyi aracının bile en iyi şekilde seçilmesinin başarılı olma olasılığı da oldukça düşüktür.

Otomatik bir çözüm genellikle ‘daha iyi görünür’ ve harcama yetkisi vermek, test sürecinin kendisinin daha temel sorunlarını ele almaktan daha kolay olabilir. Aracın, ek bir dikkat gösterilmeden kötü bir süreci düzeltmeyeceğini anlamak önemlidir. Aracı uygulamanın yanı sıra test uygulamalarını iyileştirmek mümkündür, ancak bu bilinçli bir çaba gerektirir.

• devam etmekte olan büyük bir organizasyonel karışıklık veya panik olmadığında;
• bir kişinin araç(lar)ı seçme ve uygulama sorumluluğu olduğunda;
• insanlar test uygulamasının mevcut durumundan memnun olmadığında;
• üst yönetimden donanım oluşturma çabalarını yetkilendirme ve destekleme taahhüdü olduğunda.

Bu koşullardan bir veya daha fazlasının kuruluşunuz için geçerli olmaması, test otomasyonunu başlatmamanız gerektiği anlamına gelmez. Sadece bunu yapmanın biraz daha zor olabileceğini de ima eder.

Araç ne kadar yardımcı olmalı?

Hangi araç desteğinin uygun bir çözüm olduğu sorunu belirledikten sonra, satın aldığınız herhangi bir aracın gerçekten yardımcı olup olmadığını nasıl anlayacaksınız? Koşullarınıza bağlı olarak, araç için başarı kriteri olarak ölçülebilir hedefler belirlemelisiniz. Ölçülebilir kriterler belirlemek, en azından maliyetler hakkında geniş bir genel fikir elde etmek için zor değildir. Aracın uygun maliyetli olup olmayacağını bilmek için gerekli olan tek şey genel bir fikirdir. 

The post Test Yönetimi first appeared on Akademi Delisi (Tez Yaptırma).

Otomatik bir test, belirli bir beklenen sonucu yazılımın ürettiği gerçek sonuçla karşılaştırabilir, ancak aracın kendisi size yazılımın geçip geçmediğini söyleyemez, yalnızca eşleşip eşleşmediğini söyleyebilir. Bu, test otomasyonu için hatırlanması gereken önemli bir ayrımdır.

Örneğin, beklediğiniz sonuç yanlışsa, bir manuel testçi bunu fark edebilir ve gerçek sonuç hatalı beklenen sonuçla eşleşmediğinde bile yazılımın doğru olduğunu beyan edebilir.

Bir alet bunu asla yapmaz. Çoğu kişi, belirli bir testle ilgili olarak yazılımın yalnızca iki durumunun Geçti ve Kaldı olduğunu varsayar. Ancak test otomasyonu ile birlikte bazı ek durumlara ihtiyaç duyulmaktadır.

Bilinen Düzeltilmemiş Kusurlar

Bir dizi testin başarısız olduğunu, ancak hepsinin başarısız olmasına neden olan kusurun ciddi olmadığını ve henüz düzeltmenin aciliyeti olmadığını varsayalım. Artık yazılımda düzeltilmemiş bilinen bir kusurumuz var. Örneğin, Karalama’daki kelime sayısının 1 olduğunu varsayalım, bu nedenle 143 kelime varsa, sadece 142 sayılır. Bu bir kusur, kelime sayısının farklı paragraflar için kontrol edilen şeylerden biri olduğu yarım düzine testte başarısız olabilir. 

Bu yazılım üzerinde bir sonraki otomatik testleri çalıştırdığımızda, kusur düzeltilmemişse, tekrar hatalar alacağız. Büyük olasılıkla aynı başarısızlıklardır, ancak hepsini analiz edene kadar bunu bilemeyeceğiz. Daha önce gördüğümüz gibi, başarısızlık analiz süresi önemli olabilir. Yine de bu bilinen kusurdan kaynaklanan arızaların hiçbiriyle ilgilenmiyoruz.

Yalnızca birkaç testiniz varsa bu ciddi bir sorun değildir. Ancak yüzlerce veya binlerce testiniz varsa, o zaman ilginizi çekmediğini gördüğünüz başarısızlıkları analiz etmek için zaman harcamak zorunda kalmak sadece boşa değil, aynı zamanda çok sinir bozucudur.

Yukarıda gösterilen arızaların analizi zaman alacaktır. Ama daha önce tamamen aynı şekilde başarısız oldu ve şimdi bununla ilgilenmiyoruz.

Muhtemel Çözümler

Daha önce başarısız olan testlerin tüm başarısızlıkları yoksayılsın mı?

Tüm bu başarısızlıkları basitçe görmezden gelebiliriz. Daha önce başarısız olan bir test çalıştırıldığında, bu test için başarısızlık analizinde herhangi bir zaman harcamayız.

Ama neden test çalıştırıldı? Çalıştırmak ve sonuçları yok saymak, bu testi geçerli setten çıkarmaktan daha kolay olabilir – o zaman sonuçları yok saymak iyi bir çözümdür.

Bilinen kusurumuz henüz giderilmemiş olsa da yazılım başka bir şekilde değiştirildiği için testi yeniden çalıştırmış olabiliriz. Şimdi sonuçlara bakmak istiyoruz. Ancak belki de tek bir ilginç sonuç bulmak için gözden geçirmemiz gereken 100 sahte sonucumuz olduğu gerçeği, zamanımızı iyi kullanmak değildir ve o kadar sıkılabiliriz ki aradığımız ilginç sonucu kaçırabiliriz.

Başka bir alternatif, başarısız sonuçları yeni beklenen sonuçlar olarak adlandırmaktır. Bu, bir dahaki sefere onları başarısızlık olarak ortadan kaldırma avantajına sahip olacaktır. Şimdi testleri çalıştırdığımızda sadece iki veya üç başarısızlık elde edebiliyoruz ve bunlar bizi ilgilendiren şeyler.

Burada önemli bir tehlike var. Beklenen sonuçları kasıtlı olarak yanlış olacak şekilde değiştirdiğimizi hatırladığımız sürece, küçük kusur düzeltildikten sonra geri dönüp beklenen gerçek sonuçları eski haline getirebiliriz. Ancak, insan doğası gereği, bu unutulabilir.

Bu test durumuna ‘beklenen başarısızlık’ diyoruz. Bir test hatası olarak etiketlenmiş olması, onu değiştirdiğimizi unutamayacağımız anlamına gelir. Beklenen bir sonuç olması, ilgilenmediğimiz başarısızlıkları analiz ederek zaman kaybetmekten kendimizi kurtarabileceğimiz anlamına gelir. Test çalıştırıldığında, beklenen gerçek sonuç yerine beklenen başarısızlık sonucuyla karşılaştırırız.

Yazılım test otomasyon araçları
Yazılım test araçları
Manuel test araçları
Hermenik test modeli
Fonksiyonel test Araçları
Test yönetim Araçları
Hp LoadRunner nedir
Appium

Bu testi manuel olarak analiz etmek özellikle zorsa, beklenen gerçek sonucu bir yere kaydederek saklayabiliriz. Aksi takdirde, beklenen sonucu, beklenen başarısızlık sonucuyla değiştireceğiz. Gösterilen Çalıştırma 4’te kusur henüz giderilmemiştir. Bu testi yeniden çalıştırmak istiyoruz, çünkü muhtemelen bu testi çalıştırılacak bir pakette tutmak, bu testi özel olarak hariç tutmaktan daha kolaydır. Geçen seferki başarısızlıklarla ilgilenmiyoruz.

Bu nedenle, gerçek sonucu beklenen başarısızlık sonucuyla karşılaştırırız. Fark olmadığı için analiz için zaman harcamamıza gerek yok. Test durumu Geçti değil, Beklenen Başarısız olduğundan, bu testin henüz geçilmediğini hala biliyoruz. Bu, sorunu çok düzgün bir şekilde çözdü.

Orijinal kusurun giderildiğini varsayalım. Bir yere kaydetmiş olsaydık, testi yeniden çalıştırmadan önce orijinal gerçek beklenen sonucu geri yükleyebilirdik. Bu, Pass durumuyla sonuçlanacaktır. Ancak, beklenen gerçek sonucu henüz geri yüklemezsek, ancak testi beklenen başarısızlık sonucuyla düzeltilmiş yazılım üzerinde çalıştırırsak ne olur?

Artık yazılımda herhangi bir kusur yok, dolayısıyla gerçek sonuç doğru. Ancak, gerçek sonucu beklenen başarısızlık sonucuyla karşılaştırıyoruz. Bu, aracın farklılıkları bulacağı ve bunların analiz edilmesi gerekeceği anlamına gelir.

Bu noktada tam olarak istediğimiz şey budur. Artık bir değişikliği araştırmamız gerektiğini biliyoruz, dolayısıyla bu bizi beklenen başarısızlık sonucunu gerçek beklenen sonuçla değiştirmeye sevk edecek, bu yüzden unutmadık. Bu test için durum ne olmalıdır?

Gerçek sonucun, beklenen başarısız sonuçtan ziyade gerçek beklenen sonuçla karşılaştırmasını gerçekleştirmeden testin geçtiğini söyleyemeyiz. Bunun beklenen bir başarısızlık olmadığını biliyoruz çünkü farklılıklar var ve beklenen bir başarısızlığın beklenen başarısızlık sonucunda hiçbir farkı yok.

Buna Başarısız diyebilirdik, ancak bu yanıltıcı olabilir çünkü yazılım artık doğru olabilir ve buna başarısızlık demek haksızlık gibi görünebilir! Bu nedenle dördüncü bir test durumu sunuyoruz: Bilinmiyor. Test durumu bilinmiyorsa, farklılıkları analiz etmemiz gerekir, ancak bu analizden sonra bir Geçti veya Kaldı durumu atayabiliriz.

Yazılım değişti ancak orijinal kusur henüz düzeltilmedi. Yazılım, orijinal kusurumuz henüz giderilmeden başka bir şekilde değiştirilmişse ne olur? Bunun, testte ek bir yeni hatalı sonuçla sonuçlandığını varsayalım. Bu, Çalıştırma 6’da yazılımdaki ikinci bir kusurla (*) gösterilir. Test sonucunu beklenen başarısız sonuçla karşılaştırırsak bir farkımız olur ama bu sadece ilgilendiğimiz bir sonuç olur.

Zamandan tasarruf etmek için sadece bir farkı analiz etmemiz gerekiyor. (Bu, kusurların birbiriyle etkileşime girmediğini varsayar; eğer etkileşime girerlerse, arızaları analiz etmek için zaman harcamanız gerekecektir.) Bu durum Başarılı veya Beklenen Başarısız değildir. Başarısız olabilir (bu örnekte olduğu gibi), ancak bunu henüz bilmiyoruz, dolayısıyla bu test durumu da bilinmiyor.

The post Otomatik Test Araçları 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).