Shift-left testing! Nó có ý nghĩa gì với mình?

Hẳn ai làm trong mô hình Agile gần đây đều nge đến khái niệm shif-left testing. Hiểu nôm na nó kiểu giống 1 hướng tiếp cận để làm sao tăng quality, giải quyết vấn đề testing khi có quá nhiều tickets cần testing nhưng tester không đủ thời gian và nguồn lực có thể test hết. Vậy nó là gì, team mình đang và đã vận dụng nó thế nào cho việc delivery features. Trong blog này mình sẽ chia sẻ những kinh nghiệm đó để mọi người có thêm 1 góc nhìn, nếu áp dụng được thì càng tốt nhé.

Shift-left là gì

Nếu hiểu theo nghĩa đen của “shift-left” có nghĩa là “dời qua trái” vậy chẳng lẽ nó đang ở “phải” và việc mình làm là đưa nó qua “trái” là xong sao? Đùa một chút thôi, các bạn có thể hình dung lại một vòng đời release của mỗi feature thì đều trải qua các môi trường sau:

Local => SIT(system intergration testing) => UAT(user acceptance testing) => PROD(production)

Như ai cũng thấy để 1 ticket được đi tới PROD thì các tickets đều phải ghé qua Local, SIT, UAT. Và thông thường tới các môi trường này việc testing mới được tiến hành ở cuối các giai đoạn, dẫn tới người tester sẽ có rất nhiều việc làm và thường trở thành bottleneck tại môi trường đó. Cho nên “Shif-left testing” có nghĩa là mình đưa việc testing của 1 ticket đó từ “cuối” giai đoạn thành testing từ “đầu” giai đoạn trong chu trình phát triển phần mềm. Việc đảm bảo quality ko phải dành riêng cho tester nữa mà là trách nhiệm của cả team từ developer, BA, designer, …

Shift-left testing trong các giai đoạn phát triển phần mềm

Áp dung shift-left như thế nào?

Quay lại với câu hỏi ban đầu, vậy áp dụng shift-left thế nào? Test sớm là test thế nào? Nó được tiến hành cụ thể trong từng môi trường thế nào? Có những activity xảy ra cho việc này?

Hình trên là câu trả lời cho tất cả những câu hỏi trên. Các bạn có thể thấy việc testing được tiến hành từ rất sớm và đều được tiến hành trên cả 3 môi trường, nhưng với mỗi môi trường thì chúng mình có các activity khác nhau để đảm bảo quality cho nó.

• Local: Đây là giai đoạn phát triển features nên thứ nhất chúng mình tập trung vào việc đảm bảo những acceptance criteria phải được develop như trong user story đề cập, thứ hai là làm sao đưa feedback nhanh nhất để developer có thể sửa ngay tai giai đoạn này. Chúng mình thực hiện việc đó bằng những buổi demo tại ngay bàn của anh developer đó. Tại buổi này có sự tham gia của cả BA, Designer, PO và Tester, tất cả mọi người sẽ nge anh dev đó nói những criteria mà anh đó đã implement, tiếp theo mọi người sẽ hỏi những câu hỏi liên quan đến features đó để làm rõ requirement, có thể bổ sung những negative case còn thiếu do không aware được lúc develop.
• SIT: Đây là môi trường để có thể test integration tới các 3rd party. Cũng là giai đoạn mà có rất nhiều tickets được deploy xong đồng thời cùng 1 lúc. Vậy thì xử lí bài toán testing thế nào đây? Câu trả lời là tụi mình sẽ nhóm các user story thành từng nhóm feature, thì trước sprint sẽ có 1 bạn QA được assign cho feature đó. Bạn QA đó sẽ nghiên cứu các story đó trước, tạo ra những bộ test case, cũng như chuẩn bị test data. Tiếp theo bạn tester sẽ tiến hành pair-test với developer, thứ nhất hoạt động này sẽ giúp cho ticket được verify nhanh vì developer có thể chia sẻ các test case mà họ đã test từ local, sẽ tiết kiệm thời gian cho tester, vì lúc này tester chỉ cần thêm những case về hệ thống hay những negative case mà thôi. Thứ hai, việc này sẽ thay đổi mindset của tester từ việc tìm ra bug thay bằng việc phòng ngừa, cũng như từ developer sẽ có trách nhiệm hơn với ticket mà mình làm, mục tiêu cuối cùng là làm sao cả team cùng delivery features đúng hẹn.
• UAT: Trên môi trường này thì công việc của tụi mình chỉ chạy regression test lại những test case quan trọng đã test trên môi trường SIT. Những test case quan trọng này là những test case cover được nhiều business nhất, thường sẽ được chọn theo kiểu user journey. Có 1 điểm lưu ý là các bạn nên nói chuyện nhiều với BA hoặc PO để hiểu context mà 1 enduser dùng hệ thống, để từ đó hiểu được nếu đa số khách hàng sử dụng tính năng đó thì họ sẽ sử dụng ứng dụng của mình theo những use case nào.

Vậy shift-left có phải toàn màu hồng?

Câu trả lời của mình là không. Việc áp dụng nó là không dễ cho bất kì team nào. Lí do cho việc đấy là nó đòi hỏi phải thay đổi mindset và cách làm việc cho việc này. Thí dụ cho việc này là pair-test, mình cũng từng cố gắng áp dụng pair-test cho team mình nhiều lần nhưng đa số là failed cả, nó chỉ mới hiệu quả gần đây. Bởi vì để làm được nó, ngoài việc bạn hiểu ý nghĩa tại sao phải làm vậy thì đồng đội của bạn cũng phải hiểu nó nữa. Thông thường mọi người đã quen làm việc theo cách cũ, nhưng nay nếu họ áp dụng shift-left thì họ phải thay đổi cách thức làm việc, process làm việc, cũng như phải tăng khả năng giao tiếp, trình bày trong những buổi demo, hơn nữa phải sử dụng thêm tools cho công việc. Một điều quan trọng nhất là làm sao tất cả các roles cùng hiểu và áp dụng đúng cách. Ví dụ như buổi demo, làm sao cho các role khác như PO, BA, và designer tham gia và đóng góp feedback.

Nhưng nó là điều đáng thử

Túm lại theo mình thì bất kì 1 cách tiếp cận nào đều có ưu và nhược điểm nhưng với shift-left testing thì nó mang lại nhiều ưu điểm hơn nhược điểm. Thứ nhất là tester sẽ không còn là bottleneck tại giai đoạn cuối của release, trách nhiệm testing là của cả team và ai cũng là người đóng góp vô quality cuối cùng của sản phẩm. Thứ hai là quality sẽ được tăng lên nhờ việc testing từ sớm, các defect được phát hiện, phòng ngừa từ giai đoạn phân tích requirement và giai đoạn development chứ không còn trễ như trước đây, do vậy chi phí sữa và nỗ lực sẽ được giảm đáng kể.

