when opt automation testing
Bir proje için otomasyon testini düşünmeli miyiz? Otomasyon Testine ne zaman gitmeliyiz?
Son kullanıcıya kaliteli çıktılar sağlamak için test yapılır. Test Aşaması ana yönlerinden biridir STLC .
Herhangi bir şirket, kalitesi optimum müşteri memnuniyetini sağladığı için yazılım testine daha fazla odaklanır, ancak çoğu, otomatik test veya manuel test ile ne tür testlerin gerçekleştirileceğini seçmekte zorlanır.
Bu makale okuyucunun Otomasyon Testinin ne olduğunu, ne zaman başvurulacağını ve en önemlisi ne zaman yapmayacağını anlamasına yardımcı olur. Ayrıca, aşağıdakilerden en iyi şekilde yararlanmayı öğrenin Test için Otomasyon Araçları .
Ne iş yapılırsa yapılsın, etkin bir şekilde gerçekleştirilmeli ve aynı zamanda uygun maliyetli olmalıdır. Dahası, müşterinin teslimatlardan memnun olması için mantıklı olmalıdır.
Ne öğreneceksin:
- Yazılım Testi ve Maliyet Faydaları
- Yazılım Testinin Arkasındaki Zeka
- Otomasyon - Gerçekten Gerekli mi?
- Neden Otomasyon?
- Risk faktörü
- Otomasyon Ne Zaman Tercih Edilmemelidir?
- Otomasyon için Maliyet ve Yatırım Getirisi
- Otomasyon nerede maliyet AZALTIMIYLA minimuma indirebilir?
- Sonuç
- Önerilen Kaynaklar
Yazılım Testi ve Maliyet Faydaları
Yazılım Testi normalde bir Yazılım Test Cihazı tarafından gerçekleştirilir. Bir test uzmanı ile gerçek bir kullanıcı arasındaki fark, ikincisinin kendi işleri veya görevleri için kullanılan yazılımın yalnızca kısmi bir kullanımını bilecek ve yazılımı tamamen bilmeyecek olmasıdır. Öte yandan, bir test uzmanı yazılımın tüm teknik ve işlevsel gereksinimlerinin farkında olacaktır. Müşteri tarafından sağlanan gereksinimlere göre, test planları ve test senaryolarının hazırlanması gerekecektir.
Test planı, test sürecinin gerçekleştirileceği yöntemin ayrıntılı bir planından başka bir şey değildir. Bu, teste dahil olan kaynakların ve kaynakların sayısı, ne yapılacağı ve ne zaman yapılacağı, nelerin yapılmayacağı ve uygulanacağı ortam vb. Hakkında eksiksiz ayrıntılara sahip olacaktır.
Yazılımın işlevsel ve teknik yönü net bir şekilde anlaşıldıktan sonra test senaryoları hazırlanmalıdır. Test uzmanı, keskin bir gözlem kapasitesine ve yazılım hakkında eksiksiz bilgiye sahip olmalıdır.
Dahası, maliyet burada etkili bir rol oynar. Müşteriler, minimum maliyetle maksimum kalitede yazılımı kabul etmeyi tercih ediyor. Manuel teste gittiğimizde, işlemin tamamı bir test uzmanı tarafından manuel olarak yapıldığından daha zahmetli ve zaman alıcıdır.
Örneğin , 'n' sayıda test kullanıcısına ihtiyacımız olduğunda Regresyon Testi yürütmek , tüm test senaryolarının yürütülmesi yaklaşık 50 saat sürebilir. Ve kaynak kullanılabilirliğine bağlı olarak test senaryoları yürütülecektir. Ancak, otomatik test için daha az zamanla, manuel testlere kıyasla test senaryolarının maksimum kapsamı ile birlikte kaynakların optimum kullanımı gerçekleştirilir.
Yazılım Testinin Arkasındaki Zeka
Herhangi bir kuruluşun test sürecine ne zaman başlayacağını ve ne zaman çıkacağını bilmesi çok önemlidir. Teste ne zaman başlayacağımızı bilmemiz gerekiyor çünkü geliştirme aşaması tamamlandığında ve gerekli kriterler karşılanmadığında teste başlamak gereksizdir. Geliştirme devam ederken test tasarım aşamasından başlamak her zaman en iyi uygulamadır.
Aşağıda, yazılım testi giriş ve çıkış kriterleri verilmiştir:
Giriş kriterleri
Tasarım belgesi imzalandıktan sonra, test planları planlama aşamasında hazırlanmalıdır. Bir test planı hayati bir rol oynar. Gerekli donanım düzgün şekilde kurulmalı ve yapılandırılmalı ve donanımın işlevselliği kontrol edilmelidir. İşlevsel gereksinimler açık ve onaylanmış olmalıdır. Geliştirilen kod, geliştiriciler tarafından birim testinden geçirilmeli ve imzalanmalıdır.
Test senaryoları ve test verileri hazırlanmalı ve onaylanmalıdır. Test verileri ve uygulama mevcut olmalıdır. Test uzmanı, uygulama hakkında önemli ve yeterli bilgiye sahip olmalıdır. Kaynaklar, araçlar hakkında iyi eğitilmeli ve gerekli tüm işlevler ile açıklığa kavuşturulmalıdır.
Test cihazı mevcut olmalıdır. Kriterlerden herhangi birine ulaşılamadığında, teste giriş kriterleri engellenir.
(Not: Büyütülmüş bir görünüm için herhangi bir resme tıklayın)
Çıkış kriteri
Yalnızca zorunlu test durumlarının en az% 95'i bir 'başarılı' sonucu ile kilitlendiğinde, ürün için test aşamasından çıkabiliriz. Bununla birlikte, yazılım testinin ne zaman durdurulabileceğini veya hala yürütülmesi gerekip gerekmediğini belirlemek o kadar kolay değildir. Ve bu tür durumlar da sıklıkla ortaya çıkar.
Ana kriterler aşağıda verilmiştir:
- Tüm hatalar giderildiğinde.
- Son teslim tarihine ulaşıldığında.
- Bütçe tükendiğinde veya tükendiğinde.
- Tüm test durumları geçtiğinde.
- Anlaşma imzalandığında.
- Belirli bir test yüzdesi yapıldığında.
- Ne zaman Alfa ve Beta testi sona erer.
Çıkış kriterleri tamamen risk, maliyet, vb. Gibi faktörlere dayalı olarak türetilebilir. Ana işlevsel gereksinimin test edilmesi sağlandığında, test genellikle durdurulur ve hiçbir zaman küçük hatalar aramazlar ve sonraki dönemler.
Misal: ABC yazılımı bir tasarım aşamasındadır. Geliştirme ve test yapımı genellikle aynı anda gerçekleşir. Tasarım dondurulduktan sonra yazılımın geliştirilmesine başlanır. Yazılımın geliştirilmesinin, üzerinde anlaşmaya varıldığı şekilde tamamlanması, giriş kriterlerini belirtir. Buradaki teslimatlar geliştirme ekibindendir. Sürüm notlarını ve bilinen sorunları içerir.
Birkaç test yinelemesinden sonra, hiçbir ana / engelleyici / gösteri durdurucu çözüm beklemediğinde ve testin% 95'i bir geçişle sonuçlandığında, bu çıkış kriteri olarak adlandırılır.
Otomasyon - Gerçekten Gerekli mi?
Gerekip gerekmediğine karar vermemiz gerektiğinde Otomatik Test Tekniği ya da değil, mevcut kaynaklar sorusu burada ortaya çıkar. Otomatikleştirmemiz gereken nedenler, veri akışının ve geliştirilen işlevselliğin manuel müdahale olmadan beklentiye göre çalışıp çalışmadığını kontrol etmektir. Esas olarak, yazılımın birden çok sürüm / döngü vb.Şeklinde değişikliklere sahip olacağı yerlerde kullanılır.
osi modelinin her katmanında kullanılan protokoller
Her döngünün geliştirilmesinin sonunda, o anda eklenen işlevselliğin testi yapılacaktır. Ek olarak, eski işlevselliklerin bozulmadığından emin olmak için eski işlevsellik testi yapılacaktır. Bu, otomasyon kapsamına sahip ana kısımdır.
Kod güdümlü mantık ve GUI gereksinimlerini doğrularken, risk faktörünün yüksek olması koşuluyla Otomatikleştirilmiş test seçilebilir.
Misal: ABC Yazılımı için, istemci tarafından aranan ve geliştiriciler tarafından sağlanan güncellemeler, sık sık yükseltmeler vardır. Bu nedenle, testin bir parçası olarak, halihazırda canlı olan ve üretimde çalışan yazılım için regresyon yapılır. Herhangi bir sayıda sürüm, yükseltme ve güncellemeden bağımsız olarak, mevcut sürüm geçerli olacaktır.
Diyelim ki regresyon testi kapsamı için 10 günlük manuel çaba gerekiyor ve ardından bunları otomatikleştirmek için azami özen gösterilmelidir. En az% 60 çaba ve 10 * 8 = 80 saat manuel işten tasarruf sağlayabilir.
Otomasyon yalnızca 80/24 = 3,33 gün tamamlayabilir. Bu yaklaşık 6,67 tasarruf sağlar.
Neden Otomasyon?
Otomasyon yalnızca şu durumlarda seçilebilir:
- Uygulama, regresyona yüksek derecede yatırım yapma çabası ile çok geniş bir alana sahiptir.
- Manuel hatalar nedeniyle oluşan maliyetlerde optimizasyon.
- Yazılımın birden çok sürümü ve sürümü vardır.
- Uzun vadede uygun maliyetlidir.
- Risk faktörü, daha geniş bir test yürütme kapsamı için daha yüksektir.
- Maliyet rakamları ve matematiksel hesaplamalar yazılım işlevselliğine dahildir.
- Yazılım kalitesi ile birlikte yürütme temposunda, verimlilikte daha büyük bir artış var.
- Yüksek riskli yazılım testleri için bile daha kısa bir dönüş süresi vardır.
Risk faktörü
Risk faktörü, zaman faktörüne birçok bağımlılığın olduğu iş dünyasında baskın olarak yaygın hale gelir. İşlem sistemlerine dayalı olarak çalışan ve birden çok uygulamada çalışan yazılım, yazılım tasarımına göre yazılımın ideal şekilde hareket etmesini gerektirecektir. Bu durumda, doğru işlevsel davranışın kaydedilmesiyle ilgili birçok risk vardır.
Burada Otomasyon, fonksiyonel işlemlerin yazılım mekanizmasına göre daha iyi bir hızda gerçekleştirilmesinde çok yardımcı olacaktır.
Örneğin Forex piyasası göstergesi durumunda, zaman faktörü çok önemli ve kritiktir. Hisse senetleri ve emtialardaki değişiklikler zamana bağlı olarak, bazen saniyeden daha kısa sürede gerçekleşir. Burada Otomasyon, bu tür yazılımların yüksek riskli test edilmesine yardımcı olabilir.
Misal: ABC Yazılımının birden çok güncellemesi ve yükseltmesi vardır. Manuel çabadan tasarruf etmek ve test aşaması için geri dönüş süresini azaltmak için temel sürüm veya eski işlevler otomatikleştirilebilir. Bu, yalnızca temel işlevler değişmeden kaldığında geçerli olabilir.
Otomasyondaki fayda, herhangi bir manuel müdahale olmadan çalıştırılabilmeleridir. Bu bile, yeni işlevselliğin test edilmesiyle paralel olarak gerçekleştirilebilir. Bu nedenle otomasyon, çok fazla çaba ve zaman tasarrufu sağlar.
Otomasyon Ne Zaman Tercih Edilmemelidir?
Birkaç kuruluş arasında bir soru var - Neden% 100 Otomasyon mümkün değil?
Uzmanların cevabı YAPMA çünkü yetenekli kullanıcıların Otomatikleştirilmiş testi gerçekleştirmesi ve aynı zamanda iyi eğitilmiş olmaları gerekir. Kriterlerin ilk aşamasında otomasyon gerçekleştirilemeyecek ve uygulamaların gereksinimleri net olmayacaktır.
Genellikle, Otomasyon, herhangi bir yazılım sürümünün ikinci yinelemesinden tercih edilir. Daha maliyetli olan kullanıcı arayüzü değiştirilebilir ve script bakımı da daha maliyetlidir.Otomasyon aracı için gerekli olan maliyet proje bütçesini aştığında hayır diyebiliriz.
Misal: Yazılım XYZ, müşteri gereksinimlerinin dondurulmadığı ve müşteriler tarafından talep edildiğinde değişmeye devam ettiği bir tür e-ticaret sitesidir.
Burada, bu durumda, otomasyon gerilemeye yardımcı olamaz. Bunun nedeni, geçerli olmayan eski işlevlerin test edilmemesi ve bu nedenle manuel olarak yapılması gerektiğidir. Örneğin, bir müşterinin temel yazılımdaki tüm liste kutularının açılır kutular olarak değiştirilmesi gerekir.
Otomasyon için Maliyet ve Yatırım Getirisi
Başlangıçta otomasyona gittiğimizde ROI çok düşük çünkü otomasyon ilk kez pahalı. Yazılımın test edilmesindeki manuel çaba, ikinci sürümün yinelemelerinden düştükçe yatırım getirisi artmaya devam ediyor. Otomasyondan önce herhangi bir test senaryosunun beklenen sonucunun farkında olmalıyız.
Otomasyonu ve maliyeti artırmayacağından emin olmak için herhangi bir aracı seçerken test senaryolarının tasarımını daha önemli düşünün.
Otomasyon nerede maliyet AZALTIMIYLA minimuma indirebilir?
Otomasyon maliyetleri bile, çünkü test için gerekli aracın satın alınması gerekir. Kaynaklar belirli bir araçla eğitilmelidir. Seçilen araç, yazılımın tüm alanlarını test etmek için uygun olmalıdır.
Bu nedenle araç seçimi, Otomasyon test uzmanları tarafından dikkatlice yapılmalıdır.
Misal: Sigorta ile ilgilenen XYZ ürününü düşünün. Maliyet faktörünü azaltmak için, şirket yalnızca manuel test kullandı, ancak sigorta söz konusu olduğunda, risk faktörü yüksektir ve prim hesaplamalarının herhangi biri yanlış gittiğinde firmaya maliyet olabilir. veya son kullanıcıya. Son kullanıcı, şirket yapmak zorunda olduğu halde zarara uğramayacaktır.
Hesaplanan prim tutarı, ön uç ve arka uç prim hesaplamasında farklılık olduğunda orijinal prim (yani) ile uyuşmadığında, müşteri ile ürün satıcısı arasında büyük bir sorun ortaya çıkar. Otomobiller, ev ve diğerleri gibi birçok modül içerebilir.
Bir şey ters gittiğinde, bu tam bir kayıptır. Hesaplamadaki fark, test uzmanı için anlamlı olabilir ve hatalara neden olabilir. Bu projede, manuel test TIN numarası, sosyal kimlik ve kullanıcı portföyüyle ilgili diğer bilgilerin doğrulanması gibi temel kullanıcı arayüzü için yapılabilir ve dolayısıyla risk faktörünün düşük olduğu yerlerde manuel olarak test edilebilir. M şirket kâr edecekse, yazılımlarını test etmek için otomasyonu o kadar çok tercih ederler.
Sonuç
Hem Otomasyon hem de manuel testin avantajları ve dezavantajları vardır. Ancak kavramlar ve gereksinimler konusunda net olduğumuzda ne tür testler yapacağımızı seçebiliriz.
Hiçbir proje tek başına manuel test veya otomatik test ile test edilemez. Tasarım, platform ve yazılımın birlikte geliştirildiği teknolojiye bağlıdır. Bu nedenle, bir karar verirken, test yöntemini seçerken dikkatli olmak ve uzmanların tavsiyelerini kullanmak gerekir.
Yukarıdaki yazıda, birkaç faktörü gözden kaçırmış olabiliriz, otomasyonu ve hatta otomasyon için araçları seçerken önemli olduğunu düşündüğünüz faktörleri lütfen paylaşın.
Bu arada, bu makale ile ilgili yorumlarınızı / önerilerinizi paylaşmaktan çekinmeyin.
Önerilen Kaynaklar
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- Manuel ve Otomasyon Testi Zorlukları
- En İyi 10'dan Fazla En İyi Yazılım Test Kitabı (Manuel ve Otomasyon Test Kitapları)
- Yazılım Testi QA Yardımcısı İşi
- Android Uygulamalarını Test Etmek İçin En İyi 11 Otomasyon Aracı (Android Uygulama Test Araçları)
- Manuel veya Otomasyon Test Uzmanı mısınız? Bizim İçin Yarı Zamanlı Çalışın!
- Yazılım Test Kursu: Hangi Yazılım Test Enstitüsüne katılmalıyım?
- Kariyeriniz olarak Yazılım Testini Seçme