Bug report, làm sao cho chuẩn? (P.1)

Bug report là gì, và làm sao cho chuẩn? 

Nguồn: Usersnap & Softwaretestinghelp

I)Bug report là gì?

Để giải thích được câu hỏi đó, bạn cần hiểu được ý nghĩa của Bug, Bug report và Bug Reporting Software.

Vậy Bug là gì?

Trích từ wikipedia: 

“A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.”

Hay ngắn gọn lại: 

"Software Bug là những sai lầm, hỏng hóc, lỗi, khiếm khuyết để tạo ra một kết quả sai, hoặc không lường đến được."

Theo lý thuyết, có thể coi nó như một thứ gì đó không hoạt động đúng theo thiết kế.

Vậy nếu giả sử cái phát sinh đó đó vốn dĩ không hề có trong thiết kế, vậy nó có phải là Bug? Đây chính là điều khiến người ta có khoảng trống để diễn giải nó theo nhiều cách, và phần lớn mâu thuẫn giữa dev và tester đều xuất phát từ vấn đề này.

Hẳn bạn đã hình dung ra được Bug là gì. Vậy ta tiếp tục đến vấn đề trọng tâm phần 1.

Bug report là gì?

Giả sử 1 bug xuất hiện (tất nhiên là nó sẽ xuất hiện) người tìm ra Bug phải có thể report nó (bằng văn bản và gửi) cho người có liên quan để sửa lỗi đó.

Theo Yegor: Bug report nên giải thích được sản phẩm của bạn hỏng hóc chính xác là ở chỗ nào.

Ông nói thêm rằng Bug report nên theo một quy luật tối giản như sau: 

"Nó như thế này, nó ĐÚNG RA phải hoạt động như thế khác. Fix đi."

Nghe có vẻ đơn giản nhỉ, nhưng thực tế thì mọi sự lại không diễn ra suôn sẻ như vậy.

Tưởng tượng rằng bạn gặp phải 1 bug và muốn send bug report. Bạn sẽ trình bày những thông tin gì? Hầu như mỗi người đều có một câu trả lời của riêng mình, 9 người 10 ý.

II)Tại sao cần một bug report chuẩn?

Nếu bug report hiệu quả, tỉ lệ được fix của nó sẽ cao hơn. Việc fix bug phụ thuộc vào việc bạn report nó có hiệu quả hay không. Nó là một nghệ thuật, và bài viết này hướng dẫn bạn làm sao để trở thành một nghệ sỹ.

“The point of writing problem report(bug report) is to get bugs fixed” – Cem Kaner. 

Khi tester report bug không chính xác, dev có thể reject bug vì không thể tái hiện (reprod ) được bug. Điều này ảnh hưởng đến tự tin và cái tôi của tester (Và theo như mình thì tốt nhất là đừng có cái tôi nào hết. Kiểu bào chữa như "Tao report đúng mà", "Tao làm lại được mà", "Sao nó reject bug của mình", "Không phải lỗi của mình" ..v..v.. là rất có hại cho bản thân bạn và cần tránh)

III)Điều gì quyết định một bug report tốt?

Bạn sẽ thắc mắc rằng điều gì khiến cho một bug report tốt, và điều gì làm nó dở. Và tại sao cái dở lại nhiều hơn cái tốt?

Dưới đây mình sẽ liệt kê ra một số phát biểu về vấn đề này để tách biệt giữa một bug report tốt, và một bug report tệ:

• Bug report tốt chứa đủ thông tin để reprod và sửa lỗi.

• Bug report tệ không chứa đủ thông tin để reprod và sửa lỗi.

• Bug report tốt là một cách hữu hiệu để liên lạc giữa người report bug và người sửa bug.

• Bug report tệ thường quá dài, và là phương tiện thiếu hữu hiệu để liên lạc giữa những người liên quan.

• Bug report tốt được sửa nhanh.

• Bug report tệ không bảo giờ được fix.

• Bug report tốt được gửi đến đúng người chịu trách nhiệm.

• Bug report tệ thì chẳng gửi ai, hoặc gửi nhầm người.

• Bug report tốt mô tả đúng thứ gì cần sửa.

• Bug report tệ không chứa đủ thông tin chi tiết.

• Bug report tốt được gửi theo đúng cách.

• Bug report tệ gửi theo đủ cách, nhưng không đúng (qua facebook hay mail chẳng hạn)

• Bug report tốt tạo nên được tiền đề để phối hợp.

• Bug report tệ sẽ khiến người ta không chịu hợp tác.

Sau khi đọc xong bạn có thể biết được report của bạn tệ hay tốt rồi. Vậy làm sao để viết một bug report tốt?

1) Title rõ ràng
Khi dev đọc bug, thứ đầu tiên đập vào mắt là Bug title. Nó cũng là phần được đọc nhiều nhất, không phải là description. Một bug title tốt phải ngắn gọn và diễn tả được bug một cách tối giản. Ví dụ:

Title kém : Notes don't display correctly 

Không chi tiết. Trong vòng 1 tháng sẽ không thể nhận ra được vấn đề đến từ đâu

Title tốt : Text is truncated for 32nd and 64th notes 

So với title trước, title này cải thiện rất nhiều. Nó chỉ ra được vấn đề gặp phải và nơi xuất hiện của bug.

2) Có thể Reprod:
Nếu bug của bạn không thể reprod, nó sẽ không bao giờ được fix. Ghi rõ từng step. Không nhảy cóc, không tiết kiệm dòng. Nếu bạn hình dung là mình viết để cho một thằng nhỏ 5 tuổi cũng có thể tìm được bug, tức là bạn đã đi đúng hướng.

3) Be Specific:
Không viết luận trong description. Ngắn gọn và vào trọng tâm. Cố gắng viết ít chữ nhất có thể nhưng vẫn đầy đủ ý. Khi có 2 vấn đề trong cùng 1 step giống nhau, hãy tách ra 2 bug report. Khi có cùng 1 vấn đề trong 2 step khác nhau, hãy tách ra 2 bug report.

IV)Format của một bug report tốt.

Đây là một format đơn giản của bug report. Tuỳ thuộc vào tool bạn đang dùng. Nếu bạn viết bug thủ công (excel...) thì có một số trường cần quan tâm đặc biệt, ví dụ như BUG ID hoặc priority. 

Reporter: Tên và email của bạn

Product: Tên của Application Under Test (AUT)

Version: Version đang test.

Component: Module lớn của app.

Platform: Mô tả nền tảng bạn dùng để chạy sản phẩm. Vd: Android, PC ..v...v

Operating system: Mô tả hệ điều hành bạn dùng để test sản phẩm. Vd: Windows 10, Android 4.4.2....v..v.

Priority: Bug nên được fix khi nào? Thường thì sẽ được set từ P.1 tới P.5 trong đó P.1 là "Fix càng sớm càng tốt" và P.5 là "Cho vào backlog"

Severity: Types of Severity:

• Blocker: Không thể tiếp tục test.

• Critical: App crash, mất data.

• Major: Lỗi chức năng nghiêm trọng.

• Minor: Lỗi chức năng nhỏ.

• Trivial: Lỗi UI, lỗi alignment..v..v.

• Enhancement: Request để thêm feature mới hoặc cải thiện feature có sẵn.

Status: Khi mới được log in hệ thống, bug sẽ ở trạng thái new và tuỳ trường hợp mà thành Verified, Fixed, Won't Fix, Reopen..v..v. Cái này sẽ nói rõ hơn vào bài khác.

Assign To: Người nhận trách nhiệm fix bug của bạn. Ở nhiều cty trường này được để trống để PM tự assign người.

URL: URL xảy ra bug.

Summary: Giới hạn trong 60 từ. Mô tả bug ở đâu và bug xảy ra thế nào.

Description: Description của bug. Ở đây ta có thể dùng cách viết sau.

• Reproduce steps: Mô tả rõ ràng các bước để xảy ra bug. Tuyệt đối không giả dụ, không bỏ step. Cứ nghĩ là bạn đang viết cho một đứa nhỏ 5 tuổi đọc và tìm bug. 

• Expected result: Chúng ta trông đợi cái gì.

• Actual result: Và chúng ta nhận được gì (I.E đây là bug)

------------

Trên đây là những step quan trọng cần có trong 1 bug report. Bạn cũng có thể thêm trường Bug Type để mô tả dạng bug report.

Thường là: 

1) Lỗi Coding
2) Lỗi Design 
3) New suggestion
4) Documentation issue
5) Hardware problem

V)Kết luận.

Tự rút ra kết luận đi bạn.

Read more ...

Test suite, Test plan, Test scenario và Test case

Chúng ta lại tiếp tục phân tích những định nghĩa khá rối rắm và dễ lẫn lộn trong Testing career.

Và câu hỏi được đặt ra trong bài này là: Test suite, Test plan, Test scenario và Test case là những gì, có liên quan đến nhau ra sao?

Trước tiên, ta có thể tìm định nghĩa tổng quan của chúng thông qua chương trình học của ISTQB( một cái bằng khá vớ vẩn nhưng tối cần thiết khi xin việc liên quan tới testing tại bất cứ công ty IT nào)

Test Plan: Tài liệu tổng quan về việc test 1 project. Scope của project, hướng tiếp cận, STLC(Software Testing Life Cycle), resource và nhân lực cần có, các features cần được test và không phải test, các tool test và môi trường test cần có. Có thể ví test plan là 1 cái xương sống của 1 testing project và là cái được chuẩn bị đầu tiên khi có 1 project.

Test Scenario: Đi sâu hơn vào chi tiết của từng feature. Test scenario mô tả cái cần test, lưu ý là cái cần test. Ở đây có thể ví dụ một test scenario điển hình như: Test Login form và kiểm tra chắc chắn rằng nó hoạt động như mong muốn. Một test scenario có thể gồm nhiều test case.

Test Case: Tiếp tục đi sâu hơn vào chi tiết của test scenario. Test Case được ví như những đơn vị nhỏ nhất của từng test project, như các tế bào của một cơ thể sống. Điều quan trọng khi thiết lập 1 test case:
- Ít step nhất có thể và chắc chắn rằng chỉ có 1 bước verify cần thực hiện
- Intended result phải được miêu tả 1 cách rõ ràng. Một ví dụ cho việc mô tả không rõ ràng như sau: "test pass khi user login thành công". Thành công như thế nào? điều gì chứng tỏ login thành công? App hay web sẽ redirect user tới screen nào? Điều gì xác định là user đã được login? Tất cả phải được nêu một cách RÕ RÀNG NHẤT CÓ THỂ. Điều này là tối quan trọng nếu bạn muốn test case có thể được automate.
- Prerequisites phải được miêu tả rõ ràng. Những features nào phải hoạt động trước khi test case có thể chạy? Tester phải làm gì trước khi bắt đầu test case? Test case nào cần phải pass trước khi có thể chạy test case hiện tại?

Test Suite: Là một tập hợp các test case cho một mục đích nhất định, ví dụ như Regression Test Suite được chạy để verify những feature cũ. Test Suite và Test Scenario hoàn toàn không liên quan đến nhau,

Rất nhiều tester lẫn lộn giữa test case và test scenario. Việc thực hiện test case cần chi tiết và chính xác tuyệt đối, không chung chung như scenario. Các bạn có thể thắc mắc rằng vì sao cần quá nhiều chi tiết cho test case như vậy, hoặc cảm thấy tốn thời gian khi soạn các test cases. Nên lưu ý rằng một project có rất nhiều phase. Có thể bạn test khi application đang được develop và chuyển qua project khác khi app đã live. Những tester khác sẽ được hưởng lợi rất nhiều nếu người ta biết rõ bạn đã test những gì và test như thế nào thông qua những test case bạn đã soạn. Nên nếu có thể, hãy cụ thể hóa và documentation tất cả những gì bạn đã làm thông qua những thứ như Test Plan, Test Scenario và Test Case.

Hoặc cũng có thể giúp những người viết script automate không tẩu hỏa nhập ma khi đọc test case của bạn.

Như mình.

Read more ...

QA, QC, Tester và Test Engineer

