Menü

Üretim Sürümünden Önce Manuel Testin 7 Adımlı Pratik Uygulaması

7 step practical implementation manual testing before production release

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

Bu serinin Manuel Test ile ilgili önceki gönderisinde, Manuel Testin temellerine mümkün olduğunca fazla ışık tutmaya çalıştım.

Eğer kaçırdıysan, buradan okuyabilirsin .

Umarım aradığınız cevaplara sizi mümkün olduğunca yaklaştırmada başarılı olmuştur.

Bu durumda, Manuel Testin pratik uygulaması hakkında, nasıl daha fazla aşina olacağınız ve bunun içinde bir kariyere nasıl başlayacağınız hakkında daha fazla bilgi sahibi olmayı sevmez miydiniz?

Bu makale tüm bu yönlere ışık tutacaktır.

Manuel Testin Uygulanması

Hadi başlayalım.

Ne öğreneceksin:

Manuel Test Döngüsü

Anlamak Manuel Test Döngüsü veya Yazılım Testi Yaşam Döngüsü (STLC), her şeyden önce, zaten anladığınızdan emin olduğum Yazılım Geliştirme Yaşam Döngüsünü (SDLC) anlamamız gerekiyor.

İnsanlar onlara ayrı ayrı atıfta bulunur, ancak gerçekten bir arada var olup olamayacaklarından emin değildir. Birbirlerine o kadar sıkı entegre olmuşlardır. Eh, bu döngülerin internet alanında oluşturulmuş ve yüzen çok sayıda versiyonu olsa bile, büyük ölçüde hangi geliştirme modelinin seçildiğine göre değişir.

Çoğu gibi dünya Agile gidiyor bu günlerde, işlerimi Agile çevresinde basitleştireceğim.

Üretim Sürümünden Önce 7 Pratik Manuel Test Adımları

İşte gidiyorum.

Hem SDLC hem de STLC'den bahsettiğimi hatırlayın.

# 1) İhtiyaç Toplama

Gereksinim Toplama aşaması

İş Analisti (Gereksinim Toplamadan Sorumlu Kişi / Ekip) gereksinimleri belgeler. Gereksinimleri belgelerler, önemli olan budur, yalnızca buna odaklanabilirsiniz. Belgelendiği yer daha az önemli.

İnsanlar bunları belgelemek için MS word doc gibi geleneksel platformlarla, Jira / Rally gibi modern platformlarla ve Trello gibi yeni çağ araçlarıyla sınırlı olmayan her şeyi kullanırlar.

# 2) Gereksinim Tartışması / Paylaşımı

Gereksinim tartışma aşaması

İş Analistinin daha sonra, belgelenmiş gereksinimleri Geliştirme Ekibi, Test Ekibi ve (gerekirse) UX ekibi ile paylaşması beklenir. Bu genellikle üç işlevin tümünden SPOC'ların (Tek İrtibat Noktası veya tüm ekibin) tüm gereksinimi karşıladığı ve anladığı resmi bir toplantı aracılığıyla gerçekleşir.

Sağlıklı bir çalışma kültüründe gereksinimler her açıdan tartışılır ve toplantının her üyesi soru ve şüphe sorabilir. Tüm sorular cevaplandıktan ve ihtiyaçta gerekli değişiklikler yapıldıktan sonra bu aşama Tamamlandı olarak kabul edilebilir. Yine bu belirli toplantı / adım olarak adlandırılan şey ve dokümantasyonu şirketten şirkete farklılık gösterir.

daha fazla okuma=> SRS Belgesi Nasıl Gözden Geçirilir

Tüm sorular cevaplandıktan ve ihtiyaçta gerekli değişiklikler yapıldıktan sonra, bu aşama şu şekilde değerlendirilebilir: Bitti .

Yine bu belirli toplantı / adım olarak adlandırılan şey ve dokümantasyonu şirketten şirkete farklılık gösterir.

