QA/BugTriage/tr

From The Document Foundation Wiki
< QA‎ | BugTriage
Jump to: navigation, search

Giriş

Bu belge LibreOffice için hataların acil önceliklerinin nasıl olacağı hakkında bilgi sağlar. Hata raporlarını onaylamak, öncelik vermek ve düzenleme işlemlerinin tamamı acil önceliklerinin anlamını verir ve bu alan LibreOffice'in herkes için daha iyi bir ürün olması için sınırlı programlama yetenekleri ile yeni katılımcılar ve/veya katkıda bulunanlar için iyi bir yerdir. Acil öncelik belirlemek geliştirmenin önemli bir yönüdür bu hem kullanıcılar hem de geliştiriciler için faydalı.

Diğer QA Üyelerini Bulabileceğin Yer

QA ekibi ile iletişime geçeceğin bir kaç yer var, birçoğu öncelik soruları için yardımcı olabilir..

  1. Mail Listesi
    • libreoffice-qa@lists.freedesktop.org
    • libreoffice@lists.freedesktop.org
  2. IRC Kanalı
  3. QA Üyeleri
    QA üyelerinin listesi burada (Eğer QA için katkıda bulunmak istiyorsanız kendi adınızı eklemekten çekinmeyin.). Eğer kullanıcının onlara direkt erişimine izin verildiyse bu durumda çekinmeyin.

Acil Öncelikli Hata Adımları

Bu bölümde doğru sırayla acil öncelik için gerekli adımları listelenir. Bu klavuz kısa ve öz olmayı hedefliyor, adımlardaki özelliklerle ilgili linkler bazı bölümlerde daha fazla bilgi sağlayacak. Acil öncelik işlemleri üç parçaya bölünebilir İlki "hazırlık", ikincisi "yeniden türetmesi üçüncüsü "önceliği"

Adımların özeti

  1. Acil öncelik için hataları bulmak
  2. Hata raporlarında ön eleme yapmak
  3. Hata çiftlerini aramak
  4. Hata raporlarındaki bilgilerin kontrolünü sağlamak
  5. Hatayı yeniden oluşturmaya çalışmak
  6. Hata durumunu ayarlamak
  7. Hata önceliği belirlemek
  8. Geliştiriciyi bilgilendirmek --Sadece özel durumlarda gerekli örneğin hata engelleyici/kritik gözüküyorsa

Adımların detayları

Hazırlık

In general you'll always want to do the following steps in preparing to triage bugs. Genel olarak sen her zaman aşağıdaki adımları öncelikli hataları hazırlarken yapmak isteyeceksin. Hatırlarsanız hataları yalnızca burada oturum açtığınızda çalışıtabilirsiniz (lütfen buradan [1] bir hesap oluşturunuz eğer önceden yoksa.). Ve bir hesabınız olduğunda, istediğiniz özellikleri ayarlayabilirsiniz [2] ve eğer raporladığın hata için cevaplar alındığında haberdar olmak için 'Otomatik olarak CC listesine beni de ekleyin' seçeneğini seçebilirsin.

Adım 1. Acil öncelik için hataları bulmak

a) Bugzilla Arama

LibreOffice ait hata takip sistemi mevcut bugs.documentfoundation.org. Raporladıktan sonra, [3]bileşen tarafından açık olan diğer hatalara göz atın veya hatalar için özel bir arama yapın:

a) LibreOffice ürününü bulun

b) UNCONFIRMED veya REOPENED durumuna sahip olmalı

c) Sorgulamak için diğer kriterler ne olursa olsun ekleyin

Hata için arama yapın isterseniz acil önceliği olan. Hatalar için özel aramalar olabilir Gelişmis arama formu veya hızlı arama yapmak için Hızlı Arama alanına terimler girilebilir (Bugzilla Hızlı Arama Yardım). Ayrıca aşağıdaki direk linkleri arama için kullanabilirsin. Linke tıkladığınızda Bugzilla sonuç sayfası açılır.

Adım 2. Hata Raporlarında Ön Eleme

Bazı hatalar için özel ekipler tarafından özel bakıma ihtiyac vardır.

UX Geliştirmeleri

LibreOffice'in UI/UX geliştirmelerini kapsayan herhangi bir hata UX ekibine verilmelidir.

  1. ux-advise için Bileşen değiştirin
  2. Durumu güncelleyin
    • Eğer istek akla yatkın tamamlanabilir gözüküyorsa, Durum -> YENİ
    • Eğer istek tamamlanamaz ve açıklanması gerekiyor gözüküyorsa, Durum -> BİLGİ İHTİYACI
  3. Satır aralarına yorum bırakın:
UX Takımı -- bu geliştirmeye bir göz atın lütfen. Teşekkürler!


Bazı hatalar Bugzilla'ya ait değil. Başka bir yere ait konu listesi için, bakınız Hata Raporlama Sayfası.

  • Eğer bu hatalardan birini Bugzillaya bildirdiğinizde Durum içinRESOLVED NOTOURBUG değişikliği yapın ve yoruma aşağıdakileri ekleyin:
Bizimle iletişime geçtiğin için teşekkürler!
Bugzilla bazen Evrenin merkezi gibi hissediyor olsa da, 
başka bir yerde bildirilmesi gereken birkaç konu var.
reported elsewhere. To find the right place to report
Sorununuzu bildirmek için doğru yeri bulmak için:
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Adım 3. Yinelenen Hataları Bulmak

Yinelenen hatalar RESOLVED DUPLICATE ile işaretlenir bunlar çok benzer veya aynılardır ama farklı kullanıcılar tarafından bildirmişlerdir. Bu tür hatalar Bugzilla tarafından otomatik olarak sayılıyor ve saklanıyor. [4] En sık raporlanan hatalar sayfası. Acil öncelik belirlerken lütfen listeyi kontrol edin ve Bugzilla hataları üzerinden hızlı bir arama yapın yinelenen hatanın olup olmadığını görmek için ama bunun için çok zaman harcamanıza gerek yok. Birçok hata gördüğünde benzer bir hata görmüş olabilirsin bu durumda iki(veya daha çok) hatdan yeni olanı kapatın. Genelde Bugzillaya girilmiş yinelenen hataların sayısını en aza indirmek QA Ekibine zaman kazandıracaktır.

Yinelenen bir hata bulursanız adım #5 atlayın

Adım 4. Bilgileri Kontrol Et

Bilgileri kontrol etmek geliştirme için önemlidir. Bakmanız gerekenler şunlardır:

  1. Açık ve anlamlı özet
  2. Problemin açık şekilde anlatılması
  3. Sorunu yeniden oluşturabilmek için adımlar -- eğer özet veya açıklamanız net değilse
  4. Eklemeler -- Sorunu yeniden oluşturabilmek için bir çok durumda ekler gerekebilir, eğer eklemeler durumu sağlamıyorsa bu uygun düzeltme yapmaya engel olabilir

Eğer tüm bilgiler doğru değilse adım #5 atlayın


Adım 5. Yeniden Deneyin

Eğer hatanız "geçti" ise Hazırlık adımları o hatayı yeniden denemenin tam vakti.
Sadece bunu yapın: Gerekli adımları üzerinden gidin ve hata yeniden deneyin, bu kadar basit! Hatayı yenileyebildiğin zaman, aşağıdakileri aklında tut:

  1. Bugzillada hata raporlayan yeterli bilgi bıraktı mı hatayı yeniden oluşturabilmek için veya ekstra adımalra ihtiyacın var mı? Eğer ekstra adımlara ihtiyaç varsa, fazladan bir adım(lar) tanımlamak için bir açıklama ekleyin.
  2. Yineleme sonucu aynı sonuç oluştu mu, benzer ama aynı değil mi, veya herşey ksuursuz şekilde çalıştı mı?


Adım 6. Durumu Ayarla

Bu bölüm başarılı acil öncelik belirleme adımlarından en sonununcu "zorunlu" adımdır ve bu sadece #1-#4 adımlar için bir kez yapılabilir(#4 geçerli değilse #3 için)

DURUM yukarıdaki adımlardan sonra hatanın sonuçlarına bağlı. Her durum kullanımı için kısa bir açıklama aşağıdadır. 
  1. YENİ: Hata doğrulandı, tüm gerekli bilgileri var.
  2. BİLGİ GEREKLİ: Yineleme girişimi için gerekli tüm bilgiler hata raporunda dahil değildir. Lütfen belirli kişiye ayrıntıları yorumda sorun.
  3. ÇÖZÜLDÜ: Bu kategoride bir kaç seçenek mevcut,eğer hatayı yenileyemiyorsan ÇÖZÜLDÜ BENİM İÇİN ÇALIŞIYOR durum için uygundur, daha çok bilgi için bakınız BURADA
  4. DOĞRULANDI: Bu seçenek mevcut hata durumu ÇÖZÜLDÜĞÜNDE kullanılabilir. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
  5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
  6. UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

ANY time you make changes you should put a comment that politely explains why you made the change

Flowcharts below are examples of how to visually think of setting STATUS. Feel free to edit and upload your own version if you'd like.
PDF file
LibreOffice Draw file

Step 7. Prioritize Bug

We currently highlight only critical bugs by CC-ing developers, adding special whiteboard entries, keywords, and updating MABs. See below for more information.

Bug prioritization for LibreOffice is currently a mess, but as triagers we should always be actively trying to make it better. Prioritizing a bug is relatively subjective, but the triager should always try to be consistent with how they determine a bug's prioritization. The QA team member triaging should have a clear idea of what constitutes each priority state and then try to stick with that methodology. Also, commenting on the bug after prioritizing is incredibly important to let the bug reporter (as well as developers and other users) know what thought process you used to come up with the priority status.

The flowcharts below are examples of how to visually think of setting the STATUS. Feel free to edit and upload your own version if you'd like.
Example 1 JPG
Example 1 Draw

Additional Useful (Optional) Steps

Keywords

The Keywords field holds Keywords pertaining to the categorization of this bug.

Some categories of Keywords include:

Use the keyword regression if the previous minor version or bugfix release works correctly. Please do not mark older bugs as regressions.

Fresh regressions are usually pretty annoying for affected users and easier to fix. Thus they are treated with a higher priority by the developers. On the other hand, if it takes months or years to report a regression, it must be in a less used functionality. People are used to live with it, and thus it is less important.

One interesting Keyword is needDevEval. An easyHack is a bug that will most likely not take long to fix and can be done by a new developer and/or a developer without a lot of programming skills. As QA we should NOT just mark a bug as easyHack as it requires several additional steps (including finding a developer to mentor for the bug & doing a backtrace). If you think a bug qualifies as an easyhack, mark as needDevEval, and then please send an email out on the developer mailing list with the POSSIBLE EASY HACK TDF# as subject.

Whiteboard

The Whiteboard is used to list a number of (optional) tags that have been determined to be helpful enough to single out for query purposes. Some of these tags get special attention by a certain group of developers. Example:

  • Tags that are set automatically: e.g. target:X.Y.Z, BSA

Checking Additional Info

As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:

  • Product
  • Version
  • Platform

Adding Developer to CC List

This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe not the status of MAB, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

Adding QA to CC List

This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

Most Annoying Bugs

Really critical bugs should be highlighted as Most Annoying Bugs (MABs). Please, think twice here as we need to keep the list on a reasonable level.

Hard Hacks

If a bug seems to be especially hard, affects a substantial amount of users and would be considered a MAB, the bug is a candidate for a hard hack. This list can be found here:

HardHacks wiki

Special Triage Notes for the QA Team

Here are some notes for Advanced Triagers on the QA/Team. If you're new, don't worry about any of this!

Special Software/Hardware Needed for Repro

Sometimes we need special software or hardware to reproduce a bug:

Extensions

We don't currently have a game plan for triaging extension bugs. Here's our current game plan for extension bugs:

Also read:

Suggested Triage Order

The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.

Table By Platform (OS)

Description All Bugs Windows Linux OSX Comments
Bugs Reported as Blocker BlockerAll BlockerWindows BlockerLinux BlockerOSX We no longer use the Severity 'blocker', so please indicate if a bug is incorrectly marked such (see the Severity field docs).
Bugs Reporting Crashes CrasherAll CrasherWindows CrasherLinux CrasherOSX These are bugs that have "crash" or some similar word in the title of the bug. For crashers the severity should be set to Major/Critical depending on how many users will be affected. Also, QA should look at if the crash is a regression or not and add "regression" to keywords if the bug is determined to be a regression.
Potential Regressions possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionOSX These bugs are marked as possibleRegression which is an automatic status given in BSA if a user reporting a bug said that in a particular version the bug was not present. If the bug is a regression, the Keyword "possibleRegression" should be removed and "regression" should be added to the keywords.
Keyword Regression RegressionAll RegressionWindows RegressionLinux RegressionOSX The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
Bugs Reported as Critical CriticalAll CriticalWindows CriticalLinux CriticalOSX Users can currently set the severity of their own bugs, if the bug is incorrectly marked as critical please change the severity and explain to the user why the bug is not critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart
Bugs Reported as Major MajorAll MajorWindows MajorLinux MajorOSX Users can currently set the severity of their own bugs, if the bug is incorrectly marked as major please change the severity and explain to the user why the bug is not a major bug. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
All Bugs AllBugs AllWindows AllLinux AllOSX List of all bug reports (no enhancements). If the above bugs are tackled first then the ones remaining will be of slightly lower priority to confirm. Suggestion is to do these in chronological order (oldest first so that users who reported the longest time ago get priority).
Enhancement Requests EnhancementAll EnhancementWindows EnhancementLinux EnhancementOSX Enhancement requests are the lowest priority to confirm as valid requests.

Table By Component

Description Writer Spreadsheet Impress Draw Database Other Comment
Bugs Reported as Blocker WriterBlocker SpreadsheetBlocker ImpressBlocker DrawBlocker DatabaseBlocker OtherBlocker We no longer use the Severity 'blocker', so please indicate if a bug is incorrectly marked such (see the Severity field docs).
Bugs Reported as Crashers WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers I a bug is incorrectly marked as critical please change the severity and explain why the bug is not critical. 'Critical' severity is reserved for only the most serious bugs (such as inability to install LibreOffice). For guidance see PriorityFlowChart
Potential Regressions WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg These bugs are marked as possibleRegression which is an automatic status given in BSA if a user reporting a bug said that in a particular version the bug was not present. If the bug is a regression, the Keyword "possibleRegression" should be removed and "regression" should be added.
Keyword Regression WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
Bugs Reported as Critical WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical PriorityFlowChart]].
Bugs Reported as Major WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor PriorityFlowChart]].
All Other Bugs WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther These are all bugs marked as anything below Major but not including Enhancements.
Enhancement Requests WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Enhancement Requests

List of bug reports that are difficult to triage or close

Other