Agile & Scrum Çalışma Metodolojisi ile Team Foundation Server Üzerinden Test ve BUG Yönetimi

Agile & Scrum çalışma metodolojisi için en iyi araçlardan biri olan Microsoft Team Foundation Server üzerinde Test işlemleri ve BUG yönetimini anlatacağım. Özellikle Bug yönetiminin kolaylığı sayesinde hem Test işlemleri daha da hızlanıyor hemde Developer-Tester arasındaki Fix süreci daha da verimli olabiliyor.

Anlatımı www.visualstudio.com/tfs üzerinden yaptım. Sizde ekip olarak Scrum ile çalışıyorsanız ücretsiz Microsoft üyeliği alarak link üzerinden Online Board yönetiminizi yapabilirsiniz.

TFS'de anlık işlerimiz Work sekmesi altındadır. Burada Current kısmından o an bulunduğumuz Sprint'i görürüz. Backlog kısmından Sprint içine aldığımız PBI'lar vardır. Board kısım asıl anlatacağım yer. Capacity kısmı ise takımın haftalık saat kapasitesini gösterir.

Yukarıdaki resimde (Resim üzerine tıklayarak tam boyut görebilirsiniz) örnek BUG şemasını ekledim. Burada PBI içine New item diyerek Task(Sarı) veya Bug(Kırmızı) seçeneği çıkar. Bug diyerek bulgumuzu ekliyoruz. Bug'ın adını yazıyoruz, çift tıklayıp Bug penceresi açılacaktır. Bu kısmı en son anlatacağım. Bug ekledikten sonra Board kısmında New(To Do), Active(In Progress), Resolved(In Review), Closed(Completed) alanlarımız var. Bu alanları tek tek anlatmak gerekirse;

1) New(To Do): Bu kısma Tester yeni bulgu ekler ve Developer'a haber verir. Her yeni bulgu bu kolona eklenir. (Tester'ın Alanıdır)

2) Active(In Progress): New kısmında bulguyu gören Developer hatanın içeriğini inceler ve hatayı kabul ediyorsa üzerine Assign eder ve Active kolonuna Developer bulguyu çeker. (Developer'ın Alanıdır)

3) Resolved(In Review): Developer hatayı çözüp Fix ettikten sonra Active kısımdaki bulguyu Resolved kısmına kendisi çeker ve Tester'a kontrol etmesi için haber verir. Burası Tester'ın Validate alanıdır bu kısımdan sonrasına artık Developer karışmaz, New kısımda yeni bir bulgu varsa onunla ilgilenir. Burada yapılan en büyük iki yanlış vardır.

- Developer Resolved yerine direk Closed kısmına almaktadır bu davranış yanlıştır.
- Developer bulguyu çözdükten sonra Remove(Delete) yaparsa bu davranış da yanlıştır.

Developer Resolved kısma bulguyu aldıktan sonrasını düşünmemelidir. Tüm kontrol ve süreç artık Tester'da dır. Tester, hata çözülmüş mü kontrol eder. Eğer hata çözülmüş ise Tester Closed alanına bulguyu alır. Eğer hata çözülmemiş ise Active kısmına geri gönderir ve Developer'a haber verir.

Ek olarak bazen bir bulgu çözülünce başka bir bulgu çıkabilir. Burada Developer çözdüğü bulguyu Active kısma aldırmak yerine Tester'dan yeni bulgu açmasını ister. Eski çözdüğünü ise Closed kısmına siz alabilirsiniz.

4) Closed(Completed): Bu alana Tester bulgu çözüldüyse çekmektedir ve o bulgu ile ilgili kontrol bitmiş ve hata çözülmüş demektir.

Bug üzerine geldiğiniz zaman o hatayı siz bir Developer'a Assign edebilir veya Developer kendisi Assign ettirebilir. (Hiç Assign etmeden de süreci işletebilirsiniz.) Scrum'da bir PBI ile birden fazla kişi uğraştığı için geliştirme ve hatayı çözme kısmı farklılık gösterebilir. Aynı zamanda Bug için saat bazında maliyet Developer verebilir. Fakat burada vereceğiniz saat maliyeti sizin Sprint çalışma saatinize eklenecektir, aldığınız iş saati artacaktır (Task gibi) ve Burndown alanına yansıyacaktır.

Bug penceresi içerisinde tıkladığımızda doldurmamız gereken yerleri aşağıda yazdım. Bu üç alan dışında diğer alanları da kullanabilirsiniz fakat aşağıdaki üç alan genelde kesin doldurmanız gereken yerlerdir.

Repro Steps: Test Case ve Bug Açıklaması bu alana girilir. Buraya hata ile ilgili görselde ekleyebilirsiniz.
Priority: Bug önceliğidir. Hangisi öncelikli ise buradan belirtebilirsiniz.
Severity: Bug'ın seviyesini gösterir. Critical, High, Medium ve Low

Kaynaklar
en.wikipedia.org/wiki/Team_Foundation_Server (Team Foundation Server)
www.visualstudio.com/tfs (Team Foundation Server)