Bir Scrum Takımı İçin Test Stratejisine İlişkin En İyi Uygulamalar

Scrum eksi test planı, steroidler üzerinde POC'ye eşittir.

Günümüzde en başarılı projeler, bir fikrin nispeten küçük boyutlu bir değerlendirmesi olan Kavram Kanıtı (POC) ile başlıyor; burada seçilen teknoloji ve özellik paketi önce doğrulanacak, iş kullanıcıları üzerindeki potansiyel etkisi değerlendirilecek ve ardından kanıtlandıktan sonra. yatırıma değer, tam özellikli ürünü tasarlamak, teslim etmek ve üretime yerleştirmek için tam boyutlu bir proje ekibi görevlendirilir.

Bu, bir Scrum takımı için mükemmel bir durumdur. Ekip, her sprint'te önemli yeni özellikler ekleyerek prototipi hızlı bir şekilde geliştirebilirken, işletme kullanıcıları gerçek zamanlı hızlı ilerlemeyi ve yaklaşık 10 sprint'te fikrin sıfırdan nasıl oluşturulduğunu izleyebilir. Güçlü bir izlenim bırakıyor (zaten POC'nin ana hedefi budur), ancak aynı zamanda önemli bir özelliği de var - çok az veya hiç test etkinliği yok ve test sürecini düşünmek bile düz bir şaka olurdu.

Scrum takımı içinde eğlenceli bir aktivite değildir ve insanlar çoğunlukla kendilerini yavaşlatacak süreçler olmadan geliştirme fikrinden hoşlanırlar. Temel olarak, herhangi bir test faaliyetinin dolaylı olarak yapacağı şey budur. Ve son kullanıcıyı en çok etkilememiz gereken zamanda gereksiz yavaşlamayı kim ister?

POC dönemi bittikten sonra proje ekibinin aynı şekilde devam etmesi durumunda ortaya çıkan durum , steroidler üzerinde POC olarak adlandırmak için kullandığım bir şeydir - boyutu ve özellikleri büyüyen, ancak yine de bir POC gibi davranan bir üretim sistemi - tam bir özenti ile tam bir ürün gizli kusurlar ve keşfedilmemiş köşe kasaları, yalnızca ciddi bir çarpışmayı bekliyor.

Ancak oraya dönüşmeden önce, yuvarlanan sorunları düzeltmek yalnızca daha karmaşık hale geleceğinden, ekip bir koşudan diğerine kararlı sürümlere ayak uydurmak için daha zor anlar yaşayacaktır.

İşte ben benzer problemlerle uğraşırken işe yaradığını kanıtlayan ve sağlam test süreçlerini uygulamak için en iyi uygulamalar olarak adlandırılabileceğine inandığım bazı teknikler, yine de geliştirme sürecini çok fazla karıştırmadan - çünkü hepimiz bunun için olmak istiyoruz. bir Scrum takımı.

acıyı dağıt

Gereksiz rahatsız etmeyle uğraşırken acıyı bölmekten başka nereden başlayalım :).

Bununla kastettiğim, burada ve oradaki geliştiricilerden küçük ek faaliyetler gerektirecek, ancak ortak hedefe zaman içinde, artımlı ama tutarlı bir şekilde büyük ölçüde katkıda bulunacak bir plan oluşturmak.

1 numara. Oluşturulan her yeni kod parçası için Birim test kodu geliştirin

Scrum takımlarınızı, sprint içinde oluşturulan her yeni kod için Definition Of Done maddesine birim testleri geliştirmeyi eklemeye ikna etmeyi başarırsanız, o zaman uzun vadeli bir perspektiften bakıldığında, bu büyük bir başarı olacaktır.

Nedenleri oldukça açık:

Geliştiricileri, kodun standart olmayan çeşitli yolları hakkında düşünmeye zorlayacaktır. –

• Bu tür birim testleri, otomatikleştirilmiş DevOps ardışık düzenlerine takılabilir ve geliştirme veya test ortamına yapılan her dağıtımda yürütülebilir. Ayrıca, ardışık düzendeki ölçümler kolayca dışa aktarılabilir ve daha sonra iş kullanıcılarına doğrudan kaynak koduna bağlı test senaryolarının yüzdesel kapsamını göstermek için kullanılabilir.

En önemlisi çok yakında başlamak. Birim testleri ne kadar geç geliştirilmeye başlarsa, geliştiricilerin bunları bir sprint içinde eklemeleri o kadar dikkat dağıtıcı olacaktır.

• Halihazırda var olan kod için birim testlerini geriye doğru geliştirmek büyük çaba gerektirecektir. Kodun bazı bölümleri başka bir geliştirici tarafından oluşturulmuş olabilir ve her bir kod bölümünde nasıl çalışması gerektiğine dair kesin bilgi mevcut geliştirici için tam olarak net değildir. Bazı durumlarda, değiştirilen koda bir birim testi eklemek, sprint için özellik değişikliğini geliştirmekten daha fazla zaman alacaktır (bu, sprint planlama sırasında kimsenin hesaplamadığı bir durumdur).

2 numara. Geliştirme ortamında Birim Testlerinin tüm bölümlerini yürütme rutini oluşturun

Yeni kodun Ana dalda birleştirilmesi için bir çekme isteği oluşturmadan önce bile, geliştirme ortamında hem özellik kodunu hem de birim test kodunu test etmek standart bir etkinlik olacaktır. Bunu yaparak aşağıdakiler sağlanacaktır:

• Birim test kodu aslında her parça için çalışıyor (sonuçta, doğrulanması gereken başka bir koddur). Bu adım genellikle tamamen atlanır. Bir şekilde, eğer birim testi yine de DevOps boru hattına takılırsa, sonunda varsayılan olarak bir yerde çalıştırılacağı ve test edileceği varsayılır. Bununla birlikte, bu, sorunları, ekibin taahhüt edilen her hikayeyi bitirmek için genellikle daha az zamana ve daha fazla strese sahip olduğu sprint aktivitelerinin üst seviyelerine itmekten başka bir şey değildir.
• Yeni özellik kodu, geliştirici tarafından temel işlevsellik açısından test edilir. Açıkçası, bu testten iş işlevselliğinin tam olarak doğrulanması beklenemez, ancak en azından bu test, kodun geliştiricinin amaçladığı şekilde davrandığını onaylayacaktır (şimdilik, iş mantığının olabileceği gerçeğini göz ardı ederek). geliştirilirken yanlış anlaşılmalıdır).

#3. Ana dalda kod birleştirme işleminden sonra birim testi yürütmesini bekleyin

Yerel şubede (şube sahibinden başka kimsenin yeni bir özellik geliştirmediği) işlevsel koda sahip olmak bir şeydir, ancak çekme isteğinden sonra aynı kodun çalışması ve ana dalda birleştirilmesi tamamen farklı bir şeydir.

Ana dal, diğer Scrum ekibi üyelerinden gelen değişiklikleri içerir ve çakışmalar çözülse ve her şey yolunda görünse bile, birleştirme ve çakışmaların çözülmesinden sonraki kod, temel olarak hala test edilmemiş bir kod parçasıdır ve önce doğrulamadan daha fazla göndermek risklidir. hala iyi çalışıyor.

Dolayısıyla, burada etkili olduğu kanıtlanmış olan şey, daha önce geliştirme ortamında zaten yapılmış olan aynı birim testinin, ana dal kodu sürümünden oluşturulan ortamda da yürütülmesini istemektir.

Geliştiriciler için, hayatlarına dahil etmeleri gereken ek bir adım olabilir, ancak bu o kadar da çaba gerektirmez çünkü bu durumda yeni bir şey icat edilmemelidir - sadece bir kez yapılmış olanı yeniden uygulayın.

Şimdi, bu adım belirli bir durumda atlanabilir:

• DevOps ardışık düzenlerindeki otomatikleştirilmiş birim testleri o kadar kapsamlıdır ki, buna ek olarak yürütülen tüm manuel testi zaten kapsarlar.

Bu duruma ulaşmak kesinlikle mümkün olsa da, gerçek hayatta böyle bir durumu hiç yaşamadım. Geliştiricilerin bu kadar ayrıntılı otomatikleştirilmiş Birim testleri oluşturması muhtemelen çok fazla zaman alacaktır. Bir sprint içinde teslim edilen hikayelerin sayısı üzerinde açık bir etkisi olacağından, ürün sahibinin ekibin bu aktiviteye çok fazla zaman ayırmasına izin vermesi kolayca kabul edilemez hale gelebilir.

Ancak sprint içeriğinin tercih edilmesi asla birim testlerini yapmamak hatta minimuma indirmek için bir bahane olamaz. Bunu yaparak ekip, kodun çok fazla birim testi kapsamından yoksun olduğu bir duruma yeniden dönüşecek ve ardından bir telafi için çok geç kalmış olabilir (yine, birim testini tamamlamak için gerçek çabadan daha yüksek çaba). bir sprint için kod değişikliği).

