1. Testing là gì? - Là người tìm ra lỗi của phầm mềm/ hệ thống
2. Mô hình kiểm thử
2.1. Thác nước: ứng dụng vào các dự án nhỏ, ngắn hạn hoặc các dự án ít yêu cầu/ không có những yêu cầu rõ ràng
2.2. Xoắn ốc: Thường sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các gđ nhỏ hoặc theo các phân đoạn
2.3. Agile( Linh Hoạt- Nhanh Lẹ) : có thể sử dụng ở bất kì dự án nào, nhưng cần sự tương tác và tham gia của KH, sử dụng khi KH yêu cầu chức năng sẵn sàng trong thời gian ngắn
2.4. Tiếp cận lặp: Các dự án lớn và nhiệm vụ quan trọng, yêu cầu chính phải được xác định
2.5. Tăng trưởng: Áp dụng cho những dự án có yêu cầu đã được mô tả định nghĩa và hiểu 1 cách rõ ràng- khách hàng có nhu cầu về sp sớm
2.6. Chữ V: Yêu cầu đã được xác định rõ ràng, xcs định sản phẩm ổn định, công nghệ không thay đổi và được hiểu rõ bởi nhóm dự án,
2.7. - Scum
2.8. RAD: Module hóa rõ ràng( nếu dự án ko được chia thành các module, RAD có thể không thành công- nên được sử dụng khi có nhu cầu để tạo ra 1 hệ thống có ycau KH thay đổi trong khoảng tgian nhỏ 2-3 tháng- nên sử dụng khi đã có sẵn thiết kế cho model và chi phí cao
3. Automation là gì? Là kiểm tra tự động giảm thời gian làm việc thủ công...- lương cao hơn manual testing - giới thiệu 1 tí
4. 1 số từ khóa chuyên ngành
4.1. PM= Project manager: giống như người quản lý dự án
4.2. BA= Business Analyst: là người phân tích yêu cầu của dự ấn, gặ trực tiếp khách hàng, chi tiết hóa yêu cầu và bàn giao lại cho Dev- Tes
4.3. Dev= Developer: xây dựng, phát triển
4.3.1. Frontent (FE) làm giao diện
4.3.2. Backend( BE) xử lý đằng sau
4.4. QC= Quality control= Tester: Ngăn lỗi, tìm lỗi
4.5. Designer: Thiết kế, vẽ giao diện dựa vào yêu cầu của KH
4.6. QA: Quality Assurance: Giám sát chất lượng chung của toàn bộ công ty
4.7. Issue: lỗ hổng
4.8. Bug: Lỗi
4.9. Status: trạng thái của module
4.10. Assignee: khi thấy Bug, thì phải đưa cho 1 người nào đó có khả năng xử lý
4.11. SRS: sofware prepiment specipiticion: khi có BA/PM làm việc với KH sẽ ra tài liệu này, tất cả phải theo dõi nếu như có xung đột sẽ dựa vào tài liệu
4.12. Q&A: liệt kê những câu hỏi ko hiểu trong dụ án với những bộ phận hiểu câu hỏi
4.13. Due date: thời gian muộn nhất phải hoàn thành
4.14. Expected Result: các mong muốn phải đúng theo yêu cầu
5. Vai trò KTPM
5.1. - Ngăn ngừa và tìm ra lỗi sản phẩm
5.2. - Đánh giá và đảm bảo chất lượng của SP
5.3. - Tham gia và đưa ý tưởng cải thiện sản phẩm
6. Nhiệm vụ của 1 Tester
6.1. - Đọc- hiểu yêu cầu của dự án
6.2. - Phải viết ra được yêu cầu dưới dạng testcase( kịch bản kiểm thử
6.3. - Thực hiện các testcase đó và tìm ra Bug( lỗi)
6.3.1. Lỗi trong KTPM
6.3.1.1. Layout: lỗi về giao diện hệ thống/web (GUI: hiển thị giao diện các trường)
6.3.1.2. Font: phông chữ, chính tả
6.3.1.3. Color: Màu sắc
6.3.1.4. Content: Nội dung của 1 hệ thống/ website
6.3.1.5. Functional testing: Lỗi chức năng (chức năng đăng nhập
6.3.1.6. Validate: check dữ liệu các trường
6.3.1.6.1. Hợp Lệ
6.3.1.6.2. không hợp lệ
6.3.2. Cách Viết Bug(Cấu trúc của 1 Bug)
6.3.2.1. Ngày/Tháng viết ra bug đó
6.3.2.2. Đưa con Bug này cho ai:
6.3.2.3. Status:
6.3.2.3.1. Mới Viết: New
6.3.2.3.2. Sau khi đưa cho Dev là open
6.3.2.3.3. Dev đã sửa lỗi gọi là Fix
6.3.2.4. Title: Tiêu đề- Quan trọng Nhất của Bug để hiểu được bug đó đang bị gì , lỗi ở đâu
6.3.2.5. Mô tả tiêu đề
6.3.2.6. Môi trường xảy ra Bug
6.3.2.7. Các bước để Dev tìm ra lỗi đó
6.3.2.7.1. B1: mở vao màn hình đăng nhập
6.3.2.7.2. B2: nhấn vào nút này nút kia
6.3.2.7.3. B3....
6.3.2.8. Kết quả mong đợi: mình mong muốn con bug đó khi kiểm tra sẽ có kết quả như thế nào
6.3.2.9. Kết quả trả về: kết quả thực tế sau khi kiểm tra bug đó
6.3.2.10. Severity và Priority: Mức độ nghiêm trọng và mức độ ưu tiên