Kalite Güvence Testi Mükemmelleştirildi - Bir Kullanıcı Akışı Eğitimi

Ürünler ve hizmetler daha hızlı ve daha hızlı dağıtılırken, kalite güvencesinin (QA) gelişen ortama uyum sağlaması, bazen daha kısa sürede aynı kapsama düzeyine ulaşması gerekir. Nitelik yerine Nicelik hatasından nasıl kaçınırız? Daha fazlasını nasıl kapsarız, verimliliği nasıl artırırız ve yine de işimizde etkili oluruz?

Test senaryolarının oluşturulmasının uzun zaman aldığını hepimiz biliyoruz. Farklı teknikler, test türleri uygulamalı ve ön koşulları, adımları ve beklenen sonuçları belgelemeliyiz. Ek olarak, bir test planı oluşturmamız gerekiyor.

Kalite güvence uzmanları, özellikle KG sürecindeki tüm aşamaları tamamlamaya çalıştıklarında genellikle kendilerini zamansız bulurlar. En büyük baş ağrısı, test senaryosu oluşturma ve test dokümantasyonu etrafında dönen test planlama ve tasarım aşamasıdır. Tüm işi bitirmek saatler, hatta bazen günler alabilir ve genellikle, belirli çıktıları atlamayı ve bunun yerine özetlemeyi seçerler ve bir testin unutulmasına neden olabilecek önemli bilgileri dışarıda bırakırlar. Bu aynı zamanda bilgi paylaşımının avantajını da kaybetmekle sonuçlanır.

Geleneksel KG Testi, Kullanıcı Akışıyla Buluşuyor

Geleneksel test senaryolarının ve test planlarının büyük bir hayranıyım. Sadece tonlarca test vakasının belirlenmesine yardımcı olmakla kalmaz, aynı zamanda ürünü gerçekten iyi bir şekilde belgelendirirler. Bunları eğitimde kullanabilirsiniz ve takımdaki herhangi bir kişi onları anlar. Birinin teste başlaması için deneyime aşırı derecede güvenmeniz gerekmez. Test planlarında kapsam, test öğeleri, test ettiğiniz ve test etmediğiniz özellikler gibi ayrıntılı bilgiler bulunur. Test planına giren bir risk analizi de vardır. Bunlar faydaların sadece birkaçıdır, ancak çoğu durumda toplam süre çok uzundur.

Bir test planının amacı, bir iletişim yolu ve proje paydaşları arasında bir anlaşmadır. Ürünü test etmek için hedefleri, gerekli kaynakları ve herhangi bir yaklaşımı veya stratejiyi detaylandırmaya yardımcı olur. Plan, her şeyin düşünüldüğünden emin olmaya yardımcı olur ve paydaşlara kalite güvence sürecine stratejik olarak yatırım yapıldığına dair güven verir. Bu planın 10 sayfa uzunluğunda olması gerektiğine dair somut bir kural yoktur. Hızlı tempolu bir takıma uyacak şekilde yeniden tanımlayabiliriz.

Alternatif, geleneksel test senaryolarını ve test planını, gereken zaman yatırımını azaltacak, ancak daha fazla olmasa da aynı kapsamı ve tüm paydaşlar için anlamlı olan belgeleri sunacak şekilde düzene koymaktır. Bu, tek bir gerçek kaynağı, bir bükülme ile bir kullanıcı akışı içerir. Bir kullanıcı akışını yapılandırarak ve sürdürerek, test senaryosu tasarımınızın büyük bir kısmını sizin için zaten yapmış olacaksınız. Bu, herhangi bir ürüne veya takıma uygulanabilir ve detay ve yapı bakımından çok yönlüdür.

Akış yöntemini kullanmak, test belgelerinizle daha hızlı bir geri dönüş süresi elde etmenize yardımcı olacaktır. Bu sadece manuel KG için değil, otomasyon için de geçerlidir. Akış, test planının bazı bölümlerine de katkıda bulunabilir.

Akışına bırakmak

Daha fazla gecikmeden, basit bir mesajlaşma web sitesi için bir kullanıcı akışı oluşturmaya başlayalım.

Önce ücretsiz bir zihin haritalama aracına ihtiyacımız olacak. Şahsen XMind kullanıyorum. Kendinizi rahat hissettiğiniz herhangi bir aracı indirmekten çekinmeyin; yalnızca bir akış şeması çizmek, bazı konulara “notlar” eklemek, farklı koşulları renklendirmek ve etiketleri kullanmak gibi temel özellikleri kullanacağız.