Tüm bu nedenlerden dolayı birim testlerinin ana kod versiyonunda tereddüt etmeden tekrar yapılmasını tavsiye ederim. Getireceği değere kıyasla çok düşük bir çaba.

Sürüm testi aşaması için ana dalın hazır olup olmadığına dair son kontrolü yapacaktır. Ayrıca, teknik hataların çoğunun (örneğin, kaynak kodun başarılı bir şekilde yürütülmesini engelleyen hatalar) bulunmasına yardımcı olacak ve yalnızca iş işlevselliğinin doğrulanmasına odaklanacak bir sonraki aşamaya bırakılacaktır.

İşlevsel Teste Hazırlanın

Önceki tüm test faaliyetleri, belirli bir sonuca götürecektir - ana dal kodu, teknik hatalar içermez ve uçtan uca işlevsel akışlar için sorunsuz bir şekilde yürütülebilir.

Bu, tek bir kişinin kolaylıkla üstesinden gelebileceği bir aşamadır ve bu kişinin teknik altyapıya sahip olmasına bile gerek yoktur.

Aslında, bunun geliştiricilerle bağlantısı olmayan ancak iş kullanıcılarının kodun nasıl davranmasını beklediğine dair işlevsel farkındalığa sahip biri tarafından yürütülmesi çok daha iyidir. Tamamlanması gereken iki ana faaliyet vardır:

1 numara. Yeni sprint hikayeleri fonksiyonel testi hedefledi

Her sprint ideal olarak daha önce olmayan bazı yeni işlevler (sprint hedefi artışı) getirecektir ve bu nedenle doğrulanacaktır. Yeni yazılımın, iş kullanıcılarının şu anda sahip oldukları için mutlu olacakları ölçüde çalışmasını sağlamak önemlidir, çünkü en azından tüm son sprint boyunca onu dört gözle bekliyorlardı :).

(Uzun süredir) vaat edilen işlevselliğin nihayet piyasaya sürüleceğinin duyurulması, ancak geçen gün gerçekten iyi çalışmadığını öğrenmek çok üzücü bir deneyim.

Bu nedenle, yeni sprint işlevselliğini uygun şekilde test etmek çok önemlidir. Bunu başarılı kılmak için, önemli test durumlarını önceden ve ilgili paydaşlardan (ürün sahibinden ve hatta son kullanıcılardan) toplamak ve içindeki içerik için gerekli tüm bu tür test durumlarının bir listesini yapmak iyi bir uygulamadır. hızlı koşu

Bu ilk bakışta ezici görünebilir, ancak deneyimlerime göre, yine tek bir kişi tarafından tamamen yönetilebilir. Sprintler çoğunlukla oldukça kısa olduğundan (iki haftalık süre kısalığı gibi), sprint aynı zamanda teknik borç hikayeleri, dokümantasyon, tasarım/spike hikayeleri vb.

Ardından, öncelikle istenen işlevselliği doğrulamak amacıyla test senaryoları yürütülür. Sonuçlarla ilgili herhangi bir sorun oluşursa, sorunu hızlı bir şekilde çözmek için yalnızca ilgili geliştiriciye (bu belirli kusurla ilgili değişikliklerin sahibi olan kişi) başvurulur.

Bu şekilde, geliştiriciler işlevsel testlerle bağlantılı olarak minimum zaman harcayacak ve yine de en çok sevdikleri etkinliklere konsantre olabilecekler.

2 numara. Regresyon testi vakalarının yürütülmesi

Fonksiyonel testin diğer kısmı, şimdiye kadar çalışan her şeyin bir sonraki sürümden sonra da çalışacağından emin olmak olacaktır. Regresyon testleri bunun için var.

Regresyon testleri için test senaryoları, düzenli olarak bakımlarının yapılması ve her sürümden önce yeniden ziyaret edilmesi halinde en iyisidir. Somut proje özelliklerine dayanarak, bunları basit tutmak, ancak en temel işlevlerin çoğunu ve tüm sistem boyunca çalışan önemli uçtan uca akışları kapsamak en iyisidir.

Genellikle, her sistem birçok farklı alana dokunan bu tür süreçlere sahiptir, bunlar regresyon testi senaryoları için en iyi adaylardır.

Hatta bazı durumlarda, örneğin sprintteki yeni hikaye mevcut akışın belirli bir bölümünü değiştiriyorsa, regresyon testleri dolaylı olarak sprintteki yeni özellikleri de kapsar.

Bu nedenle, çoğu durumda, özellikle her üretim sürümünden önce düzenli olarak yapılıyorsa ve üretim sürümlerinin periyodikliği çok küçük değilse, yeni sprint hikayeleri işlevsellik testlerinin yanı sıra regresyon testlerini tamamlamak hiç de karmaşık değildir.

Her üretim sürümünden önce Kalite Güvence testleri yapmakta ısrar edin

Kalite Güvencesi (QA) testi, üretime geçmeden önceki son adımdır ve genellikle bu test önemsiz görülerek atlanır. Özellikle saldırı ekibi yeni içerik için agresif bir şekilde yönetiliyorsa.

İş kullanıcıları bile yeni özelliklerle ilgilendiklerini ve işlevselliği korumak veya kusur sayısını düşük tutmakla pek ilgilenmediklerini söyleyecektir. Ancak yine de - zamanla, geliştirme ekibinin eninde sonunda yavaşlamak zorunda kalmasının ana nedeni budur ve ardından iş kullanıcıları zaten istediklerini alamazlar.

KG testi, yalnızca Scrum ekibi dışındaki kişiler tarafından, ideal olarak iş kullanıcılarının kendileri tarafından, gelecekteki üretime mümkün olduğunca yakın, özel bir ortamda yürütülecektir. Alternatif olarak, ürün sahibi burada son kullanıcıları değiştirebilir.

Her halükarda bu, geliştirici Scrum ekibiyle herhangi bir bağlantısı olmayan, son kullanıcının bakış açısından temiz, işlevsel bir test olmalıdır. Ürünün son bir görünümünü sunacak ve muhtemelen saldırı ekibinden hiç kimsenin beklemediği bir şekilde kullanılacak (hiç de ideal bir durum değil, ama kesinlikle olabilir). Son dakika düzeltmeleri için hala zaman var.

Alternatif olarak, beklentilerin scrum ekibi tarafından iyi anlaşılmadığı ortaya çıkabilir ve böyle bir durumda, en azından, fiili üretim sürümünden çok önce bir takip planı üzerinde anlaşabiliriz. Bu, yine ideal bir durum değildir, ancak yine de başarılı bir üretim sürümünü bildirdikten hemen sonra başarısızlığı kabul etmeye benzer.

Buradan sonra nereye gitmeli?

Bu uygulamaları günlük scrum çalışmasına uygulamak, üretim sürümlerini geciktirmeden veya tüm sprinti sadece bir sonraki sürüm için hazırlanmaya harcamadan ve hatta scrum ekibindeki herkesi yapmadıkları bir şeyi yapmaya zorlamadan sizi ciddi şekilde daha istikrarlı ve öngörülebilir sprint sürüm alışkanlıklarına getirebilir. Yani, sprintin çoğunluğu için zaten etkili bir şekilde nasıl yapılacağını gerçekten sevmiyorum veya bilmiyorum.

Ama kesinlikle burada durmanıza gerek yok.

Performans testi dahil etme, burada adlandırılacak bir konudur. Bunlar genellikle göz ardı edilir veya gereksiz kabul edilir, "scrum faaliyetleri optimizasyonunun" ilk turunda kazınır. Bununla birlikte, performans için düzenli olarak kontrol edilmezse, üretim sisteminin zaman içinde nasıl gelişeceğinin beklenebileceği konusunda her zaman şüphem vardı.

Bir seviye yukarı çıkmak aynı zamanda otomatikleştirilmiş testlerin getirilmesi anlamına da gelir.

Halihazırda bir grup otomatik testi (işlem hatlarındaki birim testleri) ele aldım. Ancak, tamamen otomatikleştirilmiş ve test ortamına her dağıtımdan sonra kendi başlarına yürütülen tam uçtan uca regresyon testleri geliştirebilirsiniz. Bu, geliştirme scrum ekibini daha da fazla serbest bırakır, ancak bu tür otomatikleştirilmiş testleri geliştirmek ve sürdürmek için özel bir ekip gerektirir. Üretim kodu her değiştiğinde bazı mevcut otomatik testler geçersiz hale gelebileceğinden ve bu nedenle işlem hatlarında çalışmaya devam etmeleri için güncellenmeleri gerektiğinden, bu sürekli bir çalışma haline gelecektir. Bu, yalnızca birkaç kişinin bedelini ödemeye istekli olduğu bir çabadır, ancak dev scrum ekibi için faydaları harika olacaktır.

Bunlar, bu makalenin kapsamını aşan ve burada belirtilen her test türü için doğru programı ve zamanlamayı belirleyen konulardır - böylece bunu bir sprint penceresinde yapabilirsiniz. Bir dahaki sefere dalış yapmaktan mutluluk duyacağım!