Nếu bạn là một người làm việc trong ngành công nghiệp phần mềm, hẳn không ít thì nhiều bạn cũng sẽ phần nào thắc mắc

Ủa, không phải QA hay QC gì cũng là một sao?

No they're not, my good sir.

QA (Quality Assurance = Kiểm định chất lượng) :

Được dùng để nói về quy trình được dùng để đảm bảo chất lượng của thành phẩm. Quy trình này có thể được thực hiện qua đội ngũ QA Engineer, hoặc manager, hoặc có thể là từ client (với client thì hoạt động này gọi là Acceptance Testing).

QA không phải là QC, hay nói cách khác không trực tiếp kiểm tra chất lượng phần mềm. Công việc của QA là đảm bảo process được tôn trọng, project theo kịp tiến độ hoặc là tạo ra những quy chuẩn chất lượng của sản phẩm để QC có thể follow. Trong một số công ty, QA bao hàm cả QC trong nó.

Một số công ty không có QC mà chỉ có QA, nên khái niệm sẽ được thay đổi bằng PQA và SQA. PQA (Process/Procedure QA) hoạt động như một QA thuần túy còn SQA (Software QA) chính là QC Engineer

Vậy nên: QA = Process + Procedure + meta (nền tảng và quy trình)

QC (Quality Control = Điều khiển chất lượng) :

thực hiện những bài kiểm tra chất lượng (Test) để đảm bảo sản phầm đáp ứng đúng và đủ những yêu cầu mà QA đề ra. Log bug và report bug, follow up bug, confirm bug là những hoạt động hàng ngày của QC.

Từ khoá QC hay Tester có thể được dùng thay thế nhau, và phần lớn các công ty phần mềm đều dùng QC để đặt tên cho công việc này (cho nó cool). Công việc của QC là đảm bảo chất lượng của sản phẩm bằng cách test nó. Và ngoài việc đảm bảo phần mềm follow theo guidelines & checklist của QA team, QC còn đảm bảo rằng phần mềm không chỉ đúng và đủ yêu cầu, mà còn dễ sử dụng và có hiệu suất tốt (thông qua Usability Test & Performance Test).

QC = Test + Report + Follow-up + Product (tập trung vào sản phẩm, kiểm thử sản phẩm)

- Tester (Hoặc Test Engineer) == QC Engineer

Vậy điều bạn cần quan tâm là gì?

Hầu như mọi cá nhân khi bắt đầu con đường testing đều bắt đàu bằng việc làm một QC (hay tester), sau đó có thể leo lên QC Lead, hoặc rẽ nhánh sang QA rồi QA Lead. Và vì định nghĩa của công việc này khá nhập nhằng và tùy thuộc vào văn hóa công ty, bạn nên hỏi kỹ về quy trình làm việc và career path trước khi có ý định nộp CV vào vị trí này.

Source : softwaretestingclass

Read more ...

What is it all about?

Chào mừng bạn đến với huyontesting.blogspot.com 

Blog này được lập ra với nhiệm vụ chia sẻ kiến thức cho những người có hứng thú với Testing nói chung và Automation Testing nói riêng, mình hướng đến đối tượng độc giả là những Tester và lập trình viên đang có hứng thú với Automation và Mobile Automation.

Phần lớn những kiến thức về mảng này bằng tiếng Việt vẫn còn quá ít và thiếu chi tiết. Sách xuất bản thì hầu như không có, nếu có cũng đã lỗi thời ít nhất là 3,4 năm. Với những bạn có khả năng ngoại ngữ trung bình hoặc yếu, cách duy nhất bạn có thể tiếp cận với mảng này là thông qua những đồng nghiệp đi trước.

Rủi nếu họ ngu, xin chia buồn với bạn.

Và mình không vui về điều đó.

Nội dung blog sẽ chủ yếu chia sẻ kiến thức về Automation, ngoài ra còn một chút kinh nghiệm về thiết kế cũng như viết Test Framework và Test Case. Mình sẽ cố gắng dịch các article sưu tầm được qua tiếng Việt, và chia sẻ kinh nghiệm bản thân trong quá trình làm việc.

And that's it folks, let's build stuffs!

Read more ...