Advertisement

Mẫu template mô tả hiệu quả cho một API

Nếu như ai làm trong ngành phần mềm ngày nay thì chắc hẵn không còn lạ lẫm với việc dùng API cho công việc hằng ngày. Tuy nhiên, để có thể mô tả một API cho đồng nghiệp, đối tác hiểu và sử dụng lại được thì cũng là một bài toán thú vị. Trong bài viết này, mình sẽ đưa ra một mẫu mô tả tài liệu API mà mình đã áp dụng trong dự án mình đang làm và thấy hiệu quả cho các bạn để tham khảo. 

Theo mình một mô tả API hiệu quả thì nó phải đáp ứng được các tiêu chí sau:

Dễ đọc, và dễ hiểu

Có thể lấy sử dụng liền được

Có thể dễ dàng cập nhật

Do vậy những thành phần trong 1 mô tả sẽ gồm những phần sau:

• Một môt tả ngắn gọn về chức năng của API
• URI của API đó và ý nghĩa từng thành phần trong URI đó
• Method của API đó là gì
• API đó có header gì?
• Request body
• Response
• Sample cURL

Ví dụ dưới đây là API cho việc tạo mới một học sinh vô trong danh sách học sinh của 1 trường

---

Description		Create new student
Specification	URI	/create
	HTTP Method	POST
	Required HTTP Headers	Authorization Caller-Id Channel Content-Type Correlation-Id
	Request Body	{ “name”: “Tran Van A”, “age”: 12, “grade”: “7A1” }
	Response Body	Success – Status code: 200 Error – Status code: 400 { “errorCode”: “037788”, “errorMessage”: “Duplicate name” }
CURL		curl -X POST \ https://192.168.0.0/student/create\ -H ‘Authorization: Bearer abc_xyz’\ -H ‘Caller-Id: Web’ \ -H ‘Channel: Web’ \ -H ‘Content-Type: application/json’ \ -H ‘Correlation-Id: abc_xyz’ \ -d ‘{ “name” : “Tran Van A”, “age” : 12, “grade” : “7A1” } ‘

Bạn sẽ test như thế nào nếu được đưa 1 API?

Có thể câu trả lời của mọi người là Trời ơi, nó dễ ẹc mà. Ai mà chẳng test được. Nhưng có bao nhiêu người đã từng nghĩ là làm thế nào để test API cho đúng, cho đủ, phòng tránh và hạn chế ít nhất những sai lầm tới product. Trong bài này tôi sẽ liệt kê ra những cách suy nghĩ mà tôi đã áp dụng, những công viêc mà tôi đã làm cho việc test một API, làm sao đảm bảo API đó mang lại chất lượng tốt nhất cho khách hàng.

Đầu tiên, để testing hiệu quả thì bạn phải đặt cho việc test đó nằm một ngữ cảnh cụ thể. Như nó phục vụ cho yêu cầu, nhiệm vụ nào, ai là khách hàng của bạn, khách hàng đó muốn đạt được cái gì?

Ví dụ như ngữ cảnh của tôi, tôi đang phục vụ cho developer hay cho stackholders nào, người nào trong dự án có thể đánh giá chất lượng product và tôi phải quan tâm họ cần gì ở mình.

Thêm nữa, trước khi làm bất cứ cái gì, tôi cần chỉ ra bao nhiêu thời gian để tôi có thể hoàn thành yêu cầu đó. Và tôi sẽ hỏi những câu hỏi liên quan để tìm câu trả lời cho bản thân mình: Ví dụ như có bao nhiêu deadlines tôi cần hoàn thành? Bao nhiêu lâu sẽ ra 1 bản build? Tôi có bao nhiêu thời gian để chuẩn bị một báo cáo?

Đã có ai test product này chưa? Họ là ai? Họ ở đâu? Tôi có thể nói chuyện với họ không? Nếu không thì họ có thể cung cấp những thứ giúp cho công việc của tôi được không? Tôi có nằm trong team nào? Những skill nào mà các thành viên trong team có? Skill nào mà team chúng tôi cần?

Cái gì mà khách hàng cần tôi cung cấp? Một bản báo cáo, một danh sách bugs, nhưng chúng dưới dạng nào? Chỉ cần chat thông báo với họ, hay chỉ là những tóm tắt sơ lược? Tôi sẽ muốn làm rõ những thứ này trước vì tôi biết tôi có thể nhanh chóng đưa feedback tới khách hàng của tôi hoặc tới các developer trong team tôi. Liệu khách hàng ưu tiên các cách trang trọng, ví dụ như phải dùng cụ thể một mẫu báo cáo nào đó, hay phải là một tool như họ mong đợi để quản lý những báo cáo đó? Khách hàng càng quan tâm tới bất cứ gì, tôi sẽ ghi chú lại ngay cả khi tôi thấy chúng sẽ tốn nhiều chi phí của khách hàng hơn

Vậy còn những thứ nào khác mà khách hàng, developer, hay những stackholder muốn xem, bây giờ hay sau này? Dữ liêu đầu vào mà tôi tạo ra cho testing? Script cho automation? Kết quả test? Những test result này cần mô hình hóa ra hay không? Các tools mà tôi tạo ra hay những tài liệu tôi làm cho nó? Một mô tả ngắn về product? Những bản báo cáo chi tiết cho một số đối tượng cụ thể? Qua những câu hỏi đó, tôi sẽ tiếp tục nhiệm vụ của mình và mong muốn đáp ứng hết tất cả chúng trong quá trình thực hiện dự án.

Sau khi đã liệt kê những cái tôi cần làm. Tôi sẽ bắt đầu bằng những thứ nhỏ nhất bằng việc học về product mà tôi đang làm, đồng thời thực hiện 1 hoặc 2 hạng mục trong danh sách đó một cách song song. Tôi nói chuyện với developer nếu tôi có thể. Tôi tham gia meeting trong các buổi design và planning nếu tôi có thể. Công việc của tôi trong các meeting đó là học, nghiên cứu, đánh giá khả năng có test được chức năng đó không, nêu những ý tưởng và hỏi những câu hỏi để đánh giá vấn đề và rủi ro có thể xảy ra. Tôi sẽ hỏi về những testing mà developer đã làm, và nếu có thể tôi sẽ kiểm tra chúng đã có được thực hiện hay chưa.

