Agile testing automation testing (phần 4)

Part IV - Automation
. Kiểm thử tự động là thực hành cốt lõi của Agile. Các dự án Agile phụ thuộc vào tự
động hóa.
. Nó cũng cung cấp khung làm việc giúp nhóm tối đa tốc độ phát triển nhưng vẫn đảm
bảo chất lượng sản phẩm.
. Kiểm thử tự động luôn đảm bảo độ tin cậy và tạo điều kiện để nhóm làm việc tốt nhất
có thể.

Chapter 13 - Why We Want to Automation Tests and What
Holds Us Back

13.1. Why Automate?
. Có nhiều lý do để tự động hóa để áp dụng Agile thành công:
• 1. Kiểm thử thủ công mất nhiều thời gian
• 2. Các quy trình thủ công dễ gây lỗi
• 3. Tự động hóa giúp bạn làm việc tốt nhất có thể
• 4. Kiểm thử hồi quy tự động cung cấp mạng lưới an toàn
• 5. Kiểm thử tự động cung cấp phản hồi sớm và thường xuyên
• 6. Các kiểm thử và ví dụ làm cho việc viết mã dễ dàng và nhiều hơn
• 7. Kiểm thử cung cấp tài liệu hướng dẫn
• 8. Tự động mang lại lợi nhuận

13.1.1. Manual testing takes too long
. Lý do cơ bản nhất mà nhóm muốn tự động hóa là kiểm thử thủ công chiếm nhiều thời
gian để hoàn thành. Khi ứng dụng lớn hơn, thời gian để kiểm thử tăng, có thể theo cấp
số nhân, phụ thuộc vào sự phức tạp của AUT (Application Under Test).
. Agile teams thường release sản phẩm vào cuối mỗi lần lặp, vì vậy việc chạy các kiểm
thử hồi quy là cần thiết. Nếu thực hiện kiểm thử hồi quy thủ công nó sẽ mất nhiều thời
gian, để kiểm thử kịp với việc viết mã, các lập trình viên phải giúp kiểm thử hoặc phải
thuê thêm kiểm thử viên. Chắc chắn nợ kỹ thuật và khả năng thất bại sẽ tăng lên.
. Nếu nhóm không thực hiện kiểm thử hồi quy mức đơn vị, kiểm thử viên sẽ mất nhiều

thời gian để nghiên cứu, tái hiện và báo cáo lỗi; nó làm giảm thời gian tìm lỗi nghiêm
trọng của hệ thống. Ngoài ra, nếu nhóm không thực hiện kiểm thử test-first, thiết kế mã
không được kiểm chứng và có thể không cung cấp các chức năng như mong muốn của
doanh nghiệp.
. Kiểm thử thủ công các kịch bản khác nhau có thể chiếm nhiều thời gian, đặc biệt là
giao diện người dùng. Thiết lập dữ liệu cho một chuỗi các kịch bản phức tạp là một việc
quá sức nếu không được tự động hóa. Nó có thể làm giới hạn kịch bản kiểm thử và
thiếu sót các defects.


13.1.2. Manual Processes Are Error Prone
. Kiểm thử thủ công được lặp đi lặp lại, làm cho kiểm thử viên dễ nhàm chán và dễ tạo
ra những sai lầm (mistakes) và bỏ qua lỗi đơn giản. Đặc biệt, nếu nhóm bị giới hạn về
thời gian, nó dễ gây áp lực và dẫn đến việc bỏ qua một số trường hợp kiểm thử.
. Tự động quá trình xây dựng, triển khai, kiểm soát phiên bản, giám sát cũng hướng tới
giảm thiểu rủi ro và làm cho quy trình phát triển nhất quán hơn. Các kiểm thử tự động
cũng giới hạn khả năng lỗi (errors), bởi mỗi kiểm thử sẽ được thực hiện chính xác theo
cùng một cách ở bất cứ thời điểm nào.
. Quy trình tự động xây dựng và triển khai cho phép bạn biết chính xác bạn đang kiểm
thử cái gì trên môi trường nào.

13.1.3. Automation Frees People to Do Their Best Work
. Viết mã test-first giúp lập trình viên hiểu được yêu cầu và thiết kế mã phù hợp. Tự
động kiểm thử đơn vị và kiểm thử hồi quy chức năng sẽ có nhiều thời gian để kiểm thử
thăm dò. Tự động hóa giúp bạn giảm thời gian thực hiện các kịch bản nhàm chán, tăng
thời gian để nghĩ về các kịch bản khác, học hỏi thêm về cách ứng dụng hoạt động, ….
. Tự động kiểm thử hồi quy giúp phát hiện ra những thay đổi đối với chức năng hiện tại
và cung cấp phản hồi ngay lập tức là mục tiêu chính của phần này.

13.1.4. Automated Regression Tests Provide a Safe Net

. Hầu hết những người có chuyên môn trong kinh doanh phần mềm đều cảm thấy sợ
hãi khi phải đối mặt với việc sửa lỗi, hay hoàn thành một tính năng mới với mã nguồn
được thiết kế nghèo nàn và không được bao phủ bởi các kiểm thử tự động.
. Nếu mã nguồn được bao phủ bởi các kiểm thử tự động sẽ giúp họ tự tin hơn. Chắc
chắn, sự thay đổi có thể tạo ảnh hưởng không mong muốn, nhưng nó sẽ bị phát hiện
trong vài phút nếu nó ở mức đơn vị, hoặc vài giờ nếu nó ở mức chức năng. Tạo thay đổi
ở test-first, có nghĩa thay đổi hành vi trước khi viết mã và viết kiểm thử để xác minh nó,
sẽ làm tăng niềm tin đó.
. Nhóm có bộ kiểm thử hồi quy tự động tốt sẽ không sợ việc thay đổi mã nguồn. Các
kiểm thử sẽ cho họ thấy bất cứ điều gì bị ảnh hưởng. Họ có thể đi nhanh hơn nhóm dựa
vào kiểm thử thủ công.

13.1.5. Automated Tests Give Feedback, Early, and Often
. Chạy kiểm thử tự động mỗi khi có mã nguồn mới giúp đảm bảo các lỗi (bugs) hồi quy
sẽ bị nắm bắt nhanh chóng.
. Nếu kiểm thử hồi quy không được tự động, nó sẽ không chạy ở mỗi lần lặp. Lỗi hồi
quy có thể xảy ra vào cuối sản phẩm, nhiều lợi ích từ việc kiểm thử sớm sẽ bị mất đi.
. Các kiểm thử tự động chạy thường xuyên và hoạt động như thiết bị phát hiện thay đổi.
Chúng cho biết những gì thay đổi kể từ lần build gần nhất. Nếu bộ tự động có đủ độ bao
phủ, nó sẽ dễ dàng nói ra những ảnh hưởng sâu rộng mà các kiểm thử viên không thể
tìm thấy.


13.1.6. Tests and Examples that Drive Coding Can Do More
. Trong chapter 7, “Technology-Facing Tests that Support the Team”, đã nói về việc sử
dụng kiểm thử và ví dụ để điều hướng việc viết mã. Cũng như đã đề cập đến tầm quan
trọng của việc điều hướng mã như thế nào đối với kiểm thử đơn vị và kiểm thử của
khách hàng. Cũng nhấn mạnh nếu kiểm thử đó được tự động, chúng trở nên có giá trị,
và trở thành cơ sở cho một bộ hồi quy vô cùng mạnh.
. TDD (Test-Driven Development hay Test-Driven Design) và SDD (Story test-Driven

Development) làm cho nhóm nghĩ về test-first. Họ thiết kế mã để các kiểm thử có thể
pass, vì vậy khả năng kiểm thử không bao giờ là vấn đề. Kiểm thử tự động phát triển
cùng với mã nguồn cơ bản, cung cấp mạng lưới an toàn cho việc cải tiến mã nguồn liên
tục. Quan trọng là toàn nhóm (Whole-team) thực hành TDD và luôn viết Unit test.
. Nợ kỹ thuật (Technical debt) giảm, tốc độ (velocity) ổn định và tăng theo thời gian là
một trong những lý do các nhà quản lý luôn vui vẻ để nhóm phần mềm dành thời gian
hoàn thành các thực hành một cách chính xác.

13.1.7. Tests Are Great Documentation
. Khi các kiểm thử minh họa ví dụ của hành vi mong muốn được tự động hóa, chúng trở
thành tài liệu “sống”, hướng dẫn hệ thống làm việc như thế nào.
. Khi hệ thống thay đổi, chúng ta cần cập nhật lại các kiểm thử tự động, nếu không
chúng sẽ bị fail. Điều này có nghĩa kiểm thử tự động luôn là bức tranh chính xác cho
thấy mã nguồn hiện tại làm việc như thế nào.

13.1.8. ROI and Payback
. Tự động có nghĩa thêm thời gian cho kiểm thử viên và các thành viên nhóm tập trung
vào việc tạo ra sản phẩm chất lượng ra ngoài thị trường một cách kịp thời.
. Khi các lập trình viên chạy kiểm thử tự động trong môi trường riêng của họ, các kiểm
thử hồi quy tự động tìm thấy lỗi trước khi mã nguồn được check-in, do đó có nhiều thời
gian để sửa chữa thiết kế. Đó là cách giảm nợ kỹ thuật và phát triển mã nguồn vững
chắc.

13.2. Barriers to Automation - Things that Get in the Way
. Vào năm 2001, Bret Pettichord đã liệt kê 7 vấn đề cản trở tự động hóa. Chúng vẫn
được áp dụng, nhưng dành cho nhóm không kết hợp tự động hóa vào quá trình phát
triển của họ.

13.2.1. Bret’s List
. Danh sách các vấn đề tự động của Bret như sau:

• Chỉ sử dụng thời gian rảnh để tự động hóa kiểm thử, không tập trung cần thiết.
• Thiếu mục tiêu rõ ràng.
• Thiếu kinh nghiệm.
• Có tốc độ thay thế cao, bởi bạn bị mất bất kỳ kinh nghiệm nào mà bạn có thể có.
• Phản ứng tiêu cực là nguyên nhân tại sao tự động hóa được chọn để mang lại
hy vọng hơn là đề nghị thực tế.


•
•

Miễn cưỡng nghĩ về kiểm thử trong tự động hóa.
Tập trung vào giải quyết vấn đề công nghệ có thể làm bạn mất khả năng quan
sát cho dù kết quả phù hợp với yêu cầu kiểm thử.

13.2.2. Our List
. Dựa vào kinh nghiệm làm việc với các nhóm Agile và các team khác:
• Thái độ của lập trình viên.
• “Hump of Pain” (Sự gồ ghề của nỗi đau)
• Đầu tư ban đầu.
• Mã nguồn luôn thay đổi.
• Hệ thống di sản.
• Sự sợ hãi.
• Thói quen cũ.

