how test an application without requirements
Teknik olarak gereksinimleri olmayan hiçbir uygulama yoktur. Spesifik hiçbir şey yapmayan, ancak sadece satır satır kod genişleyen bir yazılım düşünün. Hiçbir yere çıkmayan bir merdiven olacak.
Tüm yazılımların gereksinimleri vardır ve belirli bir göreve yöneliktir; özellikle, bir soruna bir çözümdür. Yani gereksinimsiz yazılım bir olasılık değildir.
Ancak, belgelenmiş gereksinimleri olmayan yazılım, ne yazık ki çoğumuzun severiz. Daha da kötüsü, belgelerin yetersiz, yanlış veya çok eski olması olabilir. Ne yazık ki bu da oluyor.
Dürüst olmak gerekirse, ayrıntılı kullanım durumları ve model ekranları olan iyi belgelenmiş bir işlevsel / sistem gereksinimi belgesinin yerini hiçbir şey tutamaz. Her ne kadar hızlı gelişme döngüleri ve dokümantasyonun minimuma veya hiç olmamasına doğru bir paradigma kayması nedeniyle bunun endüstride nadir hale geldiğini kabul etmemiz gerekiyor.
Bu nedenle, bu makale kendimizi bu durumlarda bulduğumuzda izlediğimiz bazı uygulamalara yönelik bir girişimdir.
Ayrıca Oku:
yazılım testi için örnek test planı
- Yazılım gereksinimleri spesifikasyonu (SRS) nasıl test edilir?
- Gereksinim İzlenebilirlik Matrisi Nasıl Oluşturulur
- SRS Belgesi Nasıl Gözden Geçirilir ve Test Senaryoları Oluşturulur
Önce birkaçına bakalım Başlamak için dokümantasyonun bulunmamasının nedenleri:
- Raflı proje yeniden açılıyor
- Belgeleme daha az çalışma biçimi
- Belgeler olabilir - ancak ayrıntılı veya tam olmayabilir
- Sürekli sürümler ve eski sürümle ilgili bilgiler arşivlenmedi, bu da mevcut işlevin yenisiyle nasıl tepki verdiğinin anlaşılmasında bir boşluk oluşmasına neden oldu
Tüm bunlar, biz testçilerin cesurca geçmesi ve başarılı bir şekilde ortaya çıkması gereken engeller. Tam olarak nasıl olsa, değil mi?
Bir uygulamayı gereksinim olmadan test etmek için en iyi 3 yöntem şunlardır:
Yöntem 1:
Elinize alabileceğiniz küçük belgelerle çalışın. Temel basit bir biriktirme listesi (çevik projelerde), bir yardım dosyası, bir e-posta, BRD / FRD'nin eski bir sürümü veya eski test senaryoları (bunları ALM araçlarınızda kontrol edin ve bunları bulabilirsiniz), vb.
Araştırın, etrafa sorun ve ince olsa bile her zaman bazı belgelenmiş yargılamalar vardır.
Bu işe yaramadığında, bir yazılım kullanıcısı olarak deneyiminizi azaltmayın.Örneğin, bir banka hesabı için bir transfer işlemini test etmeniz gerekiyorsa, bunu nasıl yapacağımızı kimsenin bize söylemesine gerek yok, değil mi? Çünkü çevrimiçi bankacılık müşterileri olarak hepimiz, transfer edilebilecek bir dizi paraya sahip hesaplara ihtiyacımız olduğunu biliyoruz.
Tüm durumların bu kadar basit olmayacağı konusunda hemfikir olduk, ancak yine de olabilirler.
Yöntem 2:
Bir yazılım ürününün gelecekteki sürümünü test etmek için uygulamanın eski / güncel sürümünü referans olarak kullanın. Şimdi, 'Uygulamayı referans olarak kullanarak asla test senaryoları yazmayın' kuralına ters düştüğünü kabul ediyorum. Bununla birlikte, mükemmel olmayan bir durumda çalışırken, ihtiyaçlarımızı karşılayacak şekilde kuralları şekillendirmemiz gerekir.
Bunu yaparken aşağıdaki yönleri perspektifte tutmaya yardımcı olur:
- Uygulama hatalar içerebilir - bu nedenle, kayıttan sonra sistem sizi doğrudan Ekran1'e götürürse (örneğimiz için belirli bir varsayımsal ekran) - Asla bunun doğru davranış olduğunu varsaymayın. Ayrıca, bir alan alfanümerik karakterler alıyor ve bir telefon numarasıysa, uygulamayı beklenen işlevsellik için verilen bir örnek olarak almadığınızdan emin olun.
- Yukarıdaki durumlarda kararınızı kullanın ve size hızlı bir başlangıç sağlamak için uygulamadan yardım alın, ancak işe yarayıp yaramadığını sorgulamak için eleştirel olun.
Yöntem 3:
Proje ekibi üyeleriyle konuşun:
- Toplantılarına katılmayı teklif edin.
- Ünite ve entegrasyon testi aşamalarına katılıp katılamayacağınızı sorun.
- Değilse, geliştirici ekibin kendi birimlerini ve entegrasyon testi sonuçlarını paylaşıp paylaşamayacağını sorun.
- Uygun bir zamanda bilgi aktarımı için bir zaman ayarlayın.
Şimdi, bir örnekteki yöntemleri uygulayalım:
Alışveriş sepetine ürün ekleyebileceğiniz bir alışveriş sitesi olduğunu varsayalım. İdeal olarak, dokümantasyon varsa, bize nasıl öğe ekleyeceğimizi, belirli bir zamanda kaç öğeye sahip olabileceğini, eklediğiniz öğe aniden stokta kalmadığında ne olacağını, maksimum sayı ne olduğunu söylemesi gerekir. Aynı öğeleri aynı anda satın alabilirsiniz vb. Durumumuz şu anda bunların HİÇBİRİ şu anda mevcut değil.
1. yöntemi uygulayın:
Bulabileceğiniz tüm belgeleri bulun. Geliştirme ekibinize model ekranları olup olmadığını / ALM aracına bakıp bakmadıklarını veya herhangi bir şeyi sorun. Bir şey bulursanız, bu iyi bir başlangıç noktası olur. Ancak bu yöntem hiçbir sonuç vermezse, o zaman test edenin yargısı / sezgisi.
Alışveriş sepetlerinin nasıl çalıştığını hepimiz biliyoruz, bu nedenle varsayımlarınızı yapın ve aşağıdaki gibi birkaç temel senaryoya ulaşın:
- Öğeler, göz atıldıktan veya arandıktan sonra alışveriş sepetine eklenebilir
- Alışveriş sepetine ürün ekledikten sonra, ürün listesi yenilenmeli
- Kullanıcı, sepete birkaç ürün ekledikten sonra bile alışverişe devam edebilmelidir
- Aynı öğeyi iki kez eklemek, eklenen öğelerin sayısının artmasına neden olur
- Öğeler güncellenebilir
- Öğeler kaldırılabilir
- Toplam, eklenen tüm fiyatların toplamına eşit olmalıdır
- Vergiler, girilen posta koduna göre hesaplanmalıdır
- Nakliye masrafları buna göre eklenmelidir
Devam edebiliriz ama resmi anladığına eminim.
Yöntem 2'yi uygulayın:
Uygulamanın daha eski bir sürümü mevcutsa, bu, test senaryolarınızı yazarken yardımcı olabilir, çünkü nereye tıklayacağınız, nereye giriş gireceğiniz, neyi kontrol edeceğiniz vb. Gibi adımları tam olarak yazmanız gerekecektir. Ekran görüntüleri / maketler / tel- çerçeveler - varsa, harika ikameler de olabilir.
Aşağıdaki ekrandan görebileceğiniz gibi, bunlar açıktır - alan adları, düğmeler veya mevcut diğer öğeler vb. (büyütülmüş görünüm için resme tıklayın)
Şimdi, bu noktada test uzmanlarının aşağıdaki gibi bazı soruları var:
- Miktar kutusuna bir karakter verdiğimde ne olur?
- Ne zaman çok fazla öğe eklerim?
- Maksimum hayır nedir. bunun alabileceği öğe sayısı? Vb.
Yöntem 3'ü uygula :
Soru listenizi BA'ya, Geliştiriciye veya hatta müşteriye götürün ve açıklama isteyin. Yöntem 3 uygulandığında, ayrıntılı test senaryoları yazmak ve testlerinizi ayrıntılı dokümantasyon mevcut olduğunda yapacağınız kadar güvenle gerçekleştirmek için ihtiyaç duyacağınız tüm bilgilere hemen hemen sahip olacaksınız.
Çok daha fazla adım ve çok daha fazla takip olduğu konusunda hemfikiriz, ancak Kalite testini sağlamak için bu adımlar kaçınılmazdır.
Sonuç olarak, dokümantasyon olmadığında veya yetersiz olduğunda tümü kaybolmaz. Hala umut var! Lütfen benzer durumlardaki deneyimlerinizi paylaşın.
Yazar hakkında: Bu faydalı gönderi, STH ekip üyemiz Swati S. tarafından yazılmıştır.
Her zaman olduğu gibi, yorumlarınız, sorularınız ve önerileriniz memnuniyetle karşılanmaktadır.
Önerilen Kaynaklar
- Yıkıcı Muayene ve Tahribatsız Muayene Eğitimi
- Yazılım Gereksinimleri Spesifikasyonu (SRS) Nasıl Test Edilir?
- Yazılım Testinde Maymun Testi Nedir?
- Uygulama Testi - Yazılım Testinin Temellerine Giriş!
- Yazılım Uyumluluk Testi nedir?
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- Yazılım Testinde Zihin Haritalama - Testi Daha Eğlenceli Hale Getirmenin Yolları!
- Herhangi Bir Uygulamayı Test Etmeden Önce Okumanız Gereken En İyi 20 Pratik Yazılım Test İpuçları