Part III - The Agile Testing Quadrants
Chapter 6 - The Purpose of Testing

6.1. The Agile Testing Quadrants
. Là một Matrix để tester đảm bảo đã xem xét các loại test cần thiết để bản giao
sản phẩm có giá trị. Q1, Q2 hướng đến test để hỗ trợ nhóm. Q3, Q4 để đánh giá
sản phẩm.
• Quadrant 1: bao gồm Unit tests, Component tests
• Quadrant 2: bao gồm Functional tests, Examples, Story tests, Prototypes,
Simulations
• Quadrant 3: bao gồm Exploratory testing, Scenarios, Usability
Testing,UAT, Alpha/Beta
• Quadrant 4: bao gồm Performance & Load testing, Security testing, "ility"
testing
6.1.1. Tests that Support the Team
Bao gồm các loại test thuộc Quadrant 1 và Quadrant 2
. Các loại test sẽ thực hiện trong Q1 và tầm quan trọng
• Test để định hướng phát triển (TDD) đây là core trong viecj phát triển
Agile.
• Thường được tự động, người thực hiện là developer, nó theo hướng
Developer-facing & technology-facing.
. Các loại test sẽ thực hiện trong Q2 và tầm quan trọng
• Test định hướng phát triển nhưng cao hơn so với Q1.
• Nó là business-facing test.
• Hầu hết các test đều cần tự động hóa.
• Mục đích quan trọng của các loại test trong Q2 là cung cấp thông tin
nhanh, cũng như phát hiện sớm các issue (troubles).
• Nó cần được chạy thường xuyên để cung cấp FB sớm, trong trường hợp
thay đổi hành vi không mong đợi.
• Có một vài kiểm thử tự động cần verify UI và API.
• Đôi khi, một số kiểm thử dc dùng để validate GUI hoặc để kết nối các thiết

kế đến developer trước khi bắt đầu code.
. Y nghĩa của việc test để hộ trợ Team
• Định hướng phát triển các chức năng.
• Tự động hóa cung cấp sự an toàn để ngăn chặn hệ quả không mong
muốn từ tái cấu trúc source code và thêm code mới.
• Những loại test của Q1, Q2 giúp team bàn giao được sản phẩm có giá trị
theo yêu cầu của khách hàng.
• Nó verify những business logic và UI theo những ví dụ được cung cấp


của khách hàng.
6.1.2. Tests that Critique the Product
• Bao gồm các loại test thuộc Quadrant 3 và Quadrant 4
• . Các loại test sẽ thực hiện trong Q3 và tầm quan trọng
• Kiểm thử thăm dò là trung tâm của Q3
• Tester vừa thực hiện test design và test, sử dụng tư duy phê phán để
phân tích kết quả.
• Đưa ra nhiều cơ hội để học hỏi về ứng dụng hơn là việc kịch bản hóa.
• Nó sâu hơn và khó hơn ad hoc testing.
• Ngay từ khi bắt đầu dự án hoặc story, tester đã bắt đầu suy nghĩ về các
kịch bản mà họ muốn test.
• Nó được thực hiện theo hướng người dùng cuối sử dụng hệ thống .
• UAT:
• Người dùng và khách hàng sẽ thực hiện loại test này.
• Giúp cho KH có cơ hội đưa ra những tính năng hoạt động tốt và giúp họ
nhìn thấy họ mong muốn thay đổi những gì trong tương lai.
• Usability Testing: hiểu biết cách người dùng sử dụng hệ thống là lợi thế để
thực hiện kiểm thử này.
• . Các loại test sẽ thực hiện trọng Q4 và tầm quan trọng
• Những loại test này hướng về technology-facing, thiên về kỹ thuật hơn

business.
• Nó kiểm tra đặc tính của sản phẩm như : Performance, Security,
Robustness.
• Khi lên kế họch cho một release hay dự án, chúng ta sẽ thảo luận cần
những loại test nào thuộc Q3, Q4 và khi nào nó cần được hoàn thành. Ví
dụ như không nên để load or usability testing vào cuối bởi nó có thể quá
muộn để sửa chữa vấn đề.
• . Y nghĩa của việc test để " đánh giá " sản phẩm
• Các lần lặp ngắn trong phát triển Agile đưa cho ta những cơ hội học hỏi
và trải nghiệm với những loại test khác trong trong quadrants.
• Việc sử dung Agile testing quadrant giúp chúng ta đảm bảo các loại test
cần thiết được thực hiện đúng thời điểm.
6.2. Knowing When A Story Is Done
• Đối với hầu hết các sản phẩm, chúng ta cần thực hiện 4 hạng mục testing
để đảm bảo chúng ta mang lại giá trị đúng đắn.
• Chúng ta cần đảm bảo các loại test đều được thực hiện. Mỗi story đều
được thực hiện unit test và test tích hợp giữa các module .
• Xác định các task cần phải thực hiện đối với technology-facing and
business-facing tests để kiểm nghiệm sản phẩm.
• Kết hợp test từ 4 quadrants sẽ cho team biết khi nào feature đáp ứng tiêu
chuẩn về chức năng và chất lượng của khách hàng
6.2.1.Shared Responsibility
•

Team cần có chuyên môn để cover toàn bộ Agile testing quadrants


Programmer viết technology- facing test , tuy nhiên họ vẫn cần sự
giúp đỡ từ các member khác
• Tester đảm nhận vai trò chính trong business- facing test, đồng

hành với khách hàng
• Team chịu trách nhiệm 4 Q testing được thực hiện
Team thành công là 1 team mà mọi người cùng tham gia xây dựng sản
phẩm , chia sẻ khó khăn trong nội bộ khi mọi việc không đi đúng hướng.
•

•

6.3. Managing Technical Debt (Quản lý "Nợ kỹ thuật")
• Technical debt được xây dựng lên khi development team đảm nhận việc
fix lỗi nhanh chóng hoặc skip việc writing , automation test.. Code ngày
càng trở nên khó maintance.
• Chi phí cao, tốc độ lại chậm. Developer ngại đưa ra những thay đổi, cố
gắng refactor ít nhất để cải thiện code, hoặc ngại phá vỡ code.
• Mỗi quadrant trong matrix Agile testing đóng 1 vai trò trong việc đảm bảo
cho các vấn đề Technical debt ở mức có thể quản lý được
• Technology- facing test support coding, design giúp cho code có
khả năng maintain
• Build tự động và tích hợp áp dụng cho unit test, việc bắt các lỗi ở
mức unit test sẽ giúp tester tập trung vào business- facing test ,
hướng dẫn team và cải thiện chất lượng dự án.
• áp dụng các nguyên tắc Agile sẽ giúp ích cho mỗi loại test ở mỗi mức độ
khác nhau sẽ giảm Technical debt .
6.4. Testing in Context
• Chúng ta nhận thấy Agile testing matrix giúp chúng ta đảm bảo chúng ta
có kế hoạch và hoàn thành tất cả các loại testing mà chúng ta cần.Mỗi tổ
chức, sản phẩm và team có những tình huống riêng, cần được thực hiện
theo cách riêng. Quadrant là cách hữu ích để đảm bảo team lưu ý đến tất
cả các khía cạnh testing cần được làm như thế nào
• Quadrant giúp đưa ra các ngữ cảnh cho Agile testing thực hành, bạn và

team phải thích nghi với việc đó
• Tester giúp cung cấp các thông tin feedback, giúp team điều chỉnh
và làm việc tốt hơn
• Sử dụng các kỹ năng để cam kết với khách hàng qua mỗi iteration
và release
• Luôn có ý thức khi team cần các role hoặc những kiến thức dựa
vào tình trạng hện tại.
• Agile Testing Quadrant cung cấp checklist để đảm bảo cover hết việc test
cơ bản , đồng thời cần trả lời các câu hỏi như sau:
• Chúng ta có sử dụng unit test và component test để tìm ra thiết kế
đúng cho ứng dụng?
• Có quy trình tự động build để chạy unit test tự động và get phản hồi
nhanh chóng?
• Việc thực hiện business facing test giúp chúng ta cung cấp sản
phẩm đáp ứng mong đợi của khách hàng?


•
•
•
•

Chúng ta đã nắm bắt các ví dụ đúng về những xử lý mà hệ thống
mong muốn chưa? Chúng ta cần nhiều hơn nữa không? Chúng ta
test dựa trên các ví dụ này không?
Chúng ta có show prototypes của UI và report tới khách hàng trước
khi chúng ta bắt đầu thực hiện code? Người dùng có thể liên
tưởng phần mềm đã hoàn thành sẽ làm việc như thế nào?
Chúng ta có dự tính đủ thời gian cho test exploratory không?
Chúng ta xử trí việc test usability như thế nào? Chúng ta dành đủ

sự quan tâm cho khách hàng chưa?
Chúng ta xem xét các yêu cầu kỹ thuật như performance và
security đủ sớm trong vòng đời phát triển không? Chúng ta có sử
dụng các tool đúng đê thực hện công việc testing ility không?

Summary
•
•
•
•
•

Test hỗ trợ team có thể được dùng để định hướng các yêu cầu
Việc test để kiểm nghiệm sản phẩm sẽ giúp chúng ta suy nghĩ về các khía
cạnh về chất lượng của ứng dụng
Sử dụng các quadrants để biết bạn làm xong khi nào, đảm bảo cả team
cùng chia sẻ trách nhiệm cover matrix của 4 quadrants
Việc quản lý nợ kỹ thuật là 1 nền tảng cần thiết cho bất kỳ nhóm phát triển
phần mềm nào. Sử dụng quadrants để nghĩ về các hướng khác nhau
Ngữ cảnh luôn luôn hướng dẫn chúng ta về nguồn lực test.

Chapter 7. Technology-Facing Tests that Support the Team