Örneğin, dokümantasyon SRS (Sistem Gereksinimi Belirtimi), Gereksinim Belgesi, Epic, Kullanıcı Hikayesi, Hikaye noktası (muhtemelen en küçük gereksinim birimi) vb. olarak adlandırılır veya bozulur. Gereksinim Tartışma toplantısı, Bakım, Delik delme toplantısı, vb., Umarım benim fikrimi anlarsınız?

Farklı isimlerden bağımsız olarak ana fikri her zaman hatırlayabilmeniz için bu terminolojilere basmak.

Bu toplantıyı yayınlayın, iki adım aynı anda tetiklenir, belirli bir sıra olmadan, sonraki iki adıma bakın.

# 3) Tasarım

Geliştirme ekibi, gereksinimler tartışılır tartışılmaz ve önemli bekleyen noktalar olmadığında teknik tasarımlarına başlar. Bu aşamada yapılanlar yine firmadan firmaya farklılık göstermektedir.

Bu aşama aşağıdaki görevleri içerebilir ancak bunlarla sınırlı değildir:

  • Geliştirme yaklaşımına karar vermek
  • Tasarım belgesinin hazırlanması
  • Akış şemalarının tasarlanması
  • Çabaları tahmin etmek
  • Bu yeni gereksinimin mevcut herhangi bir işlev üzerindeki etkisini anlamak
  • Mevcut verilere yama yapılması vb.

UX ekibi, bir UI değişikliği olduğunda veya yeni bir ekran geliştirilecek olduğunda da bu aşamaya dahil olabilir. UX ekibi, Tartışmadaki işlevsellik / özellik için UI prototipi konusunda Geliştirme ekibine ve Test ekibine yardımcı olur. Bu bir Photoshop belgesi, basit bir resim, PowerPoint sunumu veya geliştirme ekibinin ekranların nasıl geliştirilmesi gerektiğini anlamasını sağlayacak herhangi bir şey olabilir.

Not: İdeal olarak, bu ekranlar veya en azından taslak sürümleri, yalnızca ekibin daha iyi bir anlayış geliştirmesine yardımcı olmak için Gereksinim tartışma oturumunda gösterilir. Herhangi bir zamanda başvurulabilmesi için orijinal gereksinime göre etiketlenir.

# 4) Test Senaryosu / Test Senaryosu tasarımı

Test senaryosu Tasarım aşaması

Tasarım aşamasına paralel olarak, Test ekibi, tartışılan gereksinimlere göre Test senaryoları ve / veya Test senaryoları oluşturmaya başlar. Test senaryolarının her zaman önce yazılıp sonra Test senaryolarına girip girmediği yine sabit olmayan bir şeydir.

Bana göre, Test senaryolarını belgeleseniz de yazmasanız da, bunlar her zaman Test senaryolarından önce oradadır. Test Senaryosu, söyleyebileceğiniz mermi noktanızdır, işleri daha ayrıntılı incelemeniz için size rehberlik ederler. Test senaryosu yazımı bittikten sonra, Testin kapsamı hakkında bir fikir vermek için Geliştirme ekibiyle paylaşılabilir ve ayrıca gerçekleşen veya gerçekleşen geliştirmenin yazılı test olaylarını tatmin ettiğinden emin olabilirler.

Test senaryosu yazımı bittikten sonra, Testin kapsamı hakkında bir fikir vermek için Geliştirme ekibiyle paylaşılabilir ve ayrıca gerçekleşen veya gerçekleşen geliştirmenin yazılı test olaylarını tatmin ettiğinden emin olabilirler.

Bir kez yazılan test senaryoları ideal olarak bir Test Lideri veya aşağıdaki gibi birçok açıdan incelenir:

  • Gereksinim kapsamı
  • Yazım dilbilgisi
  • Test senaryosu yazma standartları (bir takımın / şirketin izlediği bir şablondan başka bir şey yok)
  • Geriye dönük uyumluluk
  • Platform uyumluluğu
  • Veri referanslarını test edin
  • Hedeflenen test türleri vb.

daha fazla okuma=> SRS belgesinden test senaryoları yazma

İdeal olarak, yalnızca gözden geçirme ve gerekli değişikliklerden sonra Geliştirme ekibine aktarılırlar.

