1. Kiểm thử phần mềm
    1. là quá trình tìm kiếm phát hiện lỗi
    2. nhằm đảm bảo phần mềm chính xác
    3. đáp ứng đủ và đúng theo yêu cầu của KH
  2. Công việc của Tester
    1. Đọc tài liệu
    2. Viết testcase
    3. Thực hiện test
    4. Log bug/ Report
  3. Phương pháp Testing
    1. White Box Testing (Unit Test)
      1. Kiểm thử đầu ra, đầu vào hệ thống dựa theo logic code bên trong
      2. Công việc của Dev
    2. Black Box Testing
      1. Không quan tâm code, test chức năng hệ thống dưới góc nhìn người dùng
      2. Công việc của Tester
  4. Kiểm thử Động và Tĩnh (Dynamic/Static Testing)
    1. Kiểm thử tĩnh (Static Testing)
      1. Là kiểm tra kế hoạch, kiểm tra sớm để phát hiện lỗi sớm
      2. Các Leaders và BA
      3. Kiểm thử không code, trước khi code
      4. Kiểm tra Logic
        1. Kết cấu code
        2. Tài liệu
        3. Test Plan
    2. Kiểm thử động (Dynamic Testing)
      1. Là kiểm tra quá trình, theo dõi quá trình vận hành của hệ thống
      2. Công việc của Tester và DEV
      3. Chức năng (Functional Testing)
        1. White Box
        2. Black Box
      4. Phi chức năng (Performance + Security Testing)
        1. Hiệu suất
        2. Hiệu năng
        3. Bảo mật
  5. SDLC (Software Development Life Cycle) - Vòng đời phát triển phần mềm
    1. Waterfall
      1. Khái niệm
        1. SDLC đầu tiên trên TG
        2. Phương pháp quản lý dự án trên quy trình thiết kế tuần tự và liên tiếp
        3. Giai đoạn mới chỉ được bắt đầu khi giai đoạn trước đã hoàn thành xong
        4. Các giai đoạn đều là time-fixed
      2. Sơ đồ dự án
        1. PM
          1. BA
          2. Tech Lead
          3. Dev Lead
          4. Dev member
          5. Front-end
          6. Back-end
          7. Full-stack
          8. Tester Lead
          9. Tester member
      3. Các giai đoạn vận hành dự án
        1. Requirement (Yêu cầu)
          1. Xác định yếu tố kinh doanh
          2. Chuẩn bị tài liệu theo yêu cầu client (High-level)
          3. Setup nhân sự
          4. Chốt được yêu cầu cơ bản của dự án
        2. Design (Thiết kế)
          1. BA
          2. BA Thiết kế tài liệu
          3. Tech Lead
          4. Logic hệ thống
          5. Tester Lead
          6. Chuẩn bị Test Plan
          7. - BA finish tài liệu - Tech Lead done logic - Tester Lead done Test Plan
        3. Implementation (Thực hiện)
          1. DEV
          2. Build code
          3. Tester
          4. Viết Testcase
          5. Chuẩn bị data test
          6. - DEV done code – Unit Test - Tester done testcase
        4. Verification (Kiểm tra)
          1. Tester
          2. Test các luồng
          3. Report bug nếu có
          4. DEV
          5. Fix bug nếu có
          6. - Hệ thống đã ổn định - Các bugs được fix hết - Các testcases đã execute
        5. Maintenance (Duy trì)
      4. Nhược điểm
        1. Không linh hoạt trong vận hành
        2. Khách hàng chỉ được xem sản phẩm ở bước cuối cùng
        3. Cố định về mặt thời gian – Tiến độ không đảm bảo
      5. Nên áp dụng khi nào
        1. Nắm vững công nghệ phát triển dự án
        2. Loại bỏ những yêu cầu mập mờ không rõ ràng
        3. Có lượng tài nguyên phát triển phong phú và trình độ chuyên môn kĩ thuật cao
        4. Phù hợp với dự án nhỏ, ngắn hạn hoặc dự án cực lớn
    2. Agile - Scrum
      1. Là 1 SDLC được sử dụng với những dự án phức tạp, cần sự linh hoạt trong vận hành
        1. Là nền tảng để phục vụ đa lĩnh vực
        2. 3 giá trị cốt lõi: - Tính minh bạch (Transparency) - Tính thanh tra (Inspection) - Tính thích nghi (Adaptation)
        3. 4 điều cần nhớ: - Cấu trúc dự án - Các cuộc họp - Cách vận hành - Công việc của Tester
      2. Cấu trúc dự án
        1. Customer
          1. Khách hàng - Client (Business Owner)
          2. Người dùng (End User)
        2. Scrum Team
          1. PO (Product Owner): Người chịu trách nhiệm dự án
          2. SM (Scrum Master): Người điều phối dự án
          3. Tech Architect: Chịu trách nhiệm về kĩ thuật
          4. BA, DEV, QA (QC), Designer,…
        3. Giảm tình trạng quan liêu, phân cấp bậc
      3. Sprint: Giai đoạn
        1. 1 dự án Scrum gồm nhiều Sprints
        2. 1 Sprint trung bình ~ 2 đến 4 tuần
        3. Có 4 cuộc họp cố định, các cuộc họp có thể fix cứng hoặc linh động
        4. Để hoàn thiện 1 sprint, phải hoàn thành tất cả công việc trong Sprint đó
      4. Meetings: Các cuộc họp
        1. Sprint Planning: 2 tiếng Đánh giá và phân chia công việc
        2. Daily Meeting: 15-20 phút Mems report công việc, SM đánh giá tiến độ, thông báo thông tin liên quan đến dự án
        3. Sprint Review:
          1. Internal Review (Review nội bộ): BA và Tester tham gia, thực hiện lại các luồng chính
          2. Sprint Demo: Demo cho khách hàng (BA là nhân vật chính)
        4. Sprint Retrospective: Đánh giá Sprint vừa rồi qua 3 mặt Good, Bad, Action; SM là người điều phối
        5. Note: Một số cuộc họp có thể linh động về mặt thời gian
      5. Azure DevOps/JIRA
        1. Là 1 trình quản lý công việc, tài liệu cho SDLC Agile-Scrum
        2. Nơi quản lý các ticket phải làm
        3. Để các thành viên trong Scrum quản lý công việc phải làm trong 1 sprint
        4. SM/PO/BO/Manager có thể quản lý công việc, xem báo cáo
      6. Ticket trong Agile
        1. 1 phần công việc được gọi là 1 ticket
        2. Phân loại ticket
          1. Ticket to (Ticket parent): Là 1 phần công việc high-level
          2. Các ticket nhỏ: Là các phần công việc kĩ thuật cần phải làm
          3. To do/Open/New: Tast đã được giao, chưa làm
          4. In Progress: Task đang làm
          5. Re-opened/Ready to test: Dành riêng cho Bug
          6. Done: Ticket hoàn thiện
      7. Product Backlog
        1. Là nơi chứa tất cả các ticket phải làm
        2. Có cột Itegration Path để biết ticket làm ở sprint nào
        3. BA sẽ có buổi Planning với khách hàng để biết khách hàng muốn làm ticket nào ở sprint này.
          1. Nếu muốn làm thêm => Tạo ticket, đưa vào Product Backlog rồi sắp xếp thời gian làm
      8. Trình tự thời gian theo sprint
        1. BA/PO sẽ tạo các ticket (Các tính năng phải làm), sắp xếp vào Product Backlogs
        2. BA tổng hợp 1 số ticket phù hợp với Sprint này (Dựa vào Sprint Capacity)
        3. BA/SM host buổi Sprint Planning – Tạo ra Sprint Planning file (đẩy task lên Sprint Backlog: AzureDevOps) & Build Plan
          1. Planning file - Gồm 2 sheets
          2. Capacity planning: Khai báo effort làm việc => Output ra số giờ làm việc trong 1 sprint
          3. Estimation: Các ticket sẽ có effort cho từng ticket con
          4. Note: Cách estimate sẽ dựa vào Story Point của Ticket. Ticket càng to, càng phức tạp thì càng nhiều point
          5. Build Schedule (Build Plan)
          6. DEV lead/Tech lead sẽ có lịch build tương ứng → Ngày ticket đó phải xong trong sprint
        4. Vận hành – Có daily meeting mỗi ngày
        5. Internal Review – Review nội bộ (BA & Tester)
        6. Sprint Demo – Demo cho khách hàng (BA host)
        7. Sprint Retrospective
      9. Công việc của Tester trong Agile -Scrum
        1. Đọc tài liệu
          1. Tìm các ticket to (parent ticket) được assign cho mình sau buổi planning
          2. Tìm các ticket gần nhất (theo Build Plan) để xử lý trước
          3. Đọc tài liệu các ticket
        2. Viết Testcase
          1. Từ tài liệu, áp dụng các kĩ thuật để viết testcase
        3. Thực hiện test
          1. Đợi ticket đó build xong (theo Build Plan)
          2. Test cuốn chiếu: Test xong → Chuyển sang làm ticket khác
        4. Log bug / Verify bug (nếu có)
  6. Software Requirement (Tài liệu dự án)
    1. SRS (Software requirement specification)
      1. Là một tài liệu có mục đích cung cấp mô tả toàn diện về 1 sản phẩm phần mềm sẽ được phát triển. Bao gồm:
        1. Mục đích của sản phẩm
        2. Các quy trình kinh doanh chính sẽ được hỗ trợ
        3. Các tính năng
        4. Các thông số hiệu suất chính
        5. Hành vi của sản phẩm
      2. VD: https://www.studocu.com/vn/document/hoc-vien-nong-nghiep-viet-nam/thuc-vat-hoc/template-srs-v1/23861959 OR https://qndev.github.io/resources/SRS.pdf
    2. Use case Diagram (Tài liệu dạng sơ đồ)
      1. Là 1 dạng của Phân tích và thiết kế hướng đối tượng (UML)
      2. Mô tả về ca/phần quyền sử dụng của hệ thống
      3. Bản vẽ này sẽ giúp chúng ta biết được ai sử dụng hệ thống, hệ thống có những chức năng gì
      4. Lập được bản vẽ này bạn sẽ hiểu được yêu cầu của hệ thống cần xây dựng
      5. VD chi tiết: https://iviettech.vn/blog/543-ban-ve-use-case-use-case-diagram.html
    3. User Story (Câu chuyện người dùng)
      1. Thường gặp nhất ở các dự án chạy Agile-scrum/Kanban
      2. Dùng các tool JIRA/AzureDevOps để quản lý các phần tài liệu thành các phần requirement hệ thống nhất có thể: Từ User Story > Ticket Parent > Ticket con (Sub-ticket)
      3. Trong các ticket User Story (chứa tài liệu chính), Tài liệu được chia nhỏ thành các AC (Acceptance Criteria), có Given – When – Then (Điều kiện của tại liệu)
    4. UI/UX
      1. UX (User Experience) - Trải nghiệm người dùng
        1. Cảm nhận, quy trình, kịch bản khi người dùng khi tương tác với sản phẩm (Mức độ tiện dụng, mức độ dễ sử dụng...)
          1. Wireframe của các màn hình, kịch bản, sitemap...
      2. UI (User Interface) - Giao diện người dùng
        1. Giao diện thiết kế giao diện FE của sản phẩm
          1. File Figma, Sketch, Adobe XD...
    5. User Guide
      1. Tài liệu mô tả các nội dung, chức năng, hướng dẫn sử dụng các tính năng của sản phẩm (Như 1 quyển tài liệu Hướng dẫn sử dụng sản phẩm)
      2. VD: https://vpdt.com.vn/HDSD_MOFFICE_v1.0.pdf
    6. BDD (Behaviour Driven Development)
      1. Chi tiết: https://viblo.asia/p/behaviour-driven-development-bdd-la-gi-lam-the-nao-de-su-dung-bdd-L4x5xNA1ZBM
    7. FRS (Functional Requirement Specification)
      1. là tài liệu chi tiết để xây dựng đầy đủ các tiểu tiết có trong yêu cầu chức năng của dự án
      2. Chi tiết: https://www.facebook.com/groups/vnbanet/permalink/1369698447114527/
      3. VD: https://drive.google.com/drive/folders/1xZn2uR0YiRFIPHLUKL6sh0v0zfln_zEL?fbclid=IwAR19-sn974mnPPywPddmra0VeLa8x09bSHfGvFWmi99GZqDR9nRUCQAr8eA
  7. Web Element
    1. Dropdown list: danh sách xổ xuống
    2. Textbox/Input fields: Khung nhập chữ, ô chữ
    3. Submit form/Submit button
    4. Checkbox: Hộp tich – Dùng để tích vào các trường dữ liệu
    5. Radio button: Chỉ chọn được 1 trường dữ liệu
    6. Search bar/Search box: Khung tìm kiếm
    7. Navigation/Navbar: Thanh điều hướng
    8. Filter: Lọc
    9. Hyperlink: Link kết nối
    10. Error Message: Thông báo lỗi
    11. Toast Message/Pop Up Message: Thông báo thành công
  8. Element Action
    1. Click element/Double click + on: Nhấp chuột
    2. Mouse over/hover + on: Di chuột qua – Hiển thị tooltip + Hyperlink
    3. Input/Enter text: Nhập chữ
    4. Verify/Check: Kiểm tra
    5. Display: Hiển thị
    6. Empty, Blank, Highlight,…
  9. Testcase (Kịch bản kiểm thử)
    1. Khái niệm
      1. Là tập hợp thông số: - Đầu vào kiểm thử - Điều kiện thực thi - Kết quả mong muốn
      2. Mục đích: kiểm thử cần chạy để lấy thông tin. VD: chương trình sẽ vượt qua bài kiểm thử hay không
      3. Là nền tảng của Đảm bảo chất lượng trong khi chúng được phát triển để Xác minh chất lượng, hành vi của sản phẩm
    2. 8 Trường cần có của Testcase
      1. ID (Mã định danh TC)
      2. Description (Mô tả testcase)
      3. Priority (Mức độ ưu tiên)
        1. Low Case về giao diện/ Đa trình duyệt (cross-browser)
        2. Medium Case luồng chính/Positive
        3. High Case luỗng gãy/Những luồng user hay thao tác/Negative/Luồng phụ
      4. Precondition (Tiền điều kiện)
      5. Steps (Các bước thực hiện testcase)
      6. Expected Result (Kết quả mong muốn)
      7. Actual Result (Kết quả thực tế)
        1. Pass: Hoàn thành
        2. Fail: Lỗi
        3. Block: Chưa test
        4. Not test: Không test
      8. Notes (Ghi chú/Lưu ý)
    3. Review Testcase
      1. Nhằm kiểm tra chéo về hiệu quả TC, bao phủ chuẩn hơn, cover được nhiều trường hợp có thể xảy ra
      2. Review theo chuẩn trình tự tiếp cận TC, chú ý về câu từ ngữ pháp
      3. Có thể Review trực tiếp trên file Excel chứa TC, highlight lại bằng mực đỏ/add comment, sau khi review nhắn trực tiếp cho Tester kia
  10. Các Phương pháp/ Kỹ thuật viết Testcase
    1. Mục đích: - Để viết testcase hiệu quả nhất - Tránh lãng phí thời gian mà vẫn có hiệu quả kiểm thử tốt nhất - Cover tốt các trường hợp có thể xảy ra
    2. Dựa vào tài liệu (Requirement Based)
    3. Đoán lỗi (Error Guessing)
    4. Phân tích giá trị biên (Boundary Value Analysis - BVA)
    5. Phân vùng tương đương (Equivalence Partitioning)
    6. Bảng quyết định (Decision Table)
    7. Có thể áp dụng kết hợp lẫn nhau các kĩ thuật → Để bộ testcase cover được tốt nhất
  11. Cách tiếp cận viết Testcase
    1. Đọc, phân tích tài liệu
      1. Lên Test Design
        1. UI/Wording
        2. Navigate
        3. Validate
        4. Logic
    2. Viết các case về giao diện + Các case về cross browser – Priority Low
    3. Viết các case luồng chính/happy case - Priority Medium
    4. Viết các case luồng phụ/negative (Áp dụng các kĩ thuật viết TC) – Priority High
  12. Bug = Defect
    1. Khái niệm
      1. Là lỗi của hệ thống, xảy ra trên FE/BE
      2. Xuất hiện khi developer xử lý một dòng hoặc một đoạn code bị lỗi → kết quả đưa ra khác với yêu cầu của khách hàng
      3. Được tìm thấy bởi Tester trong team phát triển sản phẩm
    2. Defect Leakage
      1. Cũng là Bug nhưng được tìm thấy bởi bên ngoài team phát triển (trong công ty, phía KH, end-user...)
      2. Khá nghiêm trọng, có thể để lại feedback không tốt cho đội phát triển
    3. Log Bug
      1. Hành động Tester ghi chú lại Bug, tổng hợp vào Excel/JIRA/Azure, mục đích để Dev biết lỗi sai ở đâu
    4. 11 trường cần có của Bug
      1. ID (Mã định danh Bug)
      2. Overview (Mô tả tổng quan lỗi = Description)
      3. Severity Mức độ nghiêm trọng (Tùy cảm quan của Tester)
        1. 1. Front-end (UI): Bug trên giao diện → Minor/Medium
        2. 2. Back-end: Bug trong cơ sở dữ liệu/API/Logic code sai… → High/Critical
        3. 3. Documentation: Bug do tài liệu sai → BA
        4. 4. UX (User experiences): Bug do trải nghiệm người dùng chưa tốt
        5. 5. Performance: Bug hiệu năng (Trang lag, load lâu hơn 3s,…) → High/Critical
        6. 6. Security: Bug bảo mật → High/Critical
      4. Precondition (Tiền điều kiện)
      5. Steps (Các bước tái hiện Bug)
      6. Expected Result (Kết quả mong muốn)
      7. Actual Result (Kết quả thực tế xảy ra khi test)
      8. Enviroment (Browser tester dùng khi test)
        1. Browser
        2. Hệ điều hành
      9. Dev Assign (Dev nào fix Bug này thì cho tên vào)
      10. Bug Status
        1. New (Tester)
        2. Open (Dev)
        3. In progress (Dev)
        4. Ready to test (Dev)
        5. In test (Tester)
        6. Re-open (Dev)
        7. Close bug
      11. Evidence (Hình ảnh/Video tái hiện Bug)
      12. Giống Testcase
    5. Vòng đời của Bug
  13. 4 giai đoạn trong Testing
    1. Unit Test
      1. Kiểm tra code (Dev thực hiện)
    2. Intergration Test
      1. Test tích hợp (2 hoặc nhiều module)
    3. System Test (E2E)
      1. Test lại full các luồng của hệ thống – Happy case
    4. UAT (User Acceptance Testing)
      1. Alpha Testing: Tets tại nơi sản xuất phần mềm, gọi là test nội bộ
      2. Beta Testing: Test bởi người dùng ngoài, thực hiện trước khi release chính thức
  14. Các bản build (môi trường)
    1. Local
      1. DEV code/thực hiện unit test trên máy cá nhân (Local)
      2. Sau khi review ok (GitHub) thì đẩy code lên Site Test
      3. Mỗi ticket được đẩy lên là 1 bảng build
    2. Site Test
      1. Team chủ yếu làm việc trên Site Test – web nội bộ
      2. Demo cho khách hàng trên Site Test
      3. Cuối mỗi sprint, Tech Lead sẽ đẩy code (deploy) lên môi trường ổn định (Staging Site)
    3. Staging Site
      1. Môi trường khách hàng thực hiện test
      2. Nếu có defect leakage sẽ báo cho team sửa
    4. Production
      1. Môi trường thực tế - nơi khách hàng/end-user sử dụng phần mềm
  15. Smoke Test/ Smoke Testcase (Phân biệt với Sanity Test)
    1. Áp dụng chủ yếu cho Agile/Scrum
    2. Smoke Testcase = Các luồng chính (Priority = Medium)
      1. Là các testcase cover được hết logic chính của tài liệu
    3. Thường tỉ lệ Smoke TC là 15%/Tổng số TC của ticket đó
    4. Mục đích của Smoke TC = Kiểm tra độ ổn định của bản build
    5. Khi có 1 bản build mới lên (Local – Site test), Tester sẽ thực hiện Smoke test (Execute với các smoke TC của ticket) trước khi test full các TC
    6. Nếu Smoke TC fail → Trả ticket cho DEV, không test nữa
  16. Retest/ Regression Test
    1. Retest: Kiểm tra lại bug bị Re-open (Sau khi Dev đã fix)
    2. Regression Test: Test hồi quy
      1. Thường khi dự án chạy lâu, nhiều tính năng ảnh hưởng lẫn nhau → Hay xảy ra lỗi → Regression Test
    3. Tester thường sẽ thực hiện lại 1 số smoke TC của các ticket để kiểm tra lại luồng chính. Sẽ có 1 bộ TC regression test cho tester thực hiện execute
    4. Ứng dụng trong Agile/Scrum: Thường mỗi sprint sẽ có riêng 1 ticket để các tester thực hiện Regression Test
    5. Fact: Công việc regression test thường do Automation Tester làm, Manual Tester cũng có thể làm khi được chia task