İlk adımımız ürünü anlamaktır. Genellikle, maket görüntülere veya tel çerçevelere atıfta bulunursunuz. Bunların hiçbiri mevcut değilse, bir geliştiriciyle yapılan hızlı bir arama, tam olarak hangi ekranların bekleneceğini verecektir. Devam ederken takip etmekten ve pratik yapmaktan çekinmeyin. Akış yalnızca bir kullanıcı arabirimiyle sınırlı değildir ve API'den API'ye çağrıları, veritabanı diyagramlarını, bağımlılık yapılarını ve daha fazlasını eşlemek için de kullanılabilir. Aynı ilkeler geçerlidir.

Koşullar, Durumlar, Eylemler

Sadece üç aktör kullanarak akışımızı kısıtlıyoruz. Belirli bir role sahip bir kullanıcı, temizlenmiş bir önbellek veya ilk kez oturum açan bir kullanıcı gibi bir Koşulunuz olacaktır. İkinci olarak, ana sayfa veya oturum açma penceresi gibi gerçek bir GUI bileşeni olan State/Page var. Ardından, durumun değişmesine neden olan fiziksel bir kullanıcı etkileşimi olan Eylem gelir. Bunu eylemde görelim.

Gereksinimleri Analiz Etme

Bu bizim ana sayfamız, yani Devlet. İki olası Eylemimiz var: Kayıt Ol ve Oturum Aç.

Ardından, Giriş Yap penceremiz var, başka bir Devlet. Buradaki işlemler Geri ve Giriş'tir. Giriş alanlarını eylemler olarak sınıflandırmadığımızı unutmayın. Bunu yapmaktan memnuniyet duyarız. Tecrübelerime göre, birkaç ondalık derinlikte çalışan karmaşık sistemler üzerinde çalışırken bakımının biraz zorlaştığını, ancak basit uygulamalar için çok uygun olabileceğini keşfettim.

Son olarak, başarılı bir şekilde oturum açtıklarında kullanıcının gideceği panoya geliyoruz. Burada üç eylemimiz var: Bir iletiyi Oluşturabilir, Düzenleyebilir veya Silebiliriz.

Artık kullanıcı akışını başlatmak için yeterli bilgiye sahibiz. Elimizdekileri özetleyelim. Ürünün durumlarını not ediyoruz. Gördüğümüz kadarıyla dört sayfa var:

1. Ana Sayfa
2. Giriş Penceresi
3. Kayıt Penceresi
4. Gösterge Paneli

Eylemlerimizi aşağıdakilerle “etkileşime girebilecek” her sayfaya/duruma yazıyoruz:

1. Ana Sayfa
   1. Giriş yapmak
   2. Kayıt ol
2. Giriş Penceresi
   1. Kayıt olmak
   2. İptal
3. Kayıt Penceresi
   1. TBD (ürüne göre değişir)
4. Gösterge Paneli
   1. Yaratmak
   2. Düzenlemek
   3. Silmek

Ortamınıza uyum sağlamak için değiştirilebilen Ürün Adı ile başlıyoruz, ancak bu çoğu takıma ve ürünlerine uyar ve aynı zamanda iyi bir başlangıç ​​noktası sağlar. Aşağıda, Register'ın yanında bir soru işareti göreceğiz.

Çoğu zaman, Agile'da henüz kapsam dahilinde olmayan veya gelecekteki bir sürüm için planlanmamış bir bileşenle karşılaşırsınız. Varlığını not edin, ancak daha fazla bilgi alana kadar onu bir bilinmeyen olarak bırakın.

Akış Şemasını Çizmek

Yukarıdakileri XMind'de şöyle görünecek şekilde çiziyoruz:

Neyin durum ve neyin eylem olduğunu basitçe renk kodlaması yaptığımı fark edeceksiniz. Ayrıca, bu akışı doğru bir şekilde temsil etmek için Eylemi İptal Et'ten ana sayfaya bir satır ekledim. Bir kullanıcı "Oturum Aç"ı seçtiğinde de iki koşul görüyoruz. Her ikisi de gösterge tablosuna gitse de, yine de her iki olası koşulu da test etmek istiyoruz.

XMind'in güzel yanı, eğer büyük, karmaşık bir uygulama üzerinde çalışıyorsak, diyagramın farklı seviyelerini oluşturabiliriz, bu nedenle akışı birden fazla akışa bölmek, ancak bunları bağlantılı tutmak istiyorsanız, bağlantı oluşturma ile yapmak çok kolaydır. Sayfaları ayırmak için konular. Bir köprü eklemeyi seçebilir ve sihirbaz açılır penceresinden eylemin yol açacağı bir “Durum” seçebilirsiniz. Bunun anlamı, XMind'de "Oturum Aç"ı seçerseniz ve "Dashboard" a köprü oluşturursa, fare imleciniz farklı bir sayfada olsa bile "Dashboard" a atlayacaktır. Oldukça havalı.

