Yazılım kabul sınaması, sistemin çözmek için kurulduğu zorluğu teslim gününde bilerek oluşturup kaydın aldığı hâli okumaktır. Senaryonun geldiği yer bellidir: projenin zorluk satırlarındaki her olumsuzlama kaydın nerede yanlış olabileceğini adlandırır ve senaryo orayı bir eyleme çevirir. AlgoKlima’da senaryo, teknisyen sahadan ve ofis panelden aynı kaydın ayrı alanlarını değiştirdikten sonra geriye tek kayıt kalıyorsa geçer.
Gösterim turu neyi gösteremez
Kabul günü çoğu masada aynı biçimde geçer. Satıcı ekranını paylaşır, menüleri sırayla açar, bir kayıt oluşturur, listeye düştüğünü gösterir, sonra raporu açar. Her tıklama beklendiği gibi çalışır ve masadaki herkes rahatlar. Rahatlamanın kaynağı gördüğünüz şeyin doğruluğu değil, gördüğünüz şeyin yapısıdır: tek arayüz, tek oturum, tek kişi.
Sisteminizin çözmek için kurulduğu zorluk tam olarak orada yoktur. İşlettiğimiz AlgoKlima’nın kurulduğu zorluk şudur: sahadaki teknisyen ile ofisteki arkadaşı aynı servis kaydına birbirinden habersiz dokunabiliyor. Satıcı tek başına tıkladığı sürece bu hâl hiç oluşmaz. Kusur gizlenmiyor, üretilmiyor. Aradaki fark önemli, çünkü gizlenen bir kusur dikkatle bulunur; üretilmeyen bir kusur ne kadar dikkat ederseniz edin görünmez.
Diotek’te aynı boşluk başka bir yüzle çıkar. Ziyaretçi siteden talebini gönderdiğinde ekranda “gönderildi” yazar. O mesaj ziyaretçi tarafının çıktısıdır. Sistemin asıl işi talebin operasyon tarafına ayrışmış hâlde düşmesidir ve bir gösterim turu operasyon tarafını genellikle hiç açmaz. Ziyaretçi ekranı doğru davrandığı sürece herkes akışın da doğru olduğunu varsayar.
Teslim gününde sınanan başka bir şey daha var: elinize geçen kalemlerle sistemi yeniden kurabiliyor musunuz. O soruyu, yani yeniden üretilebilirliği, devir listesi yazısı alıyor; yazılım firmasına sorulacak sorular yazısı da yazılımın doğru davranıp davranmadığını bilerek dışarıda bırakmıştı. Buradaki konu o ikincisi.
Kaydı tek kişinin girdiği, kaydın üstünde başka bir rolün hiç dolaşmadığı bir işte gösterim turu ile kabul örtüşür. Öyle bir akışta ekranların açılması gerçekten kabul demektir ve aşağıdaki senaryolar size fazladan yük olur. Bu yazı, aynı kaydın birden fazla rol tarafından değiştirildiği sistemler için yazıldı.
Senaryo projenin zorluk satırlarından seçilir
Kabul senaryosu yazmak yeni bir belge üretmek gibi görünür. Değildir. Senaryo listesi projenin kendi zorluk satırlarında zaten yazılı duruyor, yalnız henüz eyleme çevrilmemiş.
Bir zorluk cümlesini tanıyan işaret olumsuzlamadır. “Habersiz değiştirebiliyor”, “hiçbir koşulda sınırı geçmemeli”, “aynı form değil” — hepsi bir şeyin olmaması gerektiğini söylüyor. Olumsuzlama kaydın yanlış olabileceği yeri adlandırır. Kabul senaryosu, o adlandırılmış yeri bir eyleme çevirmekten ibarettir.
Çevrim şöyle işler. “Ofisle saha aynı kaydı habersiz değiştirebiliyor” cümlesi, “aynı kaydı aynı anda hem sahadan hem panelden değiştir” eylemine döner. “Ödeme kaydı kurum sınırını geçmemeli” cümlesi, “komşu kuruma bilinen tutarda bir ödeme gir, sonra kendi raporunu al” eylemine döner. “Keşif ile servis aynı form değil” cümlesi, “talep tiplerini art arda aç, operasyon tarafını oku” eylemine döner. Eşlemeyi biz uydurmuyoruz: proje sayfalarında zorluk satırı ile o zorluğun karşılandığı yer yan yana yazılı; senaryo ikisinin arasındaki boşluğu doldurur.
Listeye girmeyen cümle de var. Olumsuzlama taşımayan bir zorluk cümlesi, örneğin “yönetici ay raporunu görebilmeli”, kabul senaryosu değil görsel kontroldür. Ekranı açarsınız, rapor gelir, satır kapanır. Kaydın yanlış olabileceği bir yeri adlandırmadığı için sınama da üretmez. Bu ayrım listeyi kısaltır ve kısalması iyidir: kabul günü sınanabilecek senaryo sayısı sınırlıdır, o sınırlı yeri görsel kontrollerle doldurmak sınamanın kendisini yer.
Zorluk listeniz yoksa aynı listeyi bir adım geriden türetirsiniz. Teklif aşamasında yazdığınız ihtiyaç metni varsayım taşır ve her varsayım bir zorluk adayıdır. Aynı işe neden farklı fiyat çıktığını anlattığımız yazıda tekliflerin ayrıştığı yerin bu varsayım listesi olduğunu yazmıştık; ihtiyacınızı yazılımcıya nasıl anlatacağınızı anlattığımız yazı da aynı listeyi iş koşulu olarak kurar. Kabul senaryosu o metinlerden de çıkarılabilir; hangi belgeden çıktığı önemli değil, olumsuzlama taşıması önemli.
Ofis ve saha aynı kaydı aynı anda değiştirir, sonuç tek kayıt mı
AlgoKlima’da kabul senaryosunun kurulumu şöyle. Teknisyen sahada, kapsama alanının bittiği bir yerde, elindeki uygulamadan kaydın bir alanını değiştirir. Aynı dakikalarda ofisteki arkadaşı panelden aynı kaydın başka bir alanını değiştirir. Sonra teknisyen kapsama alanına döner ve bağlantı geri gelir.
Hangi alanların seçileceği projeden projeye değişir; proje sayfamızda bu alanlar adıyla yazılı değil, o yüzden örneği varsayımla veriyoruz. Diyelim ki teknisyen kaydın işlem notunu güncelliyor, ofis aynı anda kaydın ilgili kişisini değiştiriyor. Önemli olan alanların adı değil, her birinin aynı kayda ait olması ve değişikliklerin birbirinden habersiz yapılmasıdır. Alanları siz seçin, ama seçerken kaydın hem sahadan hem ofisten dokunulan bir alanını seçin; kimsenin ofisten elleşmediği bir alan senaryoyu boşa çıkarır.
Geçme koşulu tek cümleye iner: bağlantı döndükten sonra ortada tek kayıt vardır ve her tarafın değişikliği o kayıtta durur. İşlem notu teknisyenin yazdığı gibi, ilgili kişi ofisin yazdığı gibi. Ortada birbirinin kopyası olan ayrı kayıtlar duruyorsa ya da taraflardan birinin değişikliği hiç görünmüyorsa koşul sağlanmamıştır. Bu koşulun kaydın hâliyle yazılmış olması önemli: “senkronizasyon çalışıyor” bir izlenimdir, “kayıt tek ve her alan kendi yeni değerinde” bir ölçüdür.
Bağlantı dönünce bekleyen değişikliklerin nasıl birleştiğini burada anlatmıyoruz; çevrimdışı çalışan mobil uygulamanın senkronizasyonunu yazdığımız yazı o işi yapıyor. Kabul gününde sizin okuyacağınız şey mekanizma değil sonuçtur: kaydın aldığı hâl. Mekanizmayı okumak satıcının cevabını dinlemektir, kaydı okumak ise sizin ölçmenizdir.
Senaryonun bir bedeli var ve bu bedel onu masa başında imkânsız kılan şeydir. Kurulum için sahaya çıkacak bir kişi ve bağlantının gerçekten kesildiği bir an gerekir. Satıcının tek başına yürüttüğü bir gösterimde bunların hiçbiri yoktur; kusur bu yüzden üretilmez, gizlendiği için değil. Saha ekibinin elindeki uygulamanın bağlantı yokken ne yapmaya devam ettiği mobil uygulama geliştirme tarafının kararıdır ve o karar kabul gününden çok önce verilir.
AlgoKlima’nın proje sayfasında bu zorluğun kendi cümlesi yazılı duruyor; senaryoyu doğrudan oradan kopyalayabilirsiniz. Kapsama dışında çalışan bir rolünüz yoksa bu senaryo hiç kurulmaz. Herkesin aynı ağda oturduğu bir sistemde kabul senaryosu başka bir zorluk satırından seçilir.
Kiracı sınırı ekranda değil raporda sınanır
Vipkurum çatısında yedi kurum aynı çekirdeği kendi alan adından ve kendi markasıyla işletiyor. Böyle bir sistemde en can sıkıcı kusur bir ekranın yanlış açılması değil, bir kurumun verisinin başka bir kurumun sayısına karışmasıdır.
Yöneticiler bu sınırı çoğunlukla liste ekranında sınar. Kendi panelini açar, listeye bakar, komşu kurumun kayıtlarını görmez ve sınırı sınadığını düşünür. Bu, sınamanın yalnız başlangıcıdır. Liste ekranı bir okuma anıdır. Sınır bir de kayıtların toplandığı anda, yani raporda sınanır ve rapor gösterim turunda genellikle tek kurumun verisiyle açılır.
Kabul senaryosu bu yüzden rapordan kurulur. Satıcı kabul için komşu bir kurum tanımlar. O kurumun kendi adresinden, tutarı sizin belirlediğiniz bir ödeme kaydı girilir; tutarı siz seçin ki raporda tanıyabilesiniz. Kendi kurumunuzun yöneticisi ay raporunu ödeme girilmeden önce alır, giriş yapıldıktan sonra bir kez daha alır. Aradaki tek değişken komşu kuruma girilen kayıttır.
Geçme koşulu açık: raporun toplamı değişmemiştir ve girilen tutar yalnız komşu kurumun raporunda durur. Toplam oynadıysa sınır raporun okuduğu katmana yazılmamış demektir ve bunu liste ekranı size hiçbir zaman söylemezdi. Koşulun öteki yarısı da önemli — tutarın komşunun raporunda gerçekten görünmesi, kaydın kaybolmadığını gösterir. Sınır kaydı yutarak da bozulur.
Bunun neden böyle olduğu, yani kiracı sınırının hangi katmanda yazıldığı ayrı bir konu; çok kiracılı sistemin nasıl kurulduğunu anlattığımız yazı onu açıyor. Kabul gününde size düşen teşhis değil eylem: gir, al, karşılaştır.
Tek kurumun kullandığı bir sistemde komşu yoktur, senaryo da yoktur. Ama bugün tek kiracıyla başlayan ve yarın komşu kurum açmayı planlayan bir sistemde senaryo kabul gününde kurulur; komşu kurumu satıcı zaten kabul için tanımlıyor.
Talep tiplerini arka arkaya açın, operasyona ayrı düştüğünü görün
Diotek’te keşif randevusu ile servis talebi ayrı akışlar olarak kurulu. Keşif mekânı merkeze alır: nereye bakılacak, alan ne durumda. Servis talebi kurulu cihazı merkeze alır: hangi cihaz, şikâyet ne. Aynı formdan geçmezler, çünkü operasyon tarafında da aynı işi başlatmıyorlar.
Kabul senaryosu bu ayrımı zorlar. Siteden art arda talep açarsınız ve sırayı bilerek karıştırırsınız: önce bir keşif randevusu, hemen ardından bir servis talebi, sonra yine bir keşif. Karıştırmanın nedeni sıra bağımlılığını yakalamaktır. Talepler doğru akışa girişin sırasına göre değil, kendi alanlarına göre ayrılmalı; ardışık ve karışık giriş bu ayrımı zorlayan en ucuz yoldur.
Geçme koşulu ekranda değil operasyon tarafında okunur. “Gönderildi” mesajı ziyaretçiye verilen bir onaydır, sınamanın çıktısı değil. Operasyon tarafını açın ve bakın: keşif randevuları kendi akışında mı, servis talepleri kendi akışında mı, her biri yazılı bir kayıt olarak mı duruyor. Hepsi doğruysa senaryo geçmiştir. Talep doğru akışta ama yazılı değilse, yani kaydın bir yerine düşmüş serbest bir not olarak duruyorsa, sezonun ortasında o not aranmayacaktır.
Alt senaryo mesai dışına bakar. Bir talebi akşam, kimsenin başında olmadığı bir saatte açın. Ertesi sabah operasyon tarafında o talep yazılı bir kayıt olarak duruyorsa akış insanın hatırlamasına bağlı değil demektir. Bu küçük ekleme kabul gününe neredeyse hiç maliyet bindirmez ve gerçek işleyişe en yakın anı sınar.
Burada dürüst bir sınır var. Diotek’in taşıdığı zorluğun bir yüzü sezon başında taleplerin üst üste binmesidir ve o yükü kabul gününde üretemezsiniz. Ardışık ve karışık sıralı giriş yalnız ayrımın giriş sırasına dayanıp dayanmadığını gösterir; gerçek sezon yükünün ayrımı bozup bozmadığını ancak sezon geldiğinde gözlersiniz. Kabul senaryosu bu yüzden bir kapanış değil bir başlangıçtır: sezondan sonra bakılacak bir gözden geçirme tarihini de aynı gün belirleyin.
Bu ayrımın neden başlı başına bir tasarım kararı olduğunu randevu ile servis talebini ayırdığımız yazıda yazmıştık. Sitesi tek tip talep alan bir işletmede ayrışma senaryosu yoktur. O zaman sınanacak şey ayrım değil, aynı formdan gelen talebin doğru kişiye düşüp düşmediğidir.
Senaryolar yan yana
Her satır aynı sırayı taşıyor: yapılan eylem, sistemin taşıdığı zorluk, tek taraflı gösterimin gösteremediği şey ve kaydın hâliyle yazılmış geçme koşulu. Son sütun tablonun varlık nedeni; geçme koşulu kaydın hâliyle yazılmamışsa senaryo bir izlenime bağlanır ve izlenim kabul günü herkeste olumludur.
| Senaryo (eylem) | Sistemin taşıdığı zorluk | Tek taraflı gösterimin göstermediği | Geçme koşulu (kaydın hâli) |
|---|---|---|---|
| Teknisyen kapsama dışında kaydın bir alanını, ofis aynı anda panelden başka bir alanını değiştirir; bağlantı döner | Sahadaki teknisyen ile ofisteki arkadaşı aynı kaydı birbirinden habersiz değiştirebiliyor | Tek taraftan yürüyen denemede çakışma hiç oluşmaz; öteki taraf masada yoksa kusur üretilmez | Tek kayıt; her alan kendi yeni değerinde; kopyası yok |
| Komşu kurumun adresinden bilinen tutarda ödeme girilir; kendi kurumunun ay raporu önce ve sonra alınır | Ödeme, öğrenci ve veli kayıtlarının hiçbiri kurum sınırının dışına çıkmamalı | Liste ekranında komşu kaydının görünmemesi; toplanan rakam ekranda sınanmaz | Kendi raporunun toplamı değişmedi; tutar yalnız komşu kurumun raporunda |
| Keşif randevusu ile servis talebi siteden art arda, karışık sırayla açılır | Keşif mekânı, servis kurulu cihazı merkeze alıyor; aynı form değiller; sezon başında üst üste biniyor | ”Gönderildi” mesajı; operasyon tarafı gösterimde açılmaz | Operasyon tarafında talepler ayrı akışta ve yazılı; giriş sırası ayrımı bozmuyor |
Üçüncü sütunda yazan şey satıcının kötü niyeti değil, gösterim biçiminin sınırı. Aynı satırı satıcı da okuyabilir ve okuduğunda kabul gününde ne hazırlaması gerektiğini görür.
Senaryoyu işi yapan seçer, kabul senaryo kaydıyla kapanır
Kabul toplantısının kimin elinde olduğu sorusu genellikle sözleşmeye bakılarak cevaplanır. Yanlış yer. Senaryoyu seçen, kaydın yanlış olabileceği yeri bilen roldür ve o bilgi sözleşmede değil işin içinde durur. Sahadan gelen kaydın hangi alanının ofisten de değiştiğini teknisyen ile ofisteki arkadaşı bilir. Ay raporunun hangi toplamına kimin baktığını kurum yöneticisi bilir. Yanlış akışa düşen bir talep yüzünden kimin arandığını operasyon masası bilir. Bu bilgi devredilemez, çünkü hiçbir yerde yazılı değildir.
Satıcının işi ortamı hazırlamaktır. Komşu kiracı tanımını açar, ek bir hesap verir, kapsama dışına çıkarılacak bir cihazı ayırır. Vipkurum’da komşu bir kurum açmak yeni bir kurulum değil yeni bir kiracı tanımıdır; sınama ortamı bu yüzden kabul gününe yetişir ve “ortam hazırlanamaz” cevabı geçerli olmaktan çıkar. Ortamı hazırlamak ile senaryoyu seçmek aynı iş değildir. Karıştırıldığında sınama satıcının bildiği yerleri dolaşır ve gösterim turunun uzun sürümüne dönüşür.
Kabulün çıktısı bir izlenim değil bir kayıttır. Her senaryo için şunlar yazılır: yapılan eylem, beklenen kayıt hâli, gözlenen kayıt hâli. Beklenen ile gözlenen örtüşüyorsa senaryo kabul edilir. Örtüşmüyorsa senaryo kabulün dışında ayrıca tarihlenir; kapanmamış bir satır kabul edilmiş gibi listeye girmez.
Satıcı senaryo önerebilir ve önerisi işe yarayabilir. Ölçüt basit. Öneri bir zorluk satırına eşleniyorsa listeye alın. Eşlenmiyorsa öneri, satıcının gösterebildiği bir şeyi gösteriyor demektir; faydasız olmayabilir ama kabulü kapatmaz. Seçim sizde kalır.
Kabul senaryosunu kaydın ilk yazıldığı yerden kurmak istiyorsanız, iş süreç takibi tarafında kaydın neye bağlandığına ve aynı kayda hem sahadan hem ofisten dokunulduğunda geriye ne kaldığına bakın.
