Yazılım geliştirmenin kalitesinden kim sorumludur?
Bu makalenin temel noktaları:
- Yazılım geliştirme gittikçe daha fazla kalite peşinde koşarken, her ekip üyesi kaliteden sorumludur.
- Kalitenin tanımı artık sadece çalışma süresi ve güvenilirlikle ilgili değil, kullanıcıların seçim yapabileceği çeşitli yönlere sahip.
- David A. Garvin'in 1984'te "Kaliteyi Tanımlamanın Beş Yolu", kaliteyi mükemmel kalite, değer bazlı kalite, kullanıcı bazlı kalite, ürün bazlı kalite ve üretim bazlı kalite olarak tanımlar.
- Üretime dayalı kaliteye ek olarak, çoğu kalite türü ölçülemez, ancak ekibin de bunu dikkate alması ve genellikle bunu doğrudan kullanıcıyla yapması gerekir.
- Davranış odaklı tasarım (BDD), kod yazmadan önce kullanıcı yolculuklarını planlamanın ve senaryoları test etmenin bir yoludur.
Çevik yazılım geliştirme ve DevOps, kullanıcı deneyimini vurgulamanın yanı sıra, ürünün arkasındaki insanlara odaklanmamıza da izin veriyor. Ama bu süreçler önemli mi yoksa sadece yöntemin doğru olduğunu kanıtlamak için mi? London P3X (veya İnsanlar, Ürün ve Süreç Değişimi) bu üç P'nin kesişimi konusunda çok endişelidir.Belki de son X, test odaklı geliştirme (TDD), davranış odaklı geliştirme gibi daha fazla kısaltmayı yoğunlaştırdığı için en ilginç olanıdır. (BDD), Sürekli Teslimat (CD), Etki Alanına Dayalı Geliştirme (DDD), vb., Ekibin sistematik olarak daha iyi bir sistemin nasıl kurulacağını incelemesine yardımcı olmak için.
Janet Gregory, Çevik Test Derneği'nin kurucu ortağıdır. Kısa bir süre önce yazılım kalitesini sürdürme süreciyle ilgili bir açılış konuşmasını tamamladı. Konuşmanın sonunda, herkese Agile takımlarının büyüsünü hissedip hissetmediklerini ve kendilerini hissedip hissetmediklerini sordu. Kalite bilincini aktarın ve elinizi kaldırın. Bütün odada, muhtemelen sadece birkaç çevik uygulayıcı ellerini kaldırdı.
Agile Manifesto'nun imzalanmasından bu yana, bu 17 yıl geçti Buraya nasıl geldik, neden bazı insanlar onu hala ayna gibi görüyor? Belki hala düzgün iletişim kuramıyoruz, belki doğru insanlarla çalışmıyoruz veya sürecimiz hiçbir şekilde iletişimi içermiyor.
Bu manifesto, bireyleri ve etkileşimleri süreçlerin ve araçların üzerine koysa da, bazı süreçler de insan odaklıdır. Belki de sürecimizi gözden geçirerek, değişikliklere daha iyi yanıt verebilir, işbirliğini artırabilir ve hataları azaltabiliriz, bunların tümü müşterileri mümkün olan en kısa sürede ve sıklıkla tatmin etmek içindir. Gregory, nesilden nesile aktarılan kaliteli bir yöntem geliştirdi ve bunu modern Agile yazılım ekiplerine uyguladı ve herkesin yayınladıkları içeriğin mülkiyet ruhuna sahip olacağını umdu.
Tam olarak "kalite" nedir
Gregory, öncelikle kalitenin öznel tanımının verilmesi gerektiğine işaret etti. 1984'te David A. Garvin'in "Kaliteyi Tanımlamanın Beş Yöntemi" nden alıntı yaptı ve kaliteyi şu yöntemle tanımlamaya başladı:
- Mükemmel kalite: Atmosfer, doğası gereği mükemmel mizaç, dünyaca tanınan başarı
- Değere dayalı kalite: fiyat ve maliyet
- Kullanıcı tabanlı kalite: belirli insanlara değer (kaliteyi göz önünde bulundururken çoğu insanın düşündüğü kişiler)
- Ürünün kalitesine göre: Kullanıcılarınız ne arıyor? (Sağladığınız süt gibi)
- Üretim kalitesine bağlı olarak: uygulamalar, süreçler, standartlar, gereksinimler, şartnameler, bunu doğru yapıyor muyuz?
Gregory, her kategorinin önemini görselleştirdi ve bunu modern çevik ortama uyguladı. Aşağıdaki şekilde gösterildiği gibi, en gerekli merkezden dışarı doğru yayın.
Üretime dayalı kalite
Her şeyden önce, bir şeyin sorunsuz ilerlemesi gerekir, bu nedenle üretime dayalı kalite önce gelmelidir.
Gregory, bunun test odaklı tasarımla ilgili olduğunu, çünkü "açık kod oluşturarak yeniden çalışmanın önemli ölçüde azaltılabileceğini" söyledi.
Başka kusurlarımız kalmasın ve güvenle yayınlayabilmemiz için işleri ilk seferde doğru yapalım.
Yazılım testinden önce otomatik test tasarlama uygulaması olan TDD, yazılım ayırmayı zorlar ve üretim kalitesinin önemli bir parçasıdır. Gregory, TDD yapmayan takımlarla karşılaştırıldığında, TDD yapan takımların% 60 ila% 90 daha az hataya sahip olacağını, ancak TDD'nin ortalama% 15 ila% 30 daha fazla olduğunu belirten bir çalışmanın sonuçlarına atıfta bulunuyor.
Birçok takım kalite ve hız arasındaki bu değiş tokuşla karşı karşıyadır.
"Belki PO (Ürün Sahibi) kaliteyi artırmak yerine yeni özellikler eklemenizi tercih ettiğimi söyledi. Bu kararları kim veriyor?"
Gregory, TDD'ye ek olarak, üretime dayalı süreçlerin şunları da içerdiğini söyledi:
- Sürdürülebilirlik için kod
- Hata günlüklerinin izlenmesi
- Sürekli entegrasyon
- Hikaye üzerinde keşif testi
- Ürünlerin spesifikasyonları karşıladığını doğrulamak için testler
- Hızlı geri bildirim için otomatik testler oluşturun
- Platformun statik analizi
- Tamamlama standartlarını açıkça tanımlayın
Son olarak, "DevOps gibi uygulamalar, ürünleri kendilerine sunarken müşteriler için riski azaltmaya çalışıyor." Dedi.
Ürün bazlı kalite
Basitçe ifade etmek gerekirse, üretime dayalı kalite, bir şeyin normal şekilde yürütülmesini sağlamaksa, ürün temelli kalite, ürünün beklendiği gibi çalışmasını sağlamaktır. Örneğin, daha yüksek kalite için ödeme yapmak istiyoruz, ancak bir şey bozulursa, ancak maliyeti çok düşük veya hatta sıfırsa, daha bağışlayıcı olacağız. İstisnalar varsa, genellikle ücretsiz olmasını ve iyi çalışmasını beklediğimiz bir uygulama olabilir.
Gregory, ürünün kalitesine bağlı olanın hedef kitleye bağlı olduğuna dikkat çekti. Muhasebeciler, klavye tepsisinin bugün çoğu dizüstü bilgisayardan ayrılmasını isteyecektir.
Bu aslında şöyle sorular soruyor:
- Doğru şeyi mi inşa ediyoruz?
- İstediğimiz özellikleri ekledik mi?
Bu içerir:
- Bazen Öykü Testi Güdümlü Geliştirme olarak adlandırılan Kabul Testi Güdümlü Geliştirme (ATDD), anahtar müşterilerin TDD aşamasına girmesidir.
- Güvenlik testi
- Mümkün olduğunca çok sayıda hata arayan bir takım hackathonuna benzeyen hata temelleri
- Sürekli teslimat
- Özelliklerin keşif testi
- Beta sürümü
- Performans testi
- Yük testi
Kullanıcıya dayalı kalite
Bu görüşle ilgili olarak, farklılıklar en büyüktür. Gregory'e göre: "Herkesin kendine göre avantajları vardır ve farklı insanların farklı seçenekleri vardır. Farklı ihtiyaçları vardır. Müşterilerin tercih etmesini istiyorsak, bırakın tatmin olsunlar."
Ama unutmayın, "Büyük bir önermeyi varsaydık, yani tüketicilerin yeterli bilgiye sahip olduğunu, nitelikli bir karar verebilirler" dedi.
Daha önce kullandığı bir uygulamadan bahsetti ve onu çok düşmanca buldu. Kullanıcıların bundan hoşlanmasının nedeninin çalışma şeklini takip etmesi olduğu ortaya çıktı. O alanda çalışmıyor. Hepsi, belirli kullanıcılar için özel kullanım durumlarını karşılamalıdır.
Değere dayalı kalite
Çok basit, insanların bunun için para ödemeye razı oldukları. Değeri yargılamak zordur ve potansiyel müşterilerle iletişim kurmadan yargılamak temelde imkansızdır.
Değere dayalı kalite birkaç şekilde değerlendirilebilir:
- Etkililik
- etkililik
- Konfor
- güven
- Karmaşıklık
- Çevresel uyum
Mükemmel kalite
Son olarak, mükemmelliği değerlendirmek için en zor nitelik vardır. Gregory bunun sebebinin duyguların en zor miktar olduğunu ve bu tür bir değerlendirmenin mükemmel kaliteyi sanat, katılım ve müşteri sadakatiyle birleştirmesi gerektiğini söyledi.
Yazılımın kalitesini nasıl ölçüyoruz?
Genel olarak, Garvin'in kalite seviyesini kabul ederseniz, yazılım kalitesinin çoğunu ölçmek zordur. "Yazılım Kalite Ölçümü" kitabında Isabel Evans'tan alıntı yaptı. İmalat kalitesine dayalı birçok örnek vardır:
- Üretim ortamındaki kusur sayısı
- Üretim ortamındaki kusurların ciddiyeti
- Üretim ortamına son sürümden bu yana geçen gün sayısı
- Üretim ortamının son sürümünden bu yana X gün içinde alınan yeni destek oylarının sayısı
- Emisyon kaynakları oluşturmak her zaman yeşil kalır
- Tuhaf otomatik test yok (rastgele başarısızlıklar)
- Kod tabanının statik kod analizinin sonucu sağlıklıdır
- Düşük yeniden işleme oranı
- hatalar tekrar etmeyecek
Ayrıca bu formda kullanıcı bazlı kaliteyi ölçmek için kullanıcı memnuniyeti anketleri de yapabilirsiniz.
Bununla birlikte, ürün bazlı, değere dayalı veya üstün kaliteyi gerçekten ölçemezsiniz. Bununla birlikte, beş kalite düzeyinin tümünü tartışabilir ve değerlendirebilirsiniz. Test, kaliteyi ölçmenin önemli bir aracıdır, ancak Gregory, ürün ekiplerinin birbirleriyle, kullanıcılarla ve rakiplerle yapılan görüşmelerde kalitenin değerini inkar edemeyeceği konusunda uyardı.
Elbette, ekibin hatalardan kaçınma arzusu ile hız arayışı arasında bir denge bulması gerekiyor.
Kaliteden tüm ekip sorumludur
Açık olan şey, kalite güvencesinin sadece test departmanının sorumluluğu olmadığıdır.Geliştiriciler kodu onlara bırakamazlar veya kalite güvencesi terimi biraz sorunludur.
Tüm ekip kaliteyi kontrol ediyor
"Kuruluşunuz ve şirketiniz kaliteyi başlangıç noktası olarak alırsa, diğer her şey yerinde olduğu için başarılı olma olasılığı yüksektir. Her şey normaldir. Ancak, ilk başta hızın en önemli olduğunu düşünüyor ve kaliteye dikkat etmiyorsanız, Uzun bir süre için çok fazla yeniden çalışma yapmak mümkün, çok sayıda sürdürülemez kod olacak ve kalite daha da düşecek "dedi Gregory.
Ancak kalite arayışı için mükemmel bir tarif sunmadı.
Gregory, "Niteliksel veya niceliksel terimler kullanmanız fark etmez, ancak kendinize sormalısınız, ne aradığınızı ve güvenle yayınlamanıza izin verebilir mi?" Dedi.
"Ölçüm sürecinin kalitesi ürünün kalitesini ölçüyor mu?" BDD Book 1: Discovery'nin ortak yazarı Seb Rose'dan alıntı yaptı: "Ölçüm hedef haline geldiğinde artık iyi bir ölçüm değil."
Gregory, "Nasıl ölçerseniz ölçün, neye ihtiyacınız olduğunu görmek için bir tartışma başlatmalı" dedi.
Devam etti: "Takım kaliteyi kontrol ediyor, ancak daha uzun vadeli düşünmeniz gerekiyor. Süreçteki kalite ve uygulamadaki kalite.
Ekibinizin yeteneği, yazılımı nasıl teslim edersiniz.
Sonunda, bu yönde bir sohbete her başladığınızda, herkes sorunu çözmeye çalışmakla başlarsa, en iyisinin bu olduğunu söyledi.
Gregory, "Kalite yönetimini süreçlerimize dahil edelim ve ne yaptığımız hakkında konuşmayı öğrenelim" dedi.
Yazar hakkında
Jennifer Riggins Halen Londra'da yaşayan bir bilim ve teknoloji hikayesi anlatıcısı ve yazarıdır.Hikayede dijital dönüşüm ve kültür buluşuyor ve dünyayı daha iyi bir yer haline getirmeyi umuyor. Onu Twitter @jkriggins adresinden takip edebilirsiniz.
Çevik Test Derneği'nin kurucu ortağı Janet Gregory Ekibin çevik bir yazılım geliştirme ortamına geçişine yardımcı olmak 14 yıl sürdü Test uzmanlarının ve iş adamlarının "tüm ekip yaklaşımı" rolünün bir parçası olduklarını anlamalarına yardımcı olma konusunda uzmanlaşmıştır.
Orijinal İngilizce metni görüntüleyin: Yazılım Geliştirmede Kaliteden Kim Sorumlu?