Nếu tôi được mời tới một meeting nào đó muộn hay cả khi không được mời, tôi sẽ ghi chú lại nó. Tôi muốn trở thành người hữu dụng nhiều nhất có thể, và tôi cũng muốn ghi chú và lưu giữ lại những thứ làm cho việc testing của tôi khó hơn hoặc dễ hơn vì tôi biết mình có thể học được một thứ gì từ những điều đó. Tôi cũng sẽ nói ra những cái tôi đã test một cách dễ hiểu và dễ hình dung nhất với sản phẩm, với dự án và tới team mà tôi đang làm.

Tôi nghiên cứu tài liệu cho những API liên quan tới product ngay cả khi tôi không làm trong vùng đó. Tôi muốn phát triển sự hiểu biết của mình về sản phẩm: những service nào mà hệ thống đang sử dụng, chúng được control như thế nào, chúng đang đóng vai trò gì trong hệ thống. Khi tìm ra những thứ đang thắc mắc, tôi note lại để có thể tìm hiểu và nghiên cứu về nó sau. Và cứ tiếp tục như vậy, tôi quan tâm tới những thứ đang gây khó hiểu và không đồng bộ trong sản phẩm mà tôi đang làm.

Trong khi tôi đọc tài liệu, tôi sẽ tự hỏi mình rằng: Có cách nào đơn giản, dễ và tiện mà tôi có thể làm với product này? Nếu như tôi có sản phẩm trên tay, tôi sẽ thử nó bằng những yêu cầu đơn giản nhất, như dùng 1 tool cung cấp khả năng tương tác trực tiếp API đó với product. Có thể nó là 1 tool của công ty, hoặc là 1 bên thứ ba như Postman hay SOAPUI. Và tôi sẽ tự phát triển từ những script đơn giản trước. Tiếp theo, tôi sẽ xem cách ghi log từ những tool đó. Vì tôi biết, cách test hiệu quả nhất là phải kiểm tra API mà tôi đã test đã đúng hay chưa.

Nếu như tôi tìm được bug, hoặc bất cứ sự mơ hồ nào đang ảnh hưởng tới product. Tôi sẽ báo cáo nó đúng cách. Nếu như bug đó, tôi đã thử nhiều lần và nó thực sự ảnh hưởng nghiêm trọng. tôi sẽ báo cáo ngay lập tức. Có khi chúng chỉ là những vấn đề liên quan đến khả năng test, hoặc chỉ là tính dễ dàng sử dụng sản phẩm của user. Nhưng tại thời điểm đó của dự án, tôi lựa chọn phương án tiếp cận như vậy để giải quyết vấn đề, vì nó là cách nhanh nhất, ít tốn kém nhất, và đơn giản nhất trong những kiểu báo cáo mà tôi có thể làm.

Mục tiêu duy nhất của tôi lúc này, không phải là tìm bug, mà chỉ ra làm thế nào mà 1 người có thể dùng API đó để truy cập tới product, làm cách nào để họ thấy giá trị từ API đó, và những vấn đề đó đang đe dọa tới chất lượng của product như thế nào. Tôi cũng sẽ xây dựng những mô hình mà tôi có thể nhớ về product đó, cách mà chúng work ra sao, cách dùng chúng thế nào, cách mà mình có thể test được chúng. Tìm hiểu về sản phẩm là cách tốt nhất giúp tôi tìm ra những bugs tốt hơn, sâu hơn, khó tìm hơn, thường xuyên hơn và hạn chế gây hại tới product hơn.

Tóm lại, để có thể test tốt, tôi muốn trở thành 1 nhà nghiên cứu giỏi với những khả năng sau: ghi chép, tạo sơ đồ, xây dựng danh sách các chức năng, đánh giá vấn đề và rủi ro, xây dựng bản đồ tư duy, chú thích tài liệu. Và định kỳ thường xuyên, tôi sẽ work với developer, managers hay những bạn cùng team tôi để hỗ trợ cho việc tìm hiểu của tôi về product.

Bài viết được lược dich từ developsense.com – exploratory testing in api  , bạn có thể xem toàn bộ bài viết bằng tiếng anh và nguyên series liến quan đến chủ đề exploratory của tác giả Michael Bolton

Pairwise Technique

Bạn được giao test cho 1 chức năng hiển thi text or link của 1 website. Những text hay link đó được set up trong 1 trang configuration và có logic như sau:

– Type: Là 1 combobox gồm 2 giá trị: Link hay Text

– Level: Là 1 combobox gồm 2 giá trị: General hay Level. Nếu bạn chọn là General thì text box bên trái gồm Level A và Level B sẽ bị ẩn đi, bạn chỉ có thể nhập trong text box General. Ngược lại, khi chọn Level thì textbox General bị ẩn đi và 2 text box kia được nhập bình thường.

Website có 200 link và 150 text, do vậy sẽ có 350 vị trí để chúng hiển thị trên website. Với mỗi text hoặc link thì bạn có thể set up nó hiển thi chung cho tất cả level (General) hoặc bạn có thể tùy chỉnh cho mỗi level theo link hoặc text mong muốn. Là 1 tester bạn hãy test và đảm bảo những link và text hiển thị chính xác trên website.

Theo bài toán trên, để đảm bảo việc testing cho chức năng đó hoạt động tốt thì ta sẽ phải test khoảng 350 trường hợp. Tuy nhiên, trong thực tế, chúng ta sẽ không có đủ thời gian để có thể kiểm tra được tất cả các trường hợp. Do vậy, để có thể tìm ra được nhiều nhất những lỗi có thể xảy ra trong 1 điều kiện cho phép về thời gian và chi phí thì ta phải tạo ra được một bộ test case hiệu quả nhất. Pairwise testing là một trong những kỹ thuật để giúp cắt giảm số lượng test case cần test và tăng tính hiệu quả cho những test case mà mình muốn kiểm tra.

Quay trở lại bài toán trên, có 2 vấn đề mình cần test cho chức năng này:

1. Những setting trên configuration tool này có thể tạo ra được những link hay text thõa mản yêu cầu của website
2. Sau khi chúng được tạo ra từ configuration thì 350 cái này có được hiển thị chính xác trên website hay không.

All singles

Để giải quyết vấn đề số 1 thì trong phương pháp Pairwise có 1 approach là All singles. Kỹ thuật này có nguyên tắc là mỗi giá trị mà bạn quan tâm (bạn nghĩ nó quan trọng) của 1 biến sẽ được bạn ưu tiên để test và đặt trong test case trước.

Với đề bài trên thì ta thấy mỗi link hay text sẽ được quyết đinh theo Type và Level. Với biến Level sẽ có 3 vùng giá trị: General, Level A, Level B. Với Type thì sẽ có 2 vùng giá trị đó là Link hoặc Text.

