10 Tips for QA

Trong bài viết này tôi xin chia sẻ bài viết khá hay. Trong bài có nhắc tới 10 tips nhỏ mà tác giả có nhắc đến ở link trên có thể giúp khả năng kiểm thử của bạn được tốt hơn. Giúp bạn có mindset QA cho bản thân tốt hơn, và định hướng kiểm thử cũng sẽ tốt hơn. Nhưng tôi không nêu tất cả những tips trong bài chia sẻ trên, mà thay vào đó lại là từ kinh nghiệm bản thân tôi nữa.

1. Test everything:

Bạn đã bao giờ gặp phải trường hợp bị gọi tới làm việc tăng ca hoặc làm thêm cuối tuần vì một lỗi nghiêm trọng nhưng bạn đã bỏ qua nó? Họ sẽ không quan tâm bạn mất bao lâu để test nó mà bạn sẽ chỉ nhận được câu hỏi:” Tại sao bạn không tìm thấy lỗi đó?”. Và chính bản thân bạn cũng sẽ đặt câu hỏi cho bản thân mình: “Tại sao mình lại bỏ qua bug này được”. Vậy nên là một QA thì bạn phải luôn có suy nghĩ rằng : “ Nếu chưa kiểm tra mọi thứ thì bạn chưa kiểm tra bất cứ điều gì”. => Hãy nhớ kiểm tra mọi vấn đề.

2. Mind the gate:

Ai sẽ là người chịu trách nhiệm về chất lượng trong dự án bạn đang làm? Có phải là DEV? → No. Có phải là nhà phân tích kinh doanh? → No. Hay Management? → No. Bạn có nghĩ những người đó sẽ thực hiện kiểm thử chất lượng trong dự án bạn? Đương nhiên là họ không làm việc đó mà đội ngũ QA mới là những người làm công việc đó. Chỉ có đội QA mới là người quyết định xem liệu phầm mềm có đảm bảo chất lượng khi đưa tới khách hàng hay không. => Hãy nhớ bạn là người kiểm tra chất lượng và bạn phải đảm bảo chất lượng.

3. Maintain your test case:

Hiện nay có một số dự án khách hàng không yêu cầu chúng ta phải viết testcase. Vì thế mà đội QA của dự án cũng không viết testcase cho dự án của họ. Thay vào đó họ chỉ thực hiện test “Exploratory testing”. Đương nhiên khi bạn không phải viết testcase thì bạn sẽ có nhiều thời gian để làm việc khác. Nhưng tôi khuyên bạn hãy dành thời gian để viết testcase cho dự án của bạn. Điều này sẽ hạn chế việc bạn bỏ sót bug. Mặc dù exploratory testing tốt và không phải là hoàn toàn vô giá trị, nhưng nó chỉ nên được thực hiện khi bạn đã hoàn thành các manual testcase. Trong một trường hợp khác, nếu bạn cần sự trợ giúp của người khác, nhưng họ không hiểu hệ thống. Lúc này nếu bạn có bộ testcase chi tiết để gửi họ, họ chỉ cần làm theo bước bạn mô tả trong testcase vậy là mọi việc được giải quyết đơn giản, và công việc của bạn vì thế cũng nhẹ nhàng hơn rất nhiều.

Việc này còn rất có ích cho việc lưu lại sự thay đổi trong mỗi version của dự án => Hãy nhớ đừng lười viết testcase.

4. Automate testing:

Nếu bạn làm tốt bước 3 rồi thì bạn đã sẵn sàng tự động hóa các trường hợp thủ công mà bạn đang làm. Nếu dự án của bạn không cho phép bạn mất quá nhiều thời gian vào các công việc thủ công lặp đi lặp lại thì đã đến lúc bạn nên nghĩ tới kiểm thử tự động. Chỉ trong một số trường hợp thì kiểm thử tự động mới thật sự tốt cho dự án của bạn. Nhưng nếu bạn lựa chọn sai thì việc kiểm thử tự động không giú bạn nhanh hơn trong công việc mà còn khiến bạn vừa mất thời gian vừa không hoàn thành được công việc. => Hãy lựa chọn kiểm thử tự động khi cần thiết.

5. Don't be bullied by your situation:

Khi bạn không được chuẩn bị tốt cho sản phẩm mới thì bạn sẽ gặp phải những sai lầm đáng tiếc. Khi vào dự án mới, việc đầu tiền bạn cần làm là lên kế hoạch và chiến lược test, rồi dần dần thích ứng với dự án. Luôn đặt ra câu hỏi “như thế nào?” và “tại sao?”. Và bản thân bạn phải là người chủ động trước những tình huống này. => Hãy là người chủ động trong mọi tình huống.

6. Ngăn ngừa bug:

Phần lớn các dự án thật bại khi testing không phải là do đo lường. Các chỉ số không chỉ ở nhóm kiểm thử mà là cả toàn bộ dự án. Khi bắt đầu một dự án thì việc đầu tiên bạn nên làm đó là tìm kiếm những lỗi sớm nhất, vì việc tìm bug để ngăn ngừa bug đáng được khen thưởng là việc tìm bug rồi mới sửa. Ngăn ngừa bug còn giảm được nhiều thiệt hại cho dự án sau này. => Hãy tìm cách ngăn ngừa bug.

7. Code if you can

Nếu có thể thì bạn nên biết chút ít về kỹ năng lập trình. Như vậy bạn sẽ hiểu được lỗi mà lập trình viên hay mắc phải và có thể ngăn ngừa những sai lầm đó. Nhưng nếu không biết về lập trình thì không phải bạn không thể ngăn ngừa những sai lầm đó, nếu bạn đủ kinh nghiệm nhìn nhận những sai lầm này bạn vẫn có thể ngăn ngừa chúng. => Hãy biết về lập trình nếu có thể.

8. Tách biệt giữa QA và Deverloper :

Ứng dụng được sử dụng bởi người dùng, deverloper tạo chúng, QA là người kiểm thử và quyết định ứng dụng đó đã sẵn sàng tới tay người dùng. Nên bạn luôn giữ vững suy nghĩ tách biệt với quan điểm của dev và nên mang suy nghĩ của người tiêu dùng. Chỉ cần đảm bảo được suy nghĩ của người tiêu dùng thì sản phẩm của bạn mới thành công. => Hãy kiểm thử như một người dùng thực sự.

9. Be Agile:

Hãy Agile: Khi bạn đang nỗ lực để có Agileness, luôn Agility Agile Agilier Agility hơn, bởi vì Agiling là chìa khóa để trở thành Agile. Nếu bạn không Agiling được Agile đã có, sau đó được thêm Agile trong cách tiếp cận của bạn để Agiling. Hãy nhớ rằng, Agile không chỉ là một từ, nó là từ duy nhất, ngoại trừ Agiling, đó cũng là một từ.

10. Nghiêm khắc kiểm điểm và rút kinh nghiệm sâu sắc

Mỗi khi dự án kết thúc nên thực hiện “KPI” để đánh giá dự án vừa làm. Trong đó gồm các mục:

• K (Keep) : Những mặt tốt cần phát huy
• P (Problem): Những điểm chưa được, khiếm khuyết của dự án cần rút ra
• I (Improvement): Biện pháp cải thiện cho sau này

Trong bài viết trên là một số tips nhỏ để bạn có thể làm tốt hơn công việc của một QA. Tuy không phải là tất cả nhưng cũng mong bài viết giúp ích cho bạn Link tham khảo Link http://blog.moserit.com/10-best-practices-that-your-qa-team-must-follow