7.1 .Nền tảng của Agile Testing
Test theo hướng kỹ thuật để hỗ trợ Team sẽ tạo nền tảng cho phát triển Agile và
Testing. Unit test và component test trong Quadrant 1 tuy không phải là loại test
đầu tiên được viết cho từng story nhưng nó sẽ giúp chỉ đường cho việc thiet kế
và phát triển ( Design and development). Nếu thiếu đi cơ sở của test-driven
design, tự động hóa unit và component test, và quy trình tích hợp liên tục để
thực hiện những loại test đó thì sẽ rất khó để chúng ta bàn giao sản phẩm giá trị

đúng thời hạn.
7.1.1. Mục đích của test trong Quadrant 1
Unit test và component test đảm bảo chất lượng bằng cách giúp cho programer
hiểu chính xác cần phải code ntn và cung cấp hướng dẫn cho việc thiết kế đúng.
Nó giúp cho team tập trung vào story sẽ bàn giao và đưa ra cách tiếp cận đơn
giản nhất.
Việc phát triển unit test có thể trở thành công cụ thiet kế cốt lõi khi sử dụng TDD.
Bằng việc xây dựng code theo từng vòng tăng trưởng nhỏ test-code-test,


programer sẽ có cơ hội để suy nghĩ sâu về những chức năng mà khách hàng
cần. Họ có thể pair với tester để đảm bảo mọi khía cạnh của từng phần code và
sự kết nối giữa chúng đều đã được test.
Thuật ngữ “ test-driven development” có thể dẫn đến sự nhầm lẫn của nhiều
người, nếu không hiểu đúng ý nghĩa của nó là thiên về thiêt kế nhiều hơn test.
Tất cả các hoạt động trong Quadrant 1 đều nhằm tới việc tạo ra phần mềm với
chất lượng bên trong(internal quality) cao nhất có thể.
Khi team thực hành DDD sẽ giảm đến mức tối thiểu số lượng bug sẽ phát sinh
sau đó. Hầu hết những bug ở unit-level đều được ngăn chặn bởi việc test trước
khi code. Suy nghĩ sâu về thiết kế bằng việc viết unit test có nghĩa là hệ thống sẽ
có thể đáp ứng được yêu cầu của khách hàng nhiều hơn. Bởi vậy, viêc test của
programmer trong Quadrant 1 là rất quan trọng. Những team agile không áp
dụng bài học này sẽ không chắc chắn về việc thu được nhiều lợi ích từ các giá
trị và nguyên tắc của Agile.
7.1.2. Hỗ trợ cơ sở hạ tầng
Kiểm soát source code, quản lý cấu hình, và tích hợp liên tục là các yếu tố cần
thiết để thu được giá trị từ việc thực hiện test của programmer.
Tích hợp liên tục (CI) cung cấp cho chúng ta cách để chạy test mỗi khi có source
code mới được đưa vào. Việc tích hợp liên tục cũng giúp chúng ta tiết kiệm thời
gian và tạo động lực cho programmer thực hiện test trước khi đưa source code

mới lên.
Dự án thiếu những thực hành cốt lõi của Agile này thì sẽ giống với dự án "miniwaterfall", vòng đời phát triển sản phẩm ngắn nhưng code thì vẫn đến với tester
chậm. Thuật ngữ "waterfall" ở đây không có nghĩa là không tốt, khi chúng ta
code mà thiếu đi việc thực hành (practices) và tool thích hợp thì bất kể là
process nào chúng ta cũng không thể bàn giao được code có chất lượng cao.
7.2. Tại sao chúng ta viết và thực hiện những loại test này
7.2.1. Nó giúp chúng ta tiến xa hơn và làm nhiều hơn
Tốc độ không phải là mục tiêu cuối cùng của Agile, cố gắng làm nhanh để kịp
deadline mà không nghĩ đến chất lượng sẽ dồn chúng ta vào "góc", và như vậy
chúng ta sẽ càng tạo ra nhiều lỗi hơn và cuối cùng có thể dẫn đến không kịp
deadline.Tốc độ là hiệu quả mang tính chất lâu dài của việc tạo ra code chất
lượng bên trong cao nhất có thể. Việc liên tục build và chạy unit test giúp ta nhận
ra ngay chỉ trong vài phút khi có vấn đề phát sinh và bug có thể được tìm ra và
fix ngay. Một mạng lưới an toàn của việc tự động hóa kiểm thử đơn vị và tích
hợp giúp cho programmer có thể refactor code thường xuyên.
Khi dự án có phần unit test bị sao lãng, tester sẽ lãng phí thời gian để tìm bug ở
level thấp, không có thời gian tập trung tìm những bug ở level cao hơn về nghiệp


vụ. Code được design tốt thường sẽ tốt và có thể test được. Khi đó tester sẽ có
thời gian để tập trung vào exploratory test. Và khi team đã master về TDD chúng
ta sẽ tập trung vào việc chuyển từ ngăn chặn bug tới việc hình dung ra cách tốt
hơn để gợi mở và nắm bắt được REQ trước khi code.
7.2.2. Làm cho công việc của tester dễ dàng hơn
Việc programmer phải thực hiện nhiều hoạt động liên quan đến kiểm thử là thực
hành cốt lõi trong agile và họ dễ dàng hoàn thành nó. Họ làm việc trong môi
trường riêng biệt khi thêm code mới sẽ không làm ảnh hưởng đến phần của
những người khác. Họ sẽ không đưa code lên trước khi nó pass phần test hồi
qui trên môi trường của họ.
Team suy nghĩ về môi trường test và dữ liệu test sẽ sử dụng. Unit test thường

sử dụng dữ liệu giả để tăng tốc độ, tuy nhiên programmer vẫn phải test lại trên
dữ liệu thật. Tester có thể giúp họ tìm ra những dữ liệu test tốt.
Việc viết test và viết code dựa trên những case test đã được hình dùng trước sẽ
giúp programmer luôn tiếp tục suy nghĩ để tạo ra code “có thể test được”. Toàn
team sẽ luôn suy nghĩ tìm cách để cải tiến thiết kế và giúp cho việc test dễ dàng
hơn.
7.2.3. Designing with testing in mind
Một ưu điểm của việc định hướng phát triển thông qua test là những dòng code
được viết ra luôn tập trung vào việc làm cho test case pass. Toàn đội sẽ phải
suy nghĩ đúng ngay từ đầu về cách sẽ thực hiện test và tự động hoá test cho
toàn bộ các story sẽ code.
Code để “có thể test được” nghe có vẻ là một khái niệm đơn giản, nhưng thực tế
nó không phải là công việc dễ. Một cách tiếp cận phổ biến để có thể thiết kế
được một kiến trúc “có thể test được” là việc chia thành các tầng khác nhau để
thực hiện các chức năng khác nhau trong ứng dụng.
Bạn và team của bạn có thể tìm ra cách để thiết kế cho “khả năng test được”,
điều quan trọng là toàn team đều commit về việc test và chất lượng sản phẩm.
Có thể team của bạn sẽ mất thời gian để tìm ra cách làm thích hợp nhưng đừng
ngần ngại xem lại cấu trúc test tự động nếu nó hoạt động không đủ mang lại giá
trị cho những gì bạn đã đầu tư.
7.2.4. Timely feedback
Giá trị lớn nhất của unit test là tốc độ của Feedback. Theo quan điểm của chúng
tôi thì việc tích hợp liên tục và xây dựng process sẽ chạy unit test trong vòng 10
phút.
Những bản build và test ở trên mức unit như test chức năng của API hay GUI thì
có thể sẽ lâu hơn. Bạn hãy có ít nhất 1 process để run test nhanh, và 1 process


để run ở mức chậm hơn. Và nên có ít nhất một bản "build" hằng ngày để chạy
toàn bộ các mức test chậm. Nếu team bạn có một qui trình build và test mất thời

gian bạn hãy cùng team phân tích nguyên nhân và cải thiện tốc độ của nó.
Việc liên tục xây dựng và thử nghiệm các quy trình cung cấp thông tin phản hồi
liên tục , nó có vẻ giống như một giấc mơ đối với tester. Sử dụng regression giúp
lỗi sẽ được phát hiện sớm, và rất dễ để sửa. Đây là một lý do tuyệt vời chúng ta
thực hiện technology-facing test.
7.3 .Technology- Facing Test sẽ dừng ở đâu?
Chúng ta thường thấy người ta lo ngại rằng customer - facing test và
technology-facing bị chồng chéo lên nhau, vì vậy team tốn rất nhiều thời gian.
Business- facing test có thể bao gồm 1 phần giống như unit test hoặc
integration test, nhưng chúng có những mục đích khác nhau .
Khi thực hiện Unit test thành công với các giá trị như kiểm thử như các tham số
không hợp lệ, kết hợp các nghiệp vụ, programmer sẽ cảm thấy yên tâm hơn về
chất lượng code.
Mỗi unit test đều là độc lập và thực hiện test theo 1 chiều hướng tại 1 thời điểm.
Điều này có nghĩa là khi unit fail, programmer có thể nhanh chóng xác định được
vấn đề và cũng giải quyết vấn đề 1 cách nhanh chóng. Business-facing tests
hiếm khi chỉ bao gồm 1 chiều hướng bởi vì chúng được giải quyết từ quan điểm
nghiệp vụ.
Business - facing test sẽ bao phủ các kịch bản phức tạp hơn, xác nhận lại end
user có trải nghiệm tốt về sản phẩm. Nên đẩy việc test vào mức thấp hơn bất cứ
lúc nào có thể và nếu bạn xác định 1 test case có thể được thực hiện tự động ở
mức unit, đó là gần như là 1 sự đầu tư tốt.
7.4 .What if the team doesn’t do these tests?(Phải làm gì nếu team không thực
hiện công việc test)
Nhiều tổ chức đã quyết định thử phát triển theo Agile, hoặc ít nhất kiên định với
ý định đó mà không cần hiểu làm thế nào để tạo nên sự thành công.Khi chúng ta
ở vai trò tester, những cái mà chúng ta có thể làm gì để giúp development team
thực hiện TDD, tích hợp liên tục và những thực hành khác , là chìa khóa dẫn tới
thành công.
7.4.1. What Can Tester Do? (Tester có thể làm những việc gì?)

