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

Thử nghiệm Phần mềm hoặc QA là nền tảng tốt nhất cho những người mới đến vào ngành công nghiệp CNTT bất chấp những quan niệm sai lầm rằng đó là công việc được trả lương thấp hoặc thấp hơn.

Kỹ năng quan trọng nhất mà người thử nghiệm cần là khả năng tìm ra lỗi . Và, nếu bạn là người yêu thích tìm lỗi, sau đó bạn sẽ yêu và phát triển trong lĩnh vực này.

Có phát biểu nói rằng, có rất ít kỹ năng có thể giúp bạn tìm lỗi và làm việc với các quy trình kiểm soát chất lượng tốt hơn.

Đây là bài viết cho thấy quy trình kiểm soát chất lượng như được theo dõi trong hầu hết các công ty và sẽ cung cấp cho người kiểm tra mới làm rõ về thử nghiệm.

Cụ thể, bạn học các quy trình và tiêu chuẩn tài liệu, làm việc trước của người kiểm tra, kiểm tra dựa trên ràng buộc, thử nghiệm trong quá trình phát triển một phần và cuối cùng là quá trình đăng nhập.

1. Tài liệu

Tài liệu là cần thiết để thử nghiệm. Hầu hết các công ty gán nhiệm vụ này cho những người mới. Để thành công, bạn nên có từ vựng tốt vì phần còn lại của sự vật 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 giá trị của quá trình tài liệu. Lợi thế là rất nhiều - chúng giúp bạn theo dõi các thay đổi yêu cầu, theo dõi các bước kiểm tra của bạn, đăng nhập vào công việc của bạn, v.v.

2. Luyện thi

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 thử nghiệm 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 thử nghiệm. 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 thử nghiệm 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 độ thử nghiệm để 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 thử nghiệm - Trường hợp thử nghiệm, báo cáo thử nghiệm, báo cáo lỗi, số liệu thử nghiệm, 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 thử nghiệm
• Ướ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 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 thử nghiệm 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 thử nghiệm đượ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 thử nghiệm đều là:

• ID Kịch bản - Lấy từ tài liệu kịch bản thử nghiệm
• ID trường hợp thử nghiệm - Để 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 thử nghiệm
• Kết quả mong đợi - Kết quả như mong đợi
• Kết quả thực tế - Đáp ứng của AUT khi thử nghiệm đượ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 thử nghiệm, 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 thử nghiệm - Những bài kiểm tra để thực hiện?

Có một số lượng lớn các loại thử nghiệm, 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ì thử nghiệm căng thẳng và thử nghiệm 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 tra hộp đen
• Kiểm tra hộp màu xám
• Thử nghiệm đơn vị (nếu có)
• Thử nghiệm hội nhập
• Thử nghiệm tích hợp gia tăng
• Kiểm tra hồi quy
• Thử nghiệm chức năng
• Kiểm tra lại, re-test
• Thử nghiệm Độ bền
• Kiểm tra chấp nhận
• Kiểm tra khả năng sử dụng
• Thử nghiệm tương thích
• Kết thúc để kết thúc thử nghiệm
• Thử Alpha
• Thử nghiệm beta

4. Thử nghiệm ở giai đoạn phát triển một 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 thử nghiệm của họ trước khi tích hợp mô đun, có nghĩa là chúng tôi có thể đang làm bài kiểm tra tích hợp đơn vị và trung gian.

Đ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à thử nghiệm, 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 đăng nhập

Đăng xuất và gửi tài liệu cuối cùng là nhiệm vụ QA dẫn / người quản lý. Tuy nhiên, 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ả chúng và gửi các phiên bản cuối cùng.

*Bài viết được tham khảo tại nguồn: "http://www.softwaretestinghelp.com/basic-skills-that-every-tester-fresher-should-have/"