paint-brush
Üretkenliği Artırma: Daha Hızlı Sürümler için Yeni Bir Kalite Güvence Rolü Uygulama Kılavuzuile@malykhpaul
5,573 okumalar
5,573 okumalar

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

ile Paul Malykh4m2023/08/13
Read on Terminal Reader
Read this story w/o Javascript

Çok uzun; Okumak

Ekipler arası işbirliğini geliştirmek, testleri hızlandırmak ve sürüm sürecini kolaylaştırmak için bir sistem QA rolü uygulandı. Ayrı ekipler, test yapıtlarının yeniden kullanılmaması ve entegrasyon zorlukları gibi sorunlara değinildi. Sistem QA, teknik ve iş gereksinimleri arasında bir köprü görevi görerek hata tespitini, test verimliliğini ve entegrasyon kalitesini artırır. Sonuç olarak %20 daha hızlı sürüm akışı ve azaltılmış entegrasyon hataları, maliyet tasarrufu ve daha sorunsuz sürüm akışı sağladı.
featured image - Üretkenliği Artırma: Daha Hızlı Sürümler için Yeni Bir Kalite Güvence Rolü Uygulama Kılavuzu
Paul Malykh HackerNoon profile picture
0-item

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:


Her özellik için üç ana belge hazırlıyoruz: BRS, SRS ve QAP.

  1. İş Gereksinimleri Spesifikasyonu (BRS), 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ş hedefleriyle 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.
  2. Yazılım Gereksinimleri Belirtimi (SRS), 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.
  3. Kalite Eylem Planı (QAP) – ö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.

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!