13.2.3. Programmers’ Attitude - “Why Automate?”
. Các lập trình viên làm việc trong môi trường truyền thống, có một số khác biệt, QA hầu
như thực hiện toàn bộ kiểm thử. Một số lập trình viên không quan tâm đến kiểm thử bởi
họ có nhóm QA bắt lỗi trước khi release. Theo thời gian, kiểm thử viên làm công việc
của họ, lập trình viên sẽ chuyển sang release tiếp theo. Các defects đưa vào hàng đợi

để sửa chữa với chi phí rất lớn, và không ai chịu trách nhiệm tạo ra chúng.
. Ngay cả các lập trình viên đã thực hiện TDD (Test-Driven Development) và tự động
kiểm thử đơn vị vẫn không nghĩ cách kiểm thử chấp nhận.
. Giáo dục là chìa khóa để các lập trình viên và nhóm hiểu được tầm quan trọng của tự
động hóa.

13.2.4. The “Hump of Pain” (The Learning Curve)
. Thật khó để học kiểm thử tự động, đặc biệt học như thế nào để tạo ra lợi nhuận tốt về
đầu tư nguồn lực. Brian Marick sử dụng một giới hạn để mô tả giai đoạn đầu của tự
động hóa và các lập trình viên (và kiểm thử viên) phải vượt qua “Hump of Pain” khi áp
dụng tự động hóa.
. Các nhóm mới thường dự kiến áp dụng TDD và Refactoring, những kỹ thuật khó để
tìm hiểu. Nếu không có huấn luyện tốt, sẽ mất nhiều thời gian để làm chủ kỹ năng mới
và hỗ trợ quản lý, họ dễ bị nản lòng. Nếu họ có thêm trở ngại khi tìm hiểu, như phải làm
việc với thiết kế nghèo nàn từ mã nguồn cũ, thì khó có thể kéo họ về kiểm thử tự động.
. “Hump of Pain” xảy ra bởi bạn đang xây dựng khung kiểm thử dựa trên miền xác định
hay học công cụ kiểm thử chức năng mới. Bạn có thể nhờ một chuyên gia giúp bạn thiết
lập.
. Nếu team bạn không dễ dàng vượt qua “Hump”, ít nhất phải có quy trình tự nhiên và
ngấm vào từng người trong nhóm.


13.2.5. Initial Investment
. Tự động hóa đòi hỏi một sự đầu tư lớn. Nó mất thời gian và nghiên cứu để quyết định
khung kiểm thử được sử dụng và liệu tự xây dựng hay sử dụng công cụ sản xuất bên
ngoài. Phần cứng và mềm mới có thể được yêu cầu. Các thành viên trong nhóm mất
một khoảng thời gian để học cách sử dụng.
. Nếu tổ chức có người có kinh nghiệm về kiểm thử tự động, tổ chức chỉ trả tiền cho nhà
cung cấp công cụ capture-playback, đưa cho nó cho nhóm QA và mong nó giải quyết
toàn bộ vấn đề tự động hóa. Nhưng những kinh nghiệm ít ỏi có thể tạo ra các kiểm thử

khó hiểu, khó bảo trì và không hữu dụng lâu dài. Vì vậy, nhóm với đào tạo và kỹ năng
đầy đủ sẽ mang lại lợi nhuận đầu tư tự động hóa.
. Thiết kế kiểm thử đơn giản, tốt, liên tục được tái cấu trúc, các kiểm thử có khả năng
duy trì. Thư viện các module kiểm thử và đối tượng kiểm thử được xây dựng theo thời
gian và tạo các kiểm thử mới nhanh hơn.
. Tuy nhiên, không phải dễ dàng để nắm bắt số liệu. Như, thời gian để viết và duy trì các
kiểm thử tự động so với thời gian chạy kiểm thử hồi quy thủ công. Tương tự, chi phí để
sửa chữa defects trong vài phút phát hiện so với chi phí để tìm và sửa chữa sau khi kết
thúc quy trình cũng khá khó. Nếu không có các con số chứng minh tự động cần ít nguồn
lực hơn và cung cấp nhiều giá trị hơn, nhóm sẽ khó có thể thuyết phục quản lý đầu tư
vào tự động hóa, và khó để thay đổi thói quen của nhóm.

13.2.6. Code that’s Always in Flux
. Các kiểm thử tự động thông qua giao diện người dùng thì khó, bởi UI thường thay đổi
liên tục trong quá trình phát triển. Nó cũng là lý do mà kỹ thuật record và playback không
phải là lựa chọn tốt cho một dự án Agile.
. Nếu nhóm khó để tạo thiết kế tốt về logic nghiệp vụ, truy cập cơ sở dữ liệu, và thường
xuyên làm lại. Nó khó có thể kiểm thử tự động sau GUI ở mức API. Trong trường hợp
này, lập trình viên và kiểm thử viên cần làm việc với nhau để có được một ứng dụng có
thể kiểm thử.
. Mặc dù mã nguồn và thực hiện thực tế có xu hướng thay đổi liên tục trong phát triển
Agile, nhưng mục đích của mã nguồn hiếm khi thay đổi. Tổ chức mã kiểm thử bằng mục
đích của ứng dụng, cho phép bạn theo kịp với sự phát triển.

13.2.7. Legacy Code
. Viết một vài kiểm thử cho mã nguồn hiện tại hoặc không có kiểm thử là một công việc
khó khăn. Nó hầu như không thể với một nhóm mới với Agile và kiểm thử tự động.
. Nếu bạn muốn tự động các kiểm thử, bạn phải tái cấu trúc một số legacy code, nhưng
legacy code không được thiết kế cho khả năng kiểm thử, vì vậy nó khó có thể tự động
kiểm thử ngay cả mức đơn vị.

13.2.8. Fear
. Kiểm thử tự động thực sự khó với ai chưa bao giờ làm chủ nó, kể cả người đã từng sử
dụng. Các lập trình viên có thể viết mã sản phẩm tốt, nhưng họ không có nhiều kinh
nghiệm khi viết các kiểm thử tự động. Các kiểm thử viên thì không có nền tảng lập trình


tốt, họ không tin vào kỹ năng về kiểm thử tự động của họ.
. Kiểm thử viên không có kinh nghiệm lập trình thường nhận được thông điệp rằng họ
không có gì để làm trong thế giới Agile. Nhưng không lập trình viên nào cần lo lắng về
làm thế nào để tự động hóa. Nó là vấn đề của nhóm, và thường lập trình viên có thể
giúp đỡ họ về mặt lập trình.

13.2.9. Old Habits
. Khi các lần lặp (iterations) không tiến hành thuận lợi, nhóm không thể hoàn thành toàn
bộ công việc lập trình và kiểm thử vào cuối lần lặp, các thành viên nhóm rơi vào trạng
thái hoảng sợ. Khi họ rơi vào trạng thái này, họ dễ quay về thói quen cũ, kể cả những
thói quen này không mang lại kết quả tốt.
. Đây là con đường đi đến diệt vong. Một số kiểm thử thủ công có thể hoàn thành và tìm
ra lỗi nhưng chi phí công ty tăng lên đến hàng ngàn đô la. Nếu công việc kiểm thử
không thể kết thúc, chúng sẽ được chuyển sang lần lặp tiếp theo, làm giảm giá trị kinh
doanh mang lại. Nếu lặp đi lặp lại, trạng thái này tiếp tục xấu đi sau đó.

13.3. Can we Overcome These Barriers?
. Phương pháp tiếp cận toàn team (Whole-team) là nền tảng để vượt qua thử thách tự
động hóa. Các lập trình viên mới với Agile có thể cung cấp mã nguồn, cho dù có lỗi hay
không, miễn họ đúng hạn. TDD (Test-Driven Development) định hướng thiết kế hơn là
kiểm thử, vì vậy kiểm thử business-facing phải phụ thuộc vào ý thức họ.
. Nó là khả năng lãnh đạo (Leadership) và cam kết (commitment) của nhóm về chất
lượng để mọi người phải ý thức được việc phải viết, sử dụng và chạy các kiểm thử

technology-facing và business-facing.
. Bắt toàn bộ nhóm tham gia vào quá trình kiểm thử tự động là một thách thức về văn
hóa.

Summary
. Trong chương này, chúng ta đã tóm lược toàn bộ các tác nhân liên quan đến tự động
kiểm thử:
• Chúng ta cần tự động để cung cấp mạng lưới an toàn, cung cấp phản hồi cần
thiết, tối thiểu hóa nợ kỹ thuật và giúp điều hướng việc viết mã.
• Sự sợ hãi, thiếu kinh nghiệm, kinh nghiệm tiêu cực trong quá khứ với tự động
hóa, tốc độ thay đổi mã nguồn và mã di sản là những cản trở đối với tự động
hóa.
• Tự động hóa các kiểm thử hồi quy, chạy chúng trong quy trình build tự động và
sửa các nguyên nhân gốc của defects làm giảm nợ kỹ thuật và tăng trưởng mã
vững chắc.
• Tự động hóa các kiểm thử hồi quy và các việc thủ công nhàm chán giải phóng
nhóm cho việc quan trọng hơn, như kiểm thử thăm dò.
• Nhóm với các kiểm thử tự động và quy trình build tự động làm cho vận tốc ổn
định hơn
• Không có kiểm thử hồi quy tự động, kiểm thử hồi quy thủ công sẽ tiếp tục phát


•

triển trong phạm vi và cuối cùng chỉ đơn giản có thể được bỏ qua.
Văn hóa của nhóm và lịch sử có thể làm cho nó khó khăn đối với lập trình viên
để ưu tiên tự động hóa cho kiểm thử business-facing hơn là viết mã cho các tính
năng mới. Sử dụng các nguyên tắc và giá trị Agile giúp toàn nhóm vượt qua các
rào cản đối với kiểm thử tự động.

Chapter 14 - An Agile Test Automation Strategy
. Chương này giải thích làm thế nào để ứng dụng các giá trị và nguyên tắc Agile vào
việc sử dụng và cải tiến năng lực tự động hóa.