'Bir kez test senaryosu yazımı bittiğinde' dediğimde, 'tüm test senaryoları, verilen gereksinim ve o zamana kadar ortaya çıkarılan olası test senaryolarının tam bilgisine dayalı olarak yazılır' demiştim. İlk seferde% 100 test senaryosu kapsamına sahip olmak neredeyse imkansızdır.

Rastgele (ancak kasıtlı) eylemlerde, tamamen rastgele eylemlerde (maymun testi) ve bazı nadir senaryolarda bulacağınız kusurlar olacaktır. Bunlardan birkaçını kaçırma ihtimaliniz var. Ve bazen çok basit olanları bile gözden kaçırabilirsin, sonuçta sen insansın. Ancak burada, en azından iyi bir test senaryosu incelemesi ve yapılandırılmış test senaryosu yazma yöntemi sizi kurtarabilir.

Çoğu zaman, bir test uzmanı veya test ekibi, gerçeği ortaya çıkarırken veya gereksinimler hakkında daha fazla düşünürken mevcut yığınlara daha fazla test senaryosu eklemeye devam eder.

Pekala, bazılarınız (Yazılım Testinde bir tür norm haline gelen) henüz benim tarafımdan kullanılmadığı için Yazılım Testi konusundaki bilgilerimden şüphe duyuyor olmalısınız. Test Planı doğru mu?

Bununla ilgili bir şey söyleyeyim. Test Planında bahsedilen bilgilerin çoğuna ihtiyaç duyulduğuna şiddetle inanıyorum, ancak hepsini aynı yerde belgelemek ve mutlak zorunlu hale getirmek tartışmalı bulduğum bir şey.

Her neyse, bu tamamen tartışılması gereken ayrı bir konu. Bu konuda 'her şeye uygun' bir bilgiyi paylaşmak zordur, ancak deneyeyim.

Ya siz, test liderinizle birlikte ya da test lideriniz Test Planı hazırlar ya da gerekli bilgileri farklı yerlerde belgelendirirsiniz.

Daha fazla okuma=> Test Planı Belgesi Nasıl Yazılır

Bu aşamada kesinlikle dondurulması gereken bilgiler:

  • Testin kapsamı: Gereksinim, Geriye Dönük Uyumluluk, Platformlar, Cihazlar vb.
  • Test yapacak kişi / ekip
  • Test eforu tahmini
  • Sınırlamalar: Önceden yapılan varsayımlar veya kabul edilen sınırlamalar.
  • İnsanlar ayrıca giriş kriterlerini, çıkış kriterlerini, riski vb. Belgeliyorlar ki, bence bu normal bir anlayış olması gerektiğinden ayrı olarak belirtilmeye gerek yok.
    • Giriş kriterleri (Test ne zaman başlatılmalı): Test için işlevselliğin test edilebilir bir parçası olduğunda çok az başlangıç. Tüm işlevselliğin test edilebilir olması için çok az kişi beklemektedir. Temel akışın çalıştığı tespit edildiğinde test başlar.
    • Çıkış kriteri (Ne zaman durmalı): Engelleyici olmadığında, açık aşama testindeki kritik ve büyük (darbeye maruz kalan) kusurlar durdurulabilir. Ya da ortada, çok fazla kusurla karşılaşıldığında, testler uygun paydaşlar tarafından durdurulabilir.
    • Risk : Belgelenen plana göre test yapılmazsa iş riski veya işlevsel risk.

# 5) Geliştirme aşaması

Yazılım Geliştirme aşaması

Geliştirme ekibi, tasarım aşamasından sonra, test edilebilir gereksinim parçalarının geliştirilmesiyle tamamlandığında gerçek geliştirme ve birim testi ile başlar. Parçalar halinde test etme işlevini, uygulandığında ve uygulandığında aktarabilirler veya tüm işlevselliği bir kerede geçirebilirler.

İdeal bir senaryoda, test için geliştirilen işlevsellik aktarılmadan önce resmi kod incelemesi ve beyaz kutu testi gerçekleşir. İdeal olarak Geliştirme ekibi, gereksinimlere ve tasarım belgelerine ek olarak test ekibi tarafından sağlanan Test senaryolarına da başvurmalıdır.