Do vậy tổng số khả năng có thể xảy ra bằng 3*2 = 6 khả năng.

Tuy nhiên, với việc áp dụng kỹ thuật All Singles, ta sẽ chỉ cần 3 test cases. Chúng sẽ được áp dụng như sau:

1. Sắp xếp thứ tự các biến theo thứ tự giảm dần số giá trị: Ở đây thứ tự sẽ là Level (3) -> Type (2)
2. Đặt các giá trị cho biến Level ở cột đầu tiên

STT	Level	Type
1	General
2	Level A
3	Level B

3. Với các giá trị ở biến Type, bạn sẽ có 2 giá trị là Link hay Text. Bạn sẽ sắp xếp các giá trị này tương ứng với các giá trị ở cột Level nhưng với thứ tự làm sao mà bạn nghĩ đó là những combine input tạo ra những test case mà khách hàng thường xài và có độ bao phủ nhiều nhất. Qua kinh nghiệm của mình với hệ thống, mình đã chọn cách sắp xếp như sau:

STT	Level	Type
1	General	Text
2	Level A	Link
3	Level B	Link

Lợi ích của All singles là nó đã cắt giảm được số lượng TH cần phải kiểm tra từ 6 xuống còn 3. Nhưng một vấn đề của phương pháp này là có thể bị missed những combine input quan trọng trong thực tế. Ví dụ, trong thực tế rất nhiều người dùng Level là General và Type là Link, nhưng trong bảng trên thì mình đã thiếu kiểm tra TH đó. Do vậy, để khắc phục điều này thì ta sẽ thêm những TH đặc biệt đó vào trong bộ TCs.

Tuy nhiên, quay lại bài toán thực tế này, do bạn cần phải tạo 350 Link và Tex theo configuration tool này để hiển thị lên website. Cho nên, việc testing toàn bộ 6 khả năng là điều nên làm vì dù gì bạn cũng phải tạo 350 cái 😊, và vì lợi ích của việc covergare 100% sẽ đảm bảo bạn không bị thiếu bất kể khả năng nào.

All pairs

Quay lại vấn đề thứ 2, mình cần test là đảm bảo 350 cái configuration này hoạt động chính xác trên website. Tuy nhiên, chẳng lẻ mình sẽ đi test hết cả 350 cái. Câu hỏi là làm sao cắt giảm số lượng test case cần test? Trong Pairwise thì có 1 approach là All Pairs. Nguyên tắc của approach này là mỗi giá trị của mỗi biến được phối với mỗi giá trị của những biến còn lại trong ít nhất một test case

350 configuration này sẽ được hiển thị ở 350 vị trí khác nhau. Áp dụng ‘Domain Partition’ta chọn được 10 vùng (Areas) mà 350 cái này tập trung nhiều giá trị có value nhất. Và để demo những cái hay của approach All pairs này, mình sẽ chỉ lấy 1 tập giá trị gồm 3 vùng (Area 1, Area 2, Area 3) làm ví dụ.

Tổng số khả năng có thể xảy ra Areas (3) * Level (3) * Type (2) = 18 khả năng

Đây là các bước tiến hành khi áp dụng approach này

1. Sắp xếp các biến theo thứ tự giảm dần số giá trị của từng biến. Các cột sẽ có thứ tự sau: Areas, Level, Type
2. Tính số dòng của bảng phối bằng cách lấy số giá trị của biến 1 * số giá trị của biến 2. Số dòng = Areas (3) * Level (3) = 9
3. Trong cột đầu tiên, nhập từng giá tri của biến Areas theo số giá trị của biến Level, lưu ý để 1 dòng trống sau mỗi vòng. Ví dụ, nếu giá trị 1 của biến 1 là Area 1 và bộ giá trị của biến 2 là General, Level A, Level B thì đợt đầu sẽ 4 dòng, và trong cột đầu tiên sẽ là Area 1, Area 1, Area 1, 1 dòng trống.
4. Trong cột thứ 2, liệt kê tuần tự các giá trị của biến 2. Ví dụ: vòng đầu tiên của cột thứ 2 sẽ là General, Level A, Level B

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)
1	General
1	Level A
1	Lvel B
2	General
2	Level A
2	Lvel B
3	General
3	Level A
3	Lvel B

5. Trong cột thứ 3, lấy từng giá trị của biến 3 (Type) phối với các tập giá trị của biến 1, khi đã phủ hết các trường hợp, ta tiếp tục phối với tập giá trị của biến 2
   1. Trong vòng đầu khi điền giá trị của biến 3, tôi nhập giá trị cho vòng đầu lần lượt là Text, Link, Text

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)
1	General	Text
1	Level A	Link
1	Lvel B	Text
2	General
2	Level A
2	Lvel B
3	General
3	Level A
3	Lvel B

2. Tại vòng thứ 2, bộ giá trị sẽ là Link, Text, Link

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)
1	General	Text
1	Level A	Link
1	Lvel B	Text
2	General	Link
2	Level A	Text
2	Lvel B	Link
3	General
3	Level A
3	Lvel B

Câu hỏi đặt ra là tại sao bộ giá trị không phải là Text, Link, Text?

Hãy quay lại dòng đầu tiên của cột 2 và cột 3: General đã phối với Text

Nếu như tại dòng 5, nếu ta chọn là Text nữa thì lúc này ta sẽ bị trùng với dòng đầu tiên. Do vậy, nếu chọn Link thì không những không bị trùng mà ta còn cover thêm 1 TH nữa. Ở đây là General-Link

3. Từ vòng 3 bạn có thể đặt kiểu sắp xếp nào cũng được. Lí do vì dù kiểu nào thì cũng sẽ tạo 1 bộ phối hợp lệ cả.

Như vậy, với cách phối này bạn đã có 1 bộ gồm 9 test case mà các giá trị của từng biến đã phối được với nhau.

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)
1	General	Text
1	Level A	Link
1	Lvel B	Text
2	General	Link
2	Level A	Text
2	Lvel B	Link
3	General	Text
3	Level A	Link
3	Lvel B	Text

Giả sử ta có thêm một biến nữa thì sao?
Lúc này ta chỉ cần phối giữa cột Level-Variable 4 và sau đó tới Type-Variable 4. Bảng phối vẫn vừa vặn cho tất cả trường hợp như sau

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)	Variable 4 (X, Y)
1	General	Text	X
1	Level A	Link	Y
1	Lvel B	Text	X
2	General	Link	Y
2	Level A	Text	X
2	Lvel B	Link	Y
3	General	Text	Y
3	Level A	Link	X
3	Lvel B	Text	Y

