Özgeçmiş ayrıştırma için test verisi

Özgeçmiş ayrıştırma, bir dosyanın içindeki serbest metni unvan, işveren, tarih ve beceri gibi alanlara dönüştürme işidir. Bu yazıda bu işin neden tek bir dosya standardına oturmadığını, test kümesinin hangi düzen varyantlarını kapsaması gerektiğini ve sabit örneklerin zamanla nasıl eskidiğini bulacaksınız.

Özgeçmiş ayrıştırma neden tek bir standarda oturmaz?

Çünkü ortada uyulması zorunlu bir dosya düzeni yoktur. Bir özgeçmişi üreten araç çok sayıda olabilir ve her araç kendi görsel düzenini kurar. Başlıkların sırası, sütun sayısı, tarihlerin yazım biçimi ve bölüm adları üreticiden üreticiye değişir.

İkinci neden, aynı aracın bile kullanıcıya serbestlik tanımasıdır. Kullanıcı bir bölümü tablo hâlinde, başka bir bölümü düz paragraf hâlinde yazabilir. Bu yüzden ayrıştırma işi biçim doğrulaması değil, düzen varyantları altında alan bulma işidir.

Üçüncü neden, dil ve alfabe çeşitliliğidir. Tarih kalıpları, ay adları ve unvan sözcükleri dile göre değişir; bir dilde başlık olarak kullanılan sözcük başka bir dilde paragraf içinde geçebilir. Ayrıştırıcının başarısı, bu çeşitlilik altında da alanları bulabilmesine bağlıdır.

Aşağıdaki tablo, düzen çeşitliliğinin hangi alanı zorladığını özetler. Her satır, ayrıştırıcının farklı bir karar vermesini gerektirir.

Hangi düzen varyantları denenmelidir?

Test kümesinin değeri, kaç dosya içerdiğiyle değil hangi varyantları temsil ettiğiyle ölçülür. Aşağıdaki liste, en sık kırılma üreten düzenleri kapsar.

• Tek sütun ve çok sütun: Sol tarafta iletişim bilgisi, sağ tarafta deneyim bulunan iki sütunlu düzenler.
• Tablo hâlinde deneyim: Her satırın bir iş kaydı olduğu tablo biçimi.
• Düz paragraf: Deneyimin madde işareti olmadan akıcı metin hâlinde yazıldığı düzen.
• Etiket sütunu: Becerilerin virgülle ayrılmış etiketler hâlinde sıralandığı bölüm.
• Başlık sırası değişimi: Eğitimin deneyimden önce yazıldığı düzen.
• Eksik bölüm: Beceri veya sertifika bölümü hiç bulunmayan dosya.

Bu altı varyant, ayrıştırıcının gerçekten düzene bağımlı olup olmadığını gösterir. Yalnızca tek sütunlu dosyalarla yapılan bir deneme, kodun çalıştığını değil yalnızca en kolay durumu işlediğini kanıtlar. Ayrıştırma sonucunun hangi alanlara dönüştüğünü kariyer profili test kayıtları yazısından takip edebilirsiniz.

Varyantları seçerken iki noktaya dikkat etmek gerekir. Birincisi, her varyantın tek bir kırılma noktasını hedeflemesidir; aynı dosyada hem iki sütunlu düzen hem tablo biçimi bulunursa, test başarısız olduğunda hangi nedenin sorun çıkardığı anlaşılmaz. İkincisi, varyantların gerçek kullanım sıklığını yansıtmasıdır. Nadiren görülen bir düzen için ayrı dosya tutmak yararlıdır, ama kümenin tamamı nadir durumlardan oluşursa günlük kullanım hiç temsil edilmez.

Kümenin bir de bakım maliyeti vardır. Her varyant, beklenen alan listesiyle birlikte güncellenmesi gereken bir dosyadır; sayı arttıkça bakım yükü de artar. Yaygın denge, en sık görülen dört varyantı zorunlu tutmak ve kalanları bulunan her hata için teker teker eklemektir.

Sabit örnekler senaryoya göre mi numaraya göre mi düzenlenir?

Numaraya göre düzenlemek ilk bakışta pratik görünür: dosyalar sırayla adlandırılır ve liste uzar gider. Ne var ki bu düzen, dosyanın neyi temsil ettiğini sakladığı için kümeyi okunamaz hâle getirir. Bir hata raporunda dosya numarası göründüğünde, hangi düzenin bozulduğunu anlamak için dosyayı açmak gerekir.

Senaryoya göre adlandırma bunun tersini yapar. Dosya adı, temsil ettiği düzeni söyler; böylece bir test başarısız olduğunda hangi varyantın kırıldığı doğrudan görülür. Bu yaklaşımın ikinci faydası, kapsam boşluklarının görünür olmasıdır: listede iki sütunlu düzeni temsil eden bir dosya yoksa bu eksiklik hemen fark edilir.

Üçüncü fayda, beklentilerin aynı yerde tutulabilmesidir. Her senaryo için beklenen alan listesi dosyanın yanında tanımlanırsa, testin neyi doğruladığı koddan okunmak zorunda kalmaz.

Rastgele üretim neden hatayı tekrarlanamaz hâle getirir?

Rastgele üretilen bir kayıt, kapsamı genişletmek için yararlıdır ama tek başına yeterli değildir. Bir test başarısız olduğunda o kaydı yeniden üretmek gerekir; kayıt her çalıştırmada değişiyorsa aynı hatayı ikinci kez görmek mümkün olmaz.

Bu yüzden iki yaklaşımın işi farklıdır. Rastgele üretim, henüz bilinmeyen kırılmaları bulmak için kullanılır ve bulunan her kırılma sabit bir örneğe dönüştürülür. Sabit örnek ise bulunan hatayı korumak ve düzeltmenin kalıcı olduğunu göstermek için kullanılır.

Bu dönüşümü yapmamak, en sık yapılan hatadır: rastgele testte görülen bir sorun kayda geçirilmez ve bir sonraki sürümde aynı hata yeniden keşfedilir. Kural basittir: yakalanan her hata, kalıcı bir sabit örneğe dönüşmedikçe kapanmış sayılmaz.

Sabit örnekler zamanla nasıl eskir?

Sabit örnekler bir kez yazılıp bırakılabilecek dosyalar değildir. Üç nedenle eskirler. Birincisi, kaynak dosyaların düzeni zamanla değişir; gerçek dünyada kullanılan bir şablon güncellendiğinde onu temsil eden örnek artık o düzeni göstermez.

İkincisi, dil desteği genişler. Yeni bir dil eklendiğinde tarih kalıpları, ay adları ve bölüm başlıkları da değişir; eski küme bu varyantı içermez. Üçüncüsü, ürünün kendi alanları değişir. Yeni bir alan eklendiğinde bütün sabit örneklerin beklenen çıktıları güncellenmelidir.

Bu nedenle kümenin düzenli aralıklarla gözden geçirilmesi gerekir. Gözden geçirmenin en kolay yolu, her örneğin hangi varyantı temsil ettiğini ve en son ne zaman güncellendiğini kaydetmektir; böylece eskimiş örnekler tahminle değil kayıtla bulunur.

Gözden geçirmede üç soru sorulur. Örnek, gerçek dünyada hâlâ görülen bir düzeni mi temsil ediyor? Beklenen çıktısı, ürünün bugünkü alanlarıyla uyuşuyor mu? Ve bu örnek en son ne zaman bir hatayı yakaladı? Üçüncü sorunun cevabı uzun süredir boşsa, örnek büyük olasılıkla artık yeni bir şey ölçmüyordur.

Eskimiş örneği silmek yerine arşivlemek genellikle daha doğrudur. Silinen bir örnek, daha önce yakaladığı hatayı bir sonraki sürümde yeniden görünür kılabilir; arşivlenen örnek ise kapsamı daraltırken geçmişi korur.

Geliştiriciler için: ayrıştırma denemeleri ve beklenen alanlar

İlk karar, testin neyi ölçtüğüdür. Tam eşleşme aramak, farklı bir tarih biçimi yüzünden doğru sonucu yanlış sayar. Bunun yerine alan bazında beklenti tanımlamak ve her alanı ayrı puanlamak gerekir: hangi alanlar bulundu, hangileri bulunamadı, bulunanlar ne kadar doğruydu.

İkinci karar, normalleştirmenin testin içinde mi yoksa dışında mı yapılacağıdır. Karşılaştırmadan önce hem beklenen hem üretilen değeri aynı biçime indirmek, gereksiz başarısızlıkları ortadan kaldırır. Örneğin tarihleri tek bir gösterime çevirmek, ayrıştırıcıyı değil biçim farkını ölçen testleri eler.

Üçüncü karar, kısmi başarının nasıl raporlanacağıdır. Bir dosyada yalnızca bir alan yanlış bulunduysa bu, hiçbir alanın bulunamadığı durumdan farklı bir sorundur. İki durumu aynı hata olarak raporlamak, düzeltme sırasını belirsizleştirir.

Son olarak, ayrıştırma denemelerini form tarafındaki denemelerle birleştirin. Yüklenen bir dosyanın alanlara dönüşmesi ile o alanların forma doldurulması tek bir akışın iki adımıdır; ayrı ayrı doğru çalışan iki adım, birleştiğinde beklenmedik biçimde bozulabilir. Form tarafındaki kapsamı işe alım formu test senaryoları yazısında ele alıyoruz.

Sonraki adımlar

İlk adım, mevcut test kümenizi serbest metin düzenlerine göre yeniden adlandırmak ve her dosyanın hangi varyantı temsil ettiğini yazmaktır. İkinci adım, rastgele üretimde yakalanan her hatayı kalıcı bir örneğe dönüştürme kuralını ekibe yerleştirmektir.

Sabit bir kayıt kümesi kurmak için kariyer profili üreticisinde ülke seçip kayıt üretebilir, aynı kimlik anahtarıyla aynı kaydı geri getirebilirsiniz. Türkiye kayıtlarının alan biçimleri için Türkiye sayfası kısa bir özet sunar.

Bu yazıdaki test dosyaları ve beklenen alan listeleri yalnızca yazılım denemeleri için kurulmuş örneklerdir; içlerinde gerçek bir kişiye ait özgeçmiş bilgisi bulunmaz.