Nếu bạn là 1 tester trong Agile team nhưng lại không thực hiện automation ở giai
đoạn unit test hoặc hệ thống không được build liên tục (hoặc ít nhất phải build
hàng ngày) thì bạn sẽ nhanh chóng thất vọng . đừng bỏ cuộc, hãy động não để
tìm ra cách để làm thay đổi theo hướng tích cực. Hãy đưa ra các ý tưởng mới
cho tất cả các thành viên trong nhóm.
Cần tránh để tester viết unit test, bởi vì điều chủ yếu của TDD là người code


nên viết test trước khi viết code. Programmer sẽ có được phản hồi ngay từ việc
thực hiện unit test tự động.
Khi là 1 tester trong Agile team , có rất nhiều việc bạn có thể làm để đóng vai trò
là tác nhân thay đổi tuy nhiên khả năng ảnh hưởng của bạn sẽ bị giới hạn.
Trong 1 số trường hợp, sự hỗ trợ của người quản lý giỏi sẽ là chìa khóa để định
hướng team tham gia vào các hoạt động Quadrant 1.
7.4.2. What Can Managers Do? (Manager có thể làm những việc gì?)
Nếu bạn quản lý development team, bạn có thể làm nhiều việc để khuyến khích
team thực hiện TDD và unit test tự động. Làm việc với PO để đặt ra mục tiêu về
chất lượng và truyền đạt lại tiêu chuẩn chất lượng cho team. Khuyến khích
programmers dành thời gian làm công việc của mình 1 cách tốt nhất thay vì lo
lắng về deadline. Nếu ngày delivery ở tình trạng cảnh báo (vd : gần sát ngày),
nên thực hiện giảm scope chứ không phải giảm về chất lượng. Cần phải giải
thích với người quản lý về nghiệp vụ làm thế nào để uu tiên chất lượng , đảm
bảo họ nhận được business có giá trị.
Tạo thời gian cho team nghiên cứu, cung cấp các chuyên gia và đào tạo thực
hành .Mang tới hoặc thuê cho team người có nhiều kinh nghiệm về phát triển
Agile để họ truyền đạt các kỹ năng của mình . Cần có quỹ thời gian cho việc tái
cấu trúc, thảo luận về cách tiếp cận tốt nhất về việc viết unit test, integration
test , đánh giá, cài đặt và nâng cấp tool. Test manager làm việc cùng
development managers để khuyến khích việc thực hành, tăng cường khả năng
kiểm thử . Test manager đảm bảo tester có thời gian nghiên cứu cách sử dụng

test tool tự động, framework mà team đã quyết định thực hiện.
7.4.3. It’s a Team Problem? (đó là vấn đề của team)
Cách tốt nhất là cả team là cùng tham gia vào việc giải quyết các vấn đề. Cần
thực hiện retrospectives sau mỗi iteration. Trong mỗi buổi retrospective, cần đưa
ra issue, cả team cùng giải quyết. Cần khuyến khích team thử dùng cách tiếp
cận mới cho 1 vài iterations và xem nó hoạt động ra sao.
Technology-facing tests hỗ trợ quy trình phát triển của team là nền tảng quan
trọng cho mọi thử nghiệm. Nếu nhóm không thực hiện đầy đủ các kiểm thử trong
quadrant này, thì các loại test khác sẽ trở nên khó hơn nhiều, bởi vì code sẽ
thiếu chất lượng bên trong, mọi thứ sẽ lâu hơn.
Technology-facing tests không thể được hoàn thành mà không cần các tool và
cơ sở hạ tầng.
7.5 .Toolkit
Không có tool kỳ diệu nào đảm bảo chắc chắn sự thành công. Tuy nhiên tool có
thể giúp đỡ mọi người làm tốt nhất công việc của họ. Xây dựng cơ sở hạ tầng
phù hợp để hỗ trợ technology- facing test là rất quan trọng.


7.5.1. Source Code Control (Kiểm soát source code)
Source code control được biết với cái tên khác như version control hoặc
revision control, không có đội phát triển phần mềm nào có thể thành công nếu
như không có nó. Nếu không có quản lý source code, bạn không bao giờ chắc
chắn những thứ bạn đang test. Quản lý source code giúp cho chúng ta thấy
được sự thay đổi của module này so với những module khác. Nếu không có các
version, chúng ta cũng không thể chắc chắn phần code nào được release lên
production.
Nên sử dụng quản lý source code cho cả các script test tự động . điều quan
trọng là buộc các test tự động gắn với version code tương ứng , giúp ích cho
việc test lại ở các version tiếp theo.
Hệ thống mã nguồn mở cho quản lý source code như CVS và Subversion (SVN)

, IDE là dễ dàng để thực hiện, tích hợp. Vendor tools như là IBM Ratio-nal
ClearCase and Perforce
7.5.2. IDEs (integrated development environment)
IDE rất hữu ích cho programmers và tester trong Agile team. IDE tương tác với
hệ thống quản lý source code để ngăn chặn các vấn đề với versioning và thay
đổi những cái khác . IDE báo lỗi khi viết code sai. Quan trọng nhất là IDEs hỗ trợ
cho việc tái cấu trúc.
Open source IDEs như Eclipse, NetBeans được sử dụng rộng rãi trong Agile
team.
Tester có thể sử dụng tool như FishEye cho phép truy cập vào các đoạn code,
IDEs hỗ trợ cho hầu hết các ngôn ngữ lập trình
7.5.3. Build Tools
Team cần 1 số cách để xây dựng phần mềm. Việc này có thể được thực hiện với
các tool , tuy nhiên các tool đều có những hạn chế của nó, vd như về platform.
Agile team sử dụng các tool như Ant, Nant, Maven để xây dựng dự án . Các tool
này không chỉ quản lý việc xây dựng mà cung cấp 1 cách dễ dàng cho việc báo
cáo, tài liệu hóa kết quả và tích hợp dễ dàng với việc build tự động và test tool.
Chúng cũng tích hợp với IDEs.
7.5.4. Build Automation Tools
CI là 1 thực hành cốt lõi cho Agile team. Bạn không chỉ xây dựng dự án mà còn
chạy kiểm tra tự động trên từng build, đảm bảo không có gì bị phá vỡ cả. Việc tự
động hóa hoàn toàn và build lại được chạy nhiều trong ngày là chìa khóa thành
công cho Agile team. Tool build tự động cung cấp các tính năng như email thông
báo về kết quả build, tương tác với build và các tool quản lý source code.
Thông thường sử dụng các tool open source như CruiseControl,
CruiseControl.net, CruiseControl.rb, and Hudson.


Nếu không có 1 quá trình xây dựng tự đông, bạn sẽ có 1 khoảng thời gian khó
triển khai cho testing cũng như release. Quản lý việc xây dựng tool và các tool

build tự động rất cần thiết cho 1 dự án Agile thành công. Hãy đảm bảo bạn có 1
quy trình build sớm, thậm chí trước khi coding.
7.5.5. Unit Test Tools
Tools sử dụng cho Unit test phải là riêng biệt theo ngôn ngữ mà bạn code. Tool
“xUnit” thường được sử dụng cho Agile team, các tool khác nhau sẽ dùng cho
các ngôn ngữ khác nhau VD: JUnit for Java, NUnit for .NET, Test::Unit for Perl
and Ruby, and PyUnit for Python
Phát triển định hướng hành vi cũng là 1 trong những test- driven development,
sử dụng các tool như RSpec và easyb. 1 vài tool rất hiệu quả như : TestNG,
Abbot và SWTBot. Các công cụ như EasyMock và Ruby / giúp đỡ Mock với việc
thực hiện mục tiêu mock và test stubs. Các công cụ lập trình sử dụng
technology-facing tests cho business-facing tests. Mặc dù chúng phù hợp cho
mục đích trong dự án nhưng cần tùy theo yêu cầu của team và khách hàng.
Summary
Trong chương này, chúng ta giải thích về mục đích của technology-facing tests,
thảo luận về những thứ mà team cần làm để đạt hiệu quả hơn.
• Test Technology-facing hỗ trợ lập trình, giúp cho nhóm cung cấp code có
chất lượng cao nhất có thể. Chúng tạo thành nền tảng cho tất cả các loại
test khác .
• Lợi ích từ quadrant’s test này là nhằm làm cho nhanh hơn, nhiều hơn
nhưng tốc độ và số lượng sẽ chẳng bao giờ là mục tiêu cuối cùng.
• Programmers thực hiện viết technology- facing test, hỗ trợ nhóm và mang
lại giá trị cho tester bằng cách nâng cao chất lượng bên trong và khả
năng test được của hệ thống.
• Team thất bại trong việc áp dụng các bài học cốt lõi của Agile thì giống
như 1 cuộc “vật lộn”
• Legacy system thường trình bày những trở ngại lớn nhất để thử nghiệm
điều khiển
phát triển, nhưng những vấn đề này có thể được khắc
phục với gia tăng phương pháp tiếp cận.

• Nếu nhóm của bạn không thực hiện công việc test, bạn có thể giúp họ bắt
đầu bằng cách khuyến khích thành viên khác tham gia và nhận được sự
hỗ trợ từ quản lý.
• Có thể có 1 vài sự chồng chéo giữa technology-facing tests và businessfacing tests, tuy nhiên khi phải đối mặt với 1 sự lựa chọn, cần đẩy test vào
mức thấp nhất để tối đa hóa ROI
• Team nên thiết lập sự tương tác liên tục, build và qui trình test để cung
cấp phản hồi 1 cách nhanh chóng có thể.
• Agile team đòi hỏi các tool phục vụ cho các nhiệm vụ như là quản lý
source code, test tự động, IDEs, quản lý build để tạo điều kiện cho
technology- facing test hỗ trợ team.


Chapter 8. Business-Facing Tests that Support the Team
Trong chương trước chúng ta đã nói về việc programmer thực hiện test, những
loại test đã thực hiện ở level thấp đó giúp cho programmer chắc chắn họ đã viết
code đúng. Nhưng làm thế nào để họ biết code đúng để build? ở những phương
pháp trước chúng ta cố gắng giải quyết vấn đề đó bằng cách thêm vào REQ
càng chi tiết càng tốt. Trong những project sử dụng thực hành Agile chúng ta đặt
toàn bộ vào các story card và test cái mà khách hàng cũng có thể hiểu được
nhằm giúp chúng ta code đúng. Những loại test " có thể hiểu được " này là chủ
đề của chương này.
8.1.Driving development with business-facing tests
Trong agile chúng ta bắt đầu interaction với thông tin chỉ trong index card
( story).
Story thường là một đoạn mô tả ngắn yêu cầu về chức năng và thêm thông tin
để lập kế hoạch và xét độ ưu tiên trong công việc. Customer team và
Development team sẽ thảo luận dựa trên story. Team cần nhiều loại REQ và ở
level giúp họ có thể bắt đầu code gần như ngay lập tức. để làm được nó chúng
ta cần các ví dụ để đưa vào test, từ đó giúp xác nhận được khách hàng thật sự
muốn gì.

•

•

•

•

•
•

Loại test hướng tới business này nhằm vào yêu cầu về mặt business.
Những loại test này cung cấp một bức tranh lớn và đủ chi tiết để guide
code. Business-facing test nhằm đến REQ dựa trên các ví dụ, sử dụng
ngôn ngữ và định dạng mà cả khách hàng và team phát triển đều hiểu
được.
Business-facing test còn được gọi là"customer-facing", "story", "customer"
và "acceptance" test. Trong phát triển Agile, acceptance test không phải
UAT mà là business-facing test hoặc cũng có thể mang nghĩa technologyfacing test trong Q4.
Business-facing test trong Q2 được viết cho mỗi story trước khi bắt đầu
code vì nó giúp team hiểu sẽ viết code gì. Giống như các loại test trong
Q1, những loại test này định hướng phát triển nhưng ở level cao hơn.
Hoạt động ở Q1 giúp đảm bảo chất lượng bên trong code, tối ưu năng
suất của team và tối thiểu các vấn đề kĩ thuật. Test trong Q2 giúp định rõ
và kiểm tra chất lượng bên ngoài và giúp chúng ta hiểu khi nào hoàn
thành.
Loại test khách hàng thực hiện nhằm định hướng code hầu hết được viết
theo format có thể thực hiện và tự động hóa được, nhờ đó các thành viên
trong team có thể chạy test bất cứ khi nào cần nhằm kiểm tra chức năng
có hoạt động đúng không. Những loại test này, hoặc một tập hợp nhỏ của

chúng sẽ trở thành một phần trong regression test tự động.
Ngoài các mong muốn về tính năng, chúng ta cần chỉ ra các yêu cầu phi
chức năng như performance, security, và usability.
Có rất nhiều câu hỏi xung quanh việc REQ trong phát triển Agile sẽ gồm
những nội dung gì? REQ cần rõ ràng đến mức nào? Làm sao để khách


hàng nói rõ REQ cho chúng ta?
8.2. The Requirements Quandary
Phát triển Agile gắn với sự thay đổi, nhưng điều gì sẽ xảy ra nếu REQ thay đổi
trong một interaction? Chúng ta sẽ làm thế nào để biết đã thực sự hiểu chi tiết về
story trước khi bắt đầu code?
Trong phát triển Agile, tính năng mới thường bắt đầu bởi các story, hoặc group
các story, được viết bởi đội customer. Story được viết không chỉ ra chi tiết về
implementation mặc dù có thể phụ thuộc vào ảnh hưởng của các cuộc thảo luận
và bao nhiêu story được tạo ra. Sẽ rất có ích nếu một vài thành viên của team
phát triển tham gia vào quá trình tạo story, nhờ đó họ sẽ có đầu vào cho các
chức năng và giúp đảm bảo các vấn đề kỹ thuật trở thành một phần trong
backlog.
Programmer và tester cũng có thể giúp khách hàng break story thành những
phần nhỏ hợp lý hơn, gợi ý các lựa chọn có tính thực tiễn và thảo luận sự phụ
thuộc giữa các story. Bản thân story không đưa ra nhiều thông tin về chức năng
mong muốn. Nó chỉ nhấn mạnh vào : ai muốn sử dụng chức năng, chức năng
đó là gì và tại sao họ muốn nó. Story chỉ là điểm bắt đầu cho việc đối thoại giữa
khách hàng và team phát triển. Nếu thành viên của team có thể hiểu thực sự
khách hàng muốn giải quyết vấn đề gì họ có thể gợi ý lựa chọn dễ sử dụng và
cài đặt.
Trong cuộc đối thoại giữa khách hàng và thành viên team, agile team thường mở
rộng các story cho đến khi họ đủ thông tin để code. Tester sẽ giúp gợi ra các ví
dụ và ngữ cảnh cho mỗi story và giúp khách hàng viết kịch bản test cho story,

những loại test mà sẽ giúp cho programmer viết code và giúp team hiểu khi nào
thỏa mãn được điều kiện của khách hàng.
Trong phát triển agile chúng ta chấp nhận việc sẽ không bao giờ hiểu hết được
REQ từ đầu. Sau khi hoàn thành việc code để pass qua các case test của story,
chúng ta vẫn cần test nhiều hơn để hiểu rõ hơn về REQ và cách mà chức năng
sẽ hoạt động.
Khách hàng có thể sẽ có các ý tưởng khác sau khi xem phần deliver của team
phát triển. Hầu hết khách hàng đều khó khăn trong việc đưa ra điều họ thực sự
mong muốn. Team làm việc cùng với khách hàng qua một interaction có thể
deliver chỉ một phần chủ yếu của giải pháp. Team sẽ tiếp tục tinh lọc các chức
năng thông qua nhiều interaction cho đến khi nó được chỉ rõ và có thể deliver
được chức năng.
Chúng ta cần phải học càng nhiều các tốt về những điều khách hàng của mình
muốn và cần. Không chỉ hiểu tốt hơn về REQ của họ mà thậm chí chúng ta có
thể chỉ ra cả những REQ họ không nghĩ đến. Chúng ta cũng cần test cả ảnh
hưởng của system lên toàn bộ, hay sự tích hợp với các hệ thống khác. Chúng ta


có thể chỉ ra risk và giảm nhẹ chúng với các loại test cần thiết. Tất cả những yếu
tố đó sẽ dẫn đường cho code.

8.2.1. Common language
Chúng ta có thể sử dụng các loại test để cung cấp một ngôn ngữ chung mà cả
độ phát triển và các chuyên gia về business đều có thể hiểu được. Dùng các
công cụ như : ảnh, flow diagram, spreadsheet và prototype sẽ tìm ra ví dụ và sau
đó dễ dàng đưa vào test. Những loại test này cần được viết để cả những người
về business có thể đọc và team kĩ thuật có thể thực hiện test.
Business-facing test còn giúp chúng ta chỉ ra được phạm vi, giúp mọi người hiểu
phần nào thuộc story và phần nào không. Có rất nhiều các test framework cho
phép team tạo ra một ngôn ngữ chung và định nghĩa các kịch bản test dùng

ngôn ngữ đó. Ví dụ như Fit
8.2.2. Eliciting Requirements
Chúng ta có rất nhiều cách để giúp khách hàng chỉ ra rõ ràng điều họ mong
muốn
a. Ask Questions
Hãy bắt đầu bằng việc đặt câu hỏi. Tester thường có kĩ năng đặc biệt trong việc
đặt nhiều câu hỏi khác nhau vì họ thấy rõ được bức tranh toàn cảnh. Các câu
hỏi mà chúng ta có thể đặt ra :
• Story này có thể giải quyết được vấn đề ?
• Nếu như vậy, vấn đề chúng ta cần giải quyết là gì ?
• Có thể chúng ta đã implement một giải pháp không giải quyết được vấn
đề ?
• Story sẽ mang lại giá trị ntn về mặt business ?
• Ai là người dùng cuối cùng của chức năng?
• Họ sẽ nhận được giá trị gì từ các tính năng?
• Người dùng có sử dụng đúng trước và sau họ sử dụng tính năng không?
• Làm sao chúng ta biết chúng ta đã hoàn thành story?
Một câu hỏi mà Lisa thường đặt "Điều tồi tệ nhất có thể xảy ra là gì?". Các kịch
bản xấu nhất thường dẫn đến các ý tưởng. Nó cũng giúp chúng ta xem xét risk
và tập trung test vào những vùng nguy hiểm. Một câu hỏi tốt khác nữa là " Điều
tốt nhất có thể xảy ra là gì?" Câu hỏi này thường tạo ra happy path test nhưng
đôi khi lại dẫn đến việc không cover được các tình huống bị ẩn đi.
b. Use Examples
Việc quan trọng nhất là hỏi customer đưa cho bạn các ví dụ về việc tính năng sẽ
hoạt động như thế nào. Các ví dụ có thể chỉ ra các kịch bản test cơ bản. Một vài


khách hàng có thể dùng các test tool như Fit hay Fitness để đưa ra ví dụ của họ.
Các ví dụ thường giống như sau :
"There are 5 items on a page. I want to select item 1 for $20.25 and put it in the

shopping cart. I click to the next page, which has 5 more items. I select a second
item on that page for $5.38 and put it in my shopping cart. When I say I’m done
shopping, it will show both the item from the first page and the item from the
second page in my shopping cart, with the total of $25.63"

Những kịch bản test thường khác một chút so với các example. Chúng ta sẽ sử
dụng Fit format để viết các kịch bản test như hình dưới đây

Kịch bản test capture lại các ví dụ trong một format có thể thực hiện test. Nó có
thể không giống hệt input nhưng nó sẽ giống về kịch bản người dùng. Nhiều test
case hơn có thể được viết để test các giá trị biên, các cạnh và các kịch bản
khác.
c. Multiple Viewpoints
Mỗi ví dụ hoặc test có một viewpoint. Những người khác nhau sẽ viết ra các
case test và các ví dụ khác nhau cho mục đích của họ.
Chúng ta cần capture lại nhiều nhất viewpoint có thể và hãy nghĩ về khách hàng.
Tập hợp REQ từ những role khác nhau trong team sẽ có ích. BA, các chuyên
gia, programmer và các thành viên khác của customer team đều có giá trị. Hãy
nghĩ về các stakeholder khác, ví dụ như đội hỗ trợ sản phẩm, họ cũng sẽ có
cách nhìn riêng.
Những REQ phi chức năng thường bị chúng ta bỏ quên, mặc dù nó thường ở
Q3 hay Q4 nhưng chúng ta vẫn cần phải viết ra để đảm bảo nó
sẽ được hoàn
thành
Gần gũi, hợp tác giữa team khách hàng và team phát triển là chìa khóa giúp thu
được các ví dụ, cái mà sẽ là cơ sở cho các kịch bản test của khách hàng nhằm
định hướng code.
d. Communicate with Customers
Trong thực tế, có nhiều team khác xa về mặt địa lý và thời gian với khách hàng.
Nhưng chúng ta hãy sử dụng mọi công cụ để có thể hội thoại face-to face với

khách hàng (conference calls, phone conversations, email, IM, cameras...).
Tuy nhiên việc giao tiếp với khách hàng cần được quản lý, nếu chúng ta có
nhiều phiên bản khác nhau về việc một chức năng có thể hoạt động như thế nào


thì chúng ta sẽ không thể code được. Hãy cùng tìm ra cách để nhận được sự
đồng ý của khách hàng về điều kiện thỏa mãn cho mỗi story
8.2.3. Advance Clarity
Khách hàng từ các bộ phận khác nhau trong tổ chức sẽ thường có những ý kiến
xung đột về việc họ muốn có story như thế nào.
PO là một role trong Scrum. Trách nhiệm của PO không chỉ là đạt được sự rõ
ràng trong REQ mà còn đóng vai trò như người đại diện cho khách hàng trong
việc xét thứ tự ưu tiên của story. Tuy vậy đương nhiên vẫn có mặt tối, khi bạn
thu nhận nhiều viewpoint khác nhau chỉ thông qua một người. Vì vậy, team cần
ngồi lại cùng với khách hàng để học cách họ làm việc. Nếu chúng ta hiểu được
công việc hàng ngày của họ, chúng ta sẽ có nhiều cơ hội để tạo ra một phần
mềm có thể hỗ trợ công việc đó của họ. Tuy nhiên việc quan trọng là vẫn cần chỉ
duy nhất một tiếng nói của customer ( người có thể ra quyết định)
8.2.4. Conditions of satisfaction (điều kiện thỏa mãn, hài lòng)
• Toàn bộ quá trình release cũng như mỗi feature hoặc mỗi story đều có
các điều kiện hài lòng khách hàng. Acceptance test giúp xác định ra các
tiêu chí chấp thuận cho story. đội phát triển không thể bàn giao thành
công những thứ mà nghiệp vụ mong muốn trừ khi các điều kiện thỏa mãn
được nhất trí từ trước. Customer team cần có “chung tiếng nói”. Nếu bạn
nhận yêu cầu khác nhau từ các bên khác nhau , bạn cần phải “đặt vào rồi
lại lấy ra” - cân nhắc các story cho đến khi bạn chắc chắn có 1 danh sách
các điều kiện thỏa mãn về nghiệp vụ. Yêu cầu khách hàng cung cấp 1
lượng thông tin tối thiểu cho mỗi story và như vậy bạn có thể bắt đầu
interaction .
• Cách tốt nhất để hiểu được yêu cầu của customer team là nói chuyện trực

tiếp với khách hàng . Vì mỗi thành viên đều “vật lộn” với các yêu cầu, vì
thế sẽ phải có các công cụ để giúp customer team làm việc xuyên suốt
mỗi story. điều kiện thỏa mãn không những bao gồm các features được
story cung cấp mà còn bao gồm các ảnh hưởng tới hệ thống.
• PO của Lisa sử dụng checklist để chọn ra một số vấn đề như sau:
- Các điều kiện thỏa mãn nghiệp vụ
- Những ảnh hưởng đến các chức năng có sẵn như website, tài
liệu, hóa đơn, forms hoặc các báo cáo
- Xem xét tính pháp lý (Legal considerations)
- Tác động đối với các quy trình đã được lên lịch thường xuyên
- Tham khảo các mock - up cho UI story.
- Văn bản trợ giúp hoặc những người sẽ cung cấp nó
- Test cases
- Chuyển đổi dữ liệu (nếu thích hợp)
- Thông tin liên lạc nội bộ
- Thông tin liên lạc bên ngoài với đối tác kinh doanh và nhà cung
cấp
• PO sử dụng các template để đưa các thông tin này lên trên wiki của team,


•

vì thế mà nó sẽ được các thành viên trong team sử dụng để nghiên cứu
về các story và bắt đầu viết test.
Các điều kiện này dựa trên giả định chính và quyết định do customer
team tạo ra cho story. Việc thảo luận các điều kiện thỏa mãn giúp xác định
các giả định về rủi ro và tăng cường độ tin cậy của team trong việc viết và
dự đoán đúng tất cả các tasks cần thiết để hoàn thành story.

8.2.5. Ripple Effects (Hiệu ứng gợn sóng)

• Trong quá trình phát triển Agile, chúng ra chỉ tập trung vào 1 story ở 1 thời
điểm. Mỗi story thường chỉ là 1 phần nhỏ của toàn bộ ứng dụng, nhưng
nó có thể có hiệu ứng gợn sóng lớn. Một story được đưa ra giống như
viên đá nhỏ ném trong hồ nước và chúng ta không thể nghĩ đến những
đợt sóng dạt vào. Khi chúng ra chỉ tập trung vào số lượng nhỏ các story
trong mỗi interaction, rất dễ đánh mất việc nắm bắt bức tranh toàn cảnh.
• Nhóm của Lisa thấy rất hữu ích khi tạo ra một danh sách mà tất cả các
phần của hệ thống mà có thể bị ảnh hưởng bởi một story. Nhóm có thể
kiểm tra từng điểm "test" để xem những yêu cầu nào và những test case
nào có thể tạo ra. Mỗi story nhỏ có thể có những tác động rộng và lớn,
mỗi phần ứng dụng thể hiện các mức độ phức tạp khác nhau . Bạn cần
phải nhận thức được những ảnh hưởng tiềm năng của bất kỳ sự thay đổi
nào của code. Tạo ra 1 danh sách những điểm tốt để bắt đầu. Trong 1 vài
ngày đầu tiên của iteration, nhóm có thể nghiên cứu và phân tích phạm vi
ảnh hưởng xa hơn và tìm ra bất kỳ nhiệm vụ nào cần thiết để cover được
toàn bộ
• Story có vẻ nhỏ nhưng nó ảnh hưởng đến những phạm vi không mong
muốn của hệ thống có thể chống lại bạn. Nếu team của bạn quên mất
việc xem xét tất cả các ràng buộc, và nếu code mới không liên kết với
chức năng hiện có, story có thể sẽ lâu hơn dự kiến hoàn thành. Hãy chắc
chắn các story test bao gồm ít nhất là sự minh bạch, rõ ràng khi thực hiện
chức năng mới.
• Dành thời gian để xác định mỗi giá trị chính của story cung cấp và và tìm
ra một phương pháp gia tăng để phát triển nó. Có kế hoạch từng bước
nhỏ của việc viết test, viết code và test code. Bằng cách này, các kiểm thử
của Q2 đảm bảo bạn sẽ bàn giao những giá trị tối thiểu theo kế hoạch
8.3. Thin Slices, Small Chunks (Lát mỏng, khối nhỏ)
• Thực hiện viết các stories là 1 công việc nghiêm túc. Khi đội development
estimate cho các story mới, chúng ta có thể nhận ra 1 vài story quá phức
tạp, vì thế cần đề nghị nhóm customer tách chúng thành các story nhỏ

hơn. Các story càng nhỏ càng tốt, cũng có thể kết hợp với các story khác
hoặc xử lý đơn giản như là 1 task. Việc phát triển theo mô hình Agile bao
gồm cả test chỉ đảm nhiệm 1 khối chức năng nhỏ ở một thời điểm.
• Khi team của bạn tham gia vào dự án mới hoặc chủ đề mới, nên yêu cầu
PO dẫn dắt tới tất cả các story liên quan trong buổi họp brainstorming của
interaction đầu tiên. Cần phải có PO và các bên liên quan khác giải thích


•

•

•

•

•

về các story. Bạn cũng có thể thấy một vài story cần được chia nhỏ hoặc
thêm 1 vài story cần thiết vào những khoảng trống.
Sau khi đã hiểu được giá trị của mỗi story mang lại và nó phù hợp với
ngữ cảnh của hệ thống như thế nào, bạn có thể bẻ nhỏ các story thành
các phần nhỏ, dễ quản lý. Bạn cũng có thể viết customer test để xác định
từng bước nhỏ trong khi vẫn nhận thức được sự ảnh hưởng tới ứng dụng
.
Cách tiếp cận nhanh chóng với việc viết customer test là hướng dẫn phát
triển bắt đầu với “thin slice- lát mỏng” . Việc xác định 1 lát mỏng cũng gọi
là “steel thread- chủ đề thép” hoặc “tracer bullet- vết đạn” được hoàn
thành ở mỗi mức độ, nó được sử dụng để rà soát lại toàn bộ cấu trúc.
“Steel thread” kết nối tất cả các thành phần lại với nhau và sau đó chắc

chắn sẽ có nhiều chức năng được thêm vào.
Chúng ta nhận thấy chiến lược này hoạt động ở mức story cũng giống
như thế. Bạn càng xây dựng con đường “end- to- end” sớm, bạn lại càng
có thể thực hiện sớm việc testing 1 cách đúng nghĩa, nhận phản hồi, bắt
đầu thực hiện test tự động và bắt đầu test khám phá (exploratory)..Bắt
đầu với 1 lát mỏng (thin slice) của hầu hết chức năng nhỏ và cốt yếu mà
bạn có thể test. đây có thể coi như là con đường đi rất quan trọng. đối với
giao diện người dùng, việc này có thể bắt đầu chỉ đơn giản là điều hướng
từ trang này sang trang tiếp theo. Chúng ta có thể chỉ nó cho người dùng .
Chúng ta có thể viết ra các test GUI tự động 1 cách đơn giản.
Sau khi thin slice hoạt động, chúng ta có thể viết customer test cho khúc
(chunk) hoặc lớp tiếp theo của chức năng , và viết code để làm cho test
có thể pass. Như vậy quy trình sẽ là “viết test- viết code- chạy test - tìm
hiểu”. Nếu bạn làm được việc này, có nghĩa là tất cả code mà team bạn
tạo ra đãđáp ứng được khách hàng và hoạt động đúng theo từng giai
đoạn.
Nếu việc viết customer test cho 1 story có vẻ bị mơ hồ , team của bạn cần
phải bẻ nhỏ thành các bước hoặc từng khúc. Khi kết thúc mỗi bước nhỏ ở
mỗi thời điểm sẽ giúp dàn trải testing effort vì thế nó sẽ không bị đẩy đến
cuối iteration. Nó cũng đưa cho bạn bức tranh về tiến độ và giúp bạn biết
khi nào bạn phải hoàn thành.

8.4 .How do we know we’re done?
• Chúng ta thực hiện business - facing test, việc này giúp cho team thực
hiện kiểm thử những thứ được viết ra nhằm đảm bảo điều kiện thỏa mãn
được đáp ứng. Họ bắt đầu với “happy path” và chỉ ra các story đáp ứng
những dự định cần thiết. Họ bảo đảm các kịch bản khác nhau của người
dùng và cũng chắc chắn rằng các phần khác của hệ thống không bị ảnh
hưởng .
• Chúng ta đã kết thúc chưa? Chúng ta có thể nhưng chúng ta không chắc

chắn. Việc test đúng là liệu người dùng sử dụng phần mềm có thực hiện
những hành động mà story giả định là đã cung cấp. Ngay thời điểm này,
chúng ta chỉ cần thực hiện các hoạt động của Q3, Q4 như exploratory
testing, usability testing và performance testing sẽ giúp chúng ta tìm ra


•

•

điều này. Chúng ta cần phải thực hiện 1 vài customer test để đảm bảo
chúng ta nắm bắt được toàn bộ các yêu cầu. Bussiness users hoặc PO là
những người quyết định liệu mọi yêu cầu đã được bàn giao , vì thế họ
cũng chính là những người thực hiện thăm dò ở giai đoạn này.
Khi việc thực hiện kiểm thử thành công và bất kỳ yêu cầu nào bị bỏ sót
đã được xác định, chúng ta đã hoàn thành m đích hỗ trợ programmer
trong quá trình code. điều này không có nghĩa là chúng ta hoàn thành vệc
test.
Mục tiêu khác của customer test là xác định ra các khu vực có rủi ro cao
và đảm bảo code được viết ra là không bị thay đổi. Việc quản lý rủi ro là
hoạt động cần thiết cho bất kỳ phương thức phát triển phần mềm nào và
tester đóng vai trò trong việc xác định và giảm thiểu rủi ro.

8.5 .Tests mitigate risk (Test giảm thiểu rủi ro)
• Customer test được viết ra không chỉ để xác định hành vi mong đợi của
code mà là để quản lý rủi ro. Việc định hướng phát triển với test không có
nghĩa là chúng ta xác định mọi yêu cầu đơn lẻ lên trước hoặc có thể dự
đoán 1 cách hoàn hảo khi chúng ta hoàn thành. Nó đưa cho chúng ta cơ
hội xác định và giảm thiểu rủi ro bằng việc thực hiện các test case. Phân
tích rủi ro không phải là một kỹ thuật mới. Việc phát triển theo mô hình

Agile vốn là để giảm thiểu các rủi ro bằng cách ưu tiên những business
nhỏ, thực hiện test từng phần nhỏ được bàn giao và có sự tham gia của
khách hàng để tăng dần sự chấp thuaanj của khách hàng . Tuy nhiên
chúng ta vẫn cần động não nghĩ về các vấn đề tiềm tàng , chúng có thể
xảy ra và ảnh hưởng tới tổ chức . Nếu chúng xảy ra, chiến lược để giảm
thiểu cần được sử dụng.
• Bằng việc thảo luận với programmers và các thành viên khác trong nhóm
về những ảnh hưởng tiềm tàng và các vùng rủi ro, chúng ta có thể lên kế
hoạch phù hợp cho các hoạt động test .
• Có 1 rủi ro khác . Chúng ta có thể tham gia vào việc viết test case chi tiết
trước. Chúng ta có thể quên đi bức tranh lớn trong khi chúng ta chỉ tập
trung vào chi tiết, cái đó được chứng minh là không thích hợp.
• Khi làm việc trong Agile team, chúng ta sẽ làm việc với iteration ngắn, vì
thế việc quan trọng là xác định time-box cho thời gian viết test case trước
khi chúng ta bắt đầu. Sau khi iteration được hoàn thành, dành thời gian
để đánh giá liệu việc chi tiết hóa lên trước có giúp ích không.đã thực hiện
test đủ để tracking được team chưa? Có tốn nhiều thời gian khi 1 story đã
bị hiểu sai? Team của La nhận ra rằng cách tốt nhất là viết ra story test ở
mức high level trước khi code, viết test case chi tiết khi bắt đầu code , sau
đó thực hiện exploratory test đối với đoạn code đã được bàn giao để
nhằm cung cấp cho team nhiều thông tin hơn và giúp họ điều chỉnh.
• Trong khi business facing test giúp giảm thiểu rủi ro, các loại test khác
cũng rất quan trọng. VD như có nhiều bug quan trọng được phát hiện
trong quá trình thực hiện exploratory testing thủ công. Performance,
security, stability và usability cũng là nguồn gốc của rủi ro. Những loại test
để giảm thiểu các rủi ro khác được thảo luận ở những chương nói về Q3,


•


Q4.
Thử nghiệm và tìm ra cách mà nhóm của bạn có thể cân bằng giữa việc
sử dụng chi tiết lên trước và giữ tập trung vào bức tranh lớn. Với các
iteration ngắn , bạn có cơ hội thường xuyên để đánh giá tiến độ làm việc
như thế nào , vì thế bạn có thể tạo nên các cải tiến liên tục.

8.6. Testability and Automation (Khả năng kiểm thử và tự động)
• Khi programmer trong Agile team sẵn sàng thực hiện TDD (test driven
development), họ sử dụng business- facing test cho các story để biết họ
code những gì. Làm việc với kiểm thử có nghĩa là mọi người đều nghĩ ra
cách tốt nhất để thực hiện thiết kế code sao cho test được dễ dàng.
Business-facing test ở Q2 được nói đến là test tự động. Chúng cần phải
được hiểu rõ ràng, dễ chạy, cung cấp phản hồi nhanh chóng , nếu không
chúng sẽ không được sử dụng.
• Có thể viết test script thủ công cho programmer thực hiện trư khi họ kiểm
tra code , vì thế họ đảm bảo thỏa mãn điều kiện của khách hàng, nhưng
nó không là điều thực tế để mong đợi nếu họ gặp rắc rối trong thời gian
dài. Giá trị nghiệp vụ phải được bàn giao cứ hai tuần hoặc 30 ngày, thông
tin sẽ được phản hồi ngay lập tức và tự động. Các nhóm Agile có kinh
nghiệm có thể chấp nhận việc định hướng code bằng test tự động ở mức
developer test dễ dàng hơn ở mức customer test. Tuy nhiên, nếu không
có customer test, programmer mất nhiều thời gian để biết unit test viết
những gì.
• Mỗi Agile team phải tìm ra 1 quy trình viết và chạy tự động businessfacing test để định hướng việc phát triển. Nhóm mà chỉ chạy tự động
technology-facing tests nhận thấy rằng họ có thể có đoạn code không có
bug nhưng lại không làm đúng với những gì khách hàng mong muốn.
Nhóm không thực hiện bất kỳ test tự động nào thì sẽ tự gắn mình với
technical debt.
• Q2 chứa rất nhiều loại test và các hoạt động. Chúng ta cần các công cụ
thích hợp để tạo điều kiện thu thập, trao đổi, giao tiếp qua các ví dụ và

việc test. Các công cụ đơn giản như là giấy trắng hoặc bảng trắng cũng là
1 công cụ tốt để thu thập các ví dụ. Các công cụ tinh tế hơn là giúp nhóm
viết business- facing test , hướng dẫn đội phát triển thực hiện, test tự
động.
Summary
Trong chương này, chúng ta đã tìm ra cách hỗ trợ nhóm trong suốt quá trình
coding bằng business- facing test.
• Trong quá trình phát triển Agile, vd và business- facing test tốt hơn là việc
tài liệu hóa các yêu cầu truyền thống, cần thông báo với nhóm là code viết
những gì
• Làm việc với những lát cắt mỏng của chức năng, với các iteration ngắn se
góp phần mang lại cho khách hàng những cơ hội để xem và sử dụng các
ứng dụng, có thể điều chỉnh các yêu cầu của họ nếu cần.
• Một điều quan trọng là tester đóng góp trong việc giúp khách hàng thể


•
•
•
•
•
•
•
•
•

hiện được điều kện thỏa mãn và tạo ra các ví dụ mong muốn, không
mong muốn, hành vi cho mỗi story.
Hãy hỏi những câu hỏi mở để giúp khách hàng nghĩ về tất cả các chức
năng mong muốn và ngăn chặn những giả định quan trọng còn đang bị

che lấp.
Giúp khách hàng đạt được sự đồng thuận về hành vi mong muốn cho các
story, chúng chứa những quan điểm khác nhau về các phần nghiệp vụ
khác nhau.
Giúp khách hàng phát triển các công cụ (ví dụ, một danh sách kiểm tra
các story) để bày tỏ thông tin như: điều kiện thỏa mãn nghiệp vụ.
Nhóm development và customer nên nghĩ xuyên suốt các phần của ứng
dụng, đưa ra các ảnh hưởng của story và luôn nghĩ về các chức năng của
hệ thống.
Làm việc với nhóm để bẻ nhỏ các tính năng , dễ quản lý
Tuân theo khuôn mẫu “viết test- viết code- chạy test- nghiên cứu” từng
bước một, xây trên từng chức năng đã pass.
Sử dụng test và các ví dụ để giảm thiểu rủi ro của các chức năng bị bỏ sót
hoặc việc mất tầm nhìn của một bức tranh lớn.
định hướng code với việc test business- facing sẽ làm cho nhóm phát
triển có ý thức cần thiết phải thực hiện test ứng dụng.
Việc test business-facing hỗ trợ team thực hiện test tự động nhanh chóng
và nhận phản hồi nhanh chóng về những giá trị mà team đã bàn giao
trong interattion ngắn.

Chapter 9. Toolkit for Business-Facing Tests that Support the Team

9.1. Business-Facing Test Tool Strategy
. Làm thế nào để nắm bắt business-facing tests giúp các lập trình viên biết phải
viết mã cho cái gì? Đối thoại trực tiếp giữa lập trình viên và khách hàng diễn ra
thường xuyên là cách tốt nhất, nhưng khách hàng không phải lúc nào cũng có
thời gian, hoặc có thể khách hàng và lập trình viên ở những vị trí khác nhau thì
cuộc đối thoại ngẫu hứng sẽ không khả thi. Bên cạnh đó, sau một thời gian
chúng ta muốn nhớ tại sao lại viết mã như vậy. Điều này, chắc chắn cần cách để
chia sẻ thông tin điện tử.

. Do phát triển Agile đã trở nên phổ biến, chúng ta có nhiều công cụ để nắm bắt
các ví dụ và sử dụng chúng để viết các executable tests. Các công cụ có sẵn
thay đổi quá nhanh so với những công cụ chúng tôi giới thiệu trong cuốn sách
này, nhưng chúng tôi có thể cung cấp một số ví dụ về các công cụ và một số
chiến lược để sử dụng chúng, cung cấp business-facing tests hỗ trợ team phát
triển những story mới. Một trong những công cụ chúng ta thảo luận không mới,
hoặc cụ thể cho phát triển Agile, nhưng chúng làm việc tốt trong dự án Agile.
. Chiến lược trong việc lựa chọn công cụ cần dựa vào tập hợp các kỹ năng của
nhóm bạn, công nghệ mà ứng dụng đã dùng, mức độ ưu tiên tự động hóa của


nhóm, sự ràng buộc về thời gian và ngân sách, và các mối quan tâm khác duy
nhất cho tình huống của bạn. Lựa chọn một công cụ hay các công cụ không dựa
vào bản mới nhất hay thú vị nhất được cung cấp bởi một salesman. Bạn có thể
cần nhiều công cụ khác nhau để giải quyết vấn đề khác nhau.
. Chúng tôi khuyên khách hàng hãy chuẩn bị và sẵn sàng để giải thích các ví dụ
cho mỗi story trong quá trình lên kế hoạch iteration. Kiểm thử viên giúp khách
hàng tìm hiểu làm thế nào để cung cấp chi tiết khi bắt đầu iteration.
. Trải nghiệm các mức độ khác nhau của chi tiết các trường hợp kiểm thử để tìm
ra công việc nào tốt nhất cho nhóm của bạn. Dù mức độ chi tiết thế nào, bạn cần
một số cách để giúp khách hàng tìm và thể hiện các ví dụ về hành vi hệ thống
mong muốn.
9.2. Tools to Elicit Examples and Requirements
. Như đã chỉ ra trong chapter 8, các story là nơi bắt đầu để thảo luận về hành vi
mong muốn. Tính năng, ngời dùng, và mục đích trong story được đưa ra rõ ràng.
Theo Mike Cohn [2004] chỉ ra, Chúng không cần quá chi tiết cho đến khi story
được đưa và iteration. Thu thập thông tin vào một story không bao giờ được đưa
vào iteration là một sự lãng phí về tài nguyên. Mô hình “role, function, business
value” được Mike Cohn mô tả trong User Stories Applied như sau:
As a (role), I want (function) so that (business value).

. Định dạng này không phải phù hợp với tất cả mọi người, vì vậy chúng tôi
khuyến khích thử nghiệm và làm thế nào tốt nhất trong tình huống của bạn. Bất
kể user story đọc như thế nào, bạn cần một số cách để xử lý story đó với các ví
dụ và business-facing tests định hướng phát triển.
. Một story đơn giản có tác dụng sâu rộng, không chỉ với application, mà toàn bộ
organization (tổ chức), clients (khách hàng), associates (đối tác), vendors (nhà
cung cấp), hay partners (đối tác). Nếu thay đổi API, chúng ta phải thông báo cho
customer và vendor sử dụng nó. Nếu chúng ta có kế hoạch thay đổi UI, chúng ta
có thể muốn hoặc buộc phải lập lại hợp đồng để đưa thông báo đến người sử
dụng. Các story có thể ảnh hưởng đến các bên liên quan hoặc báo cáo bên
ngoài. Tính năng mới thường có nghĩa tài liệu mới hay cập nhật. Tất nhiên, chức
năng thay đổi sẽ ảnh hưởng đến các phần khác của hệ thống.
. Đội ngũ phát triển phần mềm, bao gồm cả kiểm thử viên, sẽ giúp khách hàng
nắm bắt và truyền đạt toàn bộ yêu cầu liên quan đến story hay theme. Sẽ là một
sự lãng phí thời gian nếu việc phát triển tính năng mới bị ngăn chặn bởi các lý do
chính sách/pháp luật hay business partner không được thông báo đúng lúc. Phát
triển Lean giúp chúng ta tránh lãng phí trong khi phát triển phần mềm.
. Những công cụ giúp minh họa hành vi mong muốn với các ví dụ:
• Checklists


•
•
•
•
•

Mind maps
Spreadsheets
Mock-ups

Flow diagrams
Software-based tools

Danh sách gồm các công cụ đơn giản, không chỉ sử dụng cho Agile testing,
nhưng không nên bỏ qua. Trong phát triển Agile, các giải pháp đơn giản luôn là
tốt nhất.
9.2.1. Checklists
. Checklist là một cách để PO (Product Owners) đảm bảo việc đánh giá và truyền
đạt toàn bộ khía cạnh của một story là chính xác.
. Checklist xác định các điều kiện hài lòng - mà doanh nghiệp cần từ các story.
Nó gồm các tác động từ các chức năng như website, documents (tài liệu),
administrative forms (biểu mẫu hành chính), account statements (báo cáo tài
khoản), và các thành phần khác của hệ thống, các hoạt động hằng ngày của
doanh nghiệp.
. Checklist đảm bảo nhóm không bỏ lỡ các yêu cầu như data migration (chuyển
đổi dữ liệu), notifications (thông báo), legal considerations (vấn đề pháp lý), và
thông tin liên lạc với các nhà cung cấp và đối tác thương mại.
. Ví dụ:
9.2.2. Mind Maps
. Mind maps là một cách đơn giản, hiệu quả để tìm kiếm các ý tưởng. Mind maps
là biểu đồ mô tả các khái niệm, từ ngữ hay ý tưởng liên kết đến một khái niệm
trọng tâm.
. Không quan trọng bạn sử dụng công cụ hay vẽ nó lên whileboard (bảng trắng),
hay lên một tờ giấy to. Hiệu quả sử dụng thì như nhau.
. Mind maps giúp tạo các ý tưởng và làm việc theo cách phù hợp với suy nghĩ
của bạn về các vấn đề.
. Ví dụ, đang thảo luận story trong hình
Chúng tôi tập trung xung quanh whileboard và bắt đầu đặt câu hỏi. Hình ví dụ
minh họa mind map mà chúng tôi đã vẽ trên whileboard
9.2.3. Spreadsheets

. Một số công cụ xác định business-facing tests sẽ phù hợp với lĩnh vực thương
mại của bạn. Ví dụ, Spreadsheets được sử dụng rộng rãi bởi các công ty dịch vụ
tài chính. Do đó, một dự án trong lĩnh vực dịch vụ tài chính cũng sử dụng
Spreadsheets để xác định các ví dụ về chức năng mà story sẽ phân phối.
. Customers có thể viết một vài high-level test case để bao phủ một story trước
khi bắt đầu iteration, có thể sử dụng một số loại checklist. Một số customer
teams đơn giản viết một cặp kiểm thử, có thể một happy path và một negative


