Kalite kontrol (QA) sürecinin 5 temel adımı

İçerik ve tasarım süreci sona erdiğinde tüm bu arşiv, çeşitli araçlar yardımıyla yazılım ekibine aktarılır ve kullanıcı deneyimini kurgularken iletişim kaybı olmaması için çaba sarf edilir (bakınız: Tasarımcı ve Yazılımcı İletişimi 101). Mutlaka ki yazılım ekibi de bunlara dayanarak zaten deneyimi final haline getirmek için çalışır. Ancak test süreci geldiğinde, “Tasarımdan yazılıma hangi dosyalar gitmişti?”, “Deneyim nasıl kurgulanmıştı?”, “Lorem ipsum yazan yerde aslında ne yazması gerekiyordu?”, “O butonun üzerine gelindiğinde nasıl bir animasyon hayal edilmişti?” gibi sorulara cevap verebilmek için tüm bu arşive ihtiyacınız olacak. Dolayısıyla, test süreci, testlerin yapılmaya başlandığı andan önce yapılacak hazırlıkla başlar ve dokümantasyon bunun için çok önemli.

2) Kimler test yapmalı?

Test süreci, deneyimi tasarlayan herkesin aktif şekilde yer alması gereken bir süreç. Kullanıcı deneyimi stratejisini kurgulayan, deneyime ait içerikleri yazan, wireframe’leri çizen, arabirim tasarımını yapan, projeyi yöneten, ölçümleme altyapısını oluşturan, yazılım geliştirmesini yapan herkes mutlaka test yapmalıdır. “Test, testçi rolünde olan kişinin işi değil mi? Bu kadar çok kişinin test yapmasına gerek var mı?” demeyin. Her ne kadar üretim ekibindeki herkesin test ederken ana odağı ve ortak amacı “kullanıcı deneyiminin doğru yansıtılmış olduğundan emin olmak” olsa da herkes detaylarda kendi uzmanlık alanına göre test yapar. Örneğin, içerik yöneticisi yazım hatalarına herkesten çok daha fazla dikkat ederken, arabirim tasarımcısı görsellerin kadrajlarına ve tasarım öğeleri arasındaki boşluklara daha fazla dikkat eder. Bu nedenle, verimli bir test süreci için üretimde görev alan herkesin gözüne ihtiyaç var.

3) Nereden başlamalı? Ne kadar sürmeli?

Dokümantasyon tamam, test ekibi de belli. Peki testlere nereden başlayacağız, nasıl bir yol izleyeceğiz, nerede son vereceğiz? Bunun için, başlamadan önce bir adet “checklist” oluşturmakta fayda var.

Bir web sitesinin test süreci için aşağıdaki örnekte hangi sayfada, neyi, nasıl kontrol edeceğinize dair bir liste bulabilirsiniz. Bunu yayına alınacak her bir sayfa için değişen elementleri de ekleyerek özel olarak oluşturmakta fayda var. Örneğin, alt sayfalardan biri form sayfası olabilir ve o zaman “Formdaki input alanlarının nasıl doldurulacağına dair yönlendirmeler var.” gibi spesifik bir kriter ekleyebilirsiniz. Projenin kapsamına göre hangi tarayıcılarda test edileceğini de önceden belirlemek, testlerde herhangi bir viewport’un atlanmaması açısından önemli. Bu dosyayı ortak bir alanda tutabilir, testlerde görev alacak herkesin ayrı bir “sheet” açarak bu sıralamayı takip etmesini sağlayabilirsiniz. Başladıktan sonra her bir modülün ayrı test senaryoları yazılarak tek tek test edilmesi gerekecek fakat sürece başlamadan önce nereden / nasıl başlanacağına dair kafa karışıklığının giderilmesi için buna benzer gibi bir dosya size rehberlik edecektir.

Baştan belirlediğiniz tüm kriterler test edilmişse testlerde sona yaklaşmışsınız demektir. Fakat bu noktada da ne zaman sona ereceğini net bir şekilde belirlemek için bazı tanımlamaları önceden yapmak gerekiyor. Bulgularınızdan hangileri “yeni istek (özellik)”, hangileri “bug (hata)” hangileri “kozmetik düzenleme” olarak değerlendirilmeli? Proje sahibi dahil, testlerde görev alan herkesin bu tanımlamalarda fikir birliğine varmış olması, test sürecinin verimli geçmesi için kritik önem taşıyor. Proje süresine bağlı olarak bug olarak işaretlenen bulgulardan başlayıp — kapsama bağlı olarak — kozmetik isteklerin çözümü için de çalışılabilir. Ancak test sürecinin sonsuzluğa doğru uzamaması için yeni isteklerin projenin sonraki fazlarında değerlendirilmek üzere not edilmesi önemli.

4) Hangi araçları kullanmalı?

Testlerde kullanılacak araçlar projeden projeye değişkenlik gösterir. Yine bir web sitesi projesini ele alacak olursak, testin yapıldığı tarayıcının özellikleri, bilgisayarın türü/markası, ekran çözünürlüğü, bulgunun hangi URL’de, sayfanın tam olarak neresinde, hangi aksiyonu alırken ortaya çıktığı gibi bilgileri tek bir seferde yazılım ekibine iletmek ve sonrasında da takip etmek için e-postalarda kaybolan “word” dosyalarından daha verimli çalışacak bir yönteme ihtiyaç duyulduğu kesin. E-postada yazılmış bir notu, yazılım ekibinin yeniden üretememesinin önüne geçmek için olay anına dair bir ekran görüntüsü de olsa hiç fena olmaz.

Tüm bunları tek seferde iletebilmek için biz bu tip projelerimizde Usersnap’ten faydalanıyoruz. Usersnap’te yukarıda bahsettiğim tüm bilgileri ekranda işaretlenen belirli bir alanın görüntüsüyle birlikte iletebiliyoruz. Bulguyu ileten kişi “reporter” (raporlayan) rolünde konunun takibini yapmaya devam edebiliyor, “assignee” (atanan) rolündeki kişiden bu konuda geribildirim alabiliyor. Bulgulara dair numaralandırma ve daha önce bahsettiğim “bug” (hata), “yeni istek”, “kozmetik” gibi etiketlendirmeler sayesinde yazılım ekibi önceliklendirmeyi yapabiliyor.

5) Kontrolün kontrolü nasıl olur?

Son olarak, test sürecinin tek yönlü bir süreç olmadığının altını çizmek istiyorum. Test yapıp bulguların ilgili kişilere atamasını yapınca sorumluluk sona ermiyor; sonrasında açılan ticket’ların kontrolünü yeniden yapmak ve çözüldüğünden emin olmak gerekiyor. Bu nedenle, tüm test ekibinin hem bu “online” araçlar yardımıyla hem de bildiğimiz “offline” yollarla diyaloğu sürdürmesi, sürecin daha verimli geçmesini sağlayacaktır. Her projede olduğu gibi, düzelen yerlerin, çalışan başka yerleri bozma ihtimaline karşılık genel bir kontrol yapmayı da ihmal etmeyin.

Bu yazıda, çok daha kontrollü bir test süreci geçirmeye yardımcı olacak ipuçlarını listelemeye çalıştım. Fakat ne kadar kontrollü, önceden hazırlıklı, standartlara uygun bir şekilde test sürecine girerseniz girin, her projenin kendine has bazı problemlere sahip olabileceğini ve beklenmedik durumlarla karşı karşıya kalınabilineceğini de unutmayın — bu durumlar kendi içinde özel olarak çözülebileceği için önceden hazırlıklı olmamanız normal; kendinize çok yüklenmeyin derim 🙂