Ey Habr!
Yeni ve önemli bir konumuz var: BT ürünlerinin yüksek kalitede geliştirilmesi. HighLoad++'da sık sık yoğun servislerin nasıl hızlandırılacağından bahsederiz ve Frontend Conf'ta yavaşlamayan harika bir kullanıcı arayüzünden bahsederiz. Düzenli olarak test etme ve test de dahil olmak üzere farklı süreçleri birleştirmeyle ilgili DevOpsConf konularımız oluyor. Ancak genel olarak kalite olarak adlandırılabilecek şey ve bunun üzerinde kapsamlı bir şekilde nasıl çalışılacağı hakkında - hayır.
Bunu şu şekilde düzeltelim — Geliştirmenin her aşamasında kullanıcı için nihai ürünün kalitesi hakkında düşünme kültürünü geliştireceğiz. Sorumluluk alanınıza odaklanmama ve kaliteyi sadece testçilerle ilişkilendirmeme alışkanlığı.
Kesimin altında, Rusça konuşan QA topluluğunun yaratıcısı Tinkoff.Business'ın test başkanı olan program komitesi başkanı ile konuşacağız. Anastasia Aseeva-Nguyen QA endüstrisinin durumu ve yeni konferansın misyonu hakkında.
- Nastia merhaba. Lütfen bize kendinden bahset.
anastasia: Bir bankada testleri yönetiyorum, çok büyük bir ekipten sorumluyum - 90'dan fazla kişiyiz. Önemli bir iş kolumuz var, tüzel kişiler için ekosistemden sorumluyuz.
Mekanik ve matematik okudum ve başlangıçta programcı olmak istedim. Ancak ilginç bir teklif aldığımda kendimi testçi olarak denemeye karar verdim. Garip bir şekilde, bunun benim çağrım olduğu ortaya çıktı. Artık tüm çalışmalarımı bu sektörde görüyorum.
Kalite Güvence disiplinine sıkı sıkıya bağlıyım. Hangi ürünlerin yaratıldığına, şirkette, ekipte ve prensip olarak geliştirme sürecinde kaliteye nasıl davranıldığına kayıtsız değilim.
Bana göre bu çok açık toplum bu yönde yeterince olgun değilen azından Rusya'da. Kalite güvencesinin yalnızca bir uygulamanın gereksinimlere uygunluğu açısından test edilmesi olmadığını her zaman anlamıyoruz. Bu durumu değiştirmek isterim.
— Kalite Güvencesi ve test kelimelerini kullanıyorsunuz. Ortalama bir insanın gözünde bu iki terim sıklıkla örtüşür. Derinlere inerseniz nasıl farklılaşırlar?
Anastasia: Aksine, onlardan farklı değiller. Test yapmak, Kalite Güvence disiplininin bir parçasıdır; doğrudan bir faaliyettir; bir şeyi test ettiğim gerçeğinin kendisidir. Aslında pek çok test türü vardır ve farklı test türlerinden çeşitli kişiler sorumludur. Ancak burada, Rusya'da, şirketlere test uzmanları sağlayan bir dış kaynak dalgası ortaya çıktığında, testler tek bir türe indirildi.
Çoğu durumda, yalnızca işlevsel testlerle sınırlıdırlar: geliştiricilerin kodladığı şeyin spesifikasyona uygun olup olmadığını kontrol ederler, hepsi bu.
— Lütfen bize başka hangi kalite güvence disiplinlerinin bulunduğunu söyleyin? Burada test dışında başka neler yer alıyor?
anastasia: Kalite Güvencesi her şeyden önce kaliteli bir ürün yaratmakla ilgilidir. Yani ürünümüzün hangi kalite özelliklerine sahip olması gerektiğini kendimize soruyoruz. Buna göre eğer bunu anlarsak, bu kalite niteliklerini kimin etkilediğini karşılaştırabiliriz. Önemli değil geliştirici, proje yöneticisi veya ürün uzmanı Bir ürünün gelişimini, birikimini ve stratejisini etkileyen kişidir.
Testi yapan kişi rolünün daha fazla farkına varır. Görevinin yalnızca gereksinimlere uygunluğu test etmek olmadığını, aynı zamanda gereksinimleri test etmek, ürün uzmanından gelen formülasyonları sorgulamak ve müşterinin tüm örtülü gereksinimleri ve beklentilerini ortaya çıkarmak olduğunun bilincindedir. Müşterimize yeni işlevler sunarken beklentilerini gerçekten karşılamalı ve acılarını çözmeliyiz. Kalitenin tüm özelliklerini düşünürsek müşteri memnun kalacak ve ürününü kullandığı firmanın gerçekten kendi çıkarlarını önemsediğini, “sadece bir özellik çıkarmak” ilkesiyle çalışmadığını anlayacaktır.
— Az önce tanımladığınız şeyin bir ürün uzmanının görevi olduğu anlaşılıyor. Bu prensip olarak test etmeyle veya kaliteyle ilgili değildir - genel olarak ürün yönetimiyle ilgilidir, değil mi?
anastasia: İçermek. Kalite Güvencesi belirli bir kişinin sorumlu olduğu bir disiplin değildir. Artık test etmede popüler bir yön var, adı verilen bir yaklaşım Çevik Test. Onun tanımı, bunun belirli bir dizi uygulamayı içeren teste yönelik bir ekip yaklaşımı olduğunu açıkça belirtiyor. Bu yaklaşımın uygulanmasından tüm ekip sorumludur, hatta ekipte bir testçinin bulunmasına bile gerek yoktur. Ekibin tamamı müşteriye değer sunmaya ve değerin müşteri beklentilerini karşılamasını sağlamaya odaklanmıştır.
— Görünüşe göre kalite, çevredeki tüm disiplinlerle kesişiyor ve etrafındaki her şeye bir çerçeve dayatıyor?
anastasia: Sağ. Kaliteli bir ürünü nasıl yaratmak istediğimizi düşündüğümüzde kalitenin çeşitli niteliklerini düşünmeye başlarız. Örneğin, müşterimizin ihtiyaç duyduğu özelliği gerçekten yapıp yapmadığımızı nasıl kontrol edebiliriz?
Bu tür testlerin devreye girdiği yer burasıdır: UAT (kullanıcı Kabul Testi). Ne yazık ki, Rusya'da nadiren uygulanıyor, ancak bazen SCRUM ekiplerinde son müşteriye yönelik bir demo olarak mevcut. Bu, yabancı şirketlerde oldukça yaygın bir test türüdür. İşlevselliği tüm müşterilere açmadan önce ilk olarak UAT yapıyoruz, yani ürünün gerçekten beklentileri karşılayıp karşılamadığını ve sıkıntıyı çözüp çözmediğini test eden ve hemen geri bildirimde bulunan son kullanıcıyı davet ediyoruz. Ancak bundan sonra diğer tüm istemcilere ölçeklendirme gerçekleşir.
Yani biz işe, son müşteriye odaklanıyoruz ama aynı zamanda teknolojiyi unutma. Ürünün kalitesi de büyük ölçüde teknolojiye bağlıdır. Kötü bir mimariye sahipsek özellikleri hızlı bir şekilde kullanıma sunamayız ve müşteri beklentilerini karşılayamayız. Ölçeklendirmeye çalışırken çok fazla hata olabilir veya yeniden düzenlemeye çalışırken bir şeyleri bozabiliriz. Bütün bunlar müşteri memnuniyetini etkileyecektir.
Bu açıdan bakıldığında mimari öyle olmalı ki, hızlı bir şekilde değişiklik yapmamızı sağlayacak ve her şeyi bozarız diye korkmamamızı sağlayacak temiz kod yazabiliriz. Böylece revizyon yinelemeleri birkaç aya yayılmaz çünkü elimizde çok fazla miras var ve uzun test aşamaları yapmamız gerekiyor.
— Toplamda geliştiriciler, mimarlar, ürün bilimcileri, ürün yöneticileri ve test uzmanlarının kendileri zaten işin içinde. Kalite güvence sürecine başka kimler katılıyor?
anastasia: Şimdi bu özelliği istemciye teslim ettiğimizi düşünelim. Açıkçası, ürünün kalitesinin üretim aşamasındayken bile izlenmesi gerekiyor. Bu aşamada bug olarak adlandırılan, belirgin olmayan senaryoların olduğu durumlar ortaya çıkabilir.
İlk soru, ürünü piyasaya sürdükten sonra bu hatalarla nasıl başa çıkacağız? Örneğin strese nasıl tepki veririz? Sayfanın yüklenmesi 30 saniyeden uzun sürerse müşteri pek memnun olmayacaktır.
İşte burada sömürü devreye giriyor ya da şimdi dedikleri gibi, DevOps. Aslında bunlar, ürünün üretim aşamasındayken çalıştırılmasından sorumlu olan kişilerdir. Buna çeşitli izleme türleri de dahildir. Testin bir alt türü bile var - üretimde test etme, bir şeyi piyasaya sürmeden önce test etmememize ve onu hemen üretimde test etmemize izin verdiğimizde. Bu, bir olaya hızlı bir şekilde müdahale etmenize, onu etkilemenize ve düzeltmenize olanak tanıyan altyapıyı organize etme açısından bir dizi önlemdir.
Altyapı da önemli. Çoğu zaman, bir test sırasında müşteriye vermek istediğimiz her şeye gerçekten sahip olduğumuzdan emin olmanın imkansız olduğu durumlar vardır. Bunu üretime aktarıyoruz ve bariz olmayan durumları yakalamaya başlıyoruz. Ve bunların hepsi, testteki altyapının üretimdeki altyapıya karşılık gelmemesi nedeniyle. Bu, yeni bir test türüne yol açar - altyapı testi. Bunlar çeşitli yapılandırmalar, ayarlar, veritabanı geçişi vb.'dir.
Bu durum şu soruyu gündeme getiriyor: Belki de ekibin altyapıyı kod olarak kullanması gerekiyor.
Altyapının ürünün kalitesini doğrudan etkilediğine inanıyorum.
Umarım konferansta gerçek vakayı içeren bir rapor olur. Kod olarak altyapının kaliteyi nasıl etkilediğini kendi deneyimlerinizle bize anlatmaya hazırsanız bize yazın. Kod olarak altyapı, tüm ayarların kontrol edilmesini ve başka türlü mümkün olmayan şeylerin test edilmesini kolaylaştırır. Bu nedenle kaliteli bir ürün geliştirme sürecinin içinde operasyon da yer almaktadır.
— Analitik ve dokümantasyona ne dersiniz?
anastasia: Bu daha çok kurumsal sistemler için geçerlidir. İşletme denilince akla hemen analist, sistem analisti gibi kişiler geliyor. Bunlara bazen teknik yazarlar da denir. Örneğin bir ay boyunca bir spesifikasyon yazma ve bunu tamamlama görevi alırlar.
Bu tür dokümantasyonun yazılmasının çok uzun geliştirme yinelemelerine ve uzun iyileştirme yinelemelerine yol açtığı defalarca kanıtlanmıştır, çünkü test süreci sırasında hatalar tanımlanır ve geri dönüşler başlar. Sonuç olarak, geliştirme maliyetlerini artıran birçok döngü var. Ayrıca bu durum güvenlik açıklarını da beraberinde getirebilir. Referans kodunu yazmış gibiyiz ama sonra mükemmel düşünülmüş mimariyi bozan değişiklikler yaptık.
Sonuçta pek de kaliteli olmayan bir ürün ortaya çıkıyor, çünkü mimaride yamalar zaten ortaya çıktı, bazı yerlerdeki kodlar testlerde yeterince kapsanmıyor, çünkü son teslim tarihleri doluyor, tüm hataların hızla kapatılması gerekiyor. Ve bunların hepsi, orijinal spesifikasyonun uygulanması gereken tüm noktaları dikkate almaması nedeniyle.
Geliştiriciler zararlı değildir ve bilerek hatalı kod yazmazlar.
Başlangıçta gerekli tüm noktaları kapsayan bir spesifikasyon üzerinde düşünmüş olsaydık, her şey tam olarak gerektiği gibi uygulanırdı. Ama bu bir ütopya.
100 sayfalık mükemmel bir spesifikasyon yazmak muhtemelen imkansızdır. Bu yüzden belge yazmanın alternatif yollarını düşünmemiz gerekiyor, spesifikasyonlar, geliştiricinin tam olarak ihtiyaç duyulan şeyi yapmasını sağlamaya bizi yaklaştıracak görevleri ayarlama.
Burada Agile'ın yaklaşımları akla geliyor; kabul kriterleri olan kullanıcı hikayeleri. Bu, küçük yinelemelerle gelişen ekipler için daha uygundur.
— Kullanılabilirlik testleri, ürün kullanılabilirliği ve tasarım hakkında ne düşünüyorsunuz?
anastasia: Bu çok önemli bir nokta çünkü ekipte tasarımcılar var. Çoğu zaman tasarımcılar, bir tasarım departmanı veya dış kaynaklı bir tasarımcı tarafından bir hizmet olarak kullanılır. Çoğu zaman tasarımcının ürün uzmanını dinlediği ve anladığını yaptığı durumlar vardır. Ancak yinelemeye başladığımızda, gerçekte yapılanın beklenen şey olmadığı ortaya çıkıyor: Tasarımcı bir şeyi unutmuş, davranışı tam olarak düşünmemiş çünkü o takımda değil, bağlamda ya da ön planda değil. -end geliştiricisi bu düzeni tam olarak anlamadı. Ön uç geliştiricinin tasarımı anlamasında bir sorun olduğu için birkaç yineleme gerekebilir.
Üstelik bir sorun daha var. Tasarım sistemleri artık popülerlik kazanıyor. Abartılıyorlar, ancak onlardan elde edilen faydalar tamamen açık değil.
Tasarım sistemlerinin bir yandan geliştirmeyi kolaylaştırdığı, diğer yandan da arayüze birçok kısıtlama getirdiği görüşüne rastlıyorum.
Sonuç olarak, müşterinin istediği özelliği değil, bizim için uygun olanı yapıyoruz çünkü zaten bunu yapabileceğimiz belirli küplerimiz var.
Bence bu, göz atmaya ve tasarımı kolaylaştırmaya çalışırken aslında müşterinin sıkıntılı bir noktasını çözüp çözmediğimizi merak etmeye değer bir konu.
— Kalite Güvencesi ile ilgili şaşırtıcı sayıda konu var. Rusya'da bunların hepsinin tartışılabileceği bir konferans var mı?
anastasia: Bu yıl 25. kez düzenlenecek olan ve SQA Günleri Kalite Güvence Konferansı olarak adlandırılan en eski test konferansı var. Temel olarak fonksiyonel test uzmanlarına yönelik araçlar ve spesifik test yaklaşımları tartışılmaktadır. Kural olarak, SQA Günlerindeki raporlar, karmaşık faaliyetleri değil, test uzmanlarının sorumluluk alanındaki belirli alanları derinlemesine inceler.
Bu, farklı araç ve yaklaşımların anlaşılmasına, veritabanlarının, API'lerin vb. nasıl test edileceğine çok yardımcı olur. Ancak aynı zamanda, bir yandan, daha iyi bir ürünün yaratılmasında sadece test etmekten daha fazlasını dahil etme motivasyonunu da sağlamaz. Öte yandan test uzmanları, ürünün küresel hedefi ve iş bileşeni hakkında düşünmek için sürece daha fazla dahil olmuyorlar.
Büyük bir departmanı yönetiyorum ve bir bütün olarak sektörün durumu hakkında gerçekten fikir veren çok sayıda röportaj yapıyorum. Kural olarak adamlarımız işletmelerde çalışıyor ve açık bir sorumluluk alanına sahipler. Yabancı projelerde çalışan meslektaşlar farklı test türleri kullanırlar: Yük testini, performans testini ve hatta bazen güvenlik testini kendileri yapabilirler çünkü ekibin ürünün kalitesini güvence altına almasına gerçekten yardımcı olurlar.
Rusya'daki adamların da sektörün fonksiyonel testlerle bitmediğini düşünmeye başlamalarını istiyorum.
— Bu amaçla kaliteyi ayrılmaz bir disiplin olarak ele alan yeni bir konferans olan QualityConf'u düzenliyoruz. Bize fikir hakkında daha fazla bilgi verin, konferansın ana amacı nedir?
anastasia: Kaliteli ürünler üretmeye ilgi duyan insanlardan oluşan bir topluluk oluşturmak istiyoruz. Kaliteyi artırmak için nelerin değiştirilmesi gerektiğine dair spesifik bir anlayışla gelip konferanstan sonra ayrılabilecekleri, raporları dinleyebilecekleri bir platform sunun.
Bugünlerde danışanlardan test ve kalite sorunları olduğunda ne yapılması gerektiği konusunda sık sık talep duyuyorum. Ekiplerle iletişim kurmaya başladığınızda sorunun test yapanlarda değil, sürecin nasıl yapılandırıldığında olduğunu görüyorsunuz. Örneğin geliştiriciler yalnızca kod yazmaktan sorumlu olduklarına inandıklarında, görevi teste devrettikleri anda sorumlulukları sona erer.
Kötü yazılmış, düşük kaliteli ve kötü mimariye sahip kodun proje için büyük sorunları tehdit ettiği gerçeğini herkes düşünmüyor. Hataların maliyetini, üretimde ortaya çıkan hataların şirket ve ekip için büyük maliyetlere yol açabileceğini düşünmüyorlar. Bunu düşünecek bir kültür yok. Konferansta dağıtmaya başlamamızı istiyorum.
Bunun bir yenilik olmadığını anlıyorum.Kalitenin 14 ilkesinin yazarı Edward Deming, geçen yüzyılda bir hatanın maliyeti hakkında yazmıştı. Bir disiplin olarak Kalite Güvencesi bu kitaba dayanmaktadır, ancak ne yazık ki modern gelişme bunu unutmaktadır.
— Testler ve araçlarla ilgili konulara doğrudan değinmeyi planlıyor musunuz?
anastasia: Araçlarla ilgili raporların olacağını kabul ediyorum. Şirketlerin ve ekiplerin ürünü etkileyebileceği oldukça evrensel araçlar var.
Tüm raporlar küresel olarak tek bir ortak misyon etrafında birleştirilecektir: Hedef kitleye bu yaklaşım, araç, yöntem, süreç, test türü yardımıyla ürünün kalitesini etkilediğimizi ve müşterinin ömrünü iyileştirdiğimizi anlatmak.
Bir araç uğruna mutlaka bir araçla ilgili rapor almayacağız. Programda yer alan tüm raporlar ortak bir hedefte birleştirilecektir.
— Bahsettiğiniz konularla, konferansın konuğu olarak kimi gördüğünüzle kim ilgilenecek?
anastasia: Projesinin, ürününün, sisteminin kaderini önemseyen geliştiriciler için raporlarımız olacak. Aynı şekilde test uzmanlarının ve bana öyle geliyor ki özellikle yöneticilerin ilgisini çekecek. Yönetici derken, karar veren, bir ürünün, sistemin, ekibin kaderini ve gelişimini etkileyebilen kişileri kastediyorum.
Bunlar bir ürünün veya sistemin kalitesinin nasıl artırılacağını merak eden insanlardır. Konferansımızda çeşitli önlemler hakkında bilgi sahibi olacaklar ve şu anda kendilerinde neyin yanlış olduğunu, nelerin değiştirilmesi gerektiğini anlayabilecekler.
Bence asıl kriter kaliteyle ilgili bir şeylerin yanlış olduğunu anlamak ve onu etkilemek istemek. Bunun ilk defa olacağını düşünen insanlara muhtemelen ulaşamayacağız.
— Bir bütün olarak sektörün sadece testlerden değil, kalite kültüründen de bahsetmeye hazır olduğunu düşünüyor musunuz?
anastasia: Sanırım olgunlaştım. Artık birçok şirket geleneksel Şelale yaklaşımından Agile'a doğru ilerliyor. Müşteri odaklılık var, ekiplerdeki insanlar gerçekten kaliteli bir ürünün nasıl yaratılacağını düşünmeye başlıyor. Kurumsal şirketler bile kaliteyi artırmaya yeniden odaklanıyor.
Toplulukta ortaya çıkan taleplerin sayısına bakılırsa artık zamanının geldiğine inanıyorum. Bunun geniş çaplı bir devrim olacağından elbette emin değilim ama bilinçte bu devrimin gerçekleşmesini isterim.
- Kabul! Kültürü aşılayacağız ve bilinci değiştireceğiz.
BT ürünlerinin yüksek kalitede geliştirilmesine ilişkin konferans düzenlenen 7 Haziran'da Moskova'da. Yüksek kaliteli bir ürünün hangi aşamalardan oluştuğunu biliyorsunuz, üretimdeki hatalarla başarılı bir şekilde mücadele ettiğimiz vakalar var, uygulamamızda popüler yöntemleri test ettik - deneyiminize ihtiyacımız var. onların 1 Mayıs'tan önce başvurularve Program Komitesi, konferansın genel bütünlüğü için temanın odaklanmasına yardımcı olacaktır.
Bağlanmak Kalite konularını ve konferansı tartıştığımız konferansa abone olun Program haberlerinden haberdar olmak için.
Kaynak: habr.com