it-swarm.asia

Neden geliştiricilerin kendi çalışmalarını test etmelerine izin verme / vermeme

Bir geliştiricinin, ürünün üretime geçmesinden önceki son adım olarak kendi çalışmasını test etmesine izin vermekle ilgili bazı argümanlar toplamak istiyorum, çünkü ne yazık ki, iş yerim bazen bunu yapıyor (bu son geldiğinde) , argüman çoğu insanın başka şeylerle çok meşgul olması ve başka bir kişinin programın bu bölümünü tanıması için zamana sahip olmamaya kaynıyordu - çok özel bir yazılım).

Bu durumda test planları var (her zaman olmasa da), ancak gerçekten son testi yaparken test edilen değişiklikleri yapmayan bir kişiyi yapmaktan çok memnunum. Bu yüzden, bir dahaki sefere bu tartışıldığında gündeme getirebileceğim iyi ve sağlam bir argüman listesi sağlayıp sağlayamayacağınızı soruyorum. Ya da karşı argümanlar sağlamak için, özellikle test edilecek resmi test senaryoları olduğunda bunun mükemmel olduğunu düşünüyorsanız.

82
pyvi

Diğerlerinin (ve kendinizin) belirttiği gibi, geliştiriciler kendi kodlarını birim olarak test etmelidir. Ancak bundan sonra, önemsiz olmayan herhangi bir ürün bağımsız kişiler (KG) ve/veya müşterinin kendisi tarafından da test edilmelidir.

Geliştiriciler normalde "bu iş nasıl yapılır?" geliştirici zihniyetiyle çalışır. İyi bir testçi "bunun nasıl kırılacağını?" - çok farklı bir zihniyet düşünüyor. Birim testi ve TDD, geliştiricilere şapkaları bir dereceye kadar değiştirmeyi öğretir, ancak buna güvenmemelisiniz. Dahası, diğerlerinin de belirttiği gibi, her zaman yanlış anlama gereksinimi olasılığı vardır. Bu nedenle son kabul testleri, müşteriye mümkün olduğunca yakın biri tarafından yapılmalıdır.

103
Péter Török

Geliştirici kodlarının nasıl çalıştığını bilir ve kodlarını bu bilgiye göre test etme alışkanlığına girer.

Geliştirici, 'nasıl çalışması gerektiği' yerine kendilerini 'nasıl çalışır' zihniyetinden çıkarmakta zorlanacak.

Bu nedenle, programı test etmek için yüksek derecede tarafsızlığa sahip birisini elde etmek daha iyidir, yani KG veya Test Mühendisleri

127
John Shaft

Testçiler Testi kırmak için, Basit. Gösteri tıpalarını gerçekten bulmak için bu tür önyargılara ihtiyaç var.

30
Aditya P

Geliştiriciler işlerini test etmelidir ZORUNLU. Zımni bir sorumluluktur.

Açıklamalarınızdan yola çıkarak testleri yapmaya adanmış bir ekibiniz olmadığını varsayıyorum. Ancak, geliştiriciler kodlarını kodladıkları şekilde test etme eğiliminde olduklarından, test için özel bir ekibe sahip olmak gerçekten yardımcı olacaktır. Bu, bir tür kalite güvence ekibiniz olduğunda, geliştiricilerin sorumluluğu olarak teste başlayabileceğiniz anlamına gelmez.

Geliştiriciler genellikle böcek yakalamak için büyük delikli ağları kullanırlar. Sonuç olarak, daha küçük böcekler kaçar.

15
setzamora

Çünkü geliştiriciler kendi kodlarını kırmaya çalışma konusunda iyi değiller. Akılları, veri girişi ve uygulama ile etkileşimin doğru yolunu izler. Birçok hata, sistemle normal bir adam gibi etkileşimin sonucudur. Geliştiriciler normal kullanıcı değildir. Profesyonel kullanıcılar.

15
Saeed Neamati

Özel bir test ekibine sahip olmanın birkaç iyi nedeni vardır. Birincisi, yukarıda belirtildiği gibi, geliştiriciler kodlarının çalıştığını test etmede çok iyidir, ancak bunu kırmaz.

Ayrıca, dediğiniz gibi, bir geliştirici ne yazdıklarını bilir, ancak test ekipleri ne yazılması gerektiğini bilir. Bazen bu iki kavram uyuşmuyor. Test ekibinin işlerinden biri, yazılımın gereksinimleri karşıladığından emin olmaktır. Çoğu durumda, bir geliştirici sistemin sadece birkaç bölümünü çok iyi bilir, ancak KG ekibi her şeyi bilir.

Bu, bir sonraki nedene yol açar, test ekipleri tam entegrasyon testi yapar. Az önce yazdığınız kod parçası kendi başına iyi çalışabilir, ancak bilmediğiniz diğer işlevleri bozabilir.

Bir KG ekibiyle ve onsuz çalıştıktan sonra, yaptıkları işi% 100 takdir ettiğimi söyleyebilirim ve yazılım ekibinin değerli bir parçası olduklarını söyleyeceğim. Bir KG ekibiniz olduğunda, kodunuzu yayınlamayı çok daha kolay hale getirir, b/c kapsamlı bir şekilde test edildiğini bilirsiniz ve bu da daha az 3am çağrıları alacağınız anlamına gelir.

10
Tyanna

Geliştiriciler kendi kodlarını birim olarak test etmelidir.

Bağımsız testçiler sadece kırılmayı test etmekle kalmaz, aynı zamanda geliştiricilerin kodlama sırasında yaptığı belirsiz ve tanımsız varsayımları test ederler.

8
Gilbert Le Blanc

Herhangi bir değişiklik yapmadan ve kodun çalıştığından memnun kalmadan önce geliştiricinin bazı başlangıç ​​testleri yapmasını beklerim. Daha sonra geliştiricinin test senaryolarına sahip oldukları herhangi bir 'beyaz kutu' bilgisini beslemesini beklerim. Örneğin, kodun etkilenmiş olabilecek diğer alanlarını ayrıntılı olarak açıklar.

Kendi kodlarını test eden geliştiricilere ana itiraz, sadece bir bakış açısını test etmenizdir. Geliştirici spesifikasyonu okumuş ve yorumlamıştır. Umarım şartname açık, eksiksiz ve açıktır, ancak bu her zaman böyle değildir. Geliştirici spesifikasyonun bir bölümünü yanlış anlamış olabilir. Eğer kendi kodlarını test ederlerse, fonksiyon bekledikleri gibi çalışacağını farketmezler.

Farklı insanlar ayrıca bir ürünü farklı şekillerde kullanma ve sonuç olarak kod boyunca farklı yollar kullanma eğiliminde olacaktır. Bir geliştirici, kodun kendileri için çalışmasını sağlayacak, ancak başka bir test cihazının bulabileceği bir Edge durumu düşünmemiş olabilir.

7
Luke Graham

Geliştiriciler yapmalı kendi çalışmalarını test etmelidir. Geliştiricilere izin vermek Test edilmemiş çalışmaları bir QA ekibine veya geliştirici meslektaşlarına zorlamak Gerçekten Kötü Bir Fikirdir. Geliştiricilerin ve testçilerin zamanını boşa harcar ve ilişkileri mahveder.

Ancak, bu her zaman yeterli değildir. Geliştiricilerin, sistem boyunca mutlu bir yolu izlemeleri veya geliştirme boyunca tekrar tekrar maruz kaldıkları bazı aptallıklara kör olmaları muhtemeldir.

Başka bir nokta, şartname ve dağıtım arasında bir dizi iletişim katmanının olabileceğidir. Bu, son konuşlandırılabilirlik üzerinde bir Çinli Fısıltılar etkisine yol açabilir. Gereksinimi veya hata raporu testlerini tanımlayan kişi istediği gibi çalışıp çalışmadığını test etmek en iyisidir.

5
Paul Butcher

Bir geliştirici olarak kendi kodunuzdan siz sorumlusunuz, test etmelisiniz. Does the feature work as expected? Cevabınız evet ise, işiniz bitti demektir.

Neden test senaryoları yapmıyorsunuz?

  1. Bulunan hatalar sizin (veya iş arkadaşlarınızın) tarafından yazıldığı için öznel sizsiniz.
  2. Sen de şirkete vaka testleri çalıştırmak için pahalı vardır. (Umuyorum).
3

Tipik olarak, geliştiriciler, çoğu durumda, belirli özel durumlar dışında kodu kullanan kişiler olmayacaktır. Dolayısıyla, bir üretim sistemine geçmeden önceki son test adımı kullanıcı kabul testi, UAT olmalıdır. Genellikle paketin ne yapmasını beklediklerini daha iyi bilmektedirler. Ve genellikle günlük olarak kullanmayan birine tanıdık olmayan giriş akışları ile işleri kırma konusunda daha yeteneklidir.

Proje planlarınız kullanıcı testine uygun değil mi? Kullanıcıları test ettirirseniz, dünyamda kötü bir şey olmayan uygulama sonrası daha erken hataları yakalayabilirsiniz.

3
temptar

Geliştiriciler kendi kodlarını test etmemelidir, çünkü bu kendi çocuğunuzun sanatını yargılamaya benzer. Her iki şekilde de size güzel görünecek ve kusurları belirtmek için gerçekten bir profesyonele ihtiyacınız var. Ünite testleri ise çocuğunuzun kurşunla boyamaya çalışmadığından emin olmaya benzer.

GERÇEKTEN QA kiralamak istemiyorsanız, geliştiricilerin diğer geliştiriciler için test kodu yazmasını sağlayın. Bu iyi bir ilk adımdır - yakında geliştiricilerin KG kaynakları istediklerini göreceksiniz, çünkü zamanlarının çoğu CR'ye ek olarak diğerlerinin kodlarını test etmek için harcanmaktadır.

Sadece geliştiriciler kodlarını korumakla kalmaz, belirli bir vakayı fark etmezlerse veya bir özelliği geliştirdikleri şekilde yanlış yorumlamazlarsa, kodlarını test ederken bu durumları kaçıracaklardır.

Test etme teknikleri ve becerileri de çok farklıdır.

Bir test ekibi tarafından yapılan çoğu test işlevseldir (bir ürünün bir spesifikasyona göre çalıştığı) ve kara kutu (test ekibi bir uygulamanın iç işleyişini görmeyecektir). Fonksiyonel test cihazlarının işlerin nasıl çalıştığı ile ilgilenmesi gerekmez, sadece çalışıp çalışmadığına odaklanmaları gerekir.

3
StuperUser

Bir programcı test ederken "Miktar" etiketli bir metin kutusu görür ve "1" girer. Son derece deneyimli bir programcı daha sonra "2" değerine sahip bir takip testi yapacaktır.

Bir kullanıcı "Miktar" etiketli bir metin kutusu görür ve "~~ unicorns ROX !!! ~~" girer. Deneyimli bir kullanıcı da "-12 1/2" dener.

Umarım, bir test kullanıcısı programcıya kullanıcının bunları yaparken ne deneyimleyeceği konusunda uyarmak için bir yerde olacaktır.

2

Deneyimlerime göre, en azından küçük kuruluşumda, son kullanıcının test etmesi gerekiyor. Aldığımız hemen hemen her proje, gerekli tüm bilgileri sağlayamıyor ve her zaman belirli ayrıntıları dışarıda bırakıyorlar. Geliştiricinin her zaman bir test dezavantajı var, çünkü kullanıcının işini nasıl yapacağını bilmiyor, bu yüzden yazılımın kendisine verilen bilgilere göre çalıştığını bilse de, son kullanıcıya yardımcı olup olmayacağını bilmiyor işlerini yapmak.

2
Kratz

Geliştiriciler gereksinimleri yanlış okuyor ve yanlış yorumluyor ve gereksinimlerden sorumlu olanlar genellikle kilit şeyleri belirtemiyorlar. Geliştirici testleri dışında hiç kimse, canlı yayına geçmeden önce hiç kimse bu bağlantı kesimlerini bulamaz. Geliştiriciler test ettiğinde, nasıl çalışması gerektiği hakkında çok şey biliyorlar ve kullanıcıların deneyebileceği aptalca şeyleri denemiyorlar. Devs ayrıca testlerini, gerçekten ne anlama geldiğini değil, çoğu kez gereksinimi kendi yorumlarına dayanarak yazmaktadır. Bu yüzden testler geçiyor ama şart karşılanmadı. Farklı bir kişi testine sahip olduğunuzda, o kişi gereksinimler hakkında farklı bir fikre sahip olabilir ve sıklıkla, reuirement'in iki farklı kişinin onu ne kadar farklı yorumladığıyla zayıf bir şekilde ifade edildiği yerleri bulursunuz. Bunu testte bulmak, canlı yayına geçmekten çok daha iyi.

2
HLGEM

Geliştirici ilk testi yapmalıdır, böylece kodladığımız parçanın, sahip olduğumuz gereksinimlere göre, çalışmasının beklenen şekilde çalışacağını bilelim. Bu yüzden normal testler yaptık ve yazdığımız kod için Birim Testleri yazdık.

Bir sonraki adım, kodların yazılması sırasında geliştiricilerin ne görmediğini bulmak için QA'nın işi. Bir geliştirici daha yüksek bir seviyede düşünür ancak kullanıcı aynı düzeyde düşünmeyebilir. Geliştirici parçasını test ederken ve bir metin kutusuna bir metin girmek zorunda kaldığında, kullanıcının her zaman tam bir dize girebileceğini düşünür. Kullanıcı da bunu yapabilir, ancak metinde% & $ ^ gibi özel bir karakter girdiğinde ve uygulamayı bozduğunda rastgele bir şekilde son kullanıcıda iyi görünmüyor olabilir. Bir geliştirici, bu şekilde düşünmek için eğitilmediğinden, olabilecek tüm olasılıkları düşünemez ve düşünmez. Bir QA (test cihazı) söz konusu olduğunda, her zaman kullanıcının bu uygulamayı kırmak için neler yapabileceğini düşünürler ve kitaptaki her aptal şeyi denerler, kullanıcılar aptal değildir, ancak hiçbir şeyi şansa bırakmamalıyız.

Şimdi de aynı anda birden fazla parçanın yapıldığını ve her ikisinin de üretime geçeceğini anlamalıyız. Geliştirici sadece parçasını test edebilir ve iyi çalıştığını düşünebilir, ancak itilen tüm parçalar için genel regresyon testinin yapılması ve iki farklı parçanın kombinasyonunun uygulamayı bozabileceğini ve iyi görünmüyor. Ayrıca, yük test senaryolarını ve test cihazlarının daha fazla tanıdığı diğer şeyleri de dikkate almalıyız.

Son olarak, yaptığımız parçanın beklenen şey olup olmadığını görmek için UAT'den (Kullanıcı Kabul Testi) geçmeliyiz. Genellikle gereksinimler BA'lardan geçmesine rağmen, son kişi tam olarak nasıl göründüğünü tam olarak bilemeyebilir ve bekledikleri gibi olmadığını düşünebilir veya daha iyi görünmesi için başka bir şey eklemek isteyebilir veya herhangi bir nedenle parça zaten mevcut işlevsellik ile gitmek olmaz düşündüm gibi.

Yukarıda açıklandığı gibi, bunlar çok önemlidir ve yalnızca geliştirici tarafından yapılamaz ve uygulamanın düzgün çalışması için kesinlikle gereklidir. Yönetim bunun muhafazakar bir yaklaşım olduğunu söyleyebilir ancak daha iyi bir yaklaşımdır. Yukarıda belirtilenlere bazı ince ayarlar yapabiliriz, ancak bütün olarak kaçınamayız.

2
Amar Jarubula

Yukarıdaki yorumlar büyük puanlar vermektedir.

Daha önce bahsedilmeyen bir ek, ayrı bir ayrı test koduna sahip olmanın, gereksinimler üzerinde ve sistemin bunları doğru bir şekilde uygulayıp uygulamadığı üzerinde ek bir kontrol görevi görmesidir.

Gereksinimler ve belgeler mükemmel değildir ve genellikle uygulama, geliştiricinin gereksinimlerin yorumlanmasının bir sonucudur.

Test ayrı bir kişi tarafından yapıldığında, test planını oluştururken ve testleri gerçekleştirirken kendi gereksinimlerini de yorumlarlar.

Test faaliyetleri geliştirme faaliyetlerinden bağımsız olarak yapıldığında ve her ikisinin de “katılıyorum” çıktıları, sistemin doğru olduğuna ve gereksinimlerin orijinal amacına tam olarak uyduğuna dair ek bir onay sağlar.

2
tschaible

Bunun bir nedeni, geliştiricilerin de kendi kodlarına yakın olmalarıdır. Tuhaf olduğunu biliyorlar, biraz garip davranışlar. Çok iyi bildikleri küçük özdeyişleri test etme . Bu konuda yeterince objektif değiller. Test ekipleri kara kutu gibi davranırlar. Düzinelerce veya yüzlerce test senaryosunun matrislerini yazarlar ve kodun ne yapacağını görmek için yöntemsel olarak içinden geçerler. Genellikle geliştirme ekibinin asla hayal kurmayacağı senaryolar bulurlar.

Başka bir neden zaman. Aşamalar halinde inşa edilen büyük projeler için, geliştirme ekibi Aşama 1'i inşa edecektir. Ardından testçiler Aşama 2 inşa edilirken test edecek ve Aşama 1'in kusurları düzeltilecektir. Bu, tüm aşamalar için devam eder, bu nedenle test edilen aşama, inşa edilen önceki aşamadır.

İster beğenip beğenmeseniz de kodu bilmeyen biri tarafından test edilir. Soru, birisinin müşteriniz olmasını isteyip istemediğinizdir.

1
Karl Bielefeldt

İnsan, insan olarak, bilişsel önyargıdan muzdarip olma eğilimindedir - neredeyse aynı iki senaryoda yargılarının farklılaştığı, sadece değişen birkaç şey nedeniyle - 8 yıllık gelişimde fark ettiğim bir şey, bir geliştiricinin bir meslektaşının yazdığı kodun aksine, kendi kodunu test etmekle karşı karşıyadır, kendi kodunda yapılan test çok daha kötü bir kaliteye sahiptir.

Bu, geliştiricinin doğrudan hatalı olduğunu söylemek değildir - beyni, haklarına inandıkları gerçeğini güçlendirmek için yazdığı önyargıyı kullanacak ve sadece bir geliştirici yerine temel kontroller yapacak başka birinin koduna bakıyor, çok daha kapsamlı kontroller yapacak.

İki farklı uçağın aynı hava sahasını aynı anda işgal etmesini önlemek için bilişsel önyargıyı önlemek veya hava trafik kontrolündeki bilgisayarlı sistemler gibi yaygın olarak "İnsan Faktörü" olarak bilinen prosedürün uygulandığı binlerce örnek var. zaman, tıbbi prosedürler koymak böylece birden fazla doktor teşhis etmek zorunda.

BT endüstrisinin daha profesyonel bir tutuma yönelmesi ve kendi kodunuzun test edilmesini önlemek için prosedürleri uygulamaya koyma zamanı geldi.

1
Surgical Coder

Harika bir soru. Durumunuzda, bazen test senaryoları vardır ve yazılım, ürün üzerinde bir acemi edinmenin pratik olmadığı kadar karmaşık görünmektedir. Ayrıca, yapılan testin üretim öncesi son test olduğunu da söylüyorsunuz

Geliştiricinin son testi yapmasının nedeni olabilir

  • Yeterli başka test kapsamı var ... Birim testleri var, bir entegrasyon test ortamı var ve kullanılıyor, kullanıcı arayüzü testi, keşif testi vb. Gerçekleştirildi. Sonra son bir test, bir final testinden daha az titiz bir kabul ölçütüdür " hızlıca gözden geçirme"
  • Profesyonel bir SQA/Test Cihazı tarafından yazılan bir dizi test örneği, birisinin (bir geliştiricinin) açıkça takip edebileceği/izlemesi gerektiği
  • Özelliğin/ürünün/modülün arızalanma riski aksi takdirde düşük seviyelere indirilmiştir (profesyonelin yüksek riskli alanları test etmesine ve "çaylak" düşük riski test etmesine izin ver)
  • İş durumunun gerçeği, potansiyel kusurları olan bir ürünü piyasaya sürmenin, piyasaya sürmeyi geciktirmekten daha iyi olmasıdır.
  • Söz konusu geliştirici aslında çok nitelikli bir test edicidir ve zihinsel olarak rollerde değişiklik yapabilir.
  • Değişiklik, müşterinin sitesi kapatıldığında veya sistemin çevrimdışı olması nedeniyle geliri kaybettiğinde geliştirici tarafından alanda yapılan bir hata düzeltmesidir (ofise geri getirilecek ve ASAP kontrollü bir sürümünde test edilecek/yayınlanacak bir yama )

Bir geliştiricinin testi yapmama nedenleri

  • Başka herhangi bir şey

Genel olarak, gerçek çözüme saldırmanın doğru yolunda olduğunuz görülüyor - SQA uzmanının Test Durumları oluşturmasını sağlayın ...

