[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"me":3,"catalog:tr:qa-test-automation\u002Fsenior":4,"config":126},null,{"field_key":5,"field_name":6,"seniority":7,"topic_key":8,"topic_name":8,"spec_key":8,"spec_name":8,"locale":9,"cell_total":10,"field_total":11,"seniorities":12,"topics":15,"specs":41,"samples":42},"qa-test-automation","QA \u002F Test Otomasyonu","senior","","tr",394,600,[13,14,7],"junior","mid",[16,20,23,26,29,32,35,38],{"key":17,"name":18,"count":19},"qa-api-testing","Qa Api Testing",75,{"key":21,"name":22,"count":19},"qa-automation-fundamentals","Qa Automation Fundamentals",{"key":24,"name":25,"count":19},"qa-ci-cd-testing","Qa Ci Cd Testing",{"key":27,"name":28,"count":19},"qa-defect-management","Qa Defect Management",{"key":30,"name":31,"count":19},"qa-exploratory-manual-testing","Qa Exploratory Manual Testing",{"key":33,"name":34,"count":19},"qa-performance-testing","Qa Performance Testing",{"key":36,"name":37,"count":19},"qa-test-case-design","Qa Test Case Design",{"key":39,"name":40,"count":19},"qa-test-strategy","Qa Test Strategy",[],[43,61,74,87,100,113],{"id":44,"topic":18,"difficulty":45,"body":46,"options":47,"correct_key":49,"explanation":60},"019f68ba-2388-7e64-835a-7be00e9825f4",3,"Bir test, geçersiz bir e-posta formatıyla `POST \u002Faccounts` gönderiyor ve şunu alıyor:\n```json\n{\"status\": 200, \"body\": {\"id\": null, \"error\": \"invalid email\"}}\n```\nBu response, API testi açısından neden kötü tasarlanmış?",[48,51,54,57],{"key":49,"text":50},"a","200 status, önce status'e bakan her istemciye başarı der; hata body'nin içinde gizli kalır",{"key":52,"text":53},"b","Gerçekte ne yanlış gittiğinden bağımsız olarak, response body'sinde asla \"error\" kelimesi geçmemelidir",{"key":55,"text":56},"c","Oluşturma başarısız olduğunda `id` alanı `null` yerine rastgele üretilmiş bir placeholder değer içermelidir",{"key":58,"text":59},"d","JSON response'lar validation hatalarını tanımlayamaz; hata bilgisi yalnızca HTTP header'larında taşınabilir","Birçok istemci (ve basit monitoring) önce status code'a göre dallanır; 200 \"bu işe yaradı\" der, body'ye inmeyen bir istemci reddedilmiş, geçersiz bir isteği başarı sanır. Çözüm, gerçekte olanla eşleşen bir 4xx status'tür (örn. 400\u002F422), üzerine body'deki detay eklenir. \"error\" kelimesinden kaçınmak (b) kozmetiktir ve alakasızdır, sahte bir placeholder id (c) başarısızlığı başarıya daha da çok benzetir, hata detayının body'de olması header'lardan bağımsız olarak doğaldır (d).",{"id":62,"topic":18,"difficulty":45,"body":63,"options":64,"correct_key":55,"explanation":73},"019f68ba-238d-7154-a75f-b889d41cbe31","Bir test, yalnızca bir bildirim servisinin başarı döndürdüğünü değil, gerçekten doğru alıcıyla tam olarak bir kez çağrıldığını da doğrulamak istiyor. Hangi test double türü buna uygundur ve neden?",[65,67,69,71],{"key":49,"text":66},"Stub — çünkü stub'lar yanıt döndürmenin bir yan etkisi olarak her çağrıyı otomatik olarak kaydeder",{"key":52,"text":68},"Gerçek servis — çünkü alıcı değerinin doğru olduğunu yalnızca gerçek bağımlılık kanıtlayabilir",{"key":55,"text":70},"Mock — çünkü mock, testin etkileşimin kendisini (bir kez, beklenen alıcıyla çağrıldı mı) iddia etmesine izin verir",{"key":58,"text":72},"Burada hiçbir test double uygun değildir; bu tür bir kontrol yalnızca production log'larının manuel incelemesiyle yapılabilir","Bu gereksinim, yalnızca hazır bir sonuç sağlamak değil davranış doğrulamasıdır (çağrı yapıldı mı, kaç kez, hangi argümanlarla) — mock'un tam olarak var olduğu yer burasıdır. Düz bir stub (a) yanıt döndürür ama çağrı-sayısı ve argüman kontrollerini testin iddialarının parçası yapmak için tasarlanmamıştır. Gerçek servis (b), kendi kodunuzun ona hangi argümanları geçtiğini doğrulamak için gerekli değildir, manuel log kontrolü (d) aynı şey otomatik ve tekrarlanabilir şekilde iddia edilebiliyorken gereksizdir.",{"id":75,"topic":18,"difficulty":45,"body":76,"options":77,"correct_key":58,"explanation":86},"019f68ba-238d-7a04-a219-4dc71a6c04ec","Bir test bir kaynak oluşturuyor, kontrol ediyor ve hiç silmiyor. Paylaşımlı test ortamında yüz kez çalıştırılınca kaynak listesi binlerce kayda çıkıyor ve alakasız bir `GET \u002Fresources` testi timeout vermeye başlıyor. Altta yatan sorun nedir?",[78,80,82,84],{"key":49,"text":79},"`GET \u002Fresources` endpoint'inde bug var; gerçekte kaç kaynak olduğunu yok sayacak şekilde yeniden yazılmalı",{"key":52,"text":81},"Test ortamının sunucusunun daha fazla belleğe ihtiyacı var — veri büyüdükçe her endpoint eninde sonunda yavaşlar",{"key":55,"text":83},"Hiçbir sorun yok; büyüyen kaynak sayısı testlerin tekrar tekrar çalıştırılmasının normal ve beklenen bir yan etkisidir",{"key":58,"text":85},"Oluşturan test temizlik yapmadan veri bırakıyor; kalan veri paylaşımlı ortamı diğer testler için kirletiyor","Veri oluşturan ama hiç kaldırmayan bir test, paylaşımlı ortamda kalıcı bir kalıntı bırakır; çok sayıda çalıştırmada bu kalıntı birikir ve orijinal testle hiçbir ilgisi olmayan testleri etkilemeye başlar — testlerin düzgün izole ve kendi kendini temizleyen olmamasının bir belirtisi. Çözüm, her çalıştırma sonrası oluşturulanı kaldırmak (ya da özel, tek kullanımlık veri kullanmak)tır. Listeleme endpoint'i gerçekten daha büyük bir veri kümesi altında yavaşladığı için mutlaka hatalı değildir (a), daha fazla bellek (b) aynı birikimi yalnızca erteler, buna göz yummak (c) tam olarak kaçınılması gereken pratiktir.",{"id":88,"topic":18,"difficulty":45,"body":89,"options":90,"correct_key":55,"explanation":99},"019f68ba-238f-7610-bb69-7ab38a2ade37","Bir response'un şu kuralları sağlaması bekleniyor: `id` bir integer, `name` boş olmayan bir string, `price` sıfırdan büyük bir sayı. Şu response verildiğinde:\n```json\n{\"id\": \"7\", \"name\": \"\", \"price\": 12.5}\n```\nBu response'un schema validation'ı hakkında hangi ifade doğrudur?",[91,93,95,97],{"key":49,"text":92},"Response geçer, çünkü `\"7\"` her schema validator'da otomatik olarak integer `7`'ye dönüştürülebilir",{"key":52,"text":94},"Response geçer, çünkü `price`'ın pozitif olması schema validation'ın kontrol edebildiği tek kuraldır",{"key":55,"text":96},"Response başarısız olur, çünkü `id` integer yerine string ve `name` boş-olmayan yerine boş",{"key":58,"text":98},"Response yalnızca `id`'nin tipi yüzünden başarısız olur; boş bir string yine de geçerli, boş-olmayan bir string sayılır","Belirtilen kurallara göre aynı anda iki şey yanlıştır: `id`, integer yerine `\"7\"` string'i olarak geliyor, ve `name` boş bir string — \"boş olmayan\"ı sağlamıyor. Bir schema validator varsayılan olarak sessizce tip dönüştürmez (a) — bu gerçek bir tip uyumsuzluğunu gizlerdi — ve schema validation genel olarak yapı ve tip kısıtlarını kontrol eder, yalnızca sayısal aralıkları değil (b); listelenen ihlallerin ikisi de gerçektir, yalnızca biri değil (d).",{"id":101,"topic":18,"difficulty":45,"body":102,"options":103,"correct_key":49,"explanation":112},"019f68ba-2390-7ae1-beec-39a004b1c330","Bir backend, mevcut bir response'a yeni bir opsiyonel alan (`discountCode`) ekliyor. Consumer'ın testleri, bilinmeyen alanları geçersiz sayan bir schema ile yazılmış (`additionalProperties: false` ya da eşdeğeri). Ne olur ve bu ne ortaya koyar?",[104,106,108,110],{"key":49,"text":105},"Consumer'ın testleri tamamen katkısal bir değişiklikte başarısız olur; schema'nın amaçlanandan daha katı olduğunu ortaya koyar",{"key":52,"text":107},"Hiçbir şey olmaz, çünkü schema validation yalnızca eksik alanları kontrol eder, beklenmedik şekilde var olan alanları asla kontrol etmez",{"key":55,"text":109},"Provider'ın kendi testleri hemen başarısız olur, çünkü bir response'a herhangi bir alan eklemek her zaman breaking bir API değişikliğidir",{"key":58,"text":111},"Consumer otomatik olarak `discountCode`'u kendi mantığında kullanmaya başlar, çünkü schema'lar yeni alanları doğrudan consumer'lara yayar","Zaten bilmediği herhangi bir alanı reddeden bir schema, zararsız, katkısal bir değişikliği kırılma gibi ele alır — buradaki versiyon uyumluluğu sorunu API değişikliğinde değil, testin kendi katılığındadır. Schema'yı bilinmeyen ekstra alanlara izin verecek (ve onları basitçe yok sayacak) şekilde gevşetmek, gerçekten uyumlu değişikliklerin geçmesini sağlarken eksik ya da yanlış tipte zorunlu bir alan gibi gerçek sözleşme ihlallerini yakalamaya devam eder. Schema validation, öyle yapılandırıldığında beklenmedik ekstra alanları kesinlikle işaretleyebilir (b), opsiyonel bir alan eklemek katkısaldır, doğası gereği breaking değildir (c), bir schema consumer'ın bir alanı kendiliğinden tüketmeye başlamasına yol açmaz (d).",{"id":114,"topic":22,"difficulty":45,"body":115,"options":116,"correct_key":55,"explanation":125},"019f68ba-2398-70b1-9c9f-dc238ceb12de","Bir test suite'i testler sabit alfabetik sırada çalıştığında geçiyor ama birçok CI aracının flaky testleri ortaya çıkarmak için kullandığı rastgele sırada çalıştığında başarısız oluyor. Her test tek başına sorunsuz geçiyor. Bu en güçlü şekilde neyi işaret eder?",[117,119,121,123],{"key":49,"text":118},"CI aracının rastgeleleştirme özelliğinin kendisi arızalı",{"key":52,"text":120},"Testler sadece ağ zamanlamasından dolayı flaky, sırayla ilgisi yok",{"key":55,"text":122},"Bazı testler, alfabetik olarak önce çalışan testlerden kalan state'e bağımlı",{"key":58,"text":124},"Suite'te güvenle çalıştırılamayacak kadar çok test var","Sabit bir sırada geçip rastgeleleştirmede başarısız olmak, her test tek başına sorunsuzken, araç arızasından çok bir sıra-bağımlılığı bug'ının imzasıdır. a aracın bozuk olduğunu varsayıyor ki bu gerçek bir bağımlılıktan çok daha az olası; b ve d neden özellikle sıranın önemli olduğunu açıklamıyor.",{"fields":127,"seniorities":312,"interview_shapes":313,"locales":318,"oauth":320,"question_count":323,"coach_enabled":324,"jd_match_enabled":324},[128,154,175,191,215,228,247,266,288,293,299,306],{"key":129,"name_tr":130,"name_en":130,"sort":131,"specializations":132},"backend","Backend",1,[133,136,139,142,145,148,151],{"key":134,"name":135,"field":129},"general","Genel",{"key":137,"name":138,"field":129},"go","Go",{"key":140,"name":141,"field":129},"python","Python",{"key":143,"name":144,"field":129},"java","Java",{"key":146,"name":147,"field":129},"csharp","C#\u002F.NET",{"key":149,"name":150,"field":129},"nodejs","Node.js",{"key":152,"name":153,"field":129},"php","PHP",{"key":155,"name_tr":156,"name_en":156,"sort":157,"specializations":158},"frontend","Frontend",2,[159,160,163,166,169,172],{"key":134,"name":135,"field":155},{"key":161,"name":162,"field":155},"javascript","JavaScript",{"key":164,"name":165,"field":155},"typescript","TypeScript",{"key":167,"name":168,"field":155},"react","React",{"key":170,"name":171,"field":155},"vue","Vue",{"key":173,"name":174,"field":155},"angular","Angular",{"key":176,"name_tr":177,"name_en":177,"sort":45,"specializations":178},"fullstack","Fullstack",[179,180,181,182,183,184,185,186,187,188,189,190],{"key":134,"name":135,"field":176},{"key":137,"name":138,"field":129},{"key":140,"name":141,"field":129},{"key":143,"name":144,"field":129},{"key":146,"name":147,"field":129},{"key":149,"name":150,"field":129},{"key":152,"name":153,"field":129},{"key":161,"name":162,"field":155},{"key":164,"name":165,"field":155},{"key":167,"name":168,"field":155},{"key":170,"name":171,"field":155},{"key":173,"name":174,"field":155},{"key":192,"name_tr":193,"name_en":193,"sort":194,"specializations":195},"devops-cloud","DevOps \u002F Cloud",4,[196,197,200,203,206,209,212],{"key":134,"name":135,"field":192},{"key":198,"name":199,"field":192},"aws","AWS",{"key":201,"name":202,"field":192},"gcp","GCP",{"key":204,"name":205,"field":192},"azure","Azure",{"key":207,"name":208,"field":192},"kubernetes","Kubernetes",{"key":210,"name":211,"field":192},"terraform","Terraform",{"key":213,"name":214,"field":192},"linux","Linux",{"key":216,"name_tr":217,"name_en":217,"sort":218,"specializations":219},"ai-engineer","AI Engineer",5,[220,221,222,225],{"key":134,"name":135,"field":216},{"key":140,"name":141,"field":216},{"key":223,"name":224,"field":216},"llm-rag","LLM\u002FRAG",{"key":226,"name":227,"field":216},"mlops","MLOps",{"key":229,"name_tr":230,"name_en":231,"sort":232,"specializations":233},"database","Veritabanı","Database",6,[234,235,238,241,244],{"key":134,"name":135,"field":229},{"key":236,"name":237,"field":229},"postgresql","PostgreSQL",{"key":239,"name":240,"field":229},"mysql","MySQL",{"key":242,"name":243,"field":229},"mongodb","MongoDB",{"key":245,"name":246,"field":229},"redis","Redis",{"key":248,"name_tr":249,"name_en":250,"sort":251,"specializations":252},"mobile","Mobil","Mobile",7,[253,254,257,260,263],{"key":134,"name":135,"field":248},{"key":255,"name":256,"field":248},"ios-swift","iOS (Swift)",{"key":258,"name":259,"field":248},"android-kotlin","Android (Kotlin)",{"key":261,"name":262,"field":248},"flutter","Flutter",{"key":264,"name":265,"field":248},"react-native","React Native",{"key":267,"name_tr":268,"name_en":269,"sort":270,"specializations":271},"security","Güvenlik","Security",8,[272,273,276,279,282,285],{"key":134,"name":135,"field":267},{"key":274,"name":275,"field":267},"appsec","AppSec",{"key":277,"name":278,"field":267},"offensive-pentest","Offensive \u002F Pentest",{"key":280,"name":281,"field":267},"cloud-security","Cloud Security",{"key":283,"name":284,"field":267},"devsecops","DevSecOps",{"key":286,"name":287,"field":267},"blue-team-incident","Blue Team \u002F Incident",{"key":5,"name_tr":6,"name_en":289,"sort":290,"specializations":291},"QA \u002F Test Automation",9,[292],{"key":134,"name":135,"field":5},{"key":294,"name_tr":295,"name_en":295,"sort":296,"specializations":297},"data-engineer","Data Engineer",10,[298],{"key":134,"name":135,"field":294},{"key":300,"name_tr":301,"name_en":302,"sort":303,"specializations":304},"game-dev","Oyun Geliştirme","Game Development",11,[305],{"key":134,"name":135,"field":300},{"key":307,"name_tr":308,"name_en":308,"sort":309,"specializations":310},"ml-engineer","ML Engineer",12,[311],{"key":134,"name":135,"field":307},[13,14,7],{"junior":314,"mid":316,"senior":317},{"questions":315,"median_sec":3},20,{"questions":315,"median_sec":3},{"questions":315,"median_sec":3},[9,319],"en",[321,322],"google","github",21750,true]