Tổng hợp kiến thức cơ bản cho Tester bạn nên biết
Nhiều bạn hỏi mình về chia sẻ kiến thức tổng hợp cho tester.
Vì thế hôm nay mình sẽ viết một bài tổng hợp kiến thức tổng quan, nó giống như 1 cái checklist để bạn tổng hợp lại kiến thức.
Thì sau đây là một số kiến thức mình tổng hợp lại nhiều nguồn khác nhau, mình có ghi nguồn không cần xem link vì mình ghi đủ rồi, mình tổng hợp để bạn nắm được mà không bị phân tán bởi nhiều nguồn gây rối, đọc một nơi thôi.
I: Tổng hợp một số kiến thức cần nắm của tester.
Về cơ bản các bạn cần nắm:
1: Test level
Về cơ bản có 4 mức độ kiểm thử,
A. Component testing (Unit testing): kiểm thử mức đơn vị
Kiểm tra đơn vị (Unit testing) được thực hiện để kiểm tra xem các module riêng lẻ của mã nguồn có hoạt động đúng hay không. Tức là kiểm tra từng đơn vị của ứng dụng một cách riêng biệt bởi nhà phát triển trong môi trường của nhà phát triển. Đây là thử nghiệm module. Nói chung cái đoạn này thường là do dev làm.
Unit testing là kiểu white box testing
Mục đích:
Để xác định rằng mỗi đơn vị phần mềm được thực hiện như thiết kế.
Thử nghiệm đơn vị làm tăng sự tự tin trong việc thay đổi / bảo trì code. Nếu kiểm tra đơn vị tốt được viết và nếu chúng được chạy mỗi khi bất kỳ mã nào được thay đổi, chúng ta sẽ có thể bắt kịp kịp thời mọi lỗi do thay đổi.
Chi phí sửa chữa lỗi phát hiện trong khi kiểm tra đơn vị nhỏ hơn so với lỗi phát hiện ở mức cao hơn. So sánh chi phí (thời gian, công sức, sự hỏng hóc, mất thể diện) của một lỗi phát hiện trong quá trình kiểm thử chấp nhận hoặc khi phần mềm đang hoạt động.
B. Integration testing: kiểm thử tích hợp
Định nghĩa:
Là cấp độ kiểm thử phần mềm trong đó các đơn vị riêng lẻ được kết hợp và thử nghiệm dưới dạng một nhóm. Một dự án phần mềm bao gồm nhiều module phần mềm, được code bởi nhiều người khác nhau. Kiểm thử tích hợp tập trung vào kiểm tra truyền dữ liệu giữa các module (tích hợp các hàm lại với nhau, tích hợp các màn hình lại với nhau theo từng module hay dựa theo chức năng.)
Mục đích:
Để lộ các lỗi trong sự tương tác giữa các đơn vị tích hợp. Để tìm ra lỗi trong quá trình tích hợp các thành phần, module lại với nhau. Các trình điều khiển thử nghiệm và các phần tử thử nghiệm được sử dụng để hỗ trợ trong Kiểm thử tích hợp.
Các phương pháp tiếp cận:
**1: Big bang: **
Trong kiểm thử tích hợp Big Bang, các module riêng lẻ không được tích hợp cho đến khi tất cả các module sẵn sàng. Sau đó, họ sẽ chạy để kiểm tra xem nó có hoạt động tốt hay không. Trong loại thử nghiệm này, một số nhược điểm có thể xảy ra, các lỗi có thể được tìm thấy ở giai đoạn sau. Sẽ rất khó để tìm ra liệu lỗi có xuất hiện trong giao diện hay trong module.
**2: Top Down: **
Trong kiểm thử tích hợp Top Down, các module mức cao được tích hợp và kiểm tra trước tiên. Tức là kiểm tra từ module chính đến module phụ. Trong loại thử nghiệm này, Stubs được sử dụng làm module tạm thời nếu module chưa sẵn sàng để thử nghiệm tích hợp.
**3: Button Up: **
Trong kiểm thử tích hợp Button Up, các module cấp thấp được tích hợp và kiểm tra trước tiên, tức là kiểm tra từ module phụ đến module chính. Tương tự như Stubs, trình điều khiển ở đây được sử dụng như một module tạm thời để kiểm thử tích hợp. Sandwich / Hybrid là một cách tiếp cận để kiểm thử tích hợp, đó là sự kết hợp của các phương pháp Top Down và Bottom Up.
C. System testing: kiểm thử mức hệ thống
Định nghĩa:
Là một mức độ kiểm thử phần mềm, nơi một phần mềm hoàn chỉnh và tích hợp được kiểm tra.
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.
Kiểm thử hệ thống bao gồm kiểm thử chức năng và phi chức năng.
Kiểm thử hệ thống tập trung nhiều hơn vào các chức năng của toàn bộ hệ thống.
Các trường hợp kiểm thử hệ thống bao gồm các chức năng của sản phẩm hoàn chỉnh và được thực hiện các trường hợp kiểm thử mức độ cao.
Các hành vi của ứng dụng hoàn chỉnh được kiểm tra để đáp ứng các yêu cầu quy định. Các trường hợp kiểm thử và dữ liệu kiểm thử được thực hiện và các dữ liệu thực tế không được sử dụng trong loại kiểm thử này.
Mục đích:
Để đánh giá sự tuân thủ của hệ thống với các yêu cầu được chỉ định.
D. Acceptance testing kiểm thử chấp nhận
Định nghĩa:
Là một mức độ kiểm thử phần mềm trong đó một hệ thống được kiểm tra tính chấp nhận.
Kiểm thử chấp nhận kiểm thử các chức năng để kiểm tra hành vi của hệ thống bằng cách sử dụng dữ liệu thực tế. Nó cũng được gọi là thử nghiệm người dùng doanh nghiệp.
Kiểm thử chấp nhận được thực hiện bởi người dùng cuối để kiểm tra hệ thống được xây dựng để phù hợp với yêu cầu kinh doanh của tổ chức.
Mục đích:
Đánh giá sự tuân thủ của hệ thống với các yêu cầu kinh doanh và đánh giá xem nó có được chấp nhận cho việc phân phối hay không.
Mục tiêu của acceptance testing là xác nhận lại sự tin tưởng vào hệ thống, các đặc tính thuộc về chức năng hoặc phi chức năng của hệ thống. Tìm kiếm lỗi không phải là trọng tâm chính của Acceptance testing.
Acceptance testing có thể đánh giá sự sẵn sàng của hệ thống để triển khai và sử dụng, mặc dù không nhất thiết phải là mức cuối cùng của việc kiểm thử.
Các loại kiểm thử chấp nhận:
Alpha Testing: là một dạng của Acceptance testing. Alpha testing là một nhóm người thực hiện test tại nơi sản xuất phần mềm. Là một dạng của test chấp nhận nội bộ, trước khi phần mềm thực hiện Beta Testing.
Beta Testing là hình thức kiểm thử sau Alpha Testing. Nó được thực hiện tại địa điểm của khách hàng, không phải nơi phát triển phần mềm.
Đoạn này mình tham khảo ở đây : https://viblo.asia/p/cac-giai-doan-kiem-thu-phan-mem-testing-levels-LzD5dvJeZjY
2: Test type
Đáng lẽ mình viết thêm ở đây thì sẽ bị trùng, tuy nhiên khi phỏng vấn người ta hỏi Test Type, ý là nói về cái này, phần test level ở trên chính là detail của Functional testing,
1: Testing of function ( Functional testing)
Kiểm thử chức năng có thể được hiểu là một bài test xem phần mềm có thực hiện đúng chức năng hay không và được thực hiện trong mọi mức kiểm thử. Functional Testing hướng tới việc test toàn thể chức năng hoặc một chức năng cụ thể
Functional Testing có thể được thực hiện bằng hai phương pháp sau:
Kiểm thử dựa trên yêu cầu: Đây là cách tiếp cận sử dụng chính yêu cầu (requirement) để thiết kế bài kiểm thử. Đồng thời, các tester có thể sử dụng nội dung của yêu cầu để phân chia những phần cần hay không cần kiểm thử.
Kiểm thử dựa trên bối cảnh thực tế: Có thể hiểu đây là cách tiếp cận dựa trên các bước thực tế khách hàng sử dụng phần mềm. Các use case sẽ trở nên hữu dụng trong quá trình kiểm thử phần mềm.
Functional Testing thường có 5 bước sau đây:
- Xác định các function mà bạn muốn phần mềm sẽ thực hiện.
- Tạo các dữ liệu đầu vào dựa trên các tài liệu đặc tả kỹ thuật của các function.
- Xác định các kết quả đầu ra dựa trên các tài liệu đặc tả kỹ thuật của các function.
- Thực hiện các trường hợp kiểm thử (Test Case)
- So sánh kết quả thực tế và kết quả mong muốn.
2: Testing of software product characteristics (Non - Functional testing)
Nếu như Functional Testing hướng tới việc test toàn thể chức năng hoặc một chức năng cụ thể thì Non-functional Testing được thực hiện nhằm trả lời câu hỏi: “Phần mềm có hoạt động tốt không?”. Kiểm thử phi chức năng chú trọng nhiều hơn vào những khía cạnh khác của phần mềm, như là độ bảo mật và khả năng tải của phần mềm đó, ví dụ như bao nhiêu người có thể đăng nhập cùng 1 lúc.
Hoạt động kiểm thử phi chức năng là sự bổ sung hiệu quả cho hoạt động kiểm thử chức năng vì chúng cung cấp thông tin quan trọng về độ an toàn, khả năng phục vụ và độ tin cậy của hệ thống. Loại thử nghiệm này kiểm tra cách sản phẩm phần mềm hoạt động và bao gồm (nhưng không giới hạn ở) các loại sau:
- Reliability Tests (Kiểm thử độ tin cậy)
Kiểm thử độ tin cậy kiểm tra xem phần mềm có thể duy trì một mức hiệu suất nhất định với các điều kiện nhất định và trong một khoảng thời gian nhất định hay không.
- Robustness Tests (Kiểm thử độ bền)
Loại thử nghiệm này được thiết kế để chứng minh rằng hệ thống hoạt động chính xác trong mọi điều kiện, ngay cả trong các sự kiện bất ngờ.
- Stress tests
Stress test có mục đích giám sát hành vi của hệ thống trong các trường hợp không điển hình, chẳng hạn như xác định khả năng chịu tải của hệ thống.
- Performance Tests (Kiểm tra hiệu năng)
Kiểm thử hiệu suất được tiến hành để xác định cách phần mềm hoạt động về khả năng đáp ứng và tốc độ xử lý trong một khối lượng công việc. ( mọi người thường dùng Jmetter
- Load Tests (Kiểm thử tải) Load Test là quá trình mô phỏng độ chịu tải thực tế của bất kỳ ứng dụng hoặc trang web nào. Nó kiểm thử cách ứng dụng hoạt động trong điều kiện hoạt động bình thường và hoạt động hiệu suất cao.
- Usability Tests (Kiểm thử tính khả dụng) Đây là kỹ thuật được thiết kế để xác minh xem người dùng cuối có thể dễ dàng sử dụng sản phẩm phần mềm hay không.
-Maintainability Tests (Kiểm thử khả năng bảo trì) Các bài kiểm tra khả năng bảo trì được thực hiện để đánh giá khả năng của phần mềm trong việc đáp ứng các yêu cầu của người dùng và khi được thay đổi thì không gặp bất kỳ vấn đề gì.
- Portability Tests (Kiểm tra thử khả năng thích ứng) Các bài kiểm tra tính di động đo lường mức độ dễ dàng chuyển phần mềm sang môi trường khác, chẳng hạn như mức độ dễ dàng chuyển ứng dụng di động sang các hệ điều hành khác nhau hoặc các thiết bị khác nhau.
3: Testing of software structure/architecture ( Structural testing)
Kiểm thử cấu trúc thường được coi là một loại white box testing. Quá trình này tập trung vào việc kiểm thử những gì đang diễn ra ở bên trong phần mềm hơn là về chức năng của phần mềm đó.
Khi kiểm thử cấu trúc, các tester cần có hiểu biết về quá trình xây dựng và phát triển của phần mềm này. Họ sẽ tập trung vào việc phần mềm thực hiện tác vụ như thế nào, hơn là chỉ tập trung vào chức năng của phần mềm.
Cũng giống như hai Test Type trên, Structural Testing cũng có thể được áp dụng trong mọi mức độ kiểm thử. Các Developer cũng có thể ứng dụng kiểm thử cấu trúc trong quá trình kiểm thử thành phần hoặc các mức độ thấp hơn trong kiểm thử thành phần.
4: Testing related to changes (Confirmation and regression testing)
Mục đích của kiểm thử thay đổi là để kiểm tra xem phần mềm có vận hành trơn tru sau những lần sửa lỗi hay không. Kiểm thử thay đổi gồm 2 loại chính:
Confirmation Testing (Kiểm thử xác nhận): Thường Confirmation Testing sẽ diễn ra sau khi lỗi trong phần mềm đã được xác nhận và được sửa. Lúc này, vai trò của Kiểm thử xác nhận là để xem lỗi đã thực sự được sửa hay chưa. Các tester sẽ tiến hành bằng cách cho một input giống hệt ban đầu và test xem output có ra được như mong muốn hay không.
Regression Testing (Kiểm thử hồi quy): Mục đích của kiểm thử hồi quy để xác nhận rằng các thay đổi trong phần mềm hoặc môi trường không gây ra bất lợi ngoài mong muốn và hệ thống vẫn đáp ứng các yêu cầu. Kiểm thử hồi quy được thực hiện khi phần mềm thay đổi, do sửa lỗi hoặc do chức năng mới. Việc thực thi Regression Testing cũng nên được cân nhắc khi môi trường xung quanh phần mềm có sự thay đổi.
Nguồn: https://vn.got-it.ai/blog/test-type-la-gi-tim-hieu-ve-cac-loai-test-type
3: Test design
- Là kỹ thuật giúp chúng ta thiết kế một cách đầy đủ nhất các trường hợp kiểm thử. Như mình hay ví von thì để hoàn tất quá trình kiểm thử sẽ có 2 giai đoạn là Static Testing xác minh (verification) và Dynamic Testing xác nhận (validation). Kỹ thuật thiết kế kiểm thử giúp chúng ta thiết kế một cách đầy đủ nhất các trường hợp kiểm thử. Vì việc test toàn diện là không thể nha.
- Đi vào 2 dạng kỹ thuật Test Design chính trên:
- Dạng 1: Static Testing :
-
Static Testing là 1 kỹ thuật quan trọng mà có dạng Business requirement review, Functional requirement review, design reviews, code walkthroughs và test documentation review. Nó là 1 chuỗi các hoạt động và không chỉ được làm bởi các tester.
Bao gồm các phương thức sau:
Document reviews: các review về tài liệu.
Walkthroughs: Kiểm tra từ đầu đến cuối.
Inspection: kiểm duyệt.
Feasibility analysis or any other form of analysis to determine if the software is what it should be or not: Phân tích tính khả thi hay bất kỳ các phân tích khác để chỉ ra software cần cái gì hay không cần cái gì.
Code review
- Dạng 2: Dynamic Testing
Dynamic Testing là khi bạn đang làm việc với hệ thống thật (Không phải 1 số hiện vật hoặc mô hình đại diện cho hệ thống), cung cấp 1 đầu vào, nhận 1 đầu ra và so sánh đầu ra với hành vi mong đợi. Nó làm việc thực tế với hệ thống với mục đích tìm kiếm các lỗi. Một quá trình chính thống của việc nhận diện các test case/condition, các coverage consideration, execution sẽ đánh đấu tất cả các phương thức của Dynamic Testing
1: Kỹ thuật specification-based
Nhóm kỹ thuật specification-based chỉ tập trung kiểm thử những yếu tố bên ngoài của hạng mục kiểm thử. Chúng có thể là các đặc điểm kỹ thuật, thiết kế, cách vận hành bên ngoài,… Nhờ đó, tester có thể test chất lượng bên ngoài mà không làm hỏng cấu trúc bên trong phần mềm.
Nhóm kỹ thuật này gồm có:
A. Phân vùng tương đương (Equivalence Partitioning)
Là phương pháp chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử, thường được tiến hành theo 2 bước sau:
Bước 1: phân các vùng dữ liệu thành các vùng điều kiện tương đương
Bước 2: Xác định các ca kiểm thử
Nguyên tắc xác định các lớp tương đương:
Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương thành 3 tình huống: Xác định một lớp tương đương hợp lệ. Xác định hai lớp tương đương không hợp lệ. Ví dụ: giá trị của mật khẩu phải từ 6-24 ký tự, vậy ta có 1 lớp giá trị tương đương hợp lệ là [6-24], 2 lớp tương đương không hợp lệ là: <6 và 24> Nếu điều kiện đầu vào là một giá trị xác định thì chia vùng tương đương thành 3 tình huống: Một lớp tương đương hợp lệ. Hai lớp tương đương không hợp lệ. Ví dụ: test font chữ = 12, vậy ta có 1 lớp giá trị tương đương hợp lệ là 12, 2 lớp tương đương không hợp lệ là: <12 và 12>.
B. Phân tích giá trị biên (Boundary Value Analysis)
Test các giá trị biên của các vùng dữ liệu vào và ra.
2 cách tiếp cận:
-
Kiểm tra 2 giá trị: Có 4 test cases (Nhỏ nhất, Sát dưới mức nhỏ nhất, Sát trên mức lớn nhất, Lớn nhất).
-
Ví dụ:
-
Kiểm tra 3 giá trị: Có 6 test cases (Nhỏ nhất, Sát dưới mức nhỏ nhất, Sát trên mức nhỏ nhất, Lớn nhất, Sát dưới mức lớn nhất, Sát trên mức lớn nhất).
-
Ví dụ:
C. Bảng quyết định (Decision Table Testing)
Bảng quyết định là một kỹ thuật tốt khi input có nhiều điều kiện và có nhiều action output. Giúp giảm thời gian chạy thử nhưng vẫn giữ đủ độ bao phủ của test.
Các bước thực hiện:
- Liệt kê tất cả các điều kiện và action
- Tính số lượng các trường hợp tổ hợp có thể
- Điền các tổ hợp vào Bảng
- Lược bỏ các tổ hợp test và đưa ra action cho các trường hợp test.
Ví dụ:
Tham khảo diễn đàn của anh Sơn về bảng quyết định để hiểu thêm: https://www.testingvn.com/viewtopic.php?t=2750
D. Chuyển đổi trạng thái (State Transition Testing)
Đây là một phương pháp kiểm thử mà trong đó dựa vào thay đổi điều kiện đầu vào gây ra thay đổi trạng thái trong phần mềm được kiểm thử. Trong kỹ thuật này, tester sẽ cung cấp cả giá trị kiểm thử đầu vào hợp lệ và không hợp lệ, sau đó xác định cách xử lý của hệ thống.
Các bước tạo bảng chuyển đổi trạng thái:
- Liệt kê tất cả các trạng thái từ biểu đồ chuyển đổi trạng thái vào cột đầu tiên của bảng.
- Liệt kê tất cả các kết hợp event/condition
- Tạo bảng với trong đó, mỗi hàng sẽ cho 1 trạng thái với kết hợp event/condition
Mỗi hàng bao gồm 4 trường:
-
Current state
-
Event/condition
-
Action
-
New state
E. Use cases Testing
Là một kỹ thuật kiểm thử phần mềm, giúp xác định các test cases bao phủ toàn bộ hệ thống trên cơ sở chuyển giao từ điểm bắt đầu đến điểm kết thúc. Ta có thể sử dụng Kiểm thử Use Case để tìm các liên kết còn thiếu sót hay các yêu cầu không hoàn chỉnh, từ đó tìm cách khắc phục, hệ thống sẽ hoạt động chính xác hơn.
Use Case này mình thường được cung cấp từ BA, trong đó sẽ có chi tiết các list function cùng quy ước và flow các màn hình, thể hiện tính tương tác giữa giao diện người dùng và hệ thống.
Ví dụ về Use case testing
Ví dụ với trường hợp kiểm tra điểm của sinh viên của hệ thống quản lý giáo dục
Actors: Students, Teacher, Parents
Pre-condition:
Hệ thống phải có kết nối mạng Internet
Người dùng phải có 'Student ID'
Dưới đây là Use case và Test case tương ứng đối với trường hợp kiểm tra điểm của sinh viên
2: Kỹ thuật Structure-based
Nhóm kỹ thuật structure-based giúp tester kiểm thử cấu trúc và cách vận hành bên trong của phần mềm. Cấu trúc phần mềm thường bao gồm code (mã), control flow (luồng điều khiển), data flow (luồng dữ liệu),… Lúc này, tester sẽ nạp các input để thực thi code và kiểm tra đối chiếu những output thu được. Vì có liên quan đến cấu trúc phần mềm nên tester phải có kiến thức lập trình.
Dưới đây là các kỹ thuật thiết kế test case thuộc nhóm structure-based:
A. Statement testing (kiểm thử câu lệnh)
Trong kỹ thuật statement testing, mọi câu lệnh trong cấu trúc code sẽ thực thi ít nhất một lần. Qua đó, tester có thể test được cách vận hành của toàn bộ source code (mã nguồn) phần mềm. Tuy nhiên, tester không thể kiểm thử điều kiện sai mà chỉ có thể thực thi các điều kiện đúng.
B. Decision testing (kiểm thử quyết định)
Decision testing sẽ thực thi, test những quyết định dựa trên decision result (kết quả quyết định). Để làm điều này, test case sẽ đi theo các control flow từ decision point (điểm quyết định). Decision testing giúp kiểm thử xem có câu lệnh không thể truy cập hay gây bất thường không.
C. Condition testing (kiểm thử điều kiện)
Condition testing được dùng để test các biểu thức Boolean có dạng True (đúng) hoặc False (sai). Mỗi biểu thức Boolean sẽ được thực thi ít nhất một lần bằng cả tham số True và False. Với kỹ thuật này, test case được thiết kế để những điều kiện Boolean có thể thực thi dễ dàng.
D. Multiple condition testing (kiểm thử đa điều kiện)
Mục đích của kỹ thuật này là kiểm thử mọi tổ hợp điều kiện có thể của quyết định. Công thức tính số tổ hợp này là 2 lũy thừa bậc N, với N là số biến điều kiện. Số lượng tổ hợp này cũng chính là số lượng test case mà bạn phải dùng.
3: Kỹ thuật experience-based
Như tên gọi của mình, nhóm kỹ thuật này phụ thuộc vào hiểu biết và năng lực của tester. Những kiến thức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test case. Do đó, chất lượng của các test case dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào tester. Nhóm kỹ thuật này được chia thành 2 loại:
A. Exploratory testing (kiểm thử thăm dò) Đây là kỹ thuật test không cần chuẩn bị hay theo một lịch trình cụ thể. Khi thực hiện exploratory testing, tester sẽ vừa phân tích phần mềm, vừa thiết kế và thực thi kiểm thử. Ngoài ra, việc lên kế hoạch và lưu kết quả cũng diễn ra linh động trong quá trình kiểm thử.
B. Error guessing (phỏng đoán lỗi) Error guessing được dùng để dự đoán các lỗi tiềm ẩn dựa trên kiến thức của tester. Những kiến thức này thường về cách vận hành trước đây của phần mềm, các lỗi đã và có khả năng xuất hiện, những lỗi mà tester từng phát hiện,…
Bài này mình tham khảo của anh: Nguyen Van Nam D mặc dù đọc nhiều bài nhưng bài của anh ấy là chi tiết nhất: https://viblo.asia/p/ky-thuat-thiet-ke-kiem-thu-trong-kiem-thu-phan-mem-vyDZOn1dKwj
4: Bug life cycle
Mục tiêu chính của tester không chỉ là tìm ra bug/ khiếm khuyết của phần mềm mà còn phải theo dõi lỗi đó cho đến khi close nó. Vì vậy, vòng đời của bug là từ lúc tester tìm thấy bug đó đến khi close nó.
Bug Life Cycle là tập hợp các trạng thái cụ thể mà Bug trải qua trong toàn bộ vòng đời của nó. Mục đích tạo ra quy trình cho một vòng đời bug/defect là để những người chịu trách nhiệm cho bug/defect đó dễ dàng quản lý và thay đổi trạng thái cho đến khi bug/defect được loại bỏ hoàn toàn khỏi hệ thống.
- Tester tìm thấy bug/defect
- Gán trạng thái cho bug: New/Mới
- Chuyển bug sang cho Quản lý dự án để phân tích
- Quản lý dự án quyết định xem bug có hợp lệ không
- Nếu như lỗi không hợp lệ, trạng thái sẽ được chuyển thành "Rejected/Đã từ chối."
- Nếu lỗi không bị rejected thì bước tiếp theo là kiểm tra xem nó có nằm trong phạm vi không. Giả sử chúng ta có một chức năng khác - chức năng email cho cùng một ứng dụng và bạn thấy có vấn đề với điều đó.
- Nhưng nó không nằm trong scope của lần phát hành ứng dụng lần này, trạng thái của bug đó có thể chuyển thành “Postponed/hoãn”.
- Tiếp theo, người quản lý cần xác minh xem đã có bug nào tương tự đã được tìm ra trước đó hay chưa. Nếu đã có rồi, bug này được chuyển trạng thái thành “Duplicate/trùng lặp”.
- Nếu không có vấn đề gì phát sinh trong khi dev fix bug thì bug này được chuyển sang trạng thái là “In- progress/đang tiến hành”.
- Khi code được fixed. Bug sẽ được gán trạng thái là “Fixed/đã sửa xong”
- Tiếp theo, tester sẽ test lại phần code vừa được sửa. Nếu như các phần test cases liên quan đều passed thì bug đó được đóng lại hay được chuyển trạng thái thành “Closed”. Nếu các trường hợp kiểm thử thất bại một lần nữa, lỗi được mở lại/re-opened và lại được chuyển giao sang cho dev
- Hãy xem xét một tình huống trong lần release đầu tiên, một lỗi được tìm thấy theo thứ tự Fax đã được sửa và gán trạng thái đóng. Trong lần nâng cấp thứ hai, lỗi tương tự lại xuất hiện trở lại. Trong những trường hợp như vậy, một khiếm khuyết kín sẽ được mở lại.
Đoạn này mình có tham khảo của chị Phan Thi Duy Huyen ha, ngoài ra bạn có thể đọc thêm ở https://www.guru99.com/defect-life-cycle.html
5: API testing và SQL
Thật sự thì về API Testing mình đã chia sẻ khá nhiều: cứ xem trong group https://www.facebook.com/groups/427902529270659
Nhưng mình vẫn để một số tài liệu tự học ở đây:
1: API Testing:
- Link này để biết cơ bản về các phương thức và cách ứng dụng tool postman:
- Khóa học free 15 ngày API with Postman của chính họ:
- Tham khảo video anh Sang Bui oke nha: https://www.youtube.com/watch?v=lX-S5XZ0MwE&t=1s
https://www.youtube.com/watch?v=nosLeqh7PbY&t=1s
2: SQL:
Mình hay luyện trong đây:
https://www.w3schools.com/sql/
Ngoài ra bạn có thể tham khảo bộ câu hỏi phỏng vấn tóm lại là khi phỏng vấn người ta sẽ hỏi chỉ khoảng 3,4 câu lệnh query dựa vào đề bài thôi, chứ thực tế đến lúc phải query trong dự án là tự ngồi mà nghĩ, search chứ ko ai rảnh nhớ hết tất cả.
**Tùy level mà độ chuyên sâu đòi hỏi khác nhau. ** Ngoài ra cần bạn self-management, self-learn, ability deal with problem, favor (OT khi thực sự cần)..
Vậy là bạn đã có bộ từ khóa ở trên để tìm hiểu kỹ và sâu hơn nha, tiếp đến bài sau mình sẽ chia sẻ về template mà bạn sẽ muốn làm thử nha
Mỏi người quá rồi, bài sau mình chia sẻ template sau nha, đọc ngấu nghiến đi và nhớ cho mình 1 cái động viên để viết tiếp nhé 
All rights reserved