Tuy nhiên, nếu ta tiếp tục có thêm biến Variable 5 thì bảng đó sẽ không còn phù hợp nữa.

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)	Variable 4 (X, Y)	Variable 5(M, N)
1	General	Text	X	M
1	Level A	Link	Y	N
1	Lvel B	Text	X	M
2	General	Link	Y	N
2	Level A	Text	X	M
2	Lvel B	Link	Y	N
3	General	Text	Y	N
3	Level A	Link	X	M
3	Lvel B	Text	Y	N

Có thể thấy theo bảng này, cột Level và Type các giá trị đã được phối đầy đủ với các biến của Variable 5. Tuy nhiên, có 1 chút không đúng ở cột Variable 4. X chỉ được phối với M, tương tự cho Y với N. Để khắc phục điều này ta sẽ thêm 2 test case khác ở dưới những dòng trống. Một bảng hoàn chỉnh sẽ có giá trị như sau:

Areas (1,2,3)	Level (General, Level A, Level B)	Type (Text, Link)	Variable 4 (X, Y)	Variable 5(M, N)
1	General	Text	X	M
1	Level A	Link	Y	N
1	Lvel B	Text	X	M
			X	N
2	General	Link	Y	N
2	Level A	Text	X	M
2	Lvel B	Link	Y	N
			Y	M
3	General	Text	Y	N
3	Level A	Link	X	M
3	Lvel B	Text	Y	N

Khi bạn muốn test tất cả các trường hợp có thể xảy ra, chúng sẽ là 3*3*2*2*2=72 trường hợp. Nhưng khi áp dụng all-pairs bạn đã cắt giảm từ 72 xuống còn 11.

Tuy nhiên, khi áp dụng phương pháp này, bạn hãy lưu ý trong thực tế có những combination khác và sẽ được khách hàng sử dụng thường xuyên hơn những combination trên bảng phối trên. Do vậy, cách tốt nhất là có thể thêm một số trường hợp đó vô trong bộ test case của mình. Trong kinh nghiệm thực tê của mình thì có thể thêm từ 5-10 test case nữa cần kiểm tra. Do đó, tổng số test case có thể có từ 15-20. Tuy nhiên, nó vẫn là hiệu quả hơn khi bạn phải test 72 trường hợp phải không nào.

Tester nên nói gì trong Daily Standup Meeting

Hey, mọi người trong chúng ta đều chắc hẳn đã tham gia standup meeting. Một buổi meeting sẽ kéo dài khoảng 15 phút. Vậy có ai cảm thấy chán vì không biết nói gì hay là cảm thấy áp lực và lo lắng nếu như sếp bất chợt hỏi đến mình. Thật ra, mình cũng vậy và mình cũng có những câu hỏi đó cho bản thân. Thế nên, vào một buổi sáng thứ 7 đẹp trời, mình quyết định google để tìm ra cách khắc phục cho vấn đề này. Nào, hãy đi xem mình tìm ra được thứ gì có ích cho bạn không nhé. ^^

Điều đầu tiên thì hãy tìm hiểu Daily Standup Meeting là gì và nó được sinh ra vì lí do gì?

1. Daily standup meeting là gì?

Daily standup meeting là một meeting mà người tham dự phải đứng và được kéo dài trong thời gian tối đa 15 phút. Đối tượng tham gia là tất cả các thành viên trong team.

2. Vậy nó sinh ra vì mục đích gì?

• Chia sẻ những khó khăn đang ngăn cản công việc của mình

Trong công việc của bạn hằng ngày, bạn sẽ có những yêu cầu từ phía khách hàng hoặc Product Owner, và khi thực hiện những yêu cầu đó, sẽ có những khó khăn ngăn cản công việc của bạn lại và bạn không thể làm tiếp nếu không có sự giúp đỡ của những người khác. Đó là lí do vì sao có sự xuất hiện của Daily Meeting. Nó sẽ là nơi bạn nêu những trở ngại bạn đang đối mặt và tìm sự giúp đỡ của những thành viên khác trong team. Ví dụ như trong trường hơp của mình mới đây, mình có 1 yêu cầu phải tạo data test khoảng 2100 items. Nếu mình cắm đầu giải quyết thì chắc chắn tốn rất nhiều time và công sức, nhưng khi mình nêu vấn đề này ra trước team thì mọi người đã discuss và cho mình ít nhất 2 giải pháp.

• Kết quả sau một meeting là mọi người rời khỏi với một năng lượng tích cực và tìm ra giải pháp cho những vấn đề đó

Quay trở lại vấn đề ban đầu khi tại sao bạn lại ngán và chán khi tham gia meeting. Mình nghĩ vì sau khi kết thúc meeting, bạn không biết mình sẽ làm gì tiếp theo, và rắc rối hiện tại của mình thì ai giải quyết đây? Do vậy, trong buổi meeting, bạn phải dũng cảm nói ra vấn đề của mình và sẵn sàng để người khác có thể làm tiếp cho bạn công việc đó. Mục tiêu là các thành viên khác trong team biết những khó khăn, từ đó giúp đỡ và điều chỉnh plan sao cho phù hợp với mục tiêu cuối cùng của cả đội.

Vậy có những cách nào để trình bày những vấn đề của mình trong buổi meeting

1. Xác định và mô tả vấn đề ngắn gọn, dễ hiểu

Một buổi meeting chỉ kéo dài 15 phút và có rất nhiều người tham gia gồm manager, team leader, developer, tester, … Do đó, nếu bạn mô tả vấn đề dài dòng, tràng giang đại hải thì sau khi nói xong, người nge không những không hiểu bạn đang nói gì mà bạn còn không tìm ra được giải pháp cho bạn nữa. Không những vậy, bạn đang gián tiếp làm lãng phí thời gian của những người khác. Cho nên, để có thể trình bày tốt, bạn nên chuẩn bị trước cho buổi meeting đó. Sau đây là một số tips mà bạn có thể áp dụng ngay:

• Chuẩn bi những thứ cần nói trước 15 phút
• Liệt kê những thứ đó thành những gạch đầu dòng ra một tờ giấy
• Dựa trên những gạch đầu dòng đó, sắp xếp độ ưu tiên theo thứ tự: Urgen <-Critical <- Normal <- Small

Ví dụ dưới đây là 3 thứ mình sẽ nói trong buổi meeting và sắp xếp thứ tự nói từ trên xuống dưới:

• Hiện tại để verify con critical bug này thì em cần fix con bug small này trước vì con small này đang ngăn cản việc test cho con critical kia.
• Hôm qua, như discuss thì hiện tai em đã hoàn thành test cho con user story này rồi, có ai có ý thêm gì cho việc testing không? Nếu không có thì em có thể move nó qua Acceptance Test được không?
• Con critical bug trên Production em đã hiểu vấn đề nó gặp phải, tuy nhiên, em cần viết một cái script query xuống DB, bên dev có ai có thể giúp em được?

2. Nêu vấn đề, đối tượng có thể giúp bạn giải quyết vấn đề sau đó chứ không nên đi quá xa và chi tiết

Standup meeting không phải là nơi đưa ra quyết định và giải quyết vấn đề. Nó chỉ là nơi vấn đề được nêu ra và những người liên quan tới vấn đề đó. Đó là lí do vì sao một daily-meeting chỉ kéo dài 15 phút. Do vậy, khi gặp phải những vấn đề có độ phức tạp cao hay phải trình bày trong thời gian dài, thì trong daily meeting bạn nên trình bày sơ lược, giới hạn đối tượng liên quan và sắp xếp một cuộc meeting khác ngay sau đó.

Ví dụ

• Cho regression test vào ngày mai như plan, bên QA team cần xác định những test case nào sẽ chạy cho đợt build săp tới. Do vậy, sau daily standup meeting thì QA team sẽ có buổi meeting cho vấn đề này
• Hiện trên con critical bug này, Dev đang fix. Tuy nhiên, vì nó ảnh hưởng nhiều chức năng nên QA sẽ có meeting riêng với DEV để đưa ra những case có thể bị ảnh hưởng

Tóm lại, để bạn cảm thấy việc tham dự một daily standup meeting trở nên vui vẻ và hiệu quả thì hãy biến nó thành nơi có lợi cho mình, giúp mình có thể chia sẽ những khó khăn và tìm được sự giúp đỡ của những đồng nghiệp trong team. Và để làm được nó thì hãy chuẩn bị trước thứ mà mình muốn nói, đối tượng mà mình muốn tìm kiếm sự giúp đỡ và hãy lưu ý Daily Standup Meeting chỉ có kéo dài 15 phút, cho nên hãy sử dụng nó làm sao thật hữu ích cho bản thân mình.

Cách tìm ra lời giải thích tốt nhất cho 1 con bug

Hey, trong số chúng ta – những người tester, khi tìm ra một điều bất thường của softwate thì thường tạo ra bug ngay lập tức. Vậy có ai đã bị trường hợp Dev kêu lại và hỏi 1 câu rằng:

Anh không nghĩ nó là bug, anh không bị trong một số trường hợp a, b, c này?

Mình đã gặp trường hợp này rất nhiều lần và rất lúng túng để tìm ra 1 lời giải thích tốt nhất. Lí do mình nghĩ đơn giản là vì mình chưa thực sự tìm ra được root cause của vấn đề và viết được một mô tả chính xác lỗi mà con bug đó gặp phải.

Vậy thì giải pháp là gì?

Trong cuốn sách Lesson Learn in Software Testing (James bach), ông ta đề xuất 1 phương pháp mà mình cảm thấy hay để tìm ra được 1 good explantion. Đó là phương pháp ‘Abductive inference’ – Mình không biết phải dịch tiếng viêt thế nào 😛 (dịch từ google nó hơi gớm 😊)

Đại khái ý của phương pháp này gồm những ý sau:

1. Thu thập data
2. Thu thập những data quan trọng
3. Tiếp tục thu thập data, nhưng data đó phải đáng tin
4. Hiểu được cause and effect cho từng loại data đó
5. Tìm được 1 best explantion cho mỗi data
6. Thu thập những data có những giải thích khác nhau
7. Trong số những lời giải thích, tìm cách phản biện và loại bỏ những giải thích mà không logic đi
8. Đưa ra 1 lời giải thích hợp lí nhất nhưng lưu ý nó phải đại diện cho những data quan trọng mà bạn thu thập được

Với phương pháp này bản thân mình thấy ưu điểm của nó bạn sẽ nhìn 1 vấn đề trên nhiều góc nhìn khác nhau, đồng thời có sự suy luận, phân tích cho những phỏng đoán để tìm ra một good explantion. Tuy nhiên, nhược điểm của cái này thì mất khá nhiều thời gian cho thu thập data và investigation. Nhưng nhìn chung, mình cảm nhận nó hay và sẽ follow nó ^^.

Big salary is much more important than job satisfaction

As the society grows, money is becoming more important nowadays. Having money may not make you happy, but having no money will make you miserable. Thus, most people believe that the wage is the main factor of making the decision for a career. However, in my opinion, I strongly believe job satisfaction is more important than big salary.

Firstly, I think life is too short to be wasted in only earning money without any satisfaction. For example, you work average 8 hours per day. It also means the time working accounts for one third in your life. If you just work for money then you cannot feel happy. However, job satisfaction will keep you happy every minute. For instance, researchers spent their life in research since they are passionate and feel happy about what they do. Their work’s purpose is to become famous, not to become rich.

Secondly, in my point of view, job satisfaction will help you enjoy life. Enjoyment doesn’t mean that you have a big bank balance; but it means you are satisfied with your current work. If you are not satisfied then in fact you are wasting your talent. Maybe when starting, you won’t earn much, but at least you are happy with it. It will be beneficial for you in a long term, particularly, for your own career path.

To sum up, balancing between salary and job satisfaction is better. However, I strongly believe that job satisfaction is more important because it will help you enjoy life and promote your career path.

Tại sao Testing là cần thiết? Testing để làm gì?

Khi mình đưa ra câu hỏi này tới một số người thì câu trả lời sẽ là có và cần thiết. Và họ đưa ra một số lí do như:

• Nếu không test thì ai là người đảm bảo những yêu cầu của khách hàng chạy đúng.
• Lỡ những chức năng đó implement sai hoàn toàn so với yêu cầu từ ban đầu thì sao.

Nhưng theo suy nghĩ của mình thì một câu hỏi đúng hơn là:

Ảnh hưởng như thế nào khi không có Testing?

Một ví dụ là sự cố Note 7 – Vì một lỗi dễ gây cháy do pin mà SamSung phải thu hồi toàn bộ sản phẩm và cho khai tử dòng điện thoại này.

Hay như gần đây là gần đây là mã độc WannaCry, nó đã khai thác một lỗ hổng trên phần mềm Windows và từ đó chiếm quyền điều khiển máy tính và dữ liệu của user. Hậu quả là các bệnh viện ở Anh không thể truy cập hồ sơ bệnh án, hay như Đức, nó đã tấn công và gây ảnh hưởng tới hệ thống đường sắt.

Trong 1 phạm vi nhỏ hơn là trong quá trình sản xuất phần mềm thì chi phí một lỗi khi phát hiện trong giai đoạn đầu là Tìm hiểu Requirement sẽ chỉ bằng 1/100 lần chi phí khi phát hiện trên môi trường Production.

Những ví dụ trên chứng tỏ, vai trò của testing rất quan trọng. Nó không chỉ tiết kiệm tiền thậm chí cả mạng sống.

2. Vậy vai trò của testing là gì?

Có nhiều khái niệm về vai trò cùa Testing, nhưng theo mình nghĩ thì Testing phải đảm bảo những yếu tố sau:

• Tìm ra những lỗi của phần mềm và đảm bảo những lỗi này phải được fixed trước khi Release cho khách hàng.

Với yếu tố này thì cần chú ý rằng những bug đó phải được fixed. Khi bạn là 1 tester, bạn tự hào mình có thể tìm ra được 100 bugs về 1 chức năng nào đó, nhưng tới ngày Release cho khách hàng, 100 bugs đó vẫn chưa được fix thì chất lượng của phần mềm có cải thiện không?

Câu trả lời là không! Nó không hề cải thiện bất kì chút nào như trước khi bạn phát hiện ra những bug đó.

Do vậy, chất lượng của phần mềm chỉ được cải thiện khi khách hàng dùng phần mềm và không tìm ra được những lỗi mà tester đã tìm ra.

• Gia tăng độ tự tin cho phần mềm.

Sau quá trình Testing kết thúc, nó sẽ đảm bảo những chức năng hoạt động như requirements và đồng thời sẽ đảm bảo hạn chế những tình huống bất ngờ như Crash màn hình hoặc quăng exception tới user chẳng hạn. Qua đó, làm tăng độ tự tin cho phần mềm.

• Cung cấp thông tin cho những bên liên quan tới phần mềm (stackholder), từ đó có thể đưa ra quyết định cho phần mềm trong những tình huống cụ thể.

Trong quá trình sản xuất phần mềm, tester chỉ là mắt xích trong quá trình đó. Có rất nhiều bên liên quan khác nhau như Development Team, BA hoặc Khách hàng. Cũng như vậy, có nhiều thời điểm cần đưa ra quyết định cho phần mềm, chẳng hạn như khi nào Release lên customer testing environemnt, khi nào lên Production. Do vậy, những thông tin mà tester cung cấp sau khi quá trình testing kết thúc, sẽ giúp họ đưa ra những quyết định đúng đắn.

• Ngăn ngừa lỗi cho phần mềm.

Cần phân biệt khái niệm Ngăn ngừa (Prevent) với Tránh (Avoid). Trong quá trình testing, bạn không phải là người viết ra yêu cầu, bạn chỉ là người test cho những yêu cầu đó. Cho nên, xác xuất bạn bị hiểu lầm là điều có thể xảy ra. Thứ hai, có khi bạn test trên những môi trường không giống khách hàng (Vì họ chạy thực tế, có rất nhiều yếu tố liên quan như: phần mềm tương tác, network, cấu hình máy, …). Do vậy quá trình Testing chỉ đảm bảo ngăn ngừa lỗi chứ không thể tránh chúng được.

3. Testing tới khi nào là đủ?

Giả sử bạn được giao test cho một fearture mới nào đó. Câu hỏi đặt ra là bạn sẽ test đến khi nào? Tới khi nào bạn nghĩ cái feature đó đã đủ chất lượng để giao cho khách hàng?Câu trả lời theo quan điểm của mình là nó phải thỏa mãn 2 thứ.

Trước tiên phải đảm bào từng requirement mà khác hàng đề cập phải chạy được và hoạt động tốt. Giả sử trong 1 thời gian cho phép, thì đầu tiên phải đảm bảo những case positive hoạt động tốt.

Thứ hai nó phải thõa mãn một số tiêu chí để chúng ta có thể đo lường được. Ví dụ như số lượng bug tìm được cho cái Feature đó đã được fixed bao nhiêu phần trăm hay tổng thời gian Testing cho cái feature đó mất khoảng bao lâu rồi.

Những quan điểm trên của mình về sự cần thiết của Testing là những ý kiến chủ quan. Mọi người có thể bàn bạc và thảo luận bằng cách gửi ý kiến ở phía dưới nhé.

PS: Một phần mềm không có tester thì có được không? 😉

Decision Table Technique

Hôm nay mình sẽ nói tiếp tới 1 kỹ thuật thường hay dùng trong Black Box Testing đó là Decision Table Technique. Kỹ thuật này giúp xác định những kịch bản test cho những Business Logic phức tạp.

1. Mình sẽ bắt đầu bằng 1 ví dụ như sau

Bạn được giao test cho 1 application tính toán discount cho khách hàng nhân dịch khuyến mãi. Điều kiện khuyến mãi như sau:

• Nếu là 1 khách hàng (KH) mới thì được giảm 10%
• Nếu là khách hàng hiện thời thì được giảm 15%

Câu hỏi đặt ra là với 2 điều kiện này thì bạn sẽ cần phải test bao nhiêu trường hợp để đảm bảo logic hoạt động đúng như requirement, không bị miss bất kì khả năng nào?

Decision Table đề xuất 1 cách đó là lập bảng khả năng. Nó sẽ trông như thế này 🙂

Conditions	Rule 1	Rule 2	Rule 3	Rule 4
KH mới (15%)
KH hiện thời (10%)

Như các bạn thấy, với 2 điều kiện thì có tất cả 4 khả năng có thể xảy ra. Và với mỗi  khả năng sẽ có 2 giá trị True or False. Ta đánh nó tương ứng vào các ô.

Conditions	Rule 1	Rule 2	Rule 3	Rule 4
KH mới (15%)	T	T	F	F
KH hiện thời (10%)	T	F	T	F

Một qui tắc để tính được số trường hợp khả năng là 2ⁿ. Với n là số điều kiện.

Từ bảng khả năng, ta có thể xác định giá trị Output tương ứng với từng trường hợp như bảng dưới đây.

Conditions	Rule 1	Rule 2	Rule 3	Rule 4
KH mới (15%)	T	T	F	F
KH hiện thời (10%)	T	F	T	F
Actions/Outcomes
Discount 15%	Y	Y
Discount 10%	Y		Y

Hãy phân tích 1 chút về bảng trên. Với Rule 2, khi KH chỉ chọn option là KH mới thì Output sẽ là được discount 15%. Điều đó cũng tương đương khi KH chỉ chọn option là KH hiện thời. Nhưng nếu KH chọn cả 2 option (Rule 1) hoặc không chọn option nào (Rule 4) thì sao? Những mô tả này hoàn toàn không được đề cập khi ta đọc yêu cầu từ ban đầu.

 Do vậy bảng decision cho phép ta nhìn thấy những những thiếu sót và mơ hồ trong mô tả.

