Lemidea · Yayın:
| Teslimde isteyin | Dosyaya yazılacak kanıt | Tek başına yeterli olmayan |
|---|---|---|
| Kabul edilen kapsam | Çalışacak kullanıcı adımları ve açık kalan işler | Bütün özellikler tamamlandı cümlesi |
| Kod ve sürüm | Depo adresi, erişim sahibi ve teslim edilen sürüm kimliği | Bir ZIP dosyası veya ajan sohbeti |
| Canlı yayın | Yayın adresi, yayın zamanı ve bu yayının kod sürümü | Derleme başarılı ekranı |
| Tekrar çalıştırma | Gereken araçlar, kurulum adımları ve örnek ayar dosyası | Yalnız geliştiricinin bilgisayarında açılması |
| Kabul kontrolleri | Senaryo, beklenen sonuç, gerçek sonuç ve kullanılan ortam | Kapsamı belli olmayan yeşil test sayısı |
| Hesaplar ve devam planı | Hesap sahipliği, yetkiler, yedek ve destek sorumlusu | Depoyu devretmenin bütün hesapları devrettiği varsayımı |
Teslim, uygulamanın başka biri tarafından sürdürülebilmesini de kapsasın
Claude Code, Codex veya başka bir araçla geliştirilmiş olması teslim ölçütünü değiştirmez. Devralacak kişinin aynı ajan sohbetini bulmasına gerek kalmadan neyin çalıştığını, nasıl çalıştırılacağını ve hangi işlerin açık kaldığını anlayabilmesini hedefleyin. Ajanın tamamlandı mesajı bu bilgilerin yerini tutmaz.
Buradaki liste, kapsamı belirlenmiş ve hazır olduğu söylenen bir uygulamayı devralmak içindir. Teslim dosyasına önceden anlaştığınız üç kritik kullanıcı işlemini yazın. Örneğin hizmet seçme, uygun saati görme ve randevu talebini kaydetme. Saatin ekranda seçilmesi ile randevunun sunucuda saklanması farklı işlerdir; sonuncusu kapsamdaysa yalnız ilkini gösteren demo teslimi kanıtlamaz.
Teslim notunu küçük bir devir provasıyla sınayın: işletme yetkilisi kendi hesabıyla depoya ve yayın paneline erişebilsin; devralacak geliştirici yalnız teslim notlarını izleyerek ayrı bir test ortamı hazırlasın; üzerinde anlaşılan bir işlemi sentetik veriyle tekrar göstersin. Eksik ayar veya açıklama çıkarsa notları tamamlayın. İşletme sahibinin kod yazması gerekmez. Bu, önerdiğimiz bir kabul çalışmasıdır; bu yazı için gerçek bir uygulama üzerinde yapılmış değildir.
Kod, kontrol raporu ve canlı adres aynı sürümü anlatsın
Bir sürüm kimliği, kaynak kodun belirli bir halini işaretler. Geliştiriciden bu kimliği, ona ait kontrol raporunu ve yayındaki sürüm kaydını birlikte isteyin. Kontrol raporu eski koddan, canlı adres yeni koddan geliyorsa raporun hangi değişiklikleri kapsadığı belirsiz kalır. Yayın hizmetinin sunduğu sürüm kaydı veya teslim notu bu bağlantıyı açıklamalı.
Yayın kaydındaki kod kimliği kontrol raporundakinden farklıysa, sonradan hangi değişikliğin yapıldığını ve ilgili işlemin yeniden kontrol edilip edilmediğini sorun. Böylece eski bir raporu yeni sürüm için yeterli saymazsınız. Kodun derlenmesi de randevu kaydının gerçekten saklandığını tek başına göstermez.
Depo erişimi ile işletme hesaplarını ayrı teslim alın
GitHub'ın resmî belgesinde depo aktarımında mevcut ortak erişimlerin ve webhooks, secrets, deploy keys gibi bağlantıların korunabildiği açıklanır. Eski sahibi de aktarım sonrasında ortak olarak kalabilir. Depo devri tamamlandıktan sonra erişim listesini ayrıca inceleyin; bütün yetkilerin kendiliğinden kaldırıldığını varsaymayın. Aktarımın kaynak ve hedef hesapta ayrı izin koşulları vardır.
Alan adı, barındırma, veritabanı, e-posta ve model hizmetini ayrı satırlarda listeleyin. Her satırda hesap sahibi, işletmenin erişimi, aboneliği yöneten taraf ve destek sorumlusu bulunsun. Devir kapsamındaki hesaplara işletme yetkilisinin kendi erişimiyle ulaşabildiğini kontrol edin. Parola veya anahtar değerlerini teslim dosyasına yazmayın. Bu hesap envanteri bizim önerdiğimiz yöntemdir; GitHub depo aktarımı dış hizmetlerin sahipliğini devrettiğini kanıtlamaz.
Kaynak: GitHub — depo aktarımında taşınan erişimler ve bağlantılar ↗
Kontrol listesini ekran isimleriyle değil, davranışlarla yazın
Playwright'ın resmî önerileri, testlerin kullanıcının görebildiği davranışlara dayanmasını ve birbirinden bağımsız çalışmasını vurgular. Veriyle yapılan denemelerde kontrollü bir test ortamı kullanılması da önerilir. Teslim açısından çıkarımımız şu: Her test için kullanıcının ne yaptığı ve sonunda ne gördüğü anlaşılabilmeli. Bir test aracını kullanmak, bütün kabul koşullarının kontrol edildiği anlamına gelmez.
Kontrol raporunda kullanılan sürüm, ortam, tarih, sentetik giriş verisi, beklenen sonuç ve gerçek sonuç bulunsun. Geçti, kaldı ve denenmedi durumlarını ayırın. Taklit yanıtla çalışan bir testin gerçek takvim veya e-posta bağlantısını kanıtlamadığını ayrıca yazın. Teknik testleri geliştiren kişiden, işletmenin günlük işini tarif eden kabul maddelerini ise işi kullanacak taraftan alın.
Kaynak: Playwright — kullanıcı davranışı, test izolasyonu ve veriyle test ↗
Doldurulmuş örnek: randevu süresi ve kapanış kontrolü
Sentetik örnekte işletme 18.00’de kapanıyor. Boş takvimde 60 dakikalık hizmet için 17.00 başlangıcı seçilebilmeli, 17.30 seçilememeli. Süre 90 dakikaya çıktığında en geç 16.30 seçilebilmeli. Kabul koşulu böylece randevu ekranı çalışıyor cümlesinden, hizmetin tamamı çalışma saatleri içinde kalıyor kuralına dönüşür.
Örnek kontrol kaydı: İşlem, 60 dakikalık hizmete başlangıç saati seçmek. Veri, boş takvim ve 18.00 kapanış. Beklenen, 17.00 uygun ve 17.30 uygun değil. Yerel fonksiyon kontrolündeki sonuç, iki beklenti de karşılandı. Kontrol edilmeyen, tarayıcıdan sunucuya randevu kaydı ve takvim bağlantısı. Bu kaydın geçti olması, gerçek rezervasyon sisteminin kabul edildiği anlamına gelmez.
Dolu saat de sonucu değiştirmeli. Sentetik takvimde 16.00–16.30 doluysa, 15.30’da başlayan 60 dakikalık hizmet bu aralıkla çakışır ve seçilememelidir; 16.30 başlangıcı ise başka engel yoksa uygundur. Aşağıdaki demoda hizmet süresini değiştirerek bu ayrımı inceleyebilirsiniz. Gerçek üründe sunucunun uygunluğu yeniden doğrulaması, eşzamanlı talepler ve kalıcı kayıt ayrı kabul maddeleridir.
Sonuçları kabul, açık iş ve yeniden kontrol olarak ayırın
Kabul: Üzerinde anlaşılan kritik işlemin sonucu, teslim edilen sürümde ve ilgili ortamda kanıtlanmıştır. Randevu örneğinde yalnız saat hesabı test edildiyse kabul edilen parça saat hesabıdır. Formun görünmesini, kayıt işleminin de kabulü saymayın.
Açık iş: İşlemin bir parçası tarafların bilgisiyle teslim dışında veya sonraki aşamada bırakılmıştır. Örneğin SMS bildirimi sonraki aşamadaysa kapsamını, sorumlusunu ve değerlendirme tarihini yazın. Kapsamda bulunan kritik bir işlem başarısızsa onu yalnız açık iş diye adlandırıp tamamlanmış saymayın. Sorun düzeltilip ilgili kontrol geçene kadar o işlem kabul edilmez.
Yeniden kontrol: Sonuç gösterilemiyordur, rapor başka sürüme aittir veya başarısız işlem düzeltilmiştir. Yeni sürümde ilgili kontrolü tekrar çalıştırıp sonucu kaydedin. Bu karar sınıfları bizim önerdiğimiz kayıt düzenidir; bir test aracının otomatik verdiği teslim kararı değildir.
Doldurup geliştiriciye gönderebileceğiniz kısa teslim notu
İşlem: ____. Kod sürümü: ____. Test edilen ortam ve adres: ____. Tarih: ____. Sentetik veri: ____. Beklenen sonuç: ____. Gözlenen sonuç: ____. Kontrol sonucu: geçti / kaldı / denenmedi. Kanıt bağlantısı: ____. Teslim kararı: kabul / sonraki aşama olarak kararlaştırıldı / kabul öncesi yeniden kontrol. Açık kalan iş, sorumlusu ve sonraki değerlendirme tarihi: ____. Aynı kaydı önceden seçtiğiniz üç kritik işlem için doldurun.
Devam notu: Kod nerede; kurulum adımları ve ayar isimleri nerede; yayınlanan kod sürümü hangisi; erişimleri kim yönetiyor; son çalışan yayına nasıl dönülür; veri yedeği nasıl geri yüklenir; destek hangi işleri kapsar? Bu notta bir kontrol yapılmadıysa açıkça denenmedi yazın. Geri yükleme gibi işlemleri canlı veride rastgele denemek yerine önceden belirlenen test ortamı ve planla doğrulayın.
İlk incelemeyi teslimde eksik kalan parçayla sınırlayın
Uygulama çalışıyor ama başka biri kuramıyorsa ilk iş yeniden geliştirme değil, çalıştırma notunu ve eksik erişimleri tamamlamak olabilir. Kontrol raporu yoksa önce kapsamda bulunan kritik davranışları doğrulayın. Ödeme, özel veri veya birden fazla ekip içeren uygulamalarda bu kısa listenin ötesinde kontroller gerekir; kapsamı projeye göre belirleyin.
Lemidea’ya uygulamanın amacını, hazır olduğu söylenen işleri ve teslimde belirsiz kalan bir maddeyi yazabilirsiniz. İlk mesajda parola, müşteri kaydı veya özel kaynak kodu paylaşmanız gerekmez. Önce kod, yayın ya da devir notlarından hangisinin inceleneceğini netleştirelim.
Kaynaklar ve hazırlanış
Bu içerik yapay zekâ desteğiyle hazırlanmıştır. GitHub ve Playwright açıklamaları resmî belgelerle karşılaştırılmış, randevu örneğinin saat hesabı yerel fonksiyon kontrolleriyle incelenmiştir. Teslim listesi ve karar sınıfları önerilen yöntemlerdir; müşteri uygulaması denetimi veya insan editör incelemesi olarak sunulmaz.
Araç özellikleri ve sağlayıcı koşulları değişebilir. Kaynak kontrolü: .
Örnek işletme ve teslim kararları sentetiktir. Randevu demosunun süre, kapanış ve dolu saat hesabı altı yerel fonksiyon kontrolüyle incelenmiştir. Devir provası öneridir; başka bir geliştiriciyle uygulanmamıştır. Gerçek takvim bağlantısı, kalıcı randevu kaydı, eşzamanlı rezervasyon veya müşteri uygulaması test edilmemiştir.
