Menü

Test Edici Olarak Kötü Gereksinimlerle Nasıl Başa Çıkılır?

how deal with bad requirements

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Sessiz konferans odası boğuluyordu ve içindeki herkesin kafası karışmıştı. Nasıl özleyebiliriz sorusu herkesin yüzüne yansıdı.

Sonuçta, kullanıcı mevcut kaydı kopyalamaya çalıştığında herhangi bir ilgili hatayla görünmemek ve bunu yapmasına izin vermek küçük bir hata değildi - Bu da bir sigorta şirketi için.

Sorunu çözmeye karar verdikten sonra herkes dağıldı. Ve araştırma yaparken, müşterinin gereksinimler belgesinde kayıtların çiftliğinden hiç bahsetmediği ve bu nedenle hiç kimsenin konuyla ilgili sorular sormadığı veya bunun hakkında düşünmediği gözlemlendi.

kötü gereksinimler

Bu sadece bir örnekti.

10 yıldan fazla bir kariyerde , Projelerin kötü veya yetersiz gereksinimler nedeniyle zarar gördüğü birçok vaka gözlemledim.

Ama dedikleri gibi, bu dünyada hiçbir şey mükemmel değildir ve bununla başa çıkmak zorunda kalacaksınız ve hiçbir gereksinimi olmayan veya yetersiz gereksinimleri olmayan projelerle uğraşmak bir tür kabustur.

Açıklamama izin ver -

Ne öğreneceksin:

Ne kadar kötü, zayıf ve çelişkili gereksinimler sorun yaratır:

# 1) Gereklilik yok - Hiçbir gereksinim varsayım ve tahmin anlamına gelmez ve bu nedenle güven yoktur. Herhangi bir dayanak olmadan bir ürünü / uygulamayı test etmek çok zordur. Ve bunlar daha fazla iş, müşteriden daha fazla hata ve proje için daha fazla acı ile sonuçlanır.

  • Nasıl yaparsın sorun bildir davranışın nasıl ele alınması gerektiğine dair bir tanım olmadığında sistem çökmesi hakkında?
  • Performans için ilgili bir gereklilik olmadığında, ana sayfa için 100 saniyelik yükleme süresinin kabul edilemez olduğunu nasıl ifade edersiniz?

Gereksinim yok ve test sırasında durumun nasıl ele alınacağı hakkında daha fazla bilgi daha önceki yayınlanmış makalede bulunabilir - Bir Uygulama Gereksinimler Olmadan Nasıl Test Edilir?

# 2) Yetersiz gereksinimler - Alıntı, Eksik bir şeyi bilmek, hiç bilmemekten daha tehlikelidir , kötü bir gereksinimle başa çıkmak söz konusu olduğunda çok doğrudur.

Zayıf bir gereksinimi yorumlamak ve aynısını uygulamak büyük bir risktir.

  • Arama sonuçlarını gösteren pop-up'ın geçerli olup olmadığını nasıl doğrularsınız, belirtilen tek gereksinim - arama sonuçları uygun olmalı ve arama sırasında hangi kriterlerin dikkate alınması gerektiğinden emin değilsiniz.
  • Bunu nasıl yorumlarsınız - Unutulan parola, kullanıcının unutulan parolayı yeniden oluşturmasını / sıfırlamasını kolaylaştırmak için uygulanmalıdır. Müşterinin şifresini unutmak için hangi iş akışını istediğini bilmeyen geliştirici, en iyi olduğunu düşündüğü şeyi uygular ve çatışmalar başlar.

# 3) Çakışan Gereksinimler - Birinden aynı anda iki farklı şey yapmasını istemek sadece kafasını karıştırır ve sistem de bir istisna değildir.

  • Aşağıda belirtilen gereksinimleri karşılayan bir uygulamayı nasıl test edersiniz:
    • Uygulama her zaman ana sayfada açılmalıdır.
    • Kullanıcıların uygulamaya erişmek için oturum açmaları beklenir.
  • İhtiyaç belgesi aşağıdaki gibi olduğunda önceliğe ne karar verirsiniz:
    • Oyun uygulaması, kullanıcı 1000 puan alırsa kullanıcıyı bir sonraki seviyeye yükseltmelidir.
    • Kullanıcı 1000 puan aldığında ücretsiz abonelik sayfasına yönlendirilmelidir.

Ve işte bu, kötü, zayıf ve çelişen gereksinimler sorun yaratır.

Yazılım sektöründe olmak, bazen müşteri bile tam olarak ne istediğinden ve onu nasıl ifade edeceğinden emin olmadığından projenin bir parçası olmalıdır.

Test açısından bakıldığında, bu belirsiz veya belirsiz gereksinimleri ele almak zor olsa da, tamamen imkansız değildir.

Olası çözümlere bakalım:

Kötü Gereksinimler ve bunları bir testçi olarak nasıl ele alınacağı:

Yöntem 1)Keşfedin ve Öğrenin:

Diğer uygulamaları keşfetmek, genel beklenen davranışları öğrenmek, iş akışını anlamak, kullanıcı rahatlığını düşünmek ve mantığı uygulamak durumla başa çıkmanın bir yoludur. Ayrıca, keşif testine güvenmek gereksinimlerin net olmadığı bu tür durumlarda yardımcı olacaktır.

Çoğu zaman, gereksinimler net olmadığında kullanıcı deneyimine ve rahatlığa öncelik vermek iyi bir seçimdir.

Yöntem 2)Deneyimden yararlanın:

Deneyimden yararlanın

Etki alanı deneyimi , genel test deneyimi, geçmişte karşılaşılan sorunlar ve kişisel bilgiler kafa karıştırıcı durumların ve gereksinimlerin ele alınmasına yardımcı olabilir.

Yöntem 3)Tel kafeslere bakın:

Tel çerçeveler, küçük ayrıntıları bulabileceğiniz bir tür görsel gereksinimdir ve bu ayrıntılar, ürün veya uygulamanın beklenen resmini oluşturmada çok yardımcı olabilir ve test yönlerini daha iyi bir şekilde ele almaya yardımcı olur.

Devamını oku => Tel Kafesler - Gerçekten Test Edilmeli mi? Ve eğer öyleyse, nasıl?

Yöntem 4)Akran tartışması:

.bin dosyası nedir?

Akran tartışması

Karışıklık ne olursa olsun, doğru bir grup insanla tartışılırsa, işler netleşir. Herkesin farklı deneyimleri, beklentileri, kullanıcı gözü ve analiz görüşü vardır ve bu zayıf gereksinimleri akranlarıyla tartışmak, anlayışı kristalize etme ve kendine güveni artırma faydası sağlayacaktır.

Yöntem 5)Müşteriden açıklama:

Müşteri, ürünün / uygulamanın sahibidir ve gereksinimlerin netliği söz konusu olduğunda ona yaklaşmak her zaman akıllıca olur. Ancak unutmayın, müşteriye yüzlerce soruyla saldırmanız tavsiye edilmez. Bunu yapmadan önce biraz ödev yapmak gerekiyor.

Mevcut en iyi uygulamaları bulmaya çalışın, uygulamanın faydalarını anlayın ve ardından soru ve olası çözümle müşteriyle iletişime geçin.

Sonuç

Son olarak, gevşek bir şekilde tanımlanmış veya tanımlanmamış gereksinimler, test uzmanının hayatının bir parçasıdır ve bunları kabul etmemiz gerekir, ancak iyimser olmaya ve buna yönelik çözümler belirlemeye çalışalım. Ne de olsa bizler test ediciyiz, uygulamaların yolunda gitmesine yardımcı oluyor ve düzleşmelerini önlüyoruz. YAY bize :)

Yazar hakkında: Bu ilham verici gönderi, STH ekip üyesi Bhumika M tarafından yazılmıştır. O, 10 yılı aşkın yazılım testi deneyimine sahip bir proje lideridir.

Mutlu testler, her zamanki gibi… .. görüşlerinizi, yorumlarınızı ve fikirlerinizi bekliyorum.

Önerilen Kaynaklar

^