# Programcılar ve Test Uzmanları İşbirliği Yaptığında

Testçiler ve programcılar işbirliği yapmaya başladığında sihirli bir şey olur. Hata izleme sistemi aracılığıyla hataları ileri geri göndermek için daha az zaman harcanır. Bir şeyin gerçekten bir hata mı yoksa yeni bir özellik mi olduğunu anlamaya çalışmak için daha az zaman harcanır ve müşteri beklentilerini karşılamak için iyi bir yazılım geliştirmek için daha fazla zaman harcanır. Kodlama başlamadan önce işbirliğine başlamak için birçok fırsat vardır.

Test kullanıcıları, Fit (Framework for Integrated Test - Entegre Test için Çerçeve) gibi araçlarla müşterilerin kendi alanlarının dilini kullanarak kabul testleri yazmasına ve otomatikleştirmesine yardımcı olabilir. Bu testler programcılara kodlama başlamadan önce verildiğinde, ekip Kabul Testine Dayalı Geliştirme (Acceptance Test Driven Development - ATDD) uyguluyor. Programcılar testleri çalıştırmak için fikstürleri yazar ve ardından testleri geçmek için kod yazar. Bu testler daha sonra regresyon paketinin bir parçası haline gelir. Bu işbirliği gerçekleştiğinde, işlevsel testler erken tamamlanır ve uç koşullarda veya daha büyük resmin iş akışları aracılığıyla keşif testleri için zaman tanır.

Bir adım daha ileri götürebiliriz. Bir testçi olarak, test fikirlerimin çoğunu programcılar yeni bir özelliği kodlamaya başlamadan önce sağlayabilirim. Programcılara herhangi bir önerileri olup olmadığını sorduğumda, neredeyse her zaman bana daha iyi test kapsamı konusunda yardımcı olan veya gereksiz testlere çok fazla zaman harcamaktan kaçınmama yardımcı olan bilgileri sağlıyorlar. Testler ilk fikirlerin çoğunu netleştirdiği için genellikle kusurları önledik. Örneğin, üzerinde çalıştığım bir projede, programcılara verdiğim Uyum testleri, bir joker karakter aramasına yanıt vermek için bir sorgunun beklenen sonuçlarını gösteriyordu. Programcı tamamen yalnızca tam kelime aramalarını kodlamayı amaçlamıştı. Kodlamaya başlamadan önce müşteri ile konuşup doğru yorumu tespit edebildik. İşbirliği yaparak, ikimizi de çok fazla zaman kaybından kurtaran kusuru önledik.

Programcılar, başarılı otomasyon oluşturmak için test uzmanlarıyla da işbirliği yapabilir. İyi kodlama uygulamalarını anlarlar ve test uzmanlarının tüm ekip için çalışan sağlam bir test otomasyon paketi oluşturmasına yardımcı olabilirler. Testler kötü tasarlanmış olduğu için test otomasyon projelerinin başarısız olduğunu sık sık gördüm. Testler çok fazla test etmeye çalışıyor veya testçiler, testleri bağımsız tutabilmek için teknoloji hakkında yeterince bilgi sahibi değiller. Test cihazları genellikle darboğazdır, bu nedenle programcıların otomasyon gibi görevlerde onlarla çalışması mantıklıdır. Neyin erkenden test edilebileceğini anlamak için testçilerle birlikte çalışmak, belki de basit bir araç sağlayarak, programcılara uzun vadede daha iyi kod sunmalarına yardımcı olacak başka bir geri bildirim döngüsü sağlayacaktır.

Testçiler, tek görevlerinin yazılımı kırmak ve programcıların kodunda hatalar bulmak olduğunu düşünmeyi bıraktığında, programcılar, testçilerin `onları elde etmeye hazır` olduklarını düşünmeyi bırakırlar ve işbirliğine daha açık olurlar. Programcılar, kodlarında kalite oluşturmaktan sorumlu olduklarını fark etmeye başladıklarında, kodun test edilebilirliği doğal bir yan üründür ve ekip birlikte daha fazla regresyon testini otomatikleştirebilir. Başarılı ekip çalışmasının büyüsü başlar.

[Janet Gregory](http://programmer.97things.oreilly.com/wiki/index.php/Janet_Gregory) Tarafından


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/tr/thing_92.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.