6 kỹ năng cơ bản mà Fresher Tester nên có

1. Tài liệu kiểm thử

Tài liệu là cái rất cần thiết trong việc kiểm thử. Hầu hết các công ty gán nhiệm vụ này cho những người mới. Để làm nó thành công thì bạn nên có từ vựng tốt vì phần còn lại chẳng hạn như các tiêu chuẩn tài liệu, v.v... không nằm trong sự kiểm soát của bạn và phụ thuộc vào quy trình của nhóm và công ty.

Ngoài ra, đảm bảo rằng bạn thấy được giá trị tài liệu này. Sẽ có lợi thế là rất nhiều vì chúng giúp bạn theo dõi các thay đổi từ yêu cầu, theo dõi các bước kiểm tra của bạn, xác nhận đánh giá công việc của bạn như nào, v.v.

2. Sự chuẩn bị trước khi kiểm thử

Trong tất cả các tài liệu có sẵn, những điều dưới đây không thể bỏ qua. Đây cũng được gọi là các tài liệu có thể phân phối và họ cầu nối sự hiểu biết của khách hàng, nhà phát triển và người kiểm tra.

A) Kế hoạch kiểm tra: Biểu đồ lưu lượng kiểm thử từ đầu đến cuối

Kế hoạch kiểm tra mô tả phạm vi và các hoạt động của giai đoạn kiểm thử. Do lãnh đạo QA tạo ra, nhóm đã phải đóng góp và cập nhật về mọi thứ được viết trong kế hoạch kiểm tra.

Một số đội có nhiều cấp độ của các kế hoạch kiểm tra: kế hoạch tổng thể và các kế hoạch khôn ngoan pha.

Kế hoạch kiểm tra phải có:

• Tên dự án và phiên bản
• Xác định kế hoạch kiểm tra - Người tạo, số nháp, ngày tạo, v.v ...
• Giới thiệu - Tổng quan về dự án, mục tiêu và khó khăn
• Tham khảo - Danh sách tài liệu tham khảo được sử dụng làm đầu vào (đảm bảo bạn sử dụng các phiên bản chính xác và mới nhất)
• Mục kiểm tra - Các mô-đun, phiên bản, phạm vi, ngoài phạm vi, v.v ...
• Cách tiếp cận kiểm thử tổng thể / Chiến lược kiểm tra - Công cụ sử dụng, quy trình theo dõi lỗi, mức độ kiểm thử để thực hiện, v.v ...
• Tiêu chuẩn mục vượt qua / không đạt - Hướng dẫn thi hành
• Các tiêu chí đình chỉ và tiếp tục lại
• Phân phát kiểm thử - Trường hợp kiểm thử, báo cáo kiểm thử, báo cáo lỗi, số liệu kiểm thử, v.v.
• Kiểm tra môi trường chi tiết
• Team Roster với Thông tin về điểm tiếp xúc. Cho từng mô đun hoặc kiểu kiểm thử
• Ước lượng xét nghiệm - Thời gian và nỗ lực. Chi tiết ngân sách được bảo mật và bạn sẽ không tìm thấy chúng ở đây
• Các kế hoạch rủi ro và giảm thiểu
• Phê duyệt
• Các hướng dẫn khác

B) Các kịch bản kiểm tra

Một vài dòng chỉ dẫn về 'những gì cần kiểm tra' dựa trên từng yêu cầu và thường được ghi lại và theo dõi thông qua bảng tính.

Hầu hết chứa:

• Tên Module / Hợp phần / Chức năng (đăng nhập, quản trị viên, đăng ký, v.v ...)
• ID kịch bản là tham khảo (Ví dụ: TS_Login_001)
• Mô tả Kịch bản - 'Những điều cần Kiểm tra' Ví dụ: Xác nhận nếu đăng nhập cho phép người dùng có thông tin đăng nhập hợp lệ để đăng nhập thành công
• Tầm quan trọng của kịch bản - Ưu tiên trong trường hợp không đủ thời gian - Cao / Trung bình / Thấp
• ID yêu cầu - Để truy xuất nguồn gốc

C) Các trường hợp kiểm tra

Các trường hợp kiểm tra chính xác cho kết quả kiểm tra chính xác. Bảng tính vẫn là phương tiện phổ biến để viết bài kiểm tra, đặc biệt là cho người mới bắt đầu, mặc dù một số công ty thích ứng với các công cụ quản lý kiểm tra. Cơ sở để viết bài kiểm tra là tài liệu SRS / FRD / Req. Nhưng, nó thường không đủ, vì vậy bạn sẽ phải sử dụng rất nhiều giả định và thảo luận với các nhóm BA / Dev.

Viết các trường hợp kiểm thử hiệu quả là bằng chứng quan trọng nhất mà người kiểm tra phải có. Thông thường, tất cả các trường hợp kiểm thử được phân loại là dương tính / tiêu cực. Tích cực kiểm tra trường hợp là đầu vào hợp lệ và nhận được kết quả tích cực. Trường hợp kiểm tra tiêu cực là đưa ra đầu vào không hợp lệ và nhận được thông báo lỗi chính xác.

Một số thuộc tính phổ biến mà tất cả các trường hợp kiểm thử đều là:

• ID Kịch bản - Lấy từ tài liệu kịch bản kiểm thử
• ID trường hợp kiểm thử - Để nhận dạng và theo dõi duy nhất. Ví dụ: TC_login_001
• Mô tả bài kiểm tra - Giải thích ngắn gọn về điều kiện kiểm tra được kiểm tra
• Các bước để thực hiện - Từng bước hướng dẫn về cách kiểm tra
• Dữ liệu kiểm tra - Dữ liệu được cung cấp cho các bước kiểm thử
• Kết quả mong đợi - Kết quả như mong đợi
• Kết quả thực tế - Đáp ứng của AUT khi kiểm thử được chạy
• Tình trạng - Pass / Fail / No Run / Không đầy đủ / Bị chặn - Mô tả kết quả của bài kiểm tra
• Nhận xét - Để biết thêm chi tiết
• Được thi hành bởi - Người kiểm tra tên
• Ngày thực hiện - Ngày chạy thử
• Defect ID - Defect đăng nhập chống lại các trường hợp kiểm thử, trong trường hợp kiểm tra thất bại
• Chi tiết cấu hình - Hệ điều hành, Trình duyệt, Nền tảng, thông tin thiết bị (tùy chọn)

3. Quy trình kiểm thử - Những loại kiểm thử cần thực hiện?

Có một số lượng lớn các loại kiểm thử, nhưng không phải tất cả chúng đều có thể được thực hiện trên AUT đó. Thời gian, ngân sách, bản chất của kinh doanh, bản chất của ứng dụng, và sự quan tâm của khách hàng là những người chủ chốt trong việc lựa chọn những gì các bài kiểm tra để làm trên ứng dụng.

Ví dụ: Nếu đó là cổng thương mại điện tử trực tuyến, thì kiểm thử căng thẳng và kiểm thử tải là bắt buộc. Tuy nhiên, một số loại kiểm tra không thể bỏ qua là:

• Kiểm thử hộp đen
• Kiểm thử hộp màu xám
• Kiểm thử đơn vị (nếu có)
• Kiểm thử hội nhập
• Kiểm thử tích hợp gia tăng
• Kiểm thử hồi quy
• Kiểm thử chức năng
• Kiểm tra lại, re-test
• Kiểm thử Độ bền
• Kiểm thử chấp nhận
• Kiểm tra khả năng sử dụng
• Kiểm thử tương thích
• Kết thúc để kết thúc kiểm thử
• Thử Alpha
• Kiểm thử beta

4. Kiểm thử từng phần

Nói chung, với các công ty vừa và mới thành lập, có rất ít thời gian và nguồn lực. Người kiểm tra ở đây có thể bắt đầu quá trình kiểm thử của họ trước khi tích hợp mô đun, có nghĩa là chúng ta có thể đang làm bài kiểm tra tích hợp đơn vị và trung gian (từng phần và module).

Điều quan trọng cần lưu ý là các kết quả từ các giai đoạn này không thể được tính là chính xác, do đó bạn có thể phải lên kế hoạch kiểm tra hộp đen tổng thể khi mọi thứ đã sẵn sàng. Nhìn thấy phần đó có thể chứng minh tốn kém và kiểm thử, không hiệu quả.

5. Tài liệu báo cáo lỗi

Trên thực tế, đây là tài liệu QA quan trọng nhất mà bạn sẽ làm.

Sau đây là các lĩnh vực một báo cáo lỗi tốt phải có:

• ID defect - Thường là số sê-ri
• Mô tả lỗi - Một dòng giải thích về vấn đề
• Vị trí - Mô đun / khu vực của AUT nơi vấn đề được tìm thấy
• Xây dựng số - Phiên bản và xây dựng mã số.
• Các bước sao chép - Liệt kê các bước dẫn bạn đến sự cố
• Mức độ nghiêm trọng - Thiết lập mức độ để mô tả mức độ nghiêm trọng của vấn đề - Chặn thấp, trung bình, cao, chặn, v.v ...
• Ưu tiên - Thiết lập bởi các nhà phát triển để xác định thứ tự mà các khiếm khuyết sẽ được cố định (P1, P2, P3, vv P1 - cao nhất)
• Được chỉ định cho - Chủ sở hữu của các khiếm khuyết tại thời điểm đó
• Được báo cáo bởi - Tên của Người kiểm tra
• Trạng thái - Trạng thái khác nhau để biểu thị giai đoạn chu kỳ của vòng đời lỗi
• Mới - Lỗi được tìm thấy và chỉ báo cáo
• Mở - Xác nhận bởi dẫn đầu QA
• Được chỉ định - Gửi đến người dẫn đầu dev để phân công cho nhà phát triển tương ứng
• Đang tiến triển / Đang tiến hành - Dev bắt đầu làm việc trên nó
• Cố định / Giải quyết - Nhà phát triển đã hoàn thành công việc
• Đã được xác minh / đóng - Nhóm QA đã kiểm tra lại và phát hiện lỗi đã được khắc phục
• Nhóm thử lại - nhóm QA không đồng ý với quyết định của Dev và tiếp tục phát triển lỗi cho việc làm lại
• Trùng lặp - Lỗi tương tự đã tồn tại
• Đã trì hoãn - Lỗi hợp lệ nhưng sẽ được khắc phục trong các bản phát hành sau
• Không hợp lệ - Không phải lỗi hoặc không thể tái tạo hoặc không có đủ thông tin

6. Quá trình hoàn tất ký tên

Xác nhận ký tên và gửi tài liệu cuối cùng là nhiệm vụ QA hoặc của người quản lý.  Cách nào cách thì nhóm phải nộp các tài liệu trên (Kịch bản kiểm tra, Kiểm tra trường hợp, và tài liệu đăng nhập lỗi) để đánh giá cuối cùng và kiểm toán.

Hãy chắc chắn, bạn đã kiểm chứng tất cả và gửi các phiên bản hoàn thiện cuối cùng trước khi bàn giao sản phẩm.

Bài viết được dịch lại:

• http://www.softwaretestinghelp.com/basic-skills-that-every-tester-fresher-should-have/