test vào mặt sau của mỗi story card. Một số viết các ví dụ chi tiết vào
Spreadsheets hay định dạng nào mà họ cảm thấy thoải mái khi làm việc.
. Steve Perkins, PO của nhóm Lisa, thường mô tả các phép tính và thuật toán
phức tạp trong Spreadsheets, nhóm chuyển thành các kiểm thử sau đó. Hình
dưới cho thấy một trong các worksheet, thực hiện các tính toán với dữ liệu đầu
vào để đưa ra các giá trị trong các cột ADR và ACR. Định dạng này dễ dàng có
được một khung kiểm thử tự động.
. Xem xét các công cụ được sử dụng bởi các chuyên gia kinh tế và xem chúng
có thể điều chỉnh các tài liệu ví dụ về hành vi chức năng mong muốn giúp nhóm
phát triển hiểu story tốt hơn.
9.2.4. Mock-Ups (giả lập)
. Mock-up có nhiều hình thức. Paper prototypes là cách đơn giản và hiệu quả để
kiểm thử các màn hình sẽ làm việc cùng nhau như thế nào. Vẽ trên whileboard
thực hiện cùng một mục tiêu, nhưng nó không thể pass ra xung quanh.
Screenshots từ ứng dụng hiện tại có thể hình thành cuộc thảo luận về làm thế
nào để thêm một chức năng mới và nó phù hợp với UI ở chỗ nào.
. Bạn có thể sử dụng các công cụ này trong các phương pháp phát triển khác.
Sự khác biệt lớn trong phát triển Agile là chúng ta tạo và thảo luận về mock-up
giống như bắt đầu viết mã. Chúng tôi tự tin rằng mock-up đại diện cho những gì
khách hàng mong muốn ngay từ bây giờ.
. Ví dụ, một mock-up mà nhóm Lisa sử dụng để giả lập một báo cáo mới - đơn

giản là đánh dấu lên một báo cáo tương tự, hiện có
. Mock-up không cần cầu kỳ hay đẹp, hoặc mất nhiều thời gian để tạo. Chúng
cần dễ hiểu với cả nhóm khách hàng và nhóm phát triển.
9.2.5. Flow Diagrams
. Simple diagramming tool hữu ích cho dù nhóm có cùng vị trí hay không. Nó là ý
tưởng tuyệt vời để nắm bắt một workflow hay một decision tree từ một cuộc thảo
luận. Flow diagrams có thể trở thành cơ sở của một kịch bản người dùng, giúp
bạn liên kết hai hay ba user story với nhau.
. Xem story bên dưới
. Hình dưới cho thấy một flowchart đơn giản của một quá trình ra quyết định, dù
đơn hàng của khách hàng có thể vận chuyển miễn phí dựa trên ngưỡng
(threshold) tiền đơn hàng. Bởi vì chúng tôi đã thảo luận story này với khách
hàng, chúng tôi phát hiện đơn hàng vượt quá ngưỡng tiền, và đã đề địa chỉ, cân
nặng ít hơn ngưỡng cân vận chuyển. Nếu các điều kiện được thỏa mãn, đơn
hàng sẽ được chuyển miễn phí; Nếu không, khách hàng sẽ phải lựa chọn từ
trang “Choose shipping options”.


. Flow diagram và mind maps là các cách tốt nhất để mô tả cái nhìn tổng quan về
chức năng của một story, đặc biệt chúng được vẽ bởi nhóm khách hàng, lập
trình viên và kiểm thử viên. Trong phát triển Agile, chúng tôi tạo các diagram khi
chúng tôi bắt đầu kiểm thử và viết mã nguồn. Từ đó, nhóm lập tức có thể bắt đầu
đi sâu vào yêu cầu chi tiết.
9.2.6. Software-Based Tools
. Nếu chúng ta ở vị trí khác so với khách hàng, chúng ta cần các công cụ giúp
chúng ta trò chuyện với họ. Nhóm phân phối (Distributed teams) cho chúng tôi
biết desktop là công cụ số một giúp họ xử lý với công việc tại các vị trí riêng biệt.
Windows NetMeeting và VNC là những ví dụ về công cụ cho phép hai thành viên
trong nhóm ở hai vị trí khác nhau có thể pair-test. Video conferencing tools như
WebEx và Skype cho phép cộng tác và demo giữa các đội từ xa và khách hàng.

Online whiteboards như Scriblink và các công cụ whiteboard tương tự như
Mimeo tạo điều kiện phân mối các cuộc thảo luận qua whiteboard.
. Nhiều công cụ được tạo ra để PO và business experts sử dụng trực tiếp, nhiều
nhóm phát triển công cụ của riêng họ. Các công cụ như Fit (Framework for
Integrated Tests) và FitNesse được thiết kế để tạo thuận lợi cho sự hợp tác và
liên lạc giữa khách hàng và nhóm phát triển. Chúng tôi nghe nhiều nhóm có
khách hàng đã thực sự viết các kiểm thử trên một công cụ.
. Một số nhóm xây dựng các khung làm việc (frameworks) riêng của họ, cho
phép khách hàng, business analyst, và kiểm thử viên ghi chép các ví dụ trực tiếp
để chuyển thành các kiểm thử thực thi. Chúng thường dựa vào các công cụ mã
nguồn mở như xUnit, Fit, Selenium, và Watir. Chúng tôi thích cách tiếp cận này,
vì chúng tiết kiệm thời gian và nguồn lực. Khi bạn cung cấp mã sản phẩm
(production-ready) trong lần lặp ngắn (short iteration), bạn cần một quá trình sắp
xếp hợp lý.
. Các công cụ diễn đàn trực tuyến (Online forum tool) là lựa chọn tốt để email
các cuộc thảo luận về tính năng hay kỹ thuật, đặc biệt với các nhóm không ngồi
với nhau. Các Email thường bị bỏ qua hoặc bị mất, mọi người nhớ chọn “Reply
all”, và nó có thể khó để cùng nhau đưa ra chi tiết cuộc thảo luận. Nhóm của Lisa
sử dụng online forum để khơi gợi ý kiến về các công cụ khác nhau, đề xuất hành
vi khác nhau cho các tính năng và tiến hành các cuộc thảo luận triết học như liệu
có theo dõi được các defects hay không.
. Việc tìm các công cụ điện tử thì đặc biệt quan trọng cho các nhóm phân tán. Tin
nhắn khẩn cấp, điện thoại, VoIP, và Skype giúp chúng ta giao tiếp, nhưng chúng
thiếu thành phần trực quan. Một số nhóm toàn cầu yêu cầu các thành viên của
họ đáp ứng giờ không chuẩn để họ có thể có các cuộc đối thoại thời gian thực,
nhưng frameworks cho việc giao tiếp bằng văn bản và hình ảnh vẫn còn quan
trọng.


. Wikis là một công cụ phổ biến được sử dụng để tăng cường giao tiếp và ghi lại

các cuộc thảo luận và quyết định. Wiki cho phép người dùng chỉnh sửa nội dung
trang web trong trình duyệt web. Người dùng có thể thêm hyperlinks (siêu liên
kết) và dễ dàng tạo các trong mới. Bạn có thể tải lên các mock-up, ví dụ, và hình
vẽ của whiteboard và làm cho chúng dễ dàng nhìn thấy trên trang Wiki. Tổ chức
phân cấp (hierarchical organization) có thể khó duy trì, nhưng có nhiều gói phần
mềm wiki mã nguồn mở và của nhà cung cấp có thể thực hiện việc quản lý kiến
thức cơ bản (knowledgebase) và thông tin chia sẻ của bạn dễ dàng hơn. Nếu
wiki knowledgebase đã tăng đến mức khó để tìm bất cứ điều gì, thuê một người
viết kỹ thuật để tổ chức và tài liệu hóa nó.
. Các công cụ mã nguồn mở và thương mại, cung cấp nhiều cách để các nhóm
hợp tác về yêu cầu và trường hợp kiểm thử trực tuyến. Chúng tôi không thể
nhấn mạnh đủ sự cần thiết để xác định các công cụ hữu ích, để thực nghiệm với
chúng trong vài iteration, và quyết định chúng làm việc với bạn như thế nào.
Nhóm của bạn cần thay đổi theo thời gian, vì vậy luôn luôn được mở để thử các
kỹ thuật và các khung làm việc mới.
. Những công cụ này giúp tạo cuộc đối thoại về story. Với những kỹ thuật đó, và
như nhiều cuộc đối thoại thời gian thực và chia sẻ hình ảnh mà chúng ta có thể
quản lý, chúng ta có thể xác định đúng sản phẩm ngay từ đầu.
9.3. Tools for Automating Tests Based on Examples
Những gì về các công cụ kiểm thử? Chúng tôi muốn hợp tác với các công cụ
như Fit và FitNesse. Tuy nhiên, theo ý kiến của chúng tôi, bất kỳ công cụ nào
giúp được kiểm thử viên và lập trình viên, lập trình viên và khách hàng, kiểm thử
viên và khách hàng nói chuyện với nhau đều tuyệt vời. Chúng tôi biết có nhóm
mà khách hàng thực sự viết kiểm thử trong Fit, FitNesse, Expect, hay các công
cụ khác. Việc này xảy ra khi công cụ đã được thiết lập theo cách rõ ràng để mọi
người có thể viết kiểm thử, với ngôn ngữ theo lĩnh vực dễ hiểu và các đồ nghề
(fixtures) phù hợp được cung cấp.
9.3.1. Tools to Test below the GUI and API Level
Có nhiều công cụ mã nguồn mở cho phép bạn kiểm thử bên dưới GUI hoặc ở
lớp API. Chúng tôi đã liệt kê một số, nhưng nhóm của bạn sẽ phải xác định công

cụ phù hợp.
a. Unit-Level Test Tools
. Một số nhóm sử dụng các công cụ xUnit như Junit hay Nunit cho businessfacing tests tốt như technology-facing tests. Nếu kiểm thử viên và khách hàng
cảm thấy thoải mái với những công cụ này, và họ cung cấp toàn bộ kiểm thử
chức năng bên dưới GUI, chúng thì tốt. Để làm cho các công cụ này thân thiện
hơn với khách hàng, các nhóm nên xây dựng một khung làm việc ở đầu các unitlevel tool mà kiểm thử viên và khách hàng có thể sử dụng để chỉ định các kiểm
thử.