Not: Genellikle Geliştiricilerin testi yapmasına izin veriyorum, ancak ilk kurşun noktasının var olduğundan eminim ....

1
Al Biglan
  • Herkes test etmelidir - Geliştiriciler test kodu, KG test fonksiyonu, Pazarlama testi mesajlaşma. Bu şekilde herkes aynı felsefeleri paylaşır ve savaşın yarısı olan test etrafında dil.

  • Testler rutin bakımdır ve genellikle karşılaştırmak için benzerlikler kullan. Örneğin araba yağı benzetmesini değiştirir. Yağınızı asla 'değiştirmek' zorunda değilsiniz. Ama yine de düzenli olarak yapıyorsun. Dişlerini fırçalamak için de aynı şey geçerli. Onları günlük olarak sürdürmenizin bir nedeni var - 'bugün'ü kırmayacaklar, hepsi yarın ve gelecek günler ve yatırım yapmak.

  • Herkes test etmek için sorumluluğu paylaşmalı olmalıdır. Bir KG ekibi önemlidir, ancak "testi" yalnızca KG ekibinin yaptığı bir şey olarak yapmak, onu ürün geliştirme ve iş akışına entegre etmediği "ayrı" bir etkinlik haline getirir ki bu iyi bir şey değildir.

  • Üretimde bir şey kırıldığında iki şey yapın:

    1. İlk yorum olarak "hmm, bunun için bir testimiz var mı ".
    2. Herhangi bir düzeltme yapın sorun için testleri , düzeltmeden önce çoğaltın.
1
Michael Durrant

Testin üretime geçmeden önceki son adım olarak bir geliştiricinin kendi işini test etmesine izin vermek için bazı argümanlar toplamak istiyorum, çünkü ne yazık ki, iş yerim bazen bunu yapıyor (bu son geldiğinde) , argüman çoğu insanın başka şeylerle çok meşgul olması ve başka bir kişinin programın bu bölümünü tanıması için zamana sahip olmamaya kaynıyordu - çok özel bir yazılım).

Testler bir geliştirici için isteğe bağlı değildir. Bir geliştirici yazdığı kodu test etmek zorundadır. Görevin başarıyla yerine getirildiğinden başka nasıl emin olabilir? Ya bir tür otomatik testler (unittests) yazmalı ya da kontrol etmeyi yapmalısınız "makine ne yapmak istediğimi yapıyor" manuall (GUI'yi kullanarak, komut satırındaki komutu veya her neyse).

Bundan sonra test edilen her şey, diğer insanlar (iş arkadaşları, KG, ...) tarafından "sadece" ek testtir. Bir geliştiricinin doğrudan test etmesine alternatif yoktur. Bir geliştiricinin yazdığı kodu/özelliği test etmek zorunda olmadığını (hatta test etmesine bile izin verilmediğini) söyleyen herkes, yazılımın nasıl geliştirildiğine dair sıfır anlayışa sahiptir.

1
perdian

Şirketimde oldukça karmaşık finansal uygulamalar geliştiriyoruz. Genel politikamız, geliştiricinin hiçbir teknik hatanın ortaya çıkmamasını sağlamasıdır. Temel olarak, kullanıcının kaynakları göz önüne alındığında, onu kırmak için her şeyi deneyin. Bir çalışma zamanı hatası bulamadığınızda, test için BA'lara gönderin. İş gereksinimlerini tükenme noktasına kadar test etmede kaybolan birkaç geliştiricimiz var, ancak sadece tüm testler onların sorumluluğu olmadığı için. Açıkça görülebilen bazı göze çarpan hatalar olmadıkça, çıktıyı anlamak için ödeme yapılan kişilere iletiriz. Ayrıca, kullanıcıların sonuçları doğrulamada gerçek bir rolü olmalıdır. Bir perakende mağazasındaki satış memuru sizin için kıyafetleri denemez, sadece doğru boyutta kıyafet bulmak gibi "teknik detaylar" konusunda size yardımcı olurlar.

0
Morgan Herlocker

Bir sorun, geliştiricilerin kendi kodlarını kırmak için çok az teşvikleri var - az insan kendi işlerinde kusurları aramaya istekli veya hata yapmaya hazır. Ayrı bir ekibe sahip olmak işlerin bozulmasını sağlar.

0
Wyatt Barnett