Akışımızda eksik olan şey etiketlerdir. Akışın kökü olduğu için ürüne 0 etiketi veriyoruz. Ardından, her Durum (mavi) için bir S# etiketi ekleriz, her Eylem (yeşil) için bir A# etiketi ekleriz ve son olarak her Koşul (camgöbeği) için bir C# etiketi ekleriz. Her etiket benzersiz olmalıdır. Aşağıdakilerle bitiriyoruz:

En son hangi numarayı kullandığınızı izlemek için (ürün büyüdükçe en yüksek sayıyı bulmaya çalışmak zor olabilir) bunu aşağıdaki gibi akışın Kök konusuna kaydediyorum:

Şimdi test senaryoları oluşturma kısmına geldik. Bir test senaryosundaki muhtemelen en önemli bilgi olan ve özelliğin kabul kriterlerinin bir parçası olan Beklenen Sonuçlara odaklanacağız. Her bölüm veya test için bir başlık ekleyeceğim ve ardından beklenen sonuçları onun altında listeleyeceğim. Bu makaleyi kısa tutmak için bunu yalnızca bir alt küme için yapacağım:

Ardından, Giriş Penceresi:

Ardından, Oturum Açma Eylemi:

Gerçekten şekilleniyor. Eklenen sınır ve güvenlik testlerine dikkat edin. Hangisini etiketlemek sizin için en kolaysa, bunu istediğiniz gibi adlandırabilirsiniz. Bazen başlığı Güvenlik – JS Inject – E-posta Alanı gibi bir test türüyle etiketliyorum ve ardından beklenen sonuçları aşağıda listeliyorum.

Çoğu ekipte, değişen gereksinimleri sürdürmeyi güç buluyoruz. Daha fazla yok. Diyelim ki, ilk kez kullanan tüm kullanıcılara Ts ve Cs penceresi sunulmalı ve kontrol panellerine geçmeden önce kabul etmeleri gerekiyor - sorun değil. Aşağıdaki gibi, durumu ve eylemleri nispeten kolay bir şekilde ekleyebiliriz:

Artık yeni bir durum eklemenin etkisini görüyoruz. Numaralandırmanın ilk başta garip olabileceğini unutmayın, ancak hatırladığımız sürece, sayılar yalnızca her bir aktörü benzersiz bir şekilde tanımlamak içindir - tıpkı bir veritabanındaki Birincil Anahtar gibi. Kullandığınız numaraların takibi için “Son Kullanılan” notlarınızı güncellemeyi unutmayınız.

Akıştan Test Senaryoları Oluşturma

Tüm bu ilerlemelerden sonra artık daha kolay kısma geçiyoruz: test senaryosu oluşturma. Bazı önemli noktaları vurgulayayım. Her aktör için etiketlerimiz var, her test için unvanlarımız var ve akışımızın bir parçası olarak gömülü koşullarla her test için sonuçlar bekledik. Bu kulağa bir test senaryosu tarifi gibi geliyor, aynı fikirde değil misiniz?

Şimdi tek yaptığımız, akışımızda olanı herhangi bir test senaryosu yönetim aracına, Confluence sitesine veya istediğiniz Excel belgesine kopyalayıp yapıştırmak. Hala eski ve güvenilir Excel'i kullanıyorum. Tüm test senaryolarımın kaydını "Temel" adlı tek bir dosyada tutuyorum - çok orijinal. Kopyala-yapıştır işlemini bitirdikten sonra, aşağıdakileri elde ederim:

Gerekirse test türleri, test durumu ve test yapılandırmaları için sütunlar eklemekten çekinmeyin. Koşullar "Oturum Aç" işleminden önce daha iyi olabilir, ancak bunu yapmanın doğru ya da yanlış yolu yoktur, bu kişisel tercihinize ve kendinizi nasıl organize ettiğinize bağlıdır.

