Quản lý bugs của jira

I. Quy trình quản lý bug
I.1 Vòng đời bugs
I.2 Trạng thái bugs

1. NEW
bug vừa được post lên hệ thống. bugzilla request email đến thành viên được
phân việc fix bug. Từ trạng thái NEW có thể chuyển sang ASSIGN || RESOLVED
NEW ---> ASSIGNED || RESOLVED

1.1/ ASSIGNED: bugs này được giao cho Developer fix, lúc này bug chưa được
fix (ở trạng thái này bugs có thể được chuyển sang NEW (chuyển cho người khác fix)
hoặc chuyển sang RESOLVED (đã fix xong)

assigned ---> resolved (fixed)
---> new (chuyển cho người khác fix).

1.2/ RESOLVED: bugs được sửa xong và chuyển sang kết quả bug có thể là 1 trong các trạng thái sau:
FIXED
INVALID
WONTFIX
DUPLICATE
LATER
REMIND
Từ các trạng thái bug trên có thể chuyển sang trạng thái: Reopen
 Verified
 Closed
 Unconfirmed (trạng thái này ít dùng)

Ghi chú:
Giải thích ý nghĩa của các trạng thái bugs (kết quả trạng thái bugs của RESOLVED) như sau:
FIXED: bugs đã fix xong
INVALID: Vấn đề này không phải là bug
WONTFIX: Vì lý do nào đó, bug này không fix hoặc không có time hoặc bug không nghiêm trọng, để cải tiến sau..
DUPLICATE: bug được post lên bị trùng với bug cũ. ở trạng thái này yêu cầu tester cập nhật lại ID của bug
LATER: Vì lý do nào đó chưa thể fix ngay lúc nảy.
REMIND: Giống với LATER.


2. REOPEN
Trạng thái này do QC/ manager test chuyển trạng thái từ RESOLVED. trong trường hợp kiểm tra lại vẫn còn bug
bug giống tương tự với bug cũ. trạng thái này có thể chuyển sang assigned hoặc resolved.
REOPEN ---> ASSIGNED
      ---> RESOLVED
3. VERIFIED
Trạng thái này được test xong và xác nhận bug được fix (QC lead đóng).

4. CLOSED
Kết thúc 1 vòng đời bug ( bug được fix và tet lại hoàn tất)
Nếu xảy ra bug hoặc vẫn còn bug thì chuyển sang trạng thái REOPEN.

10 nguyên tắc cơ bản cho người mới bắt đầu học automation testing

[quote] Automation testing từ khóa này lúc nào mình cũng search search research bao là nhiêu. tìm hiểu về nó thì có rất nhiều tài liệu nhưng sẽ rất mung lung không biết bắt đầu từ đâu. Bởi vậy, không biết thì hỏi muốn giỏi thì search google nhiều =)))
Dưới đây, mình cũng tìm đọc và chia sẻ cho bạn nào muốn tìm hiểu về auto testing. Bạn nào đang tìm hiểu hoặc có kinh nghiệm chia sẻ cùng mình nha. :) [/quote]

Testing là một một nhiệm vụ khó khăn và để tự động hóa đòi hỏi người kiểm thử
có sự hiểu biết sâu sắc về quá trình và thực hành liên tục, tìm ra cho mình một tool hoặc ngôn ngữ
basic để hiểu và viết testscript bằng java hoặc python (còn nhiều ngôn ngữ khác áp dụng nếu như bạn nào rành về C# cũng OK tuốt =D)
Bạn nào mới bắt đầu về java thì có thể lên mạng search learning java basic hoặc học theo bài cơ bản nhất theo link này: http://workbench.cadenhead.org/book/java-8-24-hours/

Nhưng trước hết bạn hiểu và nắm rõ được 10 nguyên tắc cơ bản dưới đây:

Nguyên tắc 1: Đọc và học/ hiểu cơ bản về nó (automation testing)
ngay cả những người phát triển có tay nghề cũng phải rà soát
lại kiến thức của mình theo thời gian, học tập là luôn cập nhật trau dồi kiến thức thường xuyên

Tự động hóa là gì? tự đặt câu hỏi và tự tìm hiểu để trả lời thì bạn sẽ nhớ lâu hơn, hoặc có thể tham khảo của những người đi trước. tự động hóa một đánh giá đơn thuần của các bước chương trình phải thực hiện, bạn tự viết một hướng dẫn chi tiết.

Nguyên tắc 2: Kế hoạch chuẩn bị để đáp ứng các dự án tự động

Thực hành là cách duy nhất để có được kiến thức hợp lệ.
Lấy bất kỳ công cụ kiểm tra mã nguồn mở có sẵn, cài đặt  và học cách sử dụng nó trong thời gian rảnh của bạn. Các sandbox (hộp kiểm thử hiện đại) có thể làm được bất cứ điều gì, thậm chí MS Office của bạn hoặc công cụ Calculator ( thực hiện demo trươc1). Chỉ cần có được công cụ và bắt đầu, Khi bạn đạt được sự hiểu biết và kinh nghiệm có thể sẵn sàng đối mặt với các dự án thực tế khi cần thiết.

Nguyên tắc 3: Các khái niệm/ định nghĩa cơ bản là giống nhau. Hãy khám phá chúng!
Ngoài đặc thù là khác nhau nhưng tất cả các ngôn ngữ cơ bản hoạt động
cùng một khái niệm như các biến, tham số, các chức năng, các
loại dữ liệu khác nhau, vòng lặp có điều kiện hoặc báo cáo, mảng, chỉ khác nhau ở công nghệ của mỗi ngôn ngữ. Sau khi có những hiểu và ghi nhớ, bạn sẽ có thể áp dụng kiến
 thức này để coding bất kỳ ngôn ngữ nào bạn học. (java ? python..)

Nguyên tắc 4: Không dừng lại khi chương trình đầu tiên bị FAIL
Khi mà thực hành viết 1 chương trình testscript nào đó bị lỗi bạn đừng vội nản lòng.
Có một câu ngạn ngữ Nga tuyệt vời: "the first pancake is a mess. It means first try on anything will most likely fail, but all the next ones will be better, as you will gain experience in the process.
 No matter how good you are on theory, first practice likely will be disappointing. So just go on."

Nguyên tắc 5: Nhìn vào code như một thủ tục chứ không phải là một magic :3

Bất cứ khi nào mới bắt đầu nhìn vào code, nó có vẻ gần như khá phức tạp.
Tuy nhiên, sau khi thực hiện một số coding, bạn sẽ có thể nhận ra mô hình và quy trình cùng một lúc làm cho việc đọc mã dễ dàng hơn nhiều. Bạn sẽ thấy nó chỉ đơn thuần là một hướng dẫn cho các chương trình.

Nguyên tắc 6: Khám phá tool
Mình nói rồi đấy. Bất cứ một người làm kiểm thử nào nếu không muốn mình đơn thuần là 1 manual testing hay chỉ test function dựa trên spec document thì hãy tìm cho mình một tool thích hợp nhất để tìm hiểu. Cách tốt nhất để làm quen với một công cụ thì hãy khám phá các tính năng của nó từ đơn giản nhất cho đến phức tạp. càng hiểu sâu bạn càng thích thú với nó. tool rất nhiều bạn có thể search tool for testing là ra cả đống =D

Nguyên tắc 7: Search for help in help section
Trong quá trình khám phá tìm hiểu bạn gặp một số lỗi thì hãy đọc phần Help của công cụ. Nó là một nguồn tuyệt vời và hướng dẫn trên mọi khía cạnh của việc sử dụng của công cụ. Khám phá kỹ để làm chủ công cụ hoàn hảo.

Nguyên tắc 8: Thực hành nhiều, nhiều hơn có thể

Hãy thử nghiệm nhiều lần như một quá trình xác nhận. Nó cho phép bạn để kết luận nếu đoạn code này là chức năng hay không. Kiểm tra nhiều lần và xem xét nó có cho ra kết quả mong muốn hay không? lặp lại nhiều lần như thế để xác nhận

Nguyên tắc 9: Cải tiến cách/ phương pháp làm việc của bạn

Tất cả những việc làm tốt có thể được thực hiện tốt hơn. Rà soát, phấn đấu để cải thiện dự án của bạn là một cách  để cải thiện kỹ năng của bạn và hướng bạn lên một tầm cao mới.


Nguyên tắc 10: Không phải lúc nào cũng cần đến tự động

Automated test là phương pháp hữu dụng và ấn tượng, thường được
sử dụng để giúp tiến hành test một cách hiệu quả. Tuy nhiên, automated test lại không phù hợp với tất cả các dự án. Nguyên nhân là do thiếu thời gian và thiếu kĩ thuật. Mất nhiều thời gian để tạo Automated test. Thời gian này phụ thuộc vào các tester. Để tạo automated test thì mất thời gian gấp 3-10 lần  so với việc chạy test bằng tay. Vì vậy, automated test sẽ chỉ được  chạy tương đương với lượng thời gian gấp 3-10 lần. bạn tìm hiểu và nắm rõ 2 trường hợp sau:
1. Automated test sẽ phù hợp cho những mục đích:
- Thực hiện test hồi quy cho 1 hệ thống ổn định chạy trên 1 cơ sở thường xuyên.
- Việc tạo dữ liệu xử lý nhanh trong các hệ thống test có cơ sở dữ liệu căn cứ trên 1 cơ sở thường xuyên.
2. Automated test KHÔNG phù hợp cho những mục đích sau:
- Thực hiện test chức năng mới – Việc này nên được làm bằng tay trước khi tạo automated test.
- Những hệ thống test hồi quy sẽ mang lại sự thay đổi giao diện người sử dụng quan trọng. Sự thay đổi lớn đối với giao diện người sử dụng cần nhiều sự bảo dưỡng duy trì cho automated test.
Khi tiến hành tự động hóa test, bạn nên chỉ tự động hóa các test mà nhóm của bạn có thể duy trì được dễ dàng. Nếu có vài test khó có thể duy trì thì phải cân nhắc để giảm các test đó.
Nói tóm lại, bạn hãy nhớ rằng automated test sẽ không bao giờ tìm ra được nhiều bug như 1 người tester tìm ra theo cùng các bước. Đó là bởi vì người tester có thể bắt được nhiều thứ bằng con mắt của mình.

Những quy tắc là không bắt buộc, nhưng chúng tương đối đơn giản hóa và rõ ràng. Sau đó sẽ giúp bạn cải thiện kỹ năng và trở thành một người kiểm thử tốt hơn.
Nếu bạn có nhận xét hay ý kiến thêm về vấn đề nào trong 10  nguyên tắc trên
hãy feedback cho mình qua mail thuyph910@gmail.com Thanks all.

Checklist for usability testing

Có rất nhiều khía cạnh liên quan đến quy trình kiểm thử, bài viết này sẽ tập trung vào “danh sách kiểm tra (checklist)” khía cạnh đó là một phần cơ bản trong các quy trình kiểm thử phần mềm.

Tại sao phải sử dụng checklist trong kiểm thử

·                     Theo quan điểm của tôi, nó có một vài lợi ích chính mà bạn đạt được khi sử dụng checklist

·                     Checklist có thể bảo đảm tất cả các yêu cầu của client sẽ được đảm bảo trong quy trình kiểm thử

·                     Checklists cón thể đảm bảo rằng phần mềm được kiểm tra với mức bao phủ cần thiết

·                     Checklists có thể giảm bớt bỏ quên lỗi cho tester

·                     Checklist có thể giúp công việc kiểm thử đảm bảo mức đúng đắn/ chính xác cho phần mềm

·                     Checklist có thể giúp tester bao quát được  vùng kiểm thử

·                     Checklist có thể giúp tester nhìn rõ thấy quy trình kiểm thử

·                     Checklist có thể tăng cường sự phối hợp giữa các nhóm tham gia khác liên quan tới nhau trong quy trình  kiểm thử phần mềm

Dưới đây, tôi chọn một vài tiêu chí cho các trường hợp test, mỗi tiêu chí đi kèm với với các ví dụ cụ thể giúp bạn thực hiện công việc kiểm thử tính khả dụng một cách tốt hơn:


User experience  

·                     Kiểm tra định dạng các thông tin hiển thị thích hợp với mức tương phản với bakground

·                     Kiểm tra / xác nhận rằng mọi thao tác người dùng có thể sử dụng các chức năng chính ngoài các hệ thống không cần thiết

·                     Kiểm tra/ xác nhận người dùng nhận được các thông báo lỗi cho các thông tin không hợp lệ VD: thông tin đăng nhập

·                     Kiểm tra người dùng có thể đăng nhập vào site của bạn, khi đó hệ thống phải chỉ dẫn tốt cho người dùng sau khi đăng nhập thành công

·                     Kiểm tra thao tác người dùng có thể thi hành hệ thống với phần cứng

·                     Kiểm tra tất cả các buttons, checkboxes, radio buttons.. khi click

·                     Kiểm tra/ xác nhận người dùng nhận được thông tin pop-up trước khi ứng dụng được thay đổi 

·                     Kiểm tra người dùng có thể thoát ra từ bất kỳ thao tác nào khỏi hộp thoại phức tạp (complex dialog)

·                     Kiểm tra/ xác nhận người dùng có thể sử dụng thông tin liên hệ có sẵn

·                     Kiểm tra/ xác nhận rằng người dùng có thể so sánh các sản phẩm khác (Nếu có liên quan)

·                     Kiểm tra/ Xác nhận rằng mọi thao tác/ hoạt động được kết thúc với thời gian hợp lý

·                     Kiểm tra/ Xác nhận rằng người dùng có thể truy cập vào chỉ dẫn “help” một cách dễ dàng

·                     Kiểm tra/ xác nhận rằng website của bạn tương thích với nhiều kích thước độ phân giải màn hình khác nhau

·                     Kiểm tra/ xác nhận rằng người sử dụng có thể truy cập nhanh vào thông tin website

·                     Kiểm tra/ xác nhận rằng người dùng nhận được một đăng ký chờ duyệt

Information and visibility

·                     Kiểm tra/ xác nhận các trường không cho phép chọn phải ở dạng disable

·                     Kiểm tra/ xác nhận cú pháp/ kiểu ngôn ngữ viết của bạn được viết đơn giản cho người dùng cuối

·                     Kiểm tra/ xác nhận rằng các thông tin không cần thiết thì không nằm trong phần nội dung của quảng cáo

·                     Kiểm tra/ xác nhận rằng logo của công ty bạn được hiển thị trên tất cả các vùng có liên quan

·                     Kiểm tra/ xác nhận rằng người dùng nhận đươc thông báo lỗi khi thao tác có lỗi xảy ra không hợp lệ

·                     Xác nhận rằng bạn có không gian hiển thị giữa các thông báo, các trường, các label … một cách hợp lý

·                     Xác nhận rằng tất cả các hình ảnh/ video phải có mô tả  thích hợp.

·                     Chắc chắn rằng nội dung của bạn được viết bằng chữ in thường/ in hoa

·                     Xác nhận rằng nội dung của bạn không có lỗi chính tả

·                     Xác nhận rằng những thông tin quan trọng phải được định dạng nổi bật

·                     Chắc chắn rằng nội dung của bạn luôn được cập nhật

·                     Xác nhận tất cả các pages/ grids phải có title

Navigation

·                     Kiểm tra/ Xác nhận rằng bạn không có bất kỳ “Drop – down” list nào chứa quá nhiều record

·                     Xác nhận thanh navigation “Tabs” được trỏ đến vị trí thích hợp khi có lệnh

·                     Kiểm tra/ Xác nhận website bạn phải có một “site map” có thể giúp người dùng end user

·                     Kiểm tra/ xác nhận người dùng di chuyển thuận tiện các phím tabs/ pages với các option trả về tab/page hiện tại có những gì

·                     Kiểm tra/ xác nhận thanh cuộn “scrolling” phải sẵn có trong vùng thích hợp

·                     Kiểm tra/ xác nhận người dùng không thể chèn thông tin đầu vào trên các danh sách “drop-down” list

·                     Kiểm tra tất cả các link liên kết được cấu hình bởi các chữ cái (?)

·                     Kiểm tra/ xác nhận tất cả các trường textbox, các button liên quan đến việc di chuyển giữa các tabs/ pages với nhau

Site links

·                     Chắc chắn các chức năng chính phải được cấu hình như các button chứ không phải dạng link liên kết.

·                     Kiểm tra/ xác nhận tất cả các link được cấu hình với các phạm vi mong muốn

·                     Kiểm tra các link liên kết được đánh dấu bởi màu sắc thích hợp

·                     Chắc chắn rằng người dùng nhận được thông báo thích hợp đối với các trường hợp bị delay giữa các link được chọn và các tham chiếu được gửi tới

·                     Kiểm tra/ xác nhận rằng không có có liên kết link nào bị hỏng

Search fields

·                     Kiểm tra/ xác nhận sẽ có lựa chọn cho keysearch đề nghị nếu người dùng search mà trả về kết quả rỗng

·                     Kiểm tra/ xác nhận màn hình hiển thị thông báo cho bất kỳ trường hợp nào bị delay trong quá trình tìm kiếm

·                     Xác nhận rằng phải có màn hình hiển thị thông báo thích hợp nếu kết quả search trả về null

·                     Kết quả tìm kiếm được hiển thị tương ứng với thuộc tính kết quả tìm kiếm

·                     Kiểm tra/ xác nhận bộ máy tìm kiếm chứa các đối tượng khai thác kết quả khác nhau (ví dụ bằng kết quả tìm kiếm hoặc gần giống với kết quả tìm kiếm, kết quả tìm kiếm tương tự,….)

·                     Xác nhận rằng người dùng có thể lọc kết quả tìm kiếm với một vài tiêu chí tìm kiếm khác  nhau

·                     Kiểm tra/ xác nhận rằng phải có màn hình hiển thị thông báo thích hợp nếu người dùng chèn vào các ký tự đặc biệt

·                     Kiểm tra rằng việc hiển thị kết quả tìm kiếm không được nhân đôi kết quả tìm kiếm giống nhau

·                     Xác định trang hiển thị kết quả tìm kiểm phải rõ ràng

·                     Xác nhận thanh công cụ tìm kiếm phải được đặt ở vị trí thích hợp

·                     Xác nhận/ kiểm tra kết quả tìm kiếm phải được hiển thị theo thứ tự hợp lý

·                     Xác nhận/ kiểm tra người dùng có thể bắt đầu tìm kiếm trên bàn phím keyboard

·                     Mặc định, website của bạn phải có một thanh công cụ tìm kiếm, kích thước, font, size, màu sắc thích hợp

·                     Kiểm tra/ xác nhận kết quả tìm kiếm trả về phải chính xác

Tham khảo tại https://userium.com/