14.1. An Agile Approach to Test Automation
14.1.1. Automation Test Categories
. Trong phần Agile Testing Quadrants, đã nói về mỗi quadrant và mục tiêu kiểm thử của
mỗi phần đó. Giờ chúng ta đi tìm hiểu khía cạnh khác của nó.
. Với 2 góc phần tư Q1, Q2 đã được dán nhãn có sử dụng tự động hóa. Với Q4, các
công cụ được sử dụng để tìm nhược điểm sản phẩm từ góc nhìn kỹ thuật, nó thường
yêu cầu các công cụ tự động hóa. Trong thực tế, Q3 không cần sử dụng tự động hóa;
Tuy nhiên, các công cụ có thể hữu dụng trong một số trường hợp, như, tự động giúp
thiết lập dữ liệu kiểm thử, kịch bản người dùng, phân thích hoạt động đăng nhập.
. Sử dụng các góc phần tư giúp xác định các loại công cụ tự động hóa cần thiết trong
mỗi dự án hay mỗi lần lặp.
. Thứ tự các góc không liên quan đến thứ tự kiểm thử. Tạo checklist các công cụ cần
thiết cho mỗi loại kiểm thử, chúng ta sẽ biết khi nào công cụ tự động hóa sẵn sàng.
. Các góc phần tư giúp chúng ta tìm ra các công cụ cần thiết, nhưng với lựa chọn tự
động hóa ở các mức khác nhau, chiến lược thực hiện và tổ chức kiểm thử sẽ khác
nhau, Kim tự tháp kiểm thử giúp tối ưu hóa năng lực kiểm thử.

14.1.2. Test Automation Pyramid
. Kim tự tháp kiểm thử tự động Agile cho thấy 3 lớp khác nhau của kiểm thử tự động.
• Lớp thấp nhất là nền tảng hỗ trợ toàn bộ phần còn lại.
• Nó chủ yếu tạo các kiểm thử đơn vị mạnh mẽ và các kiểm thử thành phần, kiểm
thử technology-facing hỗ trợ nhóm.
• Lớp này đại diện số lượng lớn các kiểm thử được tự động hóa.
• Chúng được viết cùng một ngôn ngữ với hệ thống, sử dụng công cụ thuộc gia
đình xUnit.
• Sau khi nhóm làm chủ được công nghệ TDD, các kiểm thử sẽ được tạo ra nhanh

nhất và ít tốn kém nhất. Chúng cũng cung cấp phản hồi nhanh nhất, làm cho
chúng có giá trị cao. Chúng có ROI lớn nhất so với bất kỳ loại kiểm thử nào.


•
•

•
•
•
•

•
•
•
•
•

Lớp ở giữa kim tự tháp
Nó gồm hầu hết các kiểm thử business-facing, được viết để hỗ trợ nhóm. Các
kiểm thử ở lớp này có thể bao gồm kiểm thử ‘Story’, kiểm thử chấp nhận, và các
kiểm thử bao trùm tập chức năng lớn hơn lớp kiểm thử đơn vị. Những kiểm thử
này hoạt động ở lớp API hoặc “Bên dưới GUI”, kiểm thử chức năng trực tiếp mà
không thông qua GUI.
Chúng viết các trường hợp kiểm thử, bao gồm thiết lập các đầu vào cho mã sản
phẩm, chấp nhận kết quả đầu ra, và so sánh kết quả mong đợi.
Vì các kiểm thử này bỏ qua lớp trình bày, nên chúng ít tốn kém để viết và duy trì
hơn các kiểm thử sử dụng GUI.
Cố gắng viết các kiểm thử theo ngôn ngữ xác định để khách hàng có thể hiểu
được.

Chúng chạy chậm hơn, bởi mỗi kiểm thử đảm bảo hơn một kiểm thử đơn vị và
có thể phải truy cập dữ liệu hoặc các thành phần khác. Phản hồi không nhanh
như kiểm thử đơn vị nhưng nhanh hơn kiểm thử qua GUI. Do đó, GUI của chúng
không cao như kiểm thử hình thành ở lớp cơ bản nhưng cao hơn lớp đỉnh của
kim tự tháp.
Lớp trên cùng đại diện cho năng lực tự động hóa nhỏ nhất, bởi chúng cung cấp
ROI thấp nhất.
Những kiểm thử này được thực hiện thông qua GUI. Chúng được viết sau khi
mã nguồn được hoàn thành và nhằm mục đích tìm ra nhược điểm của sản
phẩm, chúng được thêm trực tiếp vào bộ kiểm thử hồi quy.
Những kiểm thử này thường mất nhiều chi phí để viết, mặc dù có nhiều công cụ
mới giúp giảm thiểu đầu tư cần thiết. Bởi các thành phần giao diện hay bị thay
đổi, các kiểm thử dễ bị lỗi hơn các kiểm thử mức chức năng và đơn vị.
Các kiểm thử này cung cấp phản hồi quan trọng, nhưng bộ kiểm thử GUI có thể
chiếm nhiều giờ để chạy hơn là vài phút chạy bộ kiểm thử đơn vị.
Không vấn đề bao nhiêu kiểm thử được tự động hóa, hầu hết các hệ thống đều
cần các hoạt động kiểm thử thủ công, như kiểm thử thăm dò và kiểm thử chấp
nhận.

. Hầu hết các nhóm Agile mới thường bắt đầu ngược với kim tự tháp.
• Các công cụ kiểm thử GUI thường dễ học, vì vậy nhóm bắt đầu với kiểm thử ở
lớp trên cùng.
• Nếu hệ thống được thiết kế điều hướng kiểm thử, các kiểm thử chức năng ở lớp
giữa sẽ dễ dàng để viết.
• Là một nhóm có thể làm chủ TDD và kiểm thử tự động đơn vị, lớp dưới bắt đầu
phát triển. Khi chúng nhận được lực đẩy, một nhóm sử dụng TDD nhanh chóng
xây dựng các kiểm thử ở lớp thấp nhất của kim tự tháp.
. Kim tự tháp kiểm thử là nơi tốt nhất để bắt đầu tìm hiểu kiểm thử tự động có thể giúp
Agile team như thế nào.
• Các lập trình viên có xu hướng tập trung vào đáy của kim tự tháp, họ cần nhiều

thời gian, đào tạo để vượt qua “hump of pain” và tiếp nhận TDD một cách tự
nhiên và nhanh chóng. Phương pháp toàn nhóm (Whole-team) được sử dụng
bởi Agile team cho phép các kiểm thử viên ghép với lập trình viên để giúp họ


•
•

thực hiện kiểm thử tốt hơn, từ đó củng cố thêm lớp đáy của kim tự tháp. Vì phát
triển điều hướng kiểm thử, toàn bộ nhóm luôn thiết kế tối đa khả năng kiểm thử
và kim tự tháp có thể phát triển đúng hình dạng.
Các lập trình viên làm cặp với kiểm thử viên để tự động hóa kiểm thử chức
năng, làm đầy lớp giữa kim tự tháp.
Các lập trình viên tìm cách giảm chi phí tự động hóa kiểm thử GUI lớp trên cùng
cũng có nhiều lợi ích, lập trình viên hiểu hơn về “bức tranh lớn” của hệ thống và
kiểm thử viên học được cách tạo sự mềm dẻo và ít kiểm thử GUI hơn.

14.2. What Can We Automate?
14.2.1. Continuous Integration, Builds, and Deploys
. Bất kỳ công việc tẻ nhạt và lặp đi lặp lại liên quan đến phát triển phần mềm đều có thể
tự động hóa.
. Nói về tầm quan trọng của quá trình build tự động.
• Bạn không thể xây kim tự tháp kiểm thử tự động mà không có điều này. Nhóm
cần có phản hồi ngay lập tức từ các kiểm thử đơn vị để tiếp tục theo dõi lên các
lớp trên.
• Mail từ quá trình build tự động thông báo thay đổi được check-in giúp kiểm thử
viên biết được khi nào một build sẵn sàng cho việc kiểm thử.
. Quá trình triển khai tự động cũng làm tăng tốc kiểm thử và giảm thiểu lỗi.
• Trong thực tế, ngày Janet chỉnh sửa chương này, cô sai lầm trong việc triển khai
bởi nó là quá trình thủ công. Nó khá đơn giản, nhưng cô ấy mới vào dự án và

chuyển nhầm tập tin đến chỗ sai. Một quá trình triển khai tự động sẽ thực hiện
những việc cần thiết ngay tại chỗ của Janet. Nhóm của Lisa đã tích hợp thành
công nó vào khung làm việc và thấy nó khá dễ dàng và mất ít thời gian, mặc dù
nó cần bảo dưỡng và nâng cấp liên tục.
. Hầu hết các Agile team thấy một build kéo dài lâu hơn 8-10 phút thì không khả thi.
Ngay cả 15 phút cũng quá dài để chờ phản hồi, bởi các check-in sẽ xếp chồng lên và
kiểm thử viên phải chờ một thời gian dài để nhận bản build gần nhất, tốt nhất. Các build
dài có thể do việc truy cập cơ sở dữ liệu hoặc cố gắng kiểm thử GUI. Trong trường hợp
này,
• Hãy cố gắng sao chép cơ sở dữ liệu thật và sử dụng bộ nhớ trong thay thế.
• Hoặc cấu hình quy trình build để phân phối các kiểm thử trên một vài máy.
• Hoặc tìm phần mềm khác để quản lý tài nguyên tốt hơn.
• Hoặc nhờ sự giúp đỡ các các chuyên gia bên ngoài.
. Chìa khó để tăng tốc độ tích hợp liên tục và quá trình build là thực hiện từng bước nhỏ
ở một thời điểm. Nó sẽ đưa ra các thay đổi tại mỗi thời điểm, bạn có thể đo lường được
thành công và biết bạn đi đúng hướng hay không. Lúc bắt đầu, có thể bạn muốn loại bỏ
những kiểm thử tốn kém khỏi các bản build để chạy nó vào ban đêm.
. Tích hợp liên tục và quá trình build chạy nhanh mang lại ROI lớn nhất của bất kỳ năng
lực kiểm thử tự động nào. Nó là thứ đầu tiên mà mỗi team cần phải tự động.


14.2.2. Unit and Component Tests
. Chúng tôi không thể nhấn mạnh quá mức vào tầm quan trọng của việc tự động hóa
kiểm thử đơn vị. Nếu lập trình viên đang sử dụng TDD như một tổ chức để viết các kiểm
thử của họ, họ không chỉ tạo ra một bộ hồi quy lớn, mà còn sử dụng chúng để thiết kế
mã nguồn chất lượng cao, mạnh mẽ. Nếu nhóm không tự động kiểm thử, cơ hội thành
công lâu dài rất mong manh. Tạo tự động kiểm thử đơn vị và tích hợp liên tục là ưu tiên
hàng đầu.

14.2.3. API or Web Services Testing

. Kiểm thử API hay ứng dụng Web Services dễ dàng nhất là sử dụng một số mẫu tự
động hóa.
• Janet đã trưởng thành trong team và có thành công trong việc sử dụng Ruby để
đọc bảng tính với tất cả hoán vị và sự hợp tác của các biến đầu vào, so sách
đầu vào với kết quả mong muốn được lưu trữ trong bảng tính. Các kiểm thử điều
hướng dữ liệu này dễ dàng để viết và bảo trì.
• Một khách hàng của Janet sử dụng chức năng IRB (Interactive Ruby Shell) của
Ruby để kiểm thử Web Services cho phần nghiệm thu. Nhóm chia sẻ các kịch
bản với khách hàng, nhưng các kiểm thử viên nghiệp vụ thích nhìn thấy những
gì xảy ra nếu đầu vào bị thay đổi. Chạy kiểm thử theo phương pháp bán tự động
(semi-automated) cho phép điều đó xảy ra.

14.2.4. Testing behind the GUI
. Kiểm thử bên dưới GUI thì dễ dàng tự động hơn kiểm thử GUI. Bởi các kiểm thử
không chịu ảnh hưởng bởi sự thay đổi của lớp trình bày và nó làm việc dựa trên mã
nguồn logic nghiệp vụ ổn định hơn.
. Các công cụ sử dụng cho kiểm thử này thường theo định dạng khai báo, bảng hoặc
bảng tính.
. Các thiết bị lấy mã sản phẩm để thực hiện các đầu vào kiểm thử và trả về kết quả
được viết nhanh chóng.
. Nó được viết chính cho kiểm thử business-facing, dễ hiểu với cả hai khách hàng và lập
trình viên.

14.2.5. Testing the GUI
. Một GUI với một chút hoặc không có logic nghiệp vụ vẫn phải kiểm thử. Trong phát
triển Agile, chức năng mới được cung cấp ở mỗi lần lặp, do đó cần một số kiểm thử hồi
quy tự động mức GUI trong hầu hết các dự án.
. Lựa chọn công cụ là chìa khóa thành công của tự động GUI.
• Các kịch bản tự động cần sự mềm dẻo và dễ dàng để bảo trì.
• Cần thời gian để phát triển các thư viện, để các kiểm thử tự động không phải

làm lại hoặc lặp lại mã nguồn. Khi thay đổi xảy ra, chỉ việc sửa đổi ở một nơi.
Làm cho mã nguồn dễ dàng bảo trì và làm tăng ROI.


. Một điểm về khả năng kiểm thử ở đây, chắc chắn lập trình viên đặt tên đối tượng của
họ và gán ID cho chúng. Nếu họ dựa vào hệ thống tự động tạo ra các định danh, thì mỗi
khi một đối tượng được thêm vào trang, ID sẽ thay đổi, đòi hỏi thay đổi đối với các kiểm
thử.
. Tự động những kiểm thử đơn giản đầu tiên, đừng cố gắng kiểm thử chức năng nghiệp
vụ, nên dành nhiều thời gian cho các thử thách lớn hơn.

14.2.6. Load Tests
. Một số kiểu kiểm thử không thể thực hiện được mà không có tự động hóa. Manual
load tests không thể làm được hoặc không chính xác, mặc dù chúng tôi đã cố gắng thực
hiện cùng một lúc kịch bản kiểm thử. Bạn không thể tạo một cuộc tấn công số lượng lớn
để xác định website có bị hack hay không, hoặc xử lý một lượng tải lớn mà không có
khung công cụ nào.

14.2.7. Comparisons
. Kiểm tra một tập tin đầu ra ASCII từ một quy trình hệ thống thì dễ dàng nếu bạn phân
tích tập tin và hiển thị nó theo định dạng có thể đọc được.
. Một kịch bản so sách các tập tin đầu ra để đảm bảo không có các thay đổi chủ ý được
thực hiện nhanh hơn và chính xác hơn so với so sánh thủ công.
. Các công cụ so sách tập tin rất nhiều, từ miễn phí đến độc quyền như WinDiff. Các
công cụ quản lý mã nguồn và IDEs đều có các công cụ so sánh riêng của họ.
. Đừng quên việc tạo kịch bản so sánh các bảng cơ sở dữ liệu khi kiểm thử kho dữ liệu
hay các dự án di chuyển dữ liệu.

14.2.8. Repetitive Tasks
. Khi làm việc với khách hàng để hiểu nghiệp vụ tốt hơn và nghiên cứu các giá trị từ họ,

chúng ta có thể thấy các cơ hội để tự động một số công việc của họ.
• Công ty Lisa cần một vài mẫu mail với phong bì thư đến toàn bộ khách hàng của
họ. Lập trình viên không thể tạo mẫu mail, nhưng họ có thể ghép chúng với
phong bì thư và đẩy nhanh tốc độ gửi thư.
• Kiểm thử viên đồng nghiệp của Lisa, Mike Busse, đã viết một spreadsheet macro
để thực hiện các tính toán phức tạp cho việc phân bổ nguồn vốn mà các nhà
quản trị trước đó đã thực hiện thủ công.
• Nhiều checklist thủ công cũng có thể được thay thế bởi một kịch bản tự động.
. Tự động hóa không chỉ để cho kiểm thử.

14.2.9. Data Creation or Setup
. Tự động hóa còn giúp tạo và thiết lập dữ liệu. Nếu bạn liên tục thiết lập dữ liệu, hãy tự
động quá trình này. Nếu bạn cần lặp lại cái gì đó để tái hiện lỗi nhiều lần, nếu có thể tự
động hóa, bạn sẽ thu được kết quả tương đồng sau mỗi lần chạy.
. Làm sạch dữ liệu cũng quan trọng như khi tạo ra nó. Bộ công cụ tạo dữ liệu bao gồm
cả cách gỡ bỏ dữ liệu kiểm thử, vì vậy nó không ảnh hưởng đến kiểm thử khác hay


ngăn việc chạy lại kiểm thử.

14.3. What Shouldn’t We Automate?
. Một số kiểm thử cần ánh mắt, tai nghe và trí thông minh của con người. Usability và
Exploratory Testing là hai loại đó.
. Những kiểm thử không cần đầu tư tự động hóa như kiểm thử một lần hoặc không bao
giờ lỗi.

14.3.1. Usability Testing
. Usability Testing đòi hỏi một người nào đó sử dụng thực sự phần mềm. Tự động hóa
chỉ hữu dụng trong việc thiết lập các kịch bản kiểm thử.
. Quan sát người sử dụng hoạt động, thẩm vấn kinh nghiệm của họ và đánh giá các kết

quả là công việc không thể tự động hóa được.
. Nó có thể tự động nếu đảm bảo GUI không bao giờ thay đổi. Nhưng tự động hóa sẽ bỏ
lỡ một vài vấn đề trực quan ngoài khả năng của con người.

14.3.2. Exploratory Testing
. Tương tự như vậy, Exploratory Testing có thể tăng tốc với các kịch bản tạo dữ liệu
kiểm thử, và bỏ qua một số bước thiết lập, nhưng nó yêu cầu một kiểm thử viên có kỹ
năng thiết kế và thực thi kiểm thử.
. Mục tiêu chính của Exploratory Testing là tìm hiểu thêm về sản phẩm làm ra và sau đó
sử dụng thông tin đó để cải tiến, phát triển trong tương lai. Những kịch bản tự động hóa
không thể làm điều này. Tuy nhiên, tự động hóa các kiểm thử khác sẽ tạo điều kiện và
thời gian để thực hiện Exploratory Testing.

14.3.3. Tests that Will Never Fail
. Có một lập luận rằng, các kiểm thử không bao giờ lỗi thì không cần kiểm thử tự động.
. Nếu có một yêu cầu rõ ràng thì chỉ có một cách để hoàn thành có, các lập trình viên sẽ
luôn biết chính xác nó sẽ làm gì, cơ hội tìm ra defects là rất khó.
. Nếu bạn đang kiểm thử hệ thống quan trọng sống còn, thậm chí một nguy cơ nhỏ của
lỗi hồi quy cũng là quá nhiều. Sử dụng phân tích rủi ro để giúp bạn quyết định có nên tự
động hóa các kiểm thử hay không.

14.3.4. One-Off Tests
. Thường kiểm thử thủ công cho các kiểm thử một lần là đủ. Đôi khi tự động hóa có giá
trị thực hiện cho kiểm thử một lần. Các việc tẻ nhạt có giá trị tự động hóa, ngay cả khi
không làm nó thường xuyên.
. Hãy cân nhắc chi phí tự động hóa đối với thời gian đã mất bởi kiểm thử thủ công. Nếu
nó dễ dàng để thực hiện thủ công và tự động hóa không nhanh, thì nên giữ nó thủ công.


14.4. What Might Be Hard to Automate?

. Khi mã nguồn không viết test-first, hoặc không được suy nghĩ về tự động kiểm thử, nó
sẽ khó để tự động hóa.
. Legacy code có thể có I/O, truy cập cơ sở dữ liệu, cũng như logic nghiệm vụ và
presentation code đan xen vào nhau. Nó có thể không rõ ràng để lấy mã nguồn để tự
động hóa kiểm thử. Chắc chắn bạn không thể lên kế hoạch tự động mọi thứ bên dưới
GUI, bởi có quá nhiều logic ở presentation layer.
. Có một số phương pháp tiếp cận khác nhau để khắc phục nó, và sau đó kiểm thử tự
động sẽ trở nên dễ dàng
• “Làm việc hiệu quả với Legacy code [2004] của Michael Feathers giải thích làm
thế nào để xây dựng khung kiểm thử trên cơ sở mã nguồn hiện tại và tái cấu trúc
chúng để thích hợp với tự động hóa. Với Legacy code, bạn có thể viết kiểm thử
để tránh những vấn đề mới phát sinh. Cách tiếp cận này có thể làm việc ngay cả
với hệ thống thiếu cấu trúc hoặc không hướng đối tượng.
• Nhóm của Lisa có cách tiếp cận khác nhưng hiệu quả. Các thành viên của nhóm
bắt đầu “bóp nghẹt - Strangling” Legacy code bằng cách viết toàn bộ tính năng
mới với kiến trúc thân thiện với kiểm thử. Họ dần thay thế toàn bộ mã cũ bằng
mã đã viết test-first. Khi họ làm việc với mã cũ để sửa lỗi, hoặc cần cập nhật,
đơn giản họ thêm vào các kiểm thử đơn vị cho toàn bộ mã nguồn mà họ đã thay
đổi. Một GUI smoke test cho các chức năng quan trọng của Legacy system
không có kiểm thử đơn vị.

14.5. Developing an Automation Strategy - Where Do We Start?
. Đơn giản, tiếp cận từng bước một thích hợp với chiến lược tự động hóa. Nhưng trong
Agile Testing, quyết định bắt đầu tự động từ đâu và như thế nào đòi hỏi suy nghĩ và thảo
luận toàn nhóm. Khi nhóm nhìn vào các thách thức kiểm thử, bạn sẽ phải xem xét tự
động hóa ở đâu cho phù hợp. Trước khi bạn tìm kiếm công cụ tự động cụ thể, bạn nên
xác định nhu cầu của nhóm.
• Nếu bắt đầu từ đầu, hãy tìm kiếm lợi ích lớn nhất. Cú đánh lớn nhất vào vấn đề
là xác định các kiểm thử đơn vị mà các lập trình viên có thể thực hiện. Thay vì
bắt đầu từ đỉnh kim tự tháp kiểm thử, bạn có thể bắt đầu từ đáy, đảm bảo các

vấn đề cơ bản được đưa ra. Bạn cũng cần xem xét các loại kiểm thử khác mà
bạn cần kiểm thử và sau đó bạn sẽ cần một số công cụ để sử dụng.
• Giả định, bạn tự động kiểm thử đơn vị và thành phần ở Q1, và tìm kiếm tự tự
động Business-facing tests ở Q2,3, hoặc technology-facing tests ở Q4.
• Nghĩ về các kỹ năng và kinh nghiệm của nhóm. Ai cần tự động hóa và tại sao?
Mục tiêu đạt được là gì? Hiểu được một số vấn đề có thể ảnh hưởng đến lựa
chọn công cụ và nỗ lực bỏ ra. Đánh giá công cụ đã lựa chọn.

14.5.1. Where Does It Hurt the Most?
. Để tìm nơi tập trung nguồn lực tự động, hãy hỏi nhóm “Chỗ khó khăn nhất là gì?” hoặc
“Chỗ nhàm chán nhất là gì?”, bạn có phải viết mã để triển khai kiểm thử nó không? các
thành viên nhóm có tự tin với việc thay đổi mã nguồn không? họ có mạng lưới an toàn
nào không?


. Chỗ nào khó khăn nhất cũng là nơi để bắt đầu tự động hóa.
• Nếu nhóm đang vật lộn với việc phân phối mã, bạn cần thực hiện quy trình build
tự động.
• Nếu hiệu năng làm cho sự tồn tại của tổ chức bị nguy hiểm, kiểm thử hiệu năng
cần được ưu tiên hàng đầu
. Kiểm thử tự động sẽ tuyệt vời nếu nó được phát triển ở đúng nơi.
• Tính hợp liên tục chạy một bộ kiểm thử đơn vị là bước đầu hướng tới tự động
các kiểm thử khác. mã nguồn tái cấu trúc liên tục để bảo trì và thiết kế tốt sẽ giúp
ROI của tự động hóa tăng. Tái cấu trúc không thể thực hiện nếu không có kiểm
thử đơn vị tốt.
• Những thực hành phát triển này cũng nên áp dụng cho các kịch bản kiểm thử
chức năng tự động.

14.5.2. Multi-Layered Approach
. Sử dụng công cụ thích hợp cho mỗi loại yêu cầu.

• Công cụ làm việc tốt nhất cho kiểm thử đơn vị, có thể hoặc không phù hợp với
kiểm thử chức năng.
• Kiểm thử GUI, Load, Performance, Security có thể yêu cầu một công cụ, hoặc
các công cụ khác nhau.
. Nội dung kim tự tháp của Mike Cohn giúp nhóm đặt nguồn lực tự động vào đúng nơi
họ thực hiện tốt nhất. Tối đa hóa kiểm thử để thu ROI tốt nhất. Nếu kiến trúc hệ thống
được thiết kế cho khả năng kiểm thử thì kiểm thử tự động sẽ ít tốn kém và đặc biệt ở
lớp đơn vị.
• Các kiểm thử GUI thường có ROI thấp nhất, nhưng vẫn phải thực hiện chúng.
Hãy lựa chọn một số kiểm thử đơn giản để thực hiện trước nhất, những kiểm
thử GUI còn lại tốt nhất là kiểm thử dựa vào tương tác của con người (ví dụ,
kiểm thử thủ công).
• Ở lớp giữa, các kiểm thử chức năng làm việc trực tiếp với mã nguồn sản phẩm,
không cần GUI. Nếu nhóm không có kinh nghiệm để kiểm thử đơn vị thì với công
cụ thích hợp cho phép chúng có ROI tốt nhất. Các kiểm thử có thể được viết bởi
ngôn ngữ mà các chuyên gia thương mại có thể hiểu giá trị của chúng.
• Có nhiều lớp khác nhau trong ứng dụng có thể kiểm thử độc lập. Trong quyển
xUnit Test Patterns [2007], Gerard Meszaros đề cập đến điều này như Layer Test
Pattern. Ông cảnh báo rằng, khi cố gắng kiểm thử toàn bộ các lớp ứng dụng,
chúng ta vẫn phải xác minh các lớp được kết nối một cách chính xác và nó đòi
hỏi ít nhất một kiểm thử business logic thông qua presentation layer.
. Nếu đánh giá dựa trên hoàn vốn nguồn lực tự động hóa.
• Hãy xem xét các khía cạnh ít rõ ràng như công cụ có thúc đẩy hợp tác giữa
nhóm kỹ thuật và nhóm khách hàng không.
• Một lý do chính đáng để viết kiểm thử là giúp hướng dẫn phát triển. Nếu kết quả
của quá trình viết kiểm thử tự động thể hiện sự hiểu biết thấu đáo về yêu cầu
nghiệp vụ, điều đó chứa payback.


14.5.3. Think about Test Design and Maintenance

. Nghĩ về các kiểm thử thủ công mà bạn đã viết, có phải bạn không hy vọng toàn bộ
chúng có thể tự động hóa? bạn sẽ không dễ dàng để thực hiện?. Chắc chắn toàn bộ
kiểm thử đều có thể tự động hóa, hãy bắt đầu chuyển đổi những kiểm thử thủ công này
và nó có thể trở nên dễ dàng để tự động.
. Nếu nhóm có hàng chục, hàng trăm trường hợp kiểm thử cần bảo trì? nếu công cụ
không phù hợp với sự thay đổi hiện tại, kiểm thử tự động sẽ rất đau đầu.
. Kiểm thử đầu cuối đặc biệt khó khăn bởi chúng có khả năng cần bảo trì nhất khi các
quy tắc nghiệp vụ bị thay đổi.
Làm thế nào để cân bằng giữa nhua cầu tự động hóa và chi phí?
a. Test Design
. Chọn test pattern cẩn thận. Tự động hóa toàn bộ test cases mà bạn cần, nhưng không
nhiều hơn, tự động hóa chúng ở mức thấp nhất có thể.
. Giới hạn phạm vi mỗi test case từ một điều kiện kiểm thử hay quy tắc nghiệp vụ.
. Hiểu được mục tiêu của kiểm thử.
. Tránh sự phụ thuộc giữa các kiểm thử, bởi sự phức tạp sẽ khiến chi phí bảo trì tăng
lên.
b. Consider Options
. Đẩy kiểm thử tự động xuống kim tự tháp nếu bạn có thể.
• Nếu kiểm thử đơn vị và tích hợp được đảm bảo, sẽ không cần tự động nhiều
kiểm thử chức năng.
• Với việc đảm bảo kiểm thử ở các mức thấp hơn, nó đủ để thực hiện thủ công
kiểm thử đầu cuối để xác minh hành vi hệ thống.
. Sử dụng phân tích rủi ro để giúp bạn quyết định.
c. User Interface
. Giao diện người dùng cần phải được kiểm thử. Trong một số tình huống, kiểm thử tự
động GUI rất quan trọng. Nếu phân tích rủi ro và ROI hỗ trợ tự động hóa GUI, hãy đầu
tư cho nó.
. Nếu bạn thực hiện tự động hóa ở các mức cao hơn, đừng tự động toàn bộ con đường
đi qua hệ thống. Bạn không phải tự động toàn bộ kiểm thử trong bộ hồi quy, hãy xem xét
cân bằng giữa thời gian build và cơ hội tìm defects. Tập trung nguồn lực vào việc đảm

bảo con đường quan trọng thông qua mã nguồn ở mức đơn vị, tích hợp và chức năng.
Bạn sẽ nhận payback tốt hơn.
d. Strike a Balance
. Striking a balance không phải nguyên tắc Agile, nó chỉ là cảm giác bình thường. Bạn
cần giải pháp đủ tốt nhưng không cần quá hoàn hảo.
• Công cụ có cung cấp các kết quả mà bạn cần không?
• Nó có cung cấp bản thống kê đầy đủ nguồn lực mà bạn cần cho tự động hóa


không?
• Liệu công cụ có phù hợp với tình hình của bạn không?
. Bạn có thể sử dụng trước, sau đó tìm kiếm giải pháp thay thế, bạn có thể cải tiến
khung kiểm thử theo thời gian.
. Bạn cần một giải pháp không gia tăng technical debt cho nhóm. Tìm cân bằng giữa
“Nó tìm ra lỗi mà chúng tôi cần biết mà không mất chi phí quá nhiều cho việc duy trì” và
“Đây là giải pháp tốt nhất mà chúng ta có thể tìm thấy”.

14.5.4. Choosing the Right Tools
. Thật tốt nếu có nhiều công cụ giúp giải quyết các vấn đề tự động hóa. Nhưng đừng đi
quá nhu cầu của bạn.
. Công cụ Record/Playback có một số nhược điểm, nhưng chúng thích hợp trong một số
hoàn cảnh phù hợp. Bạn có thể sử dụng cho một số lý do sau: Có thể Legacy code thực
sự đã có một bộ các kiểm thử tự động được tạo ra bởi công cụ đó, nhóm của bạn có
nhiều kinh nghiệm về công cụ này, hay quản lý của bạn muốn bạn sử dụng nó bởi một
số lý do. Record/Playback có thể thích hợp với Legacy systems, nó được thiết kế theo
cách khó để tạo kiểm thử đơn vị và các kịch bản kiểm thử viết lại từ đầu thì quá tốn
kém.
. Một số Agile team thấy giá trị từ các công cụ kiểm thử thương mại hay mã nguồn mở,
trong khi những người khác thích phương pháp tiếp cận tùy biến. Nhiều kiểm thử viên
thấy giá trị từ các ngôn ngữ kịch bản như Ruby hay Shell, để tự động hóa các công việc

nhàm chán nhưng cần thiết, tạo dữ liệu kiểm thử hay điều khiển các công cụ khác.
. Nếu bạn là một kiểm thử viên không có nền tảng lập trình mạnh mẽ, bạn nên chọn một
quyển sách, tìm hướng dẫn trực tuyến, hoặc tham gia vào lớp ngôn ngữ kịch bản, và
thấy nó dễ dàng để có thể viết các kịch bản hữu dụng.
Tóm lại, bạn có thể sử dụng nhiều công cụ khác nhau. Nhìn vào vấn đề mà bạn đang cố
gắng giải quyết và quyết định theo nhóm là dễ dàng và hiệu quả nhất để lựa chọn công
cụ phù hợp. Dành thời gian để khám phá công cụ mới, xem chúng lấp đầy các thiếu sót
và thay thế các công cụ không xứng đáng.
. Nếu nhóm của bạn mới phát triển Agile, hoặc đang thực hiện dự án hoàn toàn mới,
bạn sẽ đối mặt với lựa chọn công cụ và thiết lập môi trường kiểm thử. Sẽ mất nhiều thời
gian cho các công cụ đánh giá, thiết lập quy trình build, thực nghiệm với các phương
pháp kiểm thử khác nhau.

14.6. Applying Agile Principles to Test Automation
. Mỗi nhóm, mỗi dự án và mỗi tổ chức có một tình huống độc đáo với các thử thách tự
động hóa khác nhau. Nó có văn hóa, lịch sử, nguồn lực, áp lực kinh doanh và kinh
nghiệm riêng.
. Không vấn đề tình huống của team bạn là gì, bạn có thể sử dụng các nguyên tắc và


giá trị Agile để giúp bạn tìm ra giải pháp.
. Các khái niệm như lòng cam đảm, thông tin phản hồi, đơn giản, giao tiếp, cải tiến liên
tục và ứng phó với thay đổi thì không phải quan điểm của Agile – Chúng là phẩm chất
của toàn bộ các team thành công.

14.6.1. Keep It Simple
. Phương trâm Agile “Do the simplest thing that could possibly work” áp dụng cho kiểm
thử và mã nguồn. Giữ thiết kế kiểm thử đơn giản, phạm vi tối thiểu, sử dụng công cụ
đơn giản nhất để làm việc.
. Đơn giản là giá trị cốt lõi của Agile. Tuy nhiên, đơn giản không có nghĩa là làm điều dễ

dàng nhất. Nó liên quan đến cái mà bạn cần làm là gì và tiến hành các bước nhỏ để đạt
được điều đó. Bằng cách giữ mọi thứ đơn giản, nếu bạn đưa ra lựa chọn xấu, bạn sẽ
không đi quá xa trước khi nhận ra sai lầm.
. Giống như tất cả các khía cạnh khác của kiểm thử trong dự án phát triển agile, các duy
nhất để theo kịp là làm yêu cầu tối thiểu.
. Sử dụng công cụ đơn giản nhất để thực hiện. Trong kim tự tháp kiểm thử, nếu một
customer-facing test có thể dễ dàng tự động nhất ở mức đơn vị, hãy thực hiện ở đây.

14.6.2. Iterative Feedback
. Các lần lặp cho phép thực nghiệm phương pháp tiếp cận tự động, đánh giá kết quả,
thay đổi khóa học một cách nhanh chóng khi cần thiết.
. Cam kết sử dụng nguồn lực vào tự động hóa cho một vài lần lặp, như tự phát triển
khung kiểm thử, thực hiện một công cụ mã nguồn mở. Sau mỗi lần lặp, tìm xem cái gì
đang làm việc, cái gì không làm việc. Hãy suy nghĩ về ý tưởng khắc phục các vấn đề và
cố gắng thực hiện ở lần lặp tiếp theo. Nếu nó không phải giải pháp hợp lý, hãy thử cách
khác ở các lần lặp.
. Sử dụng các lần lặp tạo điều kiện cho cách tiếp từng bước một. Nếu ý tưởng của bạn
không hợp lý, bạn sẽ nhanh chóng nhìn thấy và có cơ hội để thử cái khác. Đừng ngại để
tìm kiếm, nhưng không nên tìm kiếm giải pháp hoàn hảo, chỉ nên cố gắng thực hiện đầy
đủ nhu cầu của bạn.

14.6.3. Whole-Team Approach
. Phát triển Agile không thể làm việc mà không có tự động hóa. Phương pháp tiếp cận
whole-team, nghĩa là một phạm vi rộng lớn các kỹ năng, nguồn lực để tìm kiếm và thực
hiện chiến lược tự động có ích. Cả nhóm cùng làm có nghĩa có nhiều khả năng mã
nguồn được thiết kế cho khả năng kiểm thử. Lập trình viên, kiểm thử viên, các thành
viên khác trong nhóm sẽ hợp tác để kiểm thử, mang lại nhiều quan điểm và kỹ năng cho
nhóm.
. Phương pháp Whole-team giúp vượt qua rào cản của sự sợ hãi. Biết những người với
kỹ năng và kinh nghiệm khác nhau có thể giúp chúng ta thêm cam đảm.

. Với các kiểm thử technology-facing như Security hay Load Testing có thể yêu cầu


chuyên gia bên ngoài. Một số công ty có đội ngũ chuyên gia sẵn sàng chia sẻ cho
nhóm. Ngay cả khi có sẵn nguồn lực này, Agile team vẫn phải chịu trách nhiệm cho việc
đảm bảo các kiểm thử được thực hiện.
. Một số tổ chức có đội ngũ kiểm thử độc lập để kiểm thử sau này. Họ có thể kiểm thử
để đảm bảo phần mềm tích hợp với các hệ thống khác, hoặc tiến hành các kiểm thử
khác như Performance testing. Các nhóm phát triển làm việc chặt chẽ với các nhóm
khác, sử dụng phản hồi từ nhiều nguồn để cải thiện thiết kế mã và tạo điều kiện cho
kiểm thử tự động.

14.6.4. Taking the Time to Do It Right
. Để giải quyết vấn đề và thực hiện các giải pháp cần có thời gian. Chúng ta nên giúp
quản lý hiểu được nếu không có đủ thời gian để làm việc chính xác, technical debts sẽ
tăng và velocity sẽ giảm. Thực hiện theo đúng hướng sẽ mất nhiều thời gian phía trước,
nhưng tiết kiệm thời gian lâu dài.
. Quản lý thường chỉ quan tâm đến kết quả sản phẩm nhanh nhất có thể. Nếu quản lý
miễn cưỡng cho nhóm thời gian thực hiện tự động hóa, hãy giải thích cho họ hiểu
những lợi ích mà nó mang lại.
. Chúng ta luôn cảm thấy áp lực bởi giới hạn thời gian. Sự cán dỗ từ việc quay lại cách
làm cũ, mặc dù nó không hoạt động hiệu quả. Không bao giờ đủ thời gian để quay lại và
sửa chữa. Trong Planning Meeting, hãy đưa ra thời gian để thực hiện tự động hóa cần
thiết.
. Hãy làm việc với các nhịp đều nhau (Sustainable Pace). Hãy dành thời gian để tái cấu
trúc khi bạn đến hoặc bạn sẽ kết thúc sự lộn xộn cuối cùng. Bạn có nhiều việc để làm
như học một công cụ mới hay cố gắng tự động kiểm thử mới, đừng nên đa nhiệm, hãy
tìm một khoảng thời gian và tập trung vào.
. Nếu các business stakeholders không kiên nhẫn với nhóm. Hãy giải thích với họ
• Các rủi ro có thể xảy ra là gì?

• Mất bao nhiêu chi phí cho một vấn đề sản phẩm?
• Lợi ích của việc phát hành một quick hack là gì?
• Nó bao nhiêu technical debt được thêm vào?
• Thiết kế vững chắc hỗ trợ gì cho kiểm thử tự động?
• Phương pháp tiếp cận ảnh hưởng đến lợi nhuận của công ty và sự hài lòng của
khách hàng như thế nào?
• Những chi phí vô hình, như làm việc với chất lượng kém ảnh hưởng đến tinh
thần của nhóm như thế nào?

14.6.5. Learn by Doing
. Mọi người học theo nhiều cách khác nhau, nhưng khi bạn đã quyết định cách tự động
một kiểm thử như thế nào, hãy bắt đầu thực hiện nó. In Everyday Scripting with Ruby for
Teams, Testers, and You [2007], Brian Marick khuyên bạn nên tìm hiểu chương trình
bằng cách viết nó. Tạo mistakes, bạn có thể sẽ học được nhiều hơn. Hãy cặp với một
người nào đó, sẽ giúp bạn tăng tốc quá trình học.
. Nếu bạn không có ai để cặp cùng, hãy nói “Rubber ducky”: Hãy tưởng tượng bạn đang


mô tả vấn đề với đồng nghiệp. Đơn giản khi đọc lớn một kiểm thử, cũng có thể giúp bạn
tìm ra điểm yếu kém của nó.

14.6.6. Apply Agile Coding Practices to Tests
. Các kiểm thử có giá trị như mã nguồn sản phẩm. Hãy đối xử với các kiểm thử theo
cùng cách bạn đối xử với toàn bộ mã nguồn. Giữ nó trong cùng công cụ kiểm soát mã
nguồn với mã sản phẩm, bạn luôn xác định được các phiên bản của kịch bản kiểm thử
đi cùng phiên bản mã nguồn riêng biệt.
. Ghép nối, tái cấu trúc, thiết kế đơn giản, thiết kế module, hướng đối tượng, các tiêu
chuẩn, giữ các kiểm thử độc lập nhất có thể - Chất lượng mã nguồn tốt thì chất lượng
của các kiểm thử tự động cũng tốt.
. Kiểm thử tự động là nỗ lực của nhóm. Kinh nghiệm, kỹ năng thay đổi, hoàn cảnh của

mỗi thành viên nhóm khác nhau có thể làm việc cùng nhau để đưa ra các phương pháp
tốt nhất để tự động hóa. Đổi mới - là sáng tạo.

14.7. Supplying Data for Tests
. Không vấn đề công cụ chúng ta sử dụng để tự động kiểm thử là gì, các kiểm thử cần
dữ liệu để xử lý. Lý tưởng nhất, dữ liệu phù hợp với dữ liệu sản phẩm. Tuy nhiên, cơ sở
dữ liệu sản phẩm luôn chứa nhiều, và rất nhiều dữ liệu, chúng có độ phức tạp cao.
Ngoài ra, truy cập cơ sở dữ liệu làm chậm kiểm thử theo cấp số nhân.

14.7.1. Data Generation Tools
. Có một vài công cụ có thể sinh dữ liệu kiểm thử cho toàn bộ các trường đầu vào và
các điều kiện biên. Các công cụ mã nguồn mở và thương mại như Data Generator,
databene benerator, testgen, Datatect, và Turbo Data là có thể tạo ra các tập tin rõ ràng
hay tạo ra dữ liệu trực tiếp từ các bảng dữ liệu. Các công cụ này có thể sinh một lượng
lớn các kiểu dữ liệu khác nhau như các tên và các địa chỉ.
. Nó cũng khá dễ dàng để sinh dữ liệu kiểm thử với một kịch bản tự viết, bằng cách sử
dụng ngôn ngữ kịch bản như là Ruby hay Python, công cụ như Fit hoặc FitNesse, hay
shell script.
. Các kịch bản và công cụ để sinh dữ liệu kiểm thử không phải quá phức tạp. Ví dụ,
PerlClip sinh văn bản vào clipboard của Windows để nó có thể paste vào nơi cần thiết.

14.7.2. Avoid Database Access
. Lựa chọn đầu tiên để kiểm thử là nên cố gắng để các kiểm thử chạy ở bộ nhớ trong
(in-memory). Truy cập cơ sở dữ liệu có nghĩa I/O và đĩa vốn chậm. Mỗi khi đọc cơ sở
dữ liệu đều làm thậm quá trình chạy kiểm thử của bạn. Nếu mục tiêu của bạn là đưa ra
phản hồi nhanh chóng, bạn sẽ muốn kiểm thử chạy nhanh nhất có thể. Một fake object
như cơ sở dữ liệu bộ nhớ trong giúp kiểm thử thực hiện những gì nó cần làm và đưa ra
phản hồi ngay lập tức.

. Truy cập cơ sở dữ liệu góp phần lớn làm chậm kiểm thử. Hãy thực hiện các bước nhỏ
để giả cơ sở dữ liệu ở nơi bạn có thể, và tạo kiểm thử không liên quan đến cơ sở dữ
liệu càng nhiều càng tốt. Nếu nó khó, đánh giá lại kiến trúc hệ thống, và tổ chức cho
kiểm thử tốt hơn.
. Nếu kiểm thử logic nghiệp vụ, thuật toán, các phép tính trong mã, bạn thấy kịch bản
của mã nguồn không cần quan tâm dữ liệu đến từ đâu nhưng luôn cho ra kết quả nhất
định. Hãy xây dựng dữ liệu kiểm thử là một phần của kiểm thử và có thể truy cập từ bộ
nhớ trong. Mô phỏng truy cập cơ sở dữ liệu và các đối tượng, tập trung vào mục đích
kiểm thử. Không chỉ các kiểm thử sẽ chạy nhanh hơn, mà chúng còn được viết và bảo
trì dễ dàng hơn.
. Khi tạo dữ liệu cho kiểm thử, hãy sử dụng các giá trị phản ánh mục đích của kiểm thử.
Trừ phi, bạn hoàn toàn tin rằng mỗi kiểm thử đều độc lập và tạo ra các giá trị duy nhất
cho mỗi kiểm thử. Khi bạn cần lượng lớn dữ liệu, cố gắng tạo dữ liệu ngẫu nhiên,
nhưng luôn gỡ bỏ nó ở cuối kiểm thử. Đôi khi, các kiểm thử cần các loại dữ liệu đặc
biệt, dữ liệu ngẫu nhiên sẽ làm hỏng mục đích kiểm thử, do đó chỉ nên sử dụng ngẫu
nhiên cho các kiểm thử có các đầu vào độc nhất.

14.7.3. When Database Access Is Unavoidable or Even Desirable
. Nếu hệ thống được kiểm thử chủ yếu dựa trên cơ sở dữ liệu.
. Nếu mã nguồn kiểm thử đọc and/or vào cơ sở dữ liệu, bạn sẽ muốn có ít nhất một vài
kiểm thử hồi quy để xác minh lớp cơ sở dữ liệu của mã nguồn.
a. Setup/Teardown Data for Each Test
. Phương pháp ưa thích của chúng tôi là để cho mỗi kiểm thử thêm các dữ liệu cần thiết
đến đồ hình kiểm thử, hoạt động trên dữ liệu đó, xác minh kết quả trong cơ sở dữ liệu,
và sau đó xóa toàn bộ dữ liệu kiểm thử để kiểm thử có thể chạy lại mà không ảnh
hưởng đến các kiểm thử tiếp theo.
b. Canonical Data
. Một thay đổi khác là có các giản đồ kiểm thử có thể được làm mới nhanh chóng với dữ
liệu từ Canonical hoặc Seed database. Lý tưởng là seed data này là mẫu đại điện của
dữ liệu sản phẩm thực tế. Bởi nó là lượng nhỏ dữ liệu, nó có thể xây dựng lại nhanh

chóng mỗi khi có bộ kiểm thử hồi quy cần chạy.
. Phương pháp này cũng làm tăng thời gian cần để chạy các kiểm thử, nhưng nó chỉ
một vài phút từ lúc bắt đầu của bộ hồi quy. Các kiểm thử sẽ chậm hơn các kiểm thử
không truy cập cơ sở dữ liệu, nhưng chúng sẽ nhanh hơn kiểm thử phải truy cập vào
từng hàng của mỗi bảng.
. Canonical data có nhiều công dụng. Các kiểm thử viên và lập trình viên có thể có giản


đồ kiểm thử riêng để làm mới theo ý muốn. Họ có thể thực hiện với cả hai kiểm thử tự
động và thủ công mà không cần bước vào kiểm thử của bất kỳ ai. Nếu dữ liệu được lựa
chọn cẩn thận, dữ liệu sẽ thực tế hơn so với số lượng dữ liệu hạn chế được kiểm thử
build.
. Tất nhiên, có một nhược điểm. Canonical data có thể khó nâng cao. Khi bạn cần các
kịch bản kiểm thử mới, bạn sẽ phải xác định dữ liệu sản phẩm, hoặc tạo dữ liệu bạn cần
và thêm nó seed schema. Mỗi lần bạn thêm một bảng hay một cột vào cơ sở dữ liệu
sản phẩm, bạn nên cập nhật lại giản đồ kiểm thử sao cho phù hợp. Bạn phải lựa chọn
cẩn thận những bảng cần làm mới và những bảng không cần làm mới, như các bảng tra
cứu. Nếu bạn phải thêm dữ liệu để tăng độ bao phủ của kiểm thử, làm mới sẽ mất nhiều
thời gian, tăng thời gian của quá trình tạo ra nó. Điều quan trọng của build tự động là
cung cấp phản hồi một cách kịp thời, nhưng cơ sở dữ liệu làm mới kéo dài chu kỳ phản
hồi của bạn. Bạn cũng không được độc lập kiểm thử với Canonical data, vì vậy nếu một
kiểm thử thất bại, những cái khác cũng có thể như vậy.
c. Production-Like Data
. Khả năng kiểm thử một hệ thống giống với sản phẩm nhất có thể thì quan trọng với
hầu hết các nhóm phát triển phần mềm.
. Stress, Performance, và Load testing là những tự động chuyên sâu, cần một môi
trường mô phỏng gần giống sản phẩm để cung cấp các kết quả có thể chuyển đến các
hoạt động thực tế. Usability, Security và Reliability là những ví dụ của kiểm thử cần
production-like system, mặc dù chúng có thể không liên quan nhiều đến tự động hóa.
Luôn luôn có một sự cân bằng (trade-off); cơ sở dữ liệu sản phẩm của bạn có thể lớn,

do đó nó đắt và chậm, nhưng nó cung cấp các dữ liệu kiểm thử chính xác nhất có thể.
d. Data Migration
. Data Migration phải được kiểm thử đối với cơ sở dữ liệu thực tế. Các kịch bản nâng
cấp cơ sở dữ liệu cần phải chạy trên các dữ liệu thực tế và tiến hành release cuối cùng
của giản đồ cơ sở dữ liệu.

14.7.4. Understand Your Needs
. Hiểu được mục đích của kiểm thử, bạn có thể đánh giá những thứ bạn cần tốt hơn.
. Khi bạn cần mô phỏng môi trường sản phẩm thực tế, tạo một bản sao của toàn bộ cơ
sở dữ liệu nếu cần thiết.
. Phản hồi nhanh chóng là mục tiêu, vì vậy cân bằng giữa các kịch bản kiểm thử thực tế
với việc tìm defects hiệu quả nhất có thể.

14.8. Evaluation Automation Tools
. Bước đầu tiên trong việc lựa chọn công cụ tự động là tạo danh sách các công cụ cần
thiết cho bạn. Hãy xem xét bạn có thể quyết định trên các yêu cầu công cụ kiểm thử của
bạn thế nào?


14.8.1. Identifying Requirements for your Automation Tool
. Sau khi quyết định dựa trên thách thức tự động tiếp theo cần giải quyết, nghĩ về nhu
cầu công cụ của bạn.
• Bạn đã có công cụ nào? Nếu bạn cần bổ sung, có thể bạn muốn một cái gì đó
tích hợp các kiểm thử hiện tại và cơ sở hạ tầng phát triển. Bạn cần một công cụ
dễ dàng tích hợp vào quá trình build liên tục? Phần cứng của bạn có hộ trợ tự
động hóa không? Thiết lập quá trình build thứ hai để chạy kiểm thử chức năng
có thể cần máy móc bổ sung.
• Ai sẽ sử dụng công cụ kiểm thử? Không lập trình viên nào viết test cases? Các
lập trình viên muốn có một công cụ phù hợp? Bạn đã liên hệ với các thành viên
cần hợp tác chưa?

• Ai sẽ tự động hóa và duy trì các kiểm thử? Các kỹ năng của nhóm bạn rất quan
trọng. Mất bao nhiêu thời gian để bạn có thể cài đặt công cụ và học làm thế nào
để sử dụng nó? Những thành viên trong nhóm có kinh nghiệm với công cụ cụ
thể nào không? Có một nhóm kiểm thử riêng biệt có chuyên môn về một công cụ
nào đó không? Nếu bạn bắt đầu quá trình chuyển đổi sang phát triển Agile, bạn
nên có một nhóm kiểm thử tự động, nó có thể tận dụng chuyên môn và tiếp tục
sử dụng công cụ mà họ biết.
. Các yêu cầu về công cụ của bạn phụ thuộc vào môi trường phát triển.
• Nếu bạn đang kiểm thử một ứng dụng Web, và công cụ bạn chọn không hỗ trợ
SSL hay AJAX, bạn có thể gặp vấn đề.
• Không phải mọi công cụ kiểm thử đều có thể kiểm thử ứng dụng dịch vụ web.
Kiểm thử hệ thống nhúng có thể cần công cụ khác.
. Tất nhiên, loại kiểm thử đang tự động cũng là chìa khóa.
• Security testing cần các công cụ chuyên môn cao.
• Có nhiều công cụ mã nguồn mở và của nhà công cụ cho performance, vì vậy
việc lựa chọn không phải khó khăn.
• Ví dụ, đưa cho nhóm của Lisa một vài năm để phát triển các bộ kiểm thử hồi quy
mạnh mẽ ở mức đơn vị, tích hợp và chức năng. Performance testing vẫn là
phạm vi đau đầu của họ. Bài học kinh nghiệm từ các nguồn lực tự động hóa
trước đó đã giúp họ làm việc tốt hơn việc xác định các yêu cầu cho một công cụ
kiểm thử, chẳng hạn như dễ dàng để báo cáo kết quả, khả năng tương thích với
khung làm việc hiện tại và ngôn ngữ kịch bản.
. Viết một checklist liệt kê các yêu cầu về công cụ của bạn. Một số chúng có thể xung
đột hoặc mâu thuẫn với nhau hoặc – “Công cụ cần dễ dàng để khách hàng có thể chỉ
định các kiểm thử” hoặc “Các kiểm thử dễ dàng được tự động hóa”.

14.8.2. One Tool at a Time
. Bạn cần công cụ khác nhau phục vụ cho các mục đích khác nhau. Bắt đầu với công cụ
mới và nghiên cứu cách sử dụng chúng. Chỉ thử một công cụ tại một thời điểm, vị trí

khó khăn nhất của bạn; sau đó xem xét và đánh giá nó; nếu nó làm việc tốt, hãy chuyển
sang công cụ và vị trí khó khăn tiếp theo. Thử nhiều công cụ có thể tốt trong một số tình
huống, nhưng công nghệ mới đòi hỏi sự quan tâm đầy đủ.
. Khi đã quyết định một công cụ để giải quyết yêu cầu đặc biệt, xem thử thách tiếp theo
là gì? công cụ lựa chọn cho thể đáp ứng nhu cầu đó không, hay bắt đầu một quá trình
lựa chọn khác?
. Nếu bạn đã quyết định nhìn ra ngoài tổ chức của bạn cho những công cụ, bước đầu
tiên là tìm thời gian để thử một số bên ngoài. Bắt đầu với một số tìm kiếm: Các tìm kiếm
trên Internet, các bài báo và các ấn phẩm khác về công cụ, và danh sách mailing là nơi
tốt nhất để đưa ra các ý tưởng. Biên soạn một danh sách các công cụ để xem xét. Nếu
nhóm của bạn sử dụng wiki hoặc diễn đàn trực tuyến (online forum), gửi các thông tin
về công cụ và bắt đầu thảo luận về ưu và nhược điểm của nó.
Ngân sách thời gian cho việc đánh giá công cụ.
. Khi bạn có một danh sách các công cụ có thể đáp ứng yêu cầu của bạn, thu hẹp các
khả năng xuống một hoặc hai, tìm hiểu làm thế nào để sử dụng mỗi người cũng đủ để
cố gắng nó và làm vài mũi nhọn: Thử một kịch bản đơn giản nhưng đại diện thứ bạn có
thể vứt bỏ. Đánh giá các kết quả so với yêu cầu. Sử dụng retrospectves để xem xét ưu
và nhược điểm.
. Chọn ứng viên hàng đầu của bạn và cam kết cố gắng nó trong một khoảng thời gian –
đủ dài để thấy được khả năng của nó. Trong Retrospectives, nhìn vào những gì đã làm
và những gì không làm. Cởi mở ý tưởng rằng nó có thể không đúng và bạn phải bỏ nó
đi và bắt đầu lại. Đừng cảm thấy bạn phải tiếp tục với công cụ đó bởi bạn đã đầu tư quá
nhiều vào nó rồi.

14.8.3. Choosing Tools
. Có một phạm vi rộng lớn và đã phát triển bộ công cụ để chọn từ: home-grown, mã
nguồn mở, công cụ của nhà cung cấp, hoặc một sự kết hợp của bất kỳ, tất cả đều lựa
chọn thay thế khả thi. Tìm thời gian để thử công cụ để xem chúng có phù hợp với yêu
cầu của bạn. Nó có thể khó khăn để đánh giá ROI cho mỗi giải pháp, nhưng một cách

tiếp cận lặp để đánh giá chúng giúp có được hướng đi đúng.
a. Should You Grow Your Own
. Ứng dụng của bạn đang có thách thức kiểm thử độc đáo. Nhóm có kỹ năng, thời gian
và xu hướng viết khung kiểm thử riêng hoặc xây dựng dựa trên công cụ mã nguồn mở
hiện tại thì công cụ home-grown là phù hợp nhất.
. Trong phát triển Agile, nhiều lập trình viên có hiểu biết về kiểm thử, cũng có nhiều công
cụ và ngôn ngữ làm cho khung kiểm thử dễ dàng.


. Nếu nhóm bạn đang viết các khung làm việc tự động riêng cho nó, chúng sẽ được tùy
chỉnh chính xác với nhu cầu của nhóm khách hàng và nhóm phát triển của bạn, và tích
hợp với quá trình build hiện tại và cơ sở hạ tầng khác – và bạn có thể làm cho chúng dễ
dàng để thực thi và giải thích kết quả như bạn cần.
.Home-grown không có nghĩa là miễn phí. Một tổ chức lớn với các yêu cầu đặc biệt có
thể đật cùng một nhóm chuyên gia tự động, những người có thể hợp tác với kiểm thử
viên, khách hàng, lập trình viên và những người khác. Nếu yêu cầu của bạn quá đặc
biệt mà không công cụ hiện tại nào hỗ trợ chúng, home-grown là lựa chọn duy nhất của
bạn.
b. Open Source Tools
. Bởi những công cụ này được viết bởi các lập trình viên thích kiểm thử (test-infected)
mà nhu cầu không được đáp ứng bởi các công cụ của nhà cung cấp, chúng thường rất
nhẹ và thích hợp với phát triển Agile. Nhiều công cụ được phát triển cho test-first, và
bạn có thể tải bộ kiểm thử cùng với mã nguồn, tạo tùy biến dễ dàng và an toàn hơn.
. Không phải toàn bộ công cụ mã nguồn mở nào cũng có tài liệu tốt và đào tạo có thể là
một vấn đề. Tuy nhiên, chúng tôi thấy các cuộc hội thảo (seminars) và hướng dẫn
(tutorials) về cách sử dụng các công cụ này tại nhiều hội nghị và cuộc họp nhóm người
sử dụng. Một số công cụ mã nguồn mở có hướng dẫn sử dụng tuyệt vời và thậm chí có
các hướng dẫn trực tuyến và các lớp học theo lịch trình có sẵn.
c. Vendor Tools
. Các công cụ thương mại được coi là một vụ đánh cược an toàn. Nó khó để chỉ trích

một ai đó để lựa chọn một công cụ nổi tiếng và đã nổi trong năm. Họ có thể cung cấp tài
liệu, hỗ trợ và đào tạo. Cho kiểm thử viên hay người dùng khác thiếu nền tảng kỹ thuật,
dốc ban đầu có thể đi lên nhanh hơn. Một số khá mạnh và giàu tính nâng. Công ty bạn
có thể đã sở hữu một và có đội ngũ chuyên gia biết sử dụng nó như thế nào.
. Mặc dù chúng đang thay đổi theo thời gian, các công cụ của nhà cung cấp có lịch sử
không thân thiện với lập trình viên. Chúng có xu hướng sử dụng các ngôn ngữ kịch bản
độc quyền mà các lập trình viên không muốn dùng thời gian để học. Chúng cũng khá
nặng. Các kịch bản kiểm thử có thể trở nên mỏng manh, dễ bị phá vỡ bởi những thay
đổi nhỏ của ứng dụng, và tốn kém để duy trì. Hầu hết các công cụ này ghi lại kịch bản
để phát lại sau đó. Các kịch bản record/playback có tiếng là tốn kém từ góc độ bảo trì.

14.8.4. Agile-Friendly Tools
Elisabeth Hendrickson [2008] liệt kê một số đặc điểm của các công cụ kiểm thử tự động
Agile hiệu quả. Những công cụ này sẽ:
• Hỗ trợ bắt đầu từ những năng lực kiểm thử tự động ngay lập tức, bằng cách sử
dụng phương pháp test-first.
• Tách bản chất của các kiểm thử từ các chi tiết thực hiện.
• Hỗ trợ và khuyến khích thực hành lập trình tốt cho phần mã của kiểm thử tự


•
•

động
Hỗ trợ viết mã nguồn kiểm thử tự động bằng cách sử dụng các ngôn ngữ thực
sự, với IDEs thực.
Kích lệ sự hợp tác.

14.9. Implementing Automation
. Trong khi bạn đang đánh giá các công cụ, hãy suy nghĩ về yêu cầu tự động ưu tiên

hàng đầu của bạn nhanh chóng được giải quyết như thế nào. Bạn sẽ nhận sự hỗ trợ từ
đâu để giúp hoàn thành nó? Nhóm cần đào tạo những gì và mất bao nhiêu lâu để có thể
thực hiện nó? Bạn phải đẩy nhanh công cụ này như thế nào?
. Bạn có thể xây dựng nguồn lực tự động hóa của bạn theo từng bước một. Nhiều nhóm
trải qua nỗ lực không thành công trước khi tìm thấy sự kết hợp chính xác giữa công cụ,
kỹ năng và cơ sở hạ tầng.
. Thiết kế hướng đối tượng tốt không phải là chìa khóa duy nhất để xây dựng một bộ
kiểm thử tự động. Bạn cũng cần chạy các kiểm thử thường xuyên đủ để lấy phản hồi
mà nhóm bạn cần.
. Các công cụ lựa chọn phải làm việc trên nền tảng của chúng tôi, và phải chia sẻ và
chơi tốt với các công cụ khác.
. Cần giữ các môi trường kiểm thử độc lập, không bị ảnh hưởng bởi sự thay đổi của lập
trình viên.
. Xây dựng cơ sở hạ tầng kiểm thử có thể là một dự án lớn, nhưng nó điều mà một
nhóm Agile cần phải làm để nhảy vào tự động kiểm thử. Phần cứng, phần mềm và các
công cụ cần phải được xác định và thực hiện. Phụ thuộc vào tài nguyên của công ty
bạn, nó có thể là một dự án dài hạn.

14.10. Managing Automated Tests
. Chúng ta cần một cách để tìm được các kiểm thử xác minh một kịch bản cụ thể, để
hiểu mỗi kiểm thử thực hiện gì và để biết nó xác mình phần nào của ứng dụng. Các
kiểm thử tự động cần phải được duy trì và kiểm soát theo hướng tương tự mã nguồn
của sản phẩm. Khi bạn đánh dấu mã nguồn sản phẩm của bạn cho việc phát hành, các
kiểm thử xác minh chức năng cần phải là một phần của thẻ.

14.10.1. Organizing Tests
. Quản lý kiểm thử giúp team của bạn trả lời các câu hỏi như sau:
• Các tình huống kiểm thử nào được tự động?
• Trường hợp nào vẫn cần tự động?
• Kiểm thử nào đang chạy như một phần của bộ hồi quy?

• Kiểm thử nào bao phủ những vùng chức nâng gì?