Vurgulanacak birkaç şey var. Birincisi, aynı bilgiyi paylaşan hücreleri birleştirdim - tekrar tekrar kopyala-yapıştır yapmaya gerek yok, zaman kaybettiriyor ve bakımı daha zor. Başka bir öğe Adımlar. Testlerden ikisinin Durum ve Eylem numaralarını içeren adımlara sahip olduğunu fark edeceksiniz. Bu, ekibinizde SDLC'nin bir parçası olarak akışa sahip olduğunuzda kullanılabilir. Daha sonra tüm paydaşlar bilgi sağlayarak, maketler yaparak, riskleri artırarak vb. akışa katkıda bulunur. Bu, akış numaralarını belirterek, ekipteki herkesin ne yapacağını bileceği ve yeni bir ekip üyesi varsa, bu kadar kolay olduğu anlamına gelir. "izi takip edin, notlara bakın" gibi.

Bu da otomasyona yardımcı olur. Her adıma veya eyleme benzersiz bir referans verebilirsiniz. Akışınız gibi yapılandırılmış bir otomasyon paketi oluşturarak, oluşturabileceğiniz otomasyon çerçevesinin son derece sağlam, modüler ve uygulama genelinde uyumlu olma potansiyeline sahip olduğunu göreceksiniz. Bakım süresini azaltacak ve test fonksiyonlarını yenileriyle değiştirmenize izin verecek daha büyük bir ölçekte çağrı nesneleri kullanacak.

Akış, teknik özellikler, işlevsel özellikler, test senaryoları, durum geçişi, veri akışları vb. dahil olmak üzere tüm ürün belgeleri için tek doğru kaynak olabilir.

Kolaylaştırılmış Test Planı Yaklaşımı

Peki ya test planları?, düşünüyor olmalısın. Bu basit. Bir Test Planı aşağıdaki gibi bölümleri içerir:

1. Giriş ve kapsam
2. Test öğeleri
3. Test edilecek özellikler
4. Test edilmeyen özellikler
5. varsayımlar
6. Giriş kriterleri
7. Çıkış kriteri
8. İKY
9. Riskler
10. Çevre gereksinimleri

Giriş ve kapsam, JIRA hikayesi veya başka bir araçtaki herhangi bir görev veya hikaye olacaktır. Test öğeleri, JIRA biletine veya Confluence veya test yönetim aracındaki test çalıştırmanıza bağlayabileceğiniz, ortamınızda halihazırda dağıtılan yazılım sürümleri veya taahhüt numaralarıdır.

Test edilecek özellikler ve test edilmeyecek özellikler aslında sizin test senaryolarınızdır. Bu JIRA öyküsü için yürütülmek üzere seçilen test senaryoları "Test edilecek özellikler" ve listelenmeyen herhangi bir şey "Test Edilmeyecek Özellikler"dir. Oldukça basit bir şekilde, hikaye biletinde test edeceğiniz Durumları ve Eylemleri listeleyin.

Varsayımlar, Riskler ve hatta Çevre gereksinimleri bir belgede derlenebilir veya JIRA'daki yorumlara eklenebilir, hatta bazen Confluence'a yerleştirilebilir ve hikayeye bağlanabilir.

İKY, projenize bağlı olarak hikayeye hikaye puanları veya saatler olarak atadığınız bir tahmindir. Giriş ve Çıkış kriterleri zaten hikayenin bir parçası olacak.

"Geleneksel" test planlarına yakın olmak istiyorsanız, geliştiriciden veya diğer paydaşlardan KG planına katılıp katılmadıklarını görmek için hikaye hakkında Evet veya Hayır ile yorum yapmalarını isteyebilirsiniz. Bu teknik olarak dijital imzanız olarak hizmet eder. Tüm bunlar, QA sürecinize oldukça kolay bir şekilde dahil edilebilir ve QA belgelerinizi düzenlemenize yardımcı olabilir.

Ne Öğrendik?

Yukarıdaki yaklaşımla kullanıcı akışı ve bugün mevcut araçları kullanmak için düzenlenmiş test planları, tekrarlayan işleri azaltmamıza ve kaliteden ödün vermeden daha hızlı bir geri dönüş süresi elde etmek için KG'ye yardımcı olacaktır.

Bu yaklaşım, düzenli kalmamda, her temeli kapsamamda ve tüm ekibin anlayacağı belgeler oluşturmamda bana yol gösterdi. Agile'da bu gerçekten işe yarayacak ve bunun en iyi yanı, hala Çevik yaklaşımlardan birine uyuyor olmamız: “Dokümantasyonu Basitleştirin”.

Umarım bilgiler gerçekten yardımcı olmuştur. Her şey okuyucu olarak size kalmış. Bu, uyulması gereken somut bir kurallar dizisi değildir, bunlar yalnızca büyümeniz ve verimliliğinizi artırmanız için size fikir veren yönergelerdir. Hiçbir teknik her projeye, takıma veya ürüne uymaz, ancak başka bir yenilikçi fikrin önünü açabilir.