# 6) Test aşaması

Daha önce de belirtildiği gibi, bu aşamanın başlangıcı şirketten şirkete ve ekipten ekibe farklılık gösterir.

Test ekibi, tüm gereksinimin test edilebilir (bağımsız olarak test edilebilen bir şey) bir kısmı geliştirildiğinde veya tüm gereksinim geliştirildiğinde test etmeye başlar.

xml dosyası chrome'da nasıl açılır

Bu aşamada daha ayrıntılı inceleme yapmama ve önemli görevler hakkında konuşmama izin verin:

  • Test / Test Ekibi, test turu (keşif testi ve yazılı test senaryolarının yürütülmesi) ve hataların kaydedilmesi ile başlar
  • Geliştirme ekibi bunları öncelik sırasına göre çözer.
  • Testin yapıldığı ortamda yeni yapı (kod) alınır
  • Çözülen kusurlar daha sonra Test / Test Ekibi tarafından doğrulanır ve Düzeltildi olarak işaretlenir
  • Bu döngü, çıkış kriterine ulaşılana kadar devam eder.
  • Lütfen gerektiği gibi kusurların Geçersiz, Yinelenen olarak işaretlendiğini ve ayrıca Geliştirmeler olarak kategorize edilebileceğini unutmayın.

Şirketten şirkete farklılık gösteren bir diğer husus, kaç test turunun yapılacağıdır. Bazı durumlarda olduğu gibi, ilk test turu hazır olduklarında küçük özellikli parçalar üzerinde gerçekleşir, ardından tüm gereksinimler geliştirildikten sonra başka bir ortamda uçtan uca test turu yapılır. Ama yine, insanların üç tam test turu ve dördüncü olarak akıl sağlığı / duman turu yaptığını da duydum.

Birden fazla test turu yapmanın ardındaki ilk gündem, işlevselliği farklı ortamlarda test etmek ve ikincisi, tüm hikaye noktaları geliştirildikten sonra uçtan uca test yapmaktır. Akıl sağlığı turu genellikle bir sürümdeki tüm hikayeler bağımsız olarak geliştirilip test edildiğinde hızlı bir güven kazanır.

Ayrıntılı adımları okuyun=> Test Yürütme aşaması

# 7) İş Analisti (BA) İncelemesi

İş analisti, test sonucuna başvurarak veya test sonucuna atıfta bulunarak ve gerçek bir his elde etmek için uygulamayla oynayarak sorulan işlevselliği inceler. Bu adım yine şirketler arasında farklı eylemlere tabi tutulur.

Yönetim Kurulu tüm yayının kapsamını tek seferde veya toplu olarak gözden geçirebilir. Aynı şeye bağlı olarak, bu adım son akıl sağlığı testinden önce veya test ekibi tarafından yapılan son akıl sağlığı testi turundan sonra gelebilir.

Tüm kullanıcı öykülerinin / gereksinimlerinin, özellikle de Release (Gönderi) olmak üzere yerine getirilmesi için 7'den fazla adım gerçekleşir. Tüm gereksinimler için tüm bu adımlar tamamlandıktan sonra, sürümün sevkiyata hazır olduğu söyleniyor.

# 8) Gönderi / Bırakma

Sürüm, İş Analisti tarafından başarılı incelemeden sonra Gönderiye Hazır olarak etiketlenir.

Önerilen okuma=> Test sürüm süreci

Manuel Test Türleri (İnsan Okuma)

Sayılarla genel test türleri hakkında konuşmamız gerekirse, o zaman bulduğum bir yerde Farklı isimlerle 100 çeşit test . Dürüst olmak gerekirse, tüm bu türler arasındaki farkı anlayacak kadar zeki değilim (kelime oyunu).

Düz ve basit: Uygulamanın işlevselliğini verilen gereksinime göre insan çabası ve zekası ile test etmek. Ayrıca, testin kapsamı ve gündemine bağlı olarak birkaç türe ayrılır. Sonraki paragrafta listelenen türler.

Ayrıca, testin kapsamı ve gündemine bağlı olarak birkaç türe ayrılır. Sonraki paragrafta listelenen türler.

İzin verirseniz, birkaç satır İnsan Testinden bahsetmeme izin verin (ki bunu her test uzmanını sadece manuel fonksiyonel testler yerine yapmaya teşvik ediyorum). Şimdi kafanız karışmasın, bana göre manuel fonksiyonel test, İnsan Testinin bir alt kümesidir. Çünkü sadece İnsan zihninin yapabileceği çok şey var.

Aşağıda, İnsan Testi olarak kategorize edilebilecek bazı popüler ve önemli test türlerinin bulunduğu liste bulunmaktadır:

  • Manuel Fonksiyonel Test : Uygulamanın işlevselliğini verilen gereksinime göre insan çabası ve zekası ile test etmek. Ayrıca, sistem testi, birim testi, duman testi, akıl sağlığı testi, entegrasyon testi, regresyon testi, UI Testi vb. Gibi test kapsamına ve gündemine dayalı olarak epeyce türe ayrılır.
  • Performans testi : Bu, İşlevsel Olmayan Test olarak sınıflandırılır, değil mi? Ama yine de onu uygulayan insandır, ancak yürütme insan ya da araçla yapılır. Test uzmanı, yük testi için herhangi bir araç kullanmaması gerekiyorsa, en azından yanıt süresi açısından (kabul edilebilir olup olmadığını görmek için) bu testi yapmalıdır.
  • Tarayıcı / Platform Uyumluluk Testi: Test edilen uygulama, tarayıcılar ve platformlar (veya bir mobil uygulama ise cihazlar) arasında beklendiği gibi görünmeli ve çalışmalıdır (açıkçası tarayıcı motoruna bağlı olarak küçük bir fark olabilir).
  • Kullanılabilirlik testi : Öncelikle, bunun başlı başına büyük bir konu olduğu ve genellikle kullanılabilirlik testinde uzmanlara ait olduğu konusunda hemfikirim. Hala bir testçi olarak daha az kullanışlı bir şey bulursak en azından rapor etmemiz veya vurgulamamız gerektiğine veya görüşümüzü paylaşmamız gerektiğine inanıyorum.
  • Güvenlik Testi : Yine çok büyük bir test türü ve elbette çok fazla pratik bilgi gerektirir. Test uzmanı, mevcut bilgiye ve uygun olan her yere bağlı olarak URL kurcalama, Siteler arası komut dosyası oluşturma, SQL enjeksiyonu, Oturum ele geçirme vb. Gibi en azından temel testleri öğrenmeye ve yürütmeye çalışmalıdır.
  • Çok Kiracılı Test: Uygulamanız çok kiracılıysa, yani tek bir örnek birden fazla istemcinin verilerini tutuyorsa, bu test bir zorunluluktur. Gereksinimlerde açıkça belirtilmesine bakılmaksızın, bu yapılmalıdır. Bir müşterinin verilerinin diğerine gösterilmesi bir tür geliştirme ve test etme suçudur.

Not: Yukarıdaki görüşler benim kişisel görüşlerimdir. Ayrıca bilginiz için kapsamlı test türleri listesine bir göz atmanızı ve gerekli görürseniz takip etmenizi / kullanmanızı tavsiye ederim. Yıllar geçtikçe, bir şeyi kullansanız da kullanmasanız da, bir şeye inansanız da inanmasanız da, alanınızda yaygın olarak kullanılan kavramlar hakkında hala biraz bilgi sahibi olmanız gerektiğini anladım.

Hepsi bu kısım için. Okuduğunuz için teşekkürler. Görüşlerinizi / geri bildirimlerinizi yorumlarda paylaşın.

Bunun sonraki ve son kısmında manuel test eğitici dizisi Hepinize yardım etmeye çalışacağım test alanına girmek istiyorsanız hangi hazırlığı yapmanız gerekir ve oraya girmenin olası yolları nelerdir?

Önerilen Kaynaklar

^