Personel self servis, çalışanların kendilerine açılan PDKS bilgilerine web tarayıcısı veya mobil uygulama üzerinden eriştiği çalışan ekranıdır. Böyle bir portalı seçerken yalnız “çalışan giriş yapabildi” sonucunu kabul etmeyin. Doğru karar; doğru kişinin doğru hesaba girdiğini, yalnız yetkili olduğu veriyi gördüğünü, kaynak kayıtla ekrandaki sonucun uyuştuğunu ve işten ayrılışta erişimin kapandığını yedi senaryoyla kanıtlamaktır.
En kısa kabul kuralı şudur: web ve mobil kanalda aynı test kişisiyle oturum açın; kişinin kendi kaydını, başka bir çalışanın kaydına erişemediğini, hatalı giriş ve hesap kurtarma davranışını, oturum sonunu ve pasife alma sonucunu kanıtlayın. TigerBio Kontrol Yazılımı sayfası çalışanlara mobil uygulama ve web tarayıcısı üzerinden self servis sunulduğunu belirtir. Fakat portalda hangi kayıtların görüntülendiğini, hangi taleplerin oluşturulduğunu veya erişimin hangi kuralla kapandığını açıklamaz. Bu nedenle teklif ve demo sırasında kapsamı ekran adıyla değil, beklenen olay ve kanıtla yazın.
Personel self servis devreye alınmadan neyi kanıtlamalı?
İlk karar “portal var mı?” değil, “portal hangi çalışan işini hangi yetkiyle tamamlıyor?” olmalıdır. Bir çalışanın kendi giriş-çıkışını görmesi, izin talebi göndermesi, puantaj sonucuna itiraz etmesi ve bordro belgesi indirmesi birbirinden farklı veri ve işlem kapsamlarıdır. TigerBio’nun giriş-çıkış, izin ile günlük ve aylık puantaj başlıklarını listeleyen yazılım kapsamı, PDKS tarafındaki konu alanlarını gösterir; bu başlıkların tamamının çalışan portalında açık olduğunu kanıtlamaz.
Bu ayrımı satın alma dosyasında üç sütunla kurun: “çalışanın yapacağı iş”, “görmesine veya değiştirmesine izin verilen veri” ve “kabul kanıtı”. Örneğin hedef yalnız kendi giriş-çıkışlarını görüntülemekse, testin başarısı başka bir çalışanın kaydının görünmemesi ve seçilen tarihteki olayın kaynak kayıtla eşleşmesidir. Hedef hata bildirmekse, bildirimin ham olayı silmeden ayrı bir talep veya not olarak izlenebilmesi gerekir. Teslim edilen sürüm bu işlerden birini desteklemiyorsa, sonucu eksik kapsam olarak yazın; var olmayan menüyü varsaymayın.
Bu nedenle personel self servis kapsamını bir özellik listesiyle değil, çalışan işi başına ölçün. Her iş için başlangıç rolünü, izin verilen veriyi, yasaklanan işlemi ve kanıt sahibini yazın; böylece pilot sonunda “ekran açıldı” yerine sınanabilir bir kabul kararı oluşur.
Yedi testi aynı çalışan yaşam döngüsünde çalıştırın
Dağınık ekran kontrolleri yerine tek bir test çalışanını işe girişten ayrılışa kadar izleyin. Her test için başlangıç verisini, işlemi, beklenen sonucu, görülen sonucu ve kanıt ekranını önceden tanımlayın. Aşağıdaki tablo, ürün özelliği iddiası değil; teklif edilen sürümü ölçmek için kabul planıdır.
| Test | Uygulanacak işlem | Beklenen kanıt | Başarısızlık kararı |
|---|---|---|---|
| 1. İlk erişim | Aynı çalışan hesabıyla desteklendiği beyan edilen web ve mobil kanalda oturum açın. | Hesap doğru personel koduna bağlanır; desteklenen kanallar ve sürümler teklif kaydıyla eşleşir. | Bir kanal çalışmıyorsa kapsamı daraltın veya düzeltme sonrası yeniden test edin. |
| 2. Kendi veri sınırı | Çalışanın kendi tarih aralığını açın; ardından başka personele ait bilinen bir kayıt veya adresi deneyin. | Kendi yetkili kapsamı görünür, diğer çalışan kaydı açılmaz ve yetkisiz deneme kayda alınabilir. | Başka personele ait veri görünüyorsa canlıya geçişi durdurun. |
| 3. Kaynak kayıt uzlaştırması | Bir giriş ve bir çıkış olayını portal, ham terminal olayı ve günlük sonuçta karşılaştırın. | Personel kodu, tarih, saat ve olay yönü aynı kişiye bağlanır; fark varsa katmanı belirlenir. | Kaynak ile ekran ayrışıyorsa hesap sonucu kabul edilmez. |
| 4. Bildirim veya talep | Teklif kapsamındaysa eksik kayıt için çalışan işlemi oluşturun ve yetkili kararını izleyin. | İlk olay korunur; çalışan isteği, karar veren kişi, zaman ve sonuç birbirinden ayrılır. | Ham kayıt sessizce değişiyorsa süreç yeniden tasarlanır. |
| 5. Hatalı giriş ve kurtarma | Yanlış parola denemeleri ve unutulan hesap için tanımlı kurtarma yolunu uygulayın. | Deneme sınırı, kimlik doğrulama adımı, bildirim ve destek sorumlusu belgelenir. | Kimlik kanıtı olmadan erişim veriliyorsa kabul durur. |
| 6. Oturum sonu | Paylaşılan veya kayıp cihaz senaryosunda çıkış yapın; süre dolumu ve eski oturumu yeniden deneyin. | Beklenen çıkış veya süre sonu davranışı gerçekleşir; eski oturumun durumu açıktır. | Açık kalan oturum için risk ve düzeltme sahibi belirlenir. |
| 7. İşten ayrılış | Test çalışanını belirlenen saatte pasife alın ve web, mobil ile kurtarma yolundan tekrar deneyin. | Yeni erişim kapanır; geçmiş kayıtların kurum politikasına göre korunması erişim kapanmasından ayrı ele alınır. | Hesap kullanılabiliyorsa ayrılış süreci canlıya alınmaz. |
Yetki testini yalnız olumlu senaryoyla bitirmeyin
Çalışanın kendi ekranını açabilmesi yalnız olumlu testtir. Asıl sınır; aynı bağlantının, filtre değerinin veya kayıt kimliğinin başka bir çalışan hesabıyla değiştirildiğinde ne olduğudur. Test ekibi başka kişiye ait gerçek veriyi rastgele kullanmamalı; iki kontrollü test hesabı ve önceden hazırlanmış örnek olaylarla çalışmalıdır. Beklenen sonuç “ekran boş kaldı”dan daha açık yazılmalıdır: erişim reddedildi, başka çalışanın bilgisi dönmedi, hata mesajı gereksiz ayrıntı sızdırmadı ve deneme destek ekibinin inceleyebileceği bir kayıt üretti.
Rol ayrımını da aynı veri üzerinde ölçün. Çalışan, yönetici, insan kaynakları ve sistem yöneticisi hesabının hangi alanı görebildiğini ve hangi işlemi başlatabildiğini bir matrisle karşılaştırın. Çalışanın başlattığı bir düzeltme isteği varsa, isteğin kendi ham giriş-çıkış olayını doğrudan değiştirmemesi; yetkili karar ve yeniden hesaplama adımlarının ayrı izlenmesi daha denetlenebilir bir akış sağlar. Bu davranış TigerBio sayfasında ayrıntılandırılmadığı için demoda açıkça sınanmalı ve sözleşme kapsamına göre kabul edilmelidir.
Portal ekranını ham olay ve puantajla uzlaştırın
Personel self servis ekranında görülen saat, tek başına kaynak kayıt değildir. Aynı test için terminaldeki ham olay, yazılıma ulaşan personel kimliği, vardiya günü ve günlük sonuç yan yana konmalıdır. Gece yarısını aşan vardiya, eksik çıkış veya sonradan verilen izin gibi durumlarda portalın hangi değeri gösterdiği ve bu değerin ne zaman yenilendiği sürüm üzerinde ölçülmelidir. Aylık kapanışa etkisini ayrıca görmek için ay sonu puantajını kaynak kayıtla uzlaştıran test planını aynı örnek çalışanla uygulayabilirsiniz.
Bir fark bulunduğunda çalışan ekranındaki saati hemen “yanlış” diye değiştirmeyin. Önce olay terminalde var mı, doğru kişiye bağlanmış mı, aktarım tamamlanmış mı ve vardiya kuralı olayı hangi güne yazmış sorularını yanıtlayın. Ardından çalışan bildirimi, yetkili karar, eski değer ve yeni değer için ayrı kanıt saklayın. Böylece portal, kaynağı belirsiz manuel düzeltmelerin yapıldığı bir ekran değil; sorunun hangi katmanda olduğunu gösteren kontrollü bir temas noktası olur.
Hesap kurtarma, oturum ve ayrılış için eşik yazın
Unutulan parola ve kayıp telefon senaryosu, normal giriş kadar önemlidir. NIST SP 800-63B, kimlik doğrulayıcı yaşam döngüsü, hesap kurtarma, oturum ve geçersizleştirme için risk temelli kontroller tanımlar. Bu rehberi ürüne otomatik bir uygunluk etiketi vermek için değil, şu soruları hazırlamak için kullanın: kurtarma isteğini kim doğrular, eski erişim ne zaman geçersizleşir, kullanıcıya hangi olay bildirilir ve destek ekibi hangi kanıtı tutar?
Yetkileri görev için gerekli kapsamla sınırlamak ve ayrıcalıklı hesapları ayırmak için CISA kimlik ve erişim yönetimi önerilerindeki kontrol başlıklarını test formuna aktarın. Örneğin İK kullanıcısının çalışan hesabı üzerinden yönetim işlevine geçememesi, destek hesabının gereksiz personel ayrıntısını görmemesi ve ayrılan çalışanın eski oturumunun yeniden kullanılamaması ayrı satırlar olmalıdır.
Kişisel verilere erişimin amacı, kapsamı ve sorumluları kurumunuz tarafından belirlenmelidir. KVKK’nın veri güvenliği yükümlülükleri açıklaması, hukuka aykırı erişimi önlemeye ve uygun teknik-idari tedbirleri almaya ilişkin genel çerçeveyi verir. Bu yazı hukuki görüş değildir; hangi verinin portala açılacağı, ne kadar tutulacağı ve ayrılış sonrası hangi erişimin kapanacağı için kurumunuzun güncel hukuki ve operasyonel değerlendirmesi gerekir.
Kabul kararını kanıt paketiyle kapatın
Yedi test bittiğinde her satırı “geçti”, “düzeltme sonrası yeniden test” veya “kapsam dışı/ret” olarak kapatın. Kanıt paketinde teklif edilen sürüm, web ve mobil test tarihi, test hesapları, beklenen sonuç, ekran kanıtı, ham olay kimliği, puantaj karşılığı, hata sahibi ve yeniden test tarihi bulunmalıdır. Özellikle “mobilde var, webde yok” veya “çalışan görür, yönetici onaylar” gibi farklar sözlü bırakılmamalı; hangi kanal ve rolün teslim kapsamına girdiği yazılmalıdır.
Kararınız olumluysa önce sınırlı bir çalışan grubuyla pilot yapın; erişim sorularını, yanlış kişi eşleşmesini, hesap kurtarma taleplerini ve kapanmayan ayrılış hesaplarını günlük izleyin. Kapsam veya rol davranışı belirsizse yedi senaryolu kabul tablonuzla TigerBio teknik görüşmesi planlayın ve her belirsizliği sürüm ile teslim kapsamına bağlayın. Demo sonucunu ürün sayfasındaki beyanla karşılaştırmak için Kontrol Yazılımı’nın web ve mobil self servis kapsamını yedi testinizle doğrulayın; yalnız giriş ekranını değil, veri sınırını ve hesap yaşam döngüsünü kabul edin.
