Programcılar test yapanların test tasarlamalarına yardımcı olmalı mıdır?

Programcılar testlerin test tasarlamalarına ne kadar yardımcı olmalıdır?

Hiç yardımcı olmaları gerektiğini düşünmüyorum. Benim endişem şuydu ki, test yapanların kendi kodları için test tasarlamalarına yardımcı olurlarsa, test edenlere bu önyargıları ve bu kodla ilgili kör noktalar bulaştıracaklardır.

Test uzmanlarının testlerini yapabilmeleri için gereken bilgileri vermek için gereksinimlerin yeterli olması gerektiğini hissediyorum. Programcıların endişe verici bulduğu uygulamanın bir kısmı varsa, o parçayı test etmek için birim testleri uygulamak veya hatta o parçayı test etmek için kendi gayri resmi sistem testlerini yapmak onların görevidir.

Tanıdığım herkes buna katılmıyor (ve bazı noktalarını belli bir ölçüde anlıyorum). Diğerleri bunun hakkında ne düşünüyor? Bu literatürde herhangi bir yerde tartışılıyor mu?

Katılıyorum. Programcılar, test uzmanlarının işlevsel özellikleri anlamalarına, araştırma için kaynak bulmalarına yardımcı olabilir ancak test uzmanlarının teste nasıl yaklaşacakları konusunda kendi fikirleriyle kirletmemeleri gerekir.

Bence geliştiriciler ve test uzmanları KG alanında barış içinde bir arada var olacaklar. :)

Daha spesifik olarak, geliştiricilerin ilk test seviyesinden - birim testler ve temel entegrasyon testlerinden sorumlu olmaları gerektiğini düşünüyorum.

Herhangi bir uygulama detayından tamamen bağımsız olan gereksinimlere dayalı kabul testleri oluşturmak test uzmanlarına bağlıdır (buna genellikle 'kara kutu testi' denir). Test kullanıcılarının ve geliştiricilerin gereksinimleri nasıl anlamalarında bir tutarsızlık varsa, proje yöneticisi (varsa) veya herkesin aynı sayfanın tasarım aşamasında aynı sayfada olduğundan emin olunması gereken bir sorundur.

Bence hem test etme hem de geliştirme işbirliği çabalarıdır, bu yüzden elbette (IMO), geliştiriciler test kullanıcılarına test fikirleri vermelidir. Onları etkilediğini veya test kullanıcılarını lekelediğini sanmıyorum. Test cihazı, elbette, bu testleri diğer birçok test yaklaşımıyla geliştirmelidir.

Ayrıca geliştiricilere yardım eden büyük bir test hayranıyım - Tasarım fikirlerini geliştiricilerle beyin fırtınası yaptım ve kariyerimde birçok kez hataları düzeltmek (ve hataları ve önerilen düzeltmeleri işaret etmek) için eşleştirdim ve düşünmüyorum ' bir geliştirici testçi cooties ile lekeledi.

İşbirlikçi bir çaba olarak görmüyorsanız, geliştiriciden test etmek için "duvarın üzerinden atılmış" kodunuz olacaktır ve daha düşük kaliteye sahip olursunuz. Bu benim dünyamdaki gerçek, ama (tabii ki) ymmv.

Gördüğüm gibi, kodumu test etmek QA'nın işi değil. Testçinin işi, kodumun bu görev için tüm gereksinimleri karşıladığından emin olmaktır.

KG'ye bir şey ilettiğimde, kodumun ayrıntılarını değil, yaptığım görevi bildiğinden emin olurum. KG'ye asla içinde 'kemik başı' böcekleri olan hiçbir şey geçirmem. Bu benim zamanımı, zamanlarını ... ve hemen hemen herkesin zamanını boşa harcıyor.

Son işimde başından beri KG vardı. Gereksinim toplama oturumlarına, proje toplantılarına ve tasarım toplantılarına da oturdu. Dinlediler ve sorular sordular ve geliştiriciler kod yazarken test planlarını yazıyorlardı. Harika çalıştı ve biz muhtemelen kaymış olurdu birçok sorun yakaladı.

Bence burada tamamen yanlışsın. Bir test kullanıcısı ve geliştiriciyim ve geliştiricilerin yüksek riskli veya kırılgan oldukları düşünülen alanlarda rehberlik yapmaktan büyük ölçüde faydalandım; bir geliştirici olarak, testçilerin derinlemesine araştırmadığım sorunları bulmasını istiyorum.

Kodunuz ham kanalizasyon olmadıkça "kirlilik" olmamıştır ve bu tamamen farklı bir nedenden ötürü olacaktır.

Gereksinimler, bir QA uzmanının ilgileneceği teknik sorunları iletmek için korkunç bir iş çıkarır, çünkü en iyi ihtimalle sadece iş analistlerinin yakalamayı başardıkları şeyi incelerler. İyi geliştiriciler kodlarının "mutlu yol" etrafında optimize edildiğinin farkında olacaklar ve neyi dikkate alınmadıklarını bilmek isteyeceklerdir. En azından neyin yanlış gidebileceği ve QA'nın hangi alanları araştırmasını istedikleri hakkında bir sezgileri olacak. Ayrıca, tasarımlarına dayanarak belirli bir özellik etrafında risk için büyük resmin ne olduğunu da biliyorlar.

Test ekibinin geliştirme ekibinin rehberliği olmadığı için, bazen iyi hata raporları üreten, ancak daha iyi işbirliği ile önlenebilecek yüksek riskli kod yollarını ve daha büyük sorunları tamamen kullanmayan yanlış bir yaklaşım benimsedim. geliştirme ekibi ile, müşterilerine sevk.

Bir testçi kesinlikle geliştiricinin önemli olduğunu söylediklerini test etmekle sınırlı olmamakla birlikte, geliştiricilerin kodla ilgili endişelerinin ne olduğunu öğrenerek zarar görmezler. Bazen, uygulama bilgilerine dayanarak yaklaşımlarına ince ayar yapabilirler. Sadece bir test cihazı özellikle kısa görüşlüyse, geliştiricinin risklerin nihai kelime olarak ne olduğu hakkındaki görüşünü dikkate alacaktır; geliştiricinin düşük risk olarak tanımladığı şeyleri tamamen kapatmazlar, ancak daha yüksek müşteri etkisi olabilecek şeylere daha fazla çaba harcarlar.

KG ekibinin, bir sistemin gereksinim toplayıcılarından veya geliştiricilerinden daha büyük birleşik test kapsamına sahip alanları görmesi muhtemeldir, ancak tasarımın farkındalığından yararlanan daha ince bir kırılganlığa sahip sistemin bileşenlerinden haberdar olmayabilirler. veya sistemin uygulanması.

Deneyimlerime göre, KG ve Geliştirme arasındaki işbirliği daha kaliteli ürünler üretiyor. Asla sadece bir kara kutu teslim etmenizi tavsiye etmem.

Bir testçi olarak, programcılara test senaryoları öneren (ancak bu sadece test senaryolarına bağlı kalacağım anlamına gelmez) veya uygulama ayrıntılarını açıklayan hiçbir itirazım yok. Bazen birisinin "Bu parçanın riskli olabileceğini düşünüyorum, bu parçayı oldukça iyi test ettiyseniz gerçekten çok isterim" demesi gerçekten yararlı olabilir. Uygulama detaylarından bazılarını bilmek, başarısız olacağını düşündüğüm testleri seçmek için yılların deneyimini uygulamama yardımcı oluyor. Bazen sadece kısa bir söz, birkaç testin öncelik listeme yaklaştığını anlar.

Beni lekelendiriyor mu? Test edicimin saflığını korumak için gayretle çabalayan programcıların fikriyle gıdıklanıyorum, ama gerçekten - hayır, bu bir efsane. Daha fazla bilgi genellikle benim için daha fazla soruya neden olur, daha az değil. Zihinsel bir şey sanırım - böcek bulamıyorum çünkü cahilim, sorunları buluyorum çünkü şüphesiz, güvenilmez bir şeyim, sadece güven duymak için çok inatçı olan bir şüpheliyim. Test ettiğim her sistemde, daha fazla sorun bulduğumu ve daha "ilginç" bulduğumu fark ettim, daha derinden anlamaya başladım.

Test planlarını gözden geçirmeyi ve KG'nin düşünmemiş olabileceği ek test senaryoları önermeyi seviyorum. Bunun "testçileri kendi önyargılarıma nasıl bulaştıracağından" emin değilim.

Kendimi bu garip pozisyonda buldum ve daha sonra KG personelinde kısa olduğumuz için Selenium'da test senaryoları uygulamam ve yazmam gerekiyor. Test odaklı geliştirmenin son derece yararlı olacağına inanıyorum, ancak henüz mağazamda uyarlanmadı.

Yazma testleri yararlı bulduğum bir şey, testler yazarken hata bulmak olduğunu. Daha sağlam bir kod yazmama yardımcı olmak için farklı bir bakış açısıyla düşünüyorum. Ancak test kapsamının sınırlı olabileceği doğrudur. Bu durumda, KG'ler her zaman neyi kapsamak istediklerini bize bildirebilir. Ya da hataları gördüğümüzde pasif olarak daha fazla test ekleyebiliriz.

QA yapıyorum ve kodumuzu nasıl kullanacağını bilen çoğu alanın aksine, herhangi bir programlama dili öğrenmekten çok daha zor. Bu yüzden geliştiricilere, yepyeni whizzbang özellikleri için test senaryoları vermeleri için güveniyoruz, çünkü nasıl yapılacağını bilemeyiz. Her halükarda KG problemleri, yeni özelliklerin orijinal testinden ziyade gerilemeleri ve kırılan şeyleri yakalamak için daha fazladır. Her durumda sonuç karmaşık bir hesaplama olduğunda, doğru cevabın ne olduğunu ve yanlış cevabın ne olduğunu veya anormal bir sonlandırma iyi ya da kötü bir şey olsa bile bilmek zordur.

Her durumda, bir geliştirici, dürüstse, muhtemelen bebeklerinin güvenlik açıklarından bir şey biliyordur. Muhtemelen hangi parametre değerlerini biliyor, farklı bir algoritma veya bir tablo aramasındaki veya başka bir alandaki alanları seçmek zorunda. Zorlu testler konusunda samimi ise, kodun çoğunu kapsayan makul boyutta bir test paketi üretebilmesi gerektiğini bilir.