Để khắc phục trường hợp trên, ta có thể đặt câu hỏi với ngưới viết ra requirment để hỏi họ xem sẽ quyết định như thế nào trong những trường hợp mô tả chưa rõ như thế.

Giả sử nếu họ muốn hiện một thông báo tới người dùng trong 2 trường hợp đó thì ta sẽ có 1 bảng decision như sau:

Conditions	Rule 1	Rule 2	Rule 3	Rule 4
KH mới (15%)	T	T	F	F
KH hiện thời (10%)	T	F	T	F
Actions/Outcomes
Result	Error message	15%	10%	Error message

Như vậy với kỹ thuật này ta có thể đi qua xét tất cả các khả năng có thể xảy ra bằng cách phối các điều kiện lại với nhau và phát hiện thiếu sót từ sớm.

2. Bài học kinh nghiệm

Ví dụ mình đưa ra chỉ có 2 điều kiện nên việc lập bảng có vẻ dễ nhưng bạn hãy tưởng tượng trong thực tế có những requiment có từ 9 hoặc 10 điều kiện thì sao? Nếu áp dụng 1 cách cứng nhắc thì bạn sẽ có 2⁹ và 2¹⁰ khả năng phải xét. Nó sẽ không khả thi và bất hợp lí khi phải xét hết tất cả khả năng như vậy, đăc biệt khi bạn chỉ có 1 thời gian cho phép.

Một số lưu ý khi lập bảng:

• Đừng giả định phải phối hết tất cả các điều kiện.
• Chỉ chọn lọc và ưu tiên lấy nhưng điều kiện quan trong nhất để phối.
• Xem xét những thứ cần test hoặc không cần test cho từng giai đoạn thời gian khác nhau

Và tùy vào từng trường hợp cụ thể nên áp dụng nhiều kỹ thuật khác để tạo ra một bộ test data hợp lí và vừa đủ.

Black Box Testing

Blog này mình viết ra để note lại những kiến thức mình research về Black Box Testing, cũng như muốn rèn luyện khả năng trình bày. Rất mong các bạn góp ý để mình có thể trao đổi và cũng cố kiến thức với nhau nhé.

Nhân duyên  vì sao mình lại chọn chủ đề này vì bởi mình đã làm tester được 18 tháng. Bỗng một ngày đẹp trời, tự dưng đặt câu hỏi là mình làm về nó nhưng thực sự đã biết nó như thế nào chưa? Câu hỏi đó khiến mình muốn tìm hiểu 1 trong những phương pháp kiểm thử phần mềm phổ biến nhất. Đó là Black Box  Testing.

Nội dung mình muốn trình bày sẽ gồm những phần sau đây:

1. Nó là gì?
2. Lợi ích và bất lợi khi dùng phương pháp này
3. Một số techniques của Black Box Testing (BBT) hay dùng trong dự án thực tế

Nào chúng ta hãy tìm hiểu phần 1, xem nó là cái gì nhé.

1. Nó là gì?

   
   Như hình vẽ trên, bạn nhìn thấy là 1 hộp màu đen, bạn không thể nhìn thấy bên trong là gì, không biết có gì trong đó. Giống như đôi mắt của tester, tuy không thể biết trong nó là gì nhưng dựa vào nó thì có thể tìm ra được lỗi. Nó còn được biết với tên gọi là Behaviour Testing. Vì nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện.

2. Lợi ích và bất lợi khi dùng phương pháp này

   1. Lợi ích

      Vì nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện nên nó có những lợi ích như sau:

      • Test được thực hiện từ góc nhìn của user hoặc là tester nên có thể dùng phần mềm khách quan từ quan điểm của 1 end user.
      • Dẫn tới là tránh được sự ngộ nhận hoăc thiếu sót từ developer.
      • Không cần biết ngôn ngữ lập trình hoặc cách mà phần mềm thực hiện như thế nào.
      • Có thể viết test case và test được sớm khi requirement hoàn thiện.

   2. Bất lợi

      Do nó dựa hoàn toàn vào yêu cầu và mô tả chức năng của phần mềm để thực hiện nên nó có những bất lợi như sau:

      • Nếu requirement không rõ ràng thì có thể design test case bị sai hoặc rất khó để design test case.
      • Chỉ có thể test trên 1 số lượng data nên sẽ không cover hết tất cả các trường hợp.

3. Một số techniques của BBT hay dùng trong dự án thực tế

   1. Boundary Value Analyst (BVA)

      
      Technique dựa vào 1 thống kê đó là lỗi (Faults) thường xuất hiện ở những vùng biên của dữ liệu. Do vậy, nếu ta test những giá trị tại vùng này thì có thể tìm ra lỗi. Nói cách khác ta chỉ cần test trên 2 giá trị tại 2 bên biên. Như trong hình bạn có thể thấy có 2 vùng giá trị. Teachnique qui định chỉ cần lấy giá trị chấm bi vàng và chấm bi hồng để làm test data.Một ví dụ khác, bạn có 1 textbox cho phép nhập tuổi của user. Yêu cầu qui định giá trị hợp lệ trong khoảng từ 1 đến 100.
      
      Trong ví dụ này, ta có thể thấy ta có 2 biên: Là cận dưới = 1 và cận trên = 100. Do đó ta có 4 giá trị cần kiểm tra đó là:

      Min value -1	0
      Min value	1
      Max value	100
      Max value + 1	101

   2. Equivalence Partitioning (EP)

      Nó giúp cắt giảm 1 số lượng lớn input có khả năng xảy ra thành 1 bộ input data nhỏ nhưng hiệu quả hơn. Nó chia input data thành các class và chỉ lấy 1 giá trị đại diện để test cho mỗi class.  Vì nó giả định nếu 1 cái work đúng thì tất cả giá tri trong cùng lớp đó sẽ work đúng.Lấy ví dụ tương tư như BVA , nhưng với EP ta sẽ chỉ có 3 phân vùng (partition) như sau:
      
      Do đó ta có 3 giá trị cần kiểm tra đó là:

      Partition	Value
      Parition 1	< 1
      Partition 2	1 – 100
      Partition 3	> 100

      Một ví dụ thực tế với dự án mà mình đang work. Đó là bạn có 1 yêu cầu nhập 1 description trên 1 textbox với qui đinh là từ 1 tới không quá 400 kí tự.

      Áp dụng cả 2 techniques ta sẽ có 1 bộ test case như sau: