Modern çevik ortamlarda, hızlı yineleme genellikle belgelerin güncellenmesini geçiyor ve bu durum testerların açık gereksinimler olmadan kritik kararlar almak zorunda kaldığı senaryolar yaratıyor. Bu soru, bağlama dayalı test uygulamasındaki endüstri kaymasından ortaya çıktı. Bu bağlamda, katı senaryo uygulamalarının belirsiz durumlarda başarısız olduğu anlaşıldı. Ekipler, analitik araştırmacı olarak hareket eden testerların, yalnızca test senaryolarını izleyenlerden çok daha fazla üretim sorununu önleyebileceğini fark ettikçe bu uygulama resmileşti.
Yapılandırılmış bir sınıflandırma çerçevesi olmadan, QA mühendisleri ya her belirsizliği bir hata olarak kaydetmeye yöneliyor - bu, gürültü yaratıyor ve geliştirici güvenini azaltıyor - ya da belgelenmemiş davranışların kasıtlı özellikler olduğunu varsayarak gerçek hataları kaçırıyorlar. Bu analizle felç olma durumu, her iki durumda da gözlemlerini etkili bir şekilde derecelendirme risk değerlendirme becerisi olmayan ekiplerde sürüm gecikmelerine ve ürün kalitesinin tehlikeye girmesine yol açıyor. Ayrıca, takım üyeleri arasındaki tutarsız sınıflandırma, düzensiz sürüm kalitesi ve marka itibarını zedeleyen öngörülemeyen kullanıcı deneyimlerine neden oluyor.
Risk temelli analiz (etki × olasılık), tarihsel sistem davranışı karşılaştırması ve paydaş değer haritası kullanarak Excel veya Confluence gibi araçlarla bir sınıflandırma modeli uygulayın. Öncelikle, gözlemlenen davranışın iş riskini değerlendirin; bunun için RBT (Risk Tabanlı Test) matrisleri ve tarihsel temelleri belirlemek için SQL sorguları kullanın. İkincisi, sistem sınırlarını doğrulamak için UX akış haritalama ve API uç noktası doğrulaması ile kullanıcı yolculuğunun kritikliğini analiz edin. Son olarak, karar rasyonelini Confluence'da belgeleyin; bu, "hata" (makul beklentiden sapma), "özellik açığı" (eksik gereksinim) ve "emergent behavior" (kabul edilebilir belgelenmemiş işlevsellik) arasında ayırım yapmanızı sağlayan bir denetim izi oluşturur.
Sağlık sektöründeki HIPAA uyumlu hasta portalı için regresyon testi sırasında, "Veri Dışa Aktar" butonunun 24 saatlik oturumdan sonra yeniden kimlik doğrulama olmadan kayıt indirmesine izin verdiğini gözlemledim. Kullanıcı hikayesi şunu belirtmişti: "Kullanıcılar verilerini kolayca dışa aktarabilir," ancak güvenlik gereksinimleri belgesi güncel değildi ve güvenlik lideri bir konferanstaydı. Geliştirme ekibi bu özelliğin "tasarlandığı gibi çalıştığını" ısrarla belirtti, UX araştırmacısı ise bunun "sürtünmesiz iş akışları" oluşturduğunu savundu; bu durumda çelişkili paydaş girdisini çözmek zorundaydım.
Kritik bir kararla karşı karşıyaydım: bunu bir P1 güvenlik hatası olarak kaydetmek, düzenleyici bir son tarihi geciktirebilir ve pahalı bir penetrasyon testini tetikleyebilirdi; bunu göz ardı etmek ise HIPAA oturum zaman aşımı gereksinimlerini ihlal edebilirdi. Belirsizlik, "kolayca" kelimesinin çelişkili yorumlarından kaynaklanıyordu - bu, "sürtünmesiz" mi yoksa "uygun güvenlik ile" mi demekti - ve veri dışa aktarma işlemleri sırasında oturum yönetimi ile ilgili açık kabul kriterlerinin eksikliği. Bu durum, bir hata, belgelenmemiş bir özellik veya ürün sahibi açıklaması gerektiren bir gereksinim açığı olup olmadığını belirlemek için hemen sınıflandırma gerektiriyordu.
Bir yaklaşıma hemen CTO'ya Slack üzerinden zorlamak ve sürümü durdurmak dahildir. Bu, maksimum güvenlik ve yasal koruma sağlardı ve potansiyel HIPAA ihlallerinin üretime ulaşmadan önce önlenmesini sağlardı. Ancak, bu, yaklaşık 50.000 $ maliyetle acil bir kod dondurmasını tetikleyebilir ve eğer bu davranış aslında UX sürekliliği için düşünülmüşse QA ekibinin yanlış alarmlar çıkarma itibarı zedelenebilirdi.
Diğer bir seçenek, bu davranışın önceki üretim sürümünde (v2.1) mevcut olup olmadığını kontrol etmek için denetim günlüklerine karşı SQL sorguları kullanarak karşılaştırmalı analiz yapmaktır. Eğer bu, önceki bir davranışsa, "mevcut işlevsellik" olarak sınıflandırabilirdim ve incelemeyi erteliyordum; bu, mevcut sürüm hızını koruyordu. Bu yaklaşım ivmeyi sürdürse de, potansiyel olarak hasta PHI'nin ihlalleriyle ifşa edilmesine yol açabilecek, daha önce test edilmemiş, uyku halindeki bir güvenlik açığını yayımlama riskini taşıyordu.
Üçüncü çözüm, Excel kullanarak bir risk temelli karar matrisinin inşa edilmesini gerektiriyordu; gözlemi veri hassasiyeti (yüksek), istismar edilebilirlik (orta - fiziksel cihaz erişimi gerektiriyor) ve düzenleyici uyum (bilinmiyor) boyutlarında derecelendirerek oluşturuyordum. Bunu, arka uçun UI oturumundan bağımsız olarak yetkilendirme kontrollerini zorlayıp zorlamadığını doğrulamak için Postman API testi ile birleştirecektim. Bu yöntem önemli bir zaman yatırımı gerektirse de, öznel yorum yerine nesnel kanıt sağlayarak hem güvenlik endişelerini hem de sürüm zamanlamalarını belgeleyerek tatmin ediyordu.
Gözlemin bu sürüm için yeni olduğunu doğruladıktan sonra üçüncü yaklaşımı ve hedefli API doğrulamasını seçtim. Postman kullanarak arka uç REST uç noktalarının süresi dolmuş belirteçleri UI durumu ne olursa olsun reddettiğini doğrulayarak, güvenlik sınırının sağlam olduğunu onayladım; bu, bir güvenlik açığı değil, bir UX iyileştirmesi oluşturmaktaydı. Bu veri odaklı yaklaşım, DevOps ekibine somut kanıt sağladı ve kullanıcı arayüzü kolaylığı ile gerçek güvenlik mimarisi hataları arasında etkili bir şekilde ayrım yapmamıza izin verdi.
Davranışı JIRA'da bir P3 UX iyileştirme önerisi olarak belgelerken, Postman koleksiyon sonuçlarını ve SQL denetim kanıtını tam izlenebilirlik için bağladım. Güvenlik lideri, konferanstan sonra bunu gözden geçirdi ve arka uç doğrulamasının yeterli olduğunu onayladı; ancak UI oturum uyarısını sıkılaştırmamızı istedi. Confluence'de "kolay dışa aktarım"ın yalnızca oturum 15 dakikayı aşarsa yeniden kimlik doğrulamayı gerektirdiğini açıklığa kavuşturduk ve gelecekteki belirsizliği önledik ve gereksinimler açığını kalıcı olarak kapattık.
Belgelenmemiş bir özellik ile gereksinimler açığı arasında nasıl ayrım yaparsınız, mevcut sistem davranışı kasıtlı gibi görünüyorsa?
Birçok aday "mevcut haliyle çalışmak" ile "amaçlandığı gibi çalışmak" arasında karışıklık yaşar. Yazılım, kod mantığına göre doğru çalıştığında bir gereksinim açığı vardır, ancak bu mantık işlevsel olması gereken bir iş ihtiyacını karşılamıyorsa (örn., eyalet vergilerini hesaplamayan bir vergi hesaplayıcı). Belgelenmemiş bir özellik ise, geçerli bir iş amacını yerine getiren, ancak asla belirtilmemiş olan bir işlevselliktir (örn., güç kullanıcıları için bir klavye kısayolu). Bunları ayırt etmek için, davranışı JIRA etiketleri kullanarak kullanıcı değerine izleyin: eğer davranışın ortadan kaldırılması kullanıcı deneyimini olumsuz etkiliyorsa, bu muhtemelen belgelenmemiş bir özelliktir; eğer davranış, iş riskine veya kullanıcı karmaşasına neden oluyorsa, bu, Confluence'de belirtilmesi gereken bir açıdır.
Belirsiz davranışların sınıflandırılmasında izlenebilirliğin rolü nedir ve bunu nasıl korursunuz?
Adaylar genellikle yalnızca hemen sınıflandırmaya odaklanırlar ve ISO standartları veya düzenleyici uyum için gerekli denetim izlerini dikkate almazlar. İzlenebilirlik, belirsiz gözlem ile test durumu kimliği (TestRail veya Zephyr'de), belirli gereksinim ("TBD" olarak belirtilmiş olsa bile) ve nihai sınıflandırma rasyonalitesi arasında iki yönlü bağlantılar gerektirir. Bunu sağlamadığınızda, gelecekteki regresyon testleri aynı belirsizlikle yeniden karşılaşacak, zaman kaybına yol açacak ve tutarsız ürün davranışları yaratacaktır. İzlenebilirliği korumak için, JIRA'da özgün hikayeyi engelleyen bir "Gereksinim Açıklaması" talebi oluşturun; böylece belirsizliğin bir sonraki sprintten önce çözülmesi sağlanır ve test notlarında teknik borç olarak bırakılmaz.
Bağımsız olarak sınıflandırma kararını vermeyi ne zaman reddetmelisiniz ve paydaş girişi talep etmelisiniz?
Kritik adaylar, hem ürünü ve hem de QA mühendisinin profesyonel yükümlülüğünü koruyan yükseltme tetikleyicilerini gözden kaçırır. Davranış, PCI-DSS, GDPR, HIPAA veya yan etkileri hukuki yükümlülük veya mali ceza gerektiren diğer uyum çerçeveleri ile ilgili olduğunda bağımsız olarak sınıflandırmak yerine yükseltmek zorundasınız. Ayrıca, düzeltme çabası mevcut sprintin ekip kapasitesini aşıyorsa (bu, bir kapsam değişikliği anlamına gelir, bir hata değil) veya davranış başka bir yerde açık yazılı belgeyle çelişiyorsa (bu, belirsizlik değil bir sistem hatası göstergesi) yükseltme yapmalısınız. Uyum açısından kritik sınıflandırmalar konusunda asla tahminde bulunmayın; gözlemi JIRA'da belgeleyin, söz konusu spesifik düzenlemeyi belirtin ve bir risk değerlendirmesi matrisini ekleyerek Ürün Sahibi veya Uyum Yöneticisi'ne yükseltin.