Merhaba!  Sistem QA rolünün uygulanması yoluyla sürüm akışımızı nasıl %20 oranında iyileştirmeyi başardığımı paylaşmaktan heyecan duyuyorum.  Şirketimin tipik bir ürün şirketi olduğu göz önüne alındığında, ekipler ürüne göre değil bileşenlere göre ayrılıyor. Bu sayede bir yandan bilgi "sahipleri" olan güçlü ekipler oluşturmayı başardık. Ancak diğer yandan, birimler içindeki roller nispeten yalıtılmıştır ve farklı zorlu beceri ve uzmanlık kümeleri, kendi sınırlamalarını dayatır. Örneğin, bazen bir testçiyi arka uç ekibinden ön uca veya tam tersi şekilde taşımam gerekiyor.  Bu, QA ekipleri içinde etkili bir orkestrasyon ve ekipler arası etkileşimin yönetimi sorununun ortaya çıkmasına neden oldu. Bu da elbette sonuçta yayın akışını etkiledi.   Değişikliklerden önce akışı yayınlayın  Değişikliklerden önce sürüm akışımız şöyle görünüyordu:     bir işletme içindeki belirli bir özellik, sistem, ürün veya proje için ayrıntılı ihtiyaçları, beklentileri ve spesifikasyonları özetleyen bir belgedir. İş paydaşları ile geliştirme veya uygulama ekipleri arasında bir köprü görevi görerek neyin başarılması gerektiği ve bunun genel iş   nasıl uyumlu olduğunun net bir şekilde anlaşılmasını sağlar. Kullanıcıların bu özellikle nasıl etkileşime gireceğini açıklayan ayrıntılı senaryolar içermelidir. Özellik Sahibi (FO), iş gereksinimlerini formüle etme göreviyle görevlendirilmiştir. İş Gereksinimleri Spesifikasyonu (BRS), hedefleriyle    bir yazılım sisteminin neyi başarması beklendiğinin ayrıntılı açıklamasını özetleyen kapsamlı bir belgedir. Örneğin, hangi komutların nasıl ve hangi protokolle etkileşime gireceği ve hangi verilerin iletileceği. Özellik üzerinde çalışan ekip grafiksel bir arayüz kullanıyorsa SRS, geliştirilmekte olan özelliğin düzenlerini içermelidir. Özellik Mimarı SRS'nin yazılmasından sorumludur. Yazılım Gereksinimleri Belirtimi (SRS),    – özellik sahibinin bir özelliği kabul etmeden önce kontrol ettiği bir dizi durum. Belgeler anlatıldıktan sonra özelliği uygulamaya geçiyoruz. İlk takım özelliğin kendine ait kısmını geliştirmeyi ve test etmeyi bitirdiğinde, bu özellik ikinci takıma aktarılır. İkinci ekip ise entegrasyon/geliştirme/test işlemlerini gerçekleştirerek bir sonraki birime aktarır. Özellik geliştirmeye katılan tüm bileşen ekipleri bu akıştan geçene kadar bu böyle devam eder. FO özelliği doğrular ve yayına gönderilir. Kalite Eylem Planı (QAP)   Serbest bırakma akışı sorunları  Yani her şey yolunda görünüyor; belgeler, başvurular, kabul durumları. Ancak bu süreçte şu zorluklarla karşılaştık:   QA tarafındaki sorunlar:  Gereksinim testleri yalnızca geliştirmeden sonra başlar. Geliştiriciler tarafından halihazırda uygulanmış olan görevler, gereksinimleriyle birlikte QA ekibine devredilir. Ancak bildiğimiz gibi gereksinimlerde hatalar olabiliyor.  Bir hatadan sorumlu ekibi bulmak oldukça zaman alır çünkü hangi vakaların halihazırda diğer ekipler tarafından test edildiği her zaman net değildir.  Test eserlerinin yeniden kullanımı yoktur. Bir özelliğin test edilmesinin bir parçası olarak, QA ekipleri benzer test veri setleri hazırlar. Ancak ekiplerin izolasyonu ve dar uzmanlaşması nedeniyle bu verileri birbirlerine aktaramadılar.   FO'nun sorunları:  Pek çok özellik nedeniyle QAP yazmak çok zaman alır.  Özelliğin doğrulanması, tüm ekipler tarafından geliştirildikten sonra gerçekleşir. Bizim durumumuzda bu, birçok entegrasyon sorunu nedeniyle sürüm akışını önemli ölçüde uzatıyor.  Ürünün karmaşıklığı ve ekipler arasındaki entegrasyon hacmi nedeniyle test ortamının hazırlanması da hassastır. Farklı ekipler bileşenlerini aynı anda test ediyor; bu da verilerin ezilmesi, değiştirilmesi veya silinmesi riskini artırıyor.   Güncellenmiş sürüm akışında Sistem Kalite Güvencesi  Kalite Güvence ekipleri arasında etkili ekipler arası etkileşimi kolaylaştırmak ve sürüm akışını azaltmak için sistem Kalite Güvencesi rolünü tanıttık.  Bu, FO ile kabul senaryolarının yazılması yoluyla iş yükünün hafifletilmesine ve test senaryolarının yazılmasının hızlandırılmasına, özellik bileşeninin bir sonraki ekibe iletilmeden önce ara testlerinin yapılmasına ve ayrıca test hazırlamanın zaman alıcı çalışmasının kaydırılmasına yardımcı oldu. Entegrasyonlar ve test verileri için ekiplerin tüm nüanslarını ve gereksinimlerini dikkate alarak ortamdan sistem kalite güvencesine kadar.  Sistem Kalite Güvencesi, her bir özelliğin teknik ve iş gereksinimleri ile bir bütün olarak ürün arasında bir bağlantı haline gelmiştir.  Sistem Kalite Güvencesi için katılım  Tüm sürüm döngüsünü anlamak için Sistem QA'larının her ekipte belirli bir sürüm döngüsünün nasıl çalıştığını anlaması gerekir. Sistem QA'sı her takımda 2-3 hafta harcayarak spesifik sürüm döngülerini anladığından, katılım genellikle yaklaşık üç ay sürer.  Yeni sürecin sonuçları  Şimdi özellik sahiplerinin ve mimarların BRS/SRS gereksinimlerini test ediyoruz. Hataların erken tespiti, işletme için maliyet tasarrufu sağlar.  Test yapılarının her özelliğe (iş gereksinimleri, teknik gereksinimler, kabul durumları, diğer ekiplerin durumları, test verileri) eklendiği ekipler arası bir QA alanı oluşturduk. Bu, tüm QA ekiplerinin tek bir bağlamda olmasına ve verileri etkili bir şekilde yeniden kullanmasına önemli ölçüde yardımcı oldu.  Sistem QA'sında tüm ekiplerden test senaryoları bulunduğundan hataların yerelleştirilmesi süreci hızlandırıldı.  Sistem QA'sı her ekip için kabul senaryoları yazdığından, bu, test kalitesini hızlandırmak ve geliştirmek için mükemmel bir ipucudur.  Özellik her komuttan sonra kabul durumları ile doğrulandığından entegrasyon süreci sorunsuz hale geldi.  FO'nun yükünün önemli bir kısmının kaldırılmasıyla özelliklerin kabulü ve test verilerinin yer aldığı entegrasyon standının hazırlanması hızlandı.  Genel olarak sürüm akışını %15-20 oranında hızlandırdık ve entegrasyon hatalarının sayısını neredeyse yarı yarıya azalttık, çünkü artık bunları hem BRS ve SRS gereksinimleri yazma aşamasında hem de özellik geliştirme çerçevesinde ekip entegrasyonları sırasında yakalıyoruz.  Mutlu ve verimli testler!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

QA Head

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Make resilience your competitive advantage

Üretkenliği Artırma: Daha Hızlı Sürümler için Yeni Bir Kalite Güvence Rolü Uygulama Kılavuzu

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps