Hướng dẫn thực hành Agile testing cho testers và nhóm Agile (Addison Wesley)

Part I - Introduction
Chapter 1 - What is Agile Testing, Anyway?

1.1. Agile values
. Bàn giao từng phần nhỏ , có giá trị về mặt business trong những vòng đời phát triển ngắn
. Agile manifesto:
- Cá nhân và sự tương tác quan trọng hơn quy trình và công cụ.
- Phần mềm hoạt động được quan trọng hơn tài liệu về sản phẩm.
- Cộng tác với khách hàng quan trọng hơn đàm phán trên hợp đồng.
- Đáp ứng với sự thay đổi quan trọng hơn bám theo kế hoạch có sẵn.

1.2. What Do We Mean by “Agile Testing”?
. Tester trong team Agile sẽ phải làm nhiều tasks hơn tester thông thường
(Tham ra ngay từ đầu, liên hệ với KH, gợi ý cho KH, PO để giúp họ đưa ra các tính năng rõ
ràng hơn, guide đội phát triển cách test ...)
. Test theo hướng business-facing và customer-facing
. Test nhằm đảm bảo team có thể bàn giao cho khách hàng sản phẩm có chất lượng
. Vẫn bao gồm các kiểu truyền thống và thêm phần kiểm thử thăm dò (1 khái niệm được thừa
kế từ Agile)
. Không chỉ mang ý nghĩa test trong Agile Projects thì là Agile Testing
. Lập kế hoạch để có thể vừa test vừa học về sản phẩm >> nó là guide để test những phần tiếp
theo

1.3. A Little Context for Roles and Activities on an Agile Team
1.3.1. Customer Team
. Bao gồm business experts, product owners, domain experts, product managers, business
analysts, subject matter experts—everyone on the “business” side of a project.
. Action:
1

- Viết stories và features
- Cung cấp examples, từ đó định hướng viết mã nguồn theo hướng business-facing test
- Giao tiếp, hợp tác & trả lời các câu hỏi, đưa ra các ví dụ, review khi kết thúc một story
. Tester là một thành viên không thể thiếu ở trong team

1.3.2. Developer Team
. Bao gồm toàn bộ các thành phần liên quan đến việc coding(programmers, security specialists,
system administrator,DB administrators, architects...)
. Tester là một thành phần của đội phát triển
. Tester hỗ trợ team để deliver sản phẩm với giá trị lớn nhất và đảm bảo chất lượng dựa trên
yêu cầu của khách hàng.

1.3.3. Interaction between Customer and Developer Teams
. Làm việc gần với nhau trong toàn bộ thời gian
. Customer đưa ra mức độ ưu tiên dựa vào ý kiến của developer
. Đội developer sẽ quyết định take được bao nhiêu công việc
. Tester đối với mỗi team đều có vai trò riêng biệt: hiểu được viewpoint của khách hàng cũng
như có thể hiểu được sự phức tạp của việc implementation

1.4. How is Agile Testing Different?
1.4.1. Working on Traditional Teams
. Thường tester đóng vai trò gác cổng trong việc đảm bảo quality của dự án
. Việc testing thường xảy ra vào giai đoạn cuối, ngay trước khi delivery
. Thời gian coding và testing tương đương nhau, nhưng thực tế thời gian test thường ít vì
coding bao giờ cũng chậm thời gian hơn so với dự định
. Xảy ra vòng lặp code-fix vào cuối dự án

1.4.2. Working on Agile Teams
. Tester thường test sau khi coding trong một cycle ngắm trong một lần lặp
. Trong mô hình Agile, thường áp dụng TDD (DEV viết unit test cho 1 chức năng sau đó sửa

code để cho nó chạy đúng)
. Sản phẩm bàn giao là sự kết hợp của both customer và developer team
. Tester thực hiện kiểm thử thăm dò thủ công
. Tester pair với developer để thực hiện automation testing của mỗi story

1.5. Whole-Team Approach
. Là một trong những khác biệt lớn nhất của Agile với các mô hình khác
. Khi tham gia Agile không nghĩ về phòng ban, chỉ nghĩ về skills và resources cần thiết để có thể
bàn giao một sản phẩm tốt nhất có thể
. Mọi người đều có trách nhiệm cho testing tasks

2


. Trong Agile team, mọi người đều có thể hỏi và nhận được sự giúp đỡ của người khác (mọi
người đều bình đẳng)

Summary
. Hiểu các hoạt động mà tester cần thực hiện trong nhóm Agile, giúp bạn thể hiện cho nhóm
bạn giá trị mà tester có thể thêm vào. Học về các thực hành cốt lõi của Agile testing, giúp nhóm
bạn phân phát phần mềm thích hợp cho khách hàng của bạn
. Trong chương này, chúng tôi đã giải thích chúng tôi muốn nói gì khi chúng tôi sử dụng từ
“Agile testing”
- Chúng tôi sẽ trình bày Agile Manifesto liên quan đến kiểm thử như thế nào, với việc
nhấn mạnh vào cá nhân, tương tác, phần mềm làm việc, tương tác của khách hàng và
đáp ứng với thay đổi.
- Chúng tôi đã cung cấp một số ngữ cảnh trong quyển sách này, bao gồm một số mục mà
chúng tôi đã sử dụng như “Tester”, “Programmer”, “Customer”, và các mục liên quan. Do
đó chúng ta có thể nói với một ngôn ngữ chung.
- Chúng tôi đã giải thích Agile Testing như thế nào, với việc tập trung vào giá trị nghiệp vụ

và phân phối chất lượng theo yêu cầu khách hàng, nó thì khác với kiểm thử truyền
thống, mà nhấn mạnh vào sự phù hợp của các yêu cầu khách hàng.
- Chúng tôi đã giới thiệu phương pháp tiếp cận “Whole team” đến Agile testing, có nghĩa
mọi người tham gia vào việc phân phát phần mềm thì có trách nhiệm phân phát phần
mềm chất lượng cao.
- Chúng tôi khuyên bạn nên tiếp cận việc thực hành bằng cách áp dụng các giá trị và
nguyên tắc Agile để vượt qua các trở ngại Agile testing xuất hiện chỉ ở chỗ làm của bạn.

Chapter 2 - Ten principles for Agile Testers

3


2.1. What Is Agile Testing, Anyway?
. Agile tester là người :
- Có thể bao quát được sự thay đổi.
- Hợp tác tốt với developer và business team.
- Hiểu được khái niệm test, để có thể document lại requirements và định hướng phát
triển.
- Agile testers phải có các kỹ năng về kỹ thuật tốt.
- Biết hợp tác với những người khác để tự động kiểm thử.
- Có kinh nghiệm về kiểm thử thăm dò.
- Sẵn sàng học hỏi từ khách hàng để đáp ứng yêu cầu của khách hàng.
. Ai có thể đảm nhận vai trò Agile tester?
- Là 1 member trong team mà có thể định hướng được Agile Testing.
- Có nhiều Agile tester bắt nguồn từ các lĩnh vực khác nhau.
- Kỹ năng là quan trọng nhưng thái độ quan trọng hơn.
- Tester luôn có xu hướng nhìn thấy 1 bức tranh toàn cảnh.
- Tester luôn đứng trên quan điểm của khách hàng, hướng tới khách hàng.

2.2. The Agile Testing Mind-Set
. Agile team luôn làm việc tốt nhất và deliver sản phẩm tốt nhất có thể.
. Một dự án thành công là kết quả của những người tốt cùng làm tốt 1 công việc.
. Agile tester không coi mình là một cảnh sát chất lượng, và bảo vệ khách hàng khỏi mã nguồn
không đầy đủ. Luôn sẵn sàng thu thập và chia sẻ thông tin, làm việc với customer và PO để
giúp họ mô tả yêu cầu một cách đầy đủ.
. Agile tester phải có các kỹ năng và mind-set cần thiết, luôn tìm kiếm những cách thức để team
cung cấp sản phẩm tốt nhất.
. Đối với một Agile tester, thì luôn thích học hỏi những kỹ năng mới, đảm nhiệm những thách
thức mới, không bị giới hạn bản thân chỉ trong việc giải quyết những vấn đề kiểm thử.
4


. Có thể cung cấp thông tin giúp team nhìn lại những gì mình đã làm được và những gì chưa
làm.
. Luôn luôn sáng tạo, đưa ra ý tưởng mới và sẵn sàng đảm nhận bất kỳ vai trò và công việc
nào, focused vào khách hàng, luôn có cái nhìn về một bức tranh tổng thể.
. Một tester tốt luôn có bản năng và hiểu được phần mềm có thể lỗi ở đâu và như thế nào, làm
thế nào để theo dõi những failures.
. Mindset trong Agile testing là kết quả theo định hướng, giống như một nghệ nhân, hợp tác,
mong muốn tìm hiểu, đam mê để mang lại giá trị nghiệp vụ 1 cách kịp thời.

2.3. Applying Agile Principles and Values
Những nguyên tắc và các giá trị của team sẽ hướng dẫn bạn cách chọn lựa và quyết định bạn
muốn làm việc như thế nào.

2.3.1. Provide Continuous Feedback
. Feedback đóng vai trò lớn trong Agile team.
. Một trong những đóng góp của Agile tester là giúp PO và customer làm rõ được requirements
bằng cách thực hiện test và đưa ra các ví dụ.

. Tester và các members khác phải kiểm thử sớm để đưa ra các feedback có ý nghĩa. Khi team
gặp trở ngại, FB giúp team loại bỏ được các trở ngại đó.

2.3.2. Deliver Value to the Customer
. Phát triển Agile là đem lại giá trị cho khách hàng bằng việc release nhỏ, nó cung cấp chính xác
chức năng mà khách hàng ưu tiên gần nhất.
. Để đảm bảo rằng chúng ta mang lại giá trị cho mỗi interation, team cần xem lại mỗi story để
xác định “critical path” or “thin slice” cho các chức năng cần thiết. Chúng ta cần bắt đầu bằng
việc đảm bảo các chức năng đó hoạt đông. Việc test tự động, những case fail có thể thêm vào
sau.

2.3.3. Enable Face-to-Face Communication
. Agile tester luôn tìm cách giao tiếp tốt nhất để giúp công việc tốt hơn.
. Trong một buổi discuss, phải luôn có đầy đủ tester, programmer, PO.
. Agile tester cần giúp cho khách hàng và developer có một ngôn ngữ chung.
. Có thể thảo luận trên whileboard
. Tester liên tục cộng tác và thảo luận với nhóm khác hàng và nhóm kỹ thuật.

2.3.4. Have Courage
. Chúng ta phải có cam đảm để trả lời 3 vấn đề:
- Chúng ta có thể hoàn thành việc test cho mỗi story trong khoảng thời gian ngắn không?
- Thực hiện test cùng với việc phát triển thì như thế nào?
- Test như thế nào là đủ?
. Cần cam đảm để chấp nhận thất bại của chính mình, vì chúng ta có thể học hỏi được từ thất
bại đó và tìm ra cách để đảm bảo nó không xảy ra nữa.

5


. Cần cam đảm để chấp nhận lỗi của người khác, vì nó là cách để chúng ta có thể học hỏi.

. Cần cam đảm để không ngại hỏi và yêu cầu giúp đỡ từ người khác bởi vì Agile team luôn
open và chấp nhận những ý tưởng mới.

2.3.5. Keep It Simple
. Làm những việc đơn giản nhất mà chúng ta có thể làm.
. Cần có một cách tiếp cận đơn giản để đảm bảo phần mềm đáp ứng các yêu cầu của khách
hàng.
. Agile testing sẽ thực hiện test 1 cách đơn giản nhất với các tool, kỹ thuật đơn giản như một
bảng tính hoặc một danh sách kiểm tra để xác nhận chức năng đó có hoặc tiêu chuẩn về chất
lượng của khách hàng được đáp ứng.Thự hiện test tự động ở mức thấp nhất có thể .Thậm chí
những case test smoke đơn giản cũng là đủ.
. Việc đơn giản hóa giúp chúng ta tập trung vào các rủi ro, ROI, giảm thiểu những khó khăn gặp
phải.

2.3.6. Practice Continuous Improvement
. Mindset của tester là luôn tìm kiếm cách làm cho công việc tốt hơn và cả nhóm cũng phải
luôn nghĩ về điều này.
. Việc sử dụng các cải tiến về quy trình, những buổi retrospective và backlogs chứa những chở
ngại ,nhóm đã đạt được những cải tiến nhất định trong lĩnh vực test và các lĩnh vực khác.
. Nếu không giải quyết được, thì bỏ qua và tiếp tục.
. Agile team luôn tìm kiếm các công cụ, kỹ năng hoặc thực hành sẽ giúp họ có thêm nhiều
values hơn. Các iteraction ngắn sẽ dễ dàng cho việc thử 1 vài cái mới, đánh giá hiệu quả sử
dụng lâu dài.
. Retrospectives là 1 cách thực hành chính của Agile, giúp cho team sử dụng kinh nghiệm đã có
để làm công việc sắp tới tốt hơn.Agile tester nhân cơ hội này sẽ đưa ra các vấn đề liên quan
đến testing, yêu cầu team đưa ra cách giải quyết chúng.

2.3.7. Respond to Change
. So sánh giữa waterfall & agile iteration:
- Waterfall: Khi có thay đổi về requirement, chúng ta sẽ từ chối sự thay đổi đó và thực

hiện nó ở lần sau. Như vậy sẽ khiến khách hàng không hài lòng
- Agile iteration: Khi có thay đổi về requirement, chúng ta sẽ tiếp nhận và sẽ làm nó ở
iteration kế tiếp hoặc release tiếp theo.
. Phản ứng trước những thay đổi là giá trị cốt lõi của Agile, nhưng nó cũng là điều khó khăn cho
tester. Tester luôn mong sự ổn định. Việc thay đổi requirement thường xuyên sẽ là cơn ác mộng
với tester. Tuy nhiên là 1 Agile tester thì phải luôn welcome sự thay đổi đó.
. Agile tester phải luôn cùng team thích nghi với những thay đổi.
. Test tự động là giải pháp chính cho sự thay đổi.

6


2.3.8. Self-Organize
. Agile tester là 1 phần Agile team tự quản.
. Programmers, system administrators, analysts, database experts và customer team luôn suy
nghĩ về testing, test tự động.
. Test tự động là vấn đề khó, nhưng dễ dàng hơn rất nhiều khi cả team làm việc cùng nhau. Bất
kỳ vấn đề nào về testing cũng dễ giải quyết hơn khi mọi người có nhiều kỹ năng cùng giải quyết
nó.
. Khi Agile team đối mặt với vấn đề lớn, nó không chỉ là vần đề của riêng ai cả. Tất cả team
cùng thảo luận để đưa ra cách giải quyết , quyết định là làm như thế nào, ai sẽ fix .

2.3.9. Focus on People
. Các giá trị và nguyên tắc của Agile được tạo ra với mục tiêu mỗi cá nhân và toàn đội đạt được
thành công.
. Thành viên trong nhóm Agile tôn trọng nhau và công nhận thành tích cá nhân.
. Mỗi người đều có cơ hội trưởng thành và phát triển kỹ năng của họ.
. Agile tester biết được những giá trị nhất định họ đem lại cho nhóm . Đội phát triển cũng nhận
thấy họ thành công hơn khi team có những người có kỹ năng test.

2.3.10. Enjoy
. Làm việc trên một nhóm mà mọi người cộng tác, nơi bạn đang tham gia vào các dự án từ đầu
đến cuối, nơi mà đội nghiệp vụ làm việc cùng với đội ngũ phát triển, nơi mà toàn đội chịu trách
nhiệm chất lượng.
. Tất cả mọi người nên tìm thấy niềm vui trong công việc của họ.
. Sự đam mê trong công việc của Agile tester chính là phần thưởng xứng đáng.

2.4. Adding Value
. Các nguyên tắc mang lại những giá trị về nghiệp vụ.
. 1 người đảm nhận nhiều vai trò trong dự án
. Trong Agile team, toàn team cùng có trách nhiệm cung cấp phần mềm có chất lượng cao nhất,
nó không chỉ đáp ứng được khách hàng mà nó còn khiến cho công việc có nhiều lợi nhuận.Và
mang lại lợi thế mới cho doanh nghiệp.
. Thực hiện test đúng sẽ định hướng được lập trinh, giúp ngăn chặn việc tạo ra sự khác biệt
giữa những gì khách hàng mong đợi và những gì nhóm cung cấp.
. Agile tester thường đặt ra các câu hỏi cho cả nhóm khách hàng và nhóm phát triển 1 cách
thường xuyên, giúp họ hình thành câu trả lời theo cách test đúng.
. Agile tester áp dụng các kỹ năng và kinh nghiệm của mình cho dự án, đảm bảo khách hàng
cung cấp requirement 1 cách rõ ràng. Họ đưa ra issue, đề cập tới các vần đề liên quan đến bảo
mật, hiệu suất và độ tn cậy với khách hàng.
. Không có sự phân biệt giữa các vai trò trong Agile team, tuy nhiên nhóm được hưởng lợi rất
nhiều từ các kỹ năng kiểm thử.

7


. Agile tester mang lại giá trị cho nhóm và tổ chức của mình bằng những quan điểm độc đáo ,
cách tiếp cận hướng đồng đội.

Summary

Trong chương này, chúng tôi đưa toàn bộ các nguyên tắc cho các Agile tester và các giá trị mà
chúng tôi nghĩ một Agile tester cần để làm việc hiệu quả trong một nhóm Agile.
- Mind set của Agile testing là focused vào khách hàng, kết quả theo định hướng, giống
như 1 nghệ nhân, hợp tác, sáng tạo , ham học hỏi và đam mê để mang lại giá trị về
nghiệp vụ đúng thời điểm
- Thái độ là rất quan trọng, không có sự phân biệt các vai trò trong Agile team.
- Agile tester áp dụng các giá trị và các nguyên tắc Agile như : feedback, giao tiếp, can
đảm, đơn giản hóa, yêu thích mang lại những giá trị giúp nhóm xác định các yêu cầu
của khách hàng trong mỗi story.
- Agile tester mang lại giá trị cho team và tổ chức với quan điểm duy nhất và cách tiếp
cận hướng về team.

Part II - Organizational Challenges
Khi tổ chức quyết định áp dụng Agile thì quá trình kiểm thử hay nhóm QA thường chiếm nhiều
thời gian để chuyển đổi. Các nhóm QA độc lập ở nhiều tổ chức, do vậy khi chuyển sang mô
hình Agile mới, họ khó thích nghi với văn hóa mới. Trong Part II, chúng ta nói về những thay đổi
và rào cản mà bạn phải đối mặt khi chuyển đổi sang Agile.
Đào tạo (Training) là phần to và quan trọng nhất trong quá trình chuyển đổi sang Agile và nó
thường bị quên lãng. Nó cũng khó để thấy các quy trình hiện tại như đánh giá (Audits) và khung
cải tiến (Improvement Framework) sẽ làm việc trong môi trường Agile như thế nào. Đi từ nhóm
QA độc lập đến nhóm agile là một sự thay đổi lớn.

Chapter 3 - Cultural Challenges

8


Nhiều tác nhân tổ chức có thể ảnh hưởng đến một dự án, nó có thể sử dụng An Agile hay a
traditional phased hay gated approach. Văn hóa tổ chức và nhóm có thể ngăn cản sự chuyển
đổi mềm dẻo đến phương thức Agile. Trong chương này, chúng ta thảo luận về các tác nhân

(factors) có thể ảnh hưởng trực tiếp đến vai trò của Tester trong nhóm Agile.

3.1. Organizational Culture
Văn hóa tổ chức được định nghĩa là các giá trị (values), các quy tắc (norms) và các giả định
(assumptions). Văn hóa của tổ chức sẽ quyết định cách giao tiếp, hướng tương tác, và tạo
quyết định như thế nào, và nó dễ dàng thấy được qua việc quan sát hành vi của employee.
Văn hóa của một tổ chức có thể ảnh hưởng đến sự thành công của một nhóm Agile. Các nhóm
Agile phù hợp nhất với các tổ chức cho phép suy nghĩ độc lập. Ví dụ như, nếu một công ty có
kiến trúc phân lớp và khuyến kích phong cách (kiểu) quản lý chỉ huy thì các nhóm Agile chắc
chắn sẽ đối nghịch lại điều này. Các kinh nghiệm trong quá khứ của tổ chức cũng ảnh hưởng
đến sự thành công của một nhóm Agile mới. Nếu một công ty đang cố gắng áp dụng agile và có
kết quả không tốt, mọi người sẽ không cố gắng áp dụng lại và đưa ra trích dẫn tại sao không
hiệu quả. Họ có thể không bao giờ thực hiện nó lại lần nữa.
Chúng ta sẽ nói chính xác về Văn hóa tổ chức ảnh hưởng như thế nào đến việc các tester làm
việc trong môi trường Agile. Thư mục chứa tài nguyên giải quyết các khía cạnh văn hóa ảnh
hưởng đến nhóm.

9


3.1.1. Quality Philosophy (Triết lý chất lượng)
Xem xét triết lý chất lượng của tổ chức nằm trong các mục làm thế nào để xác định mức độ
chấp nhận của chất lượng phần mềm. Nó cho phép chất lượng kém không? Nó có nhớ các yêu
cầu chất lượng của khách hàng không hay nó chỉ quan tâm đến việc bàn giao sản phẩm cho
khách hàng nhanh nhất có thể?
Khi một tổ chức thiếu triết lý chất lượng tổng thể và ép nhóm đưa ra sản phẩm mà không quan
tâm đến chất lượng thì các tester cảm thấy bị gò ép. Lúc đó mọi sự cố gắng phát triển Agile của
nhóm sẽ đối mặt với những thách thức khó khăn.
Một số tổ chức có những nhóm kiểm thử độc lập, mạnh mẽ và đầy năng lực. Những nhóm đó,
và quản lý của họ có thể nhận thấy việc phát triển Agile sẽ làm mất đi năng lực của họ. Họ sợ

rằng Agile trái với triết lý chất lượng của họ. Đánh giá triết lý chất lượng của tổ chức và triết lý
của các nhóm thi hành nó.
Các công ty có nhân viên đề cao chất lượng sẽ dễ dàng để chuyển đổi sang Agile. Nếu một
nhóm nào đó đã sở hữu chất lượng, thì họ phải học cách chia sẻ chúng với những người khác
để thành công.
a. Whole-team Ownership of Quality (toàn team sở hữu chất lượng)
Trong chương 1 “What Is Agile Testing, Anyway?”, chúng ta đã nói cách tiếp cận toàn nhóm đến
chất lượng. Đối với nhiều nhóm tester và QA, điều này có nghĩa thay đổi suy nghĩ về việc sở
hữu chất lượng đến việc có một vai trò xác định trong việc xác định và duy trì chất lượng. Một
sự thay đổi mạnh mẽ như vậy sẽ là khó khăn có nhiều nhóm tests và QA.
Những tester làm việc trong môi trường truyền thống sẽ có một khoảng thời gian khó khăn để
điều chỉnh sang vai trò và hoạt động mới của họ. Nếu họ đến từ tổ chức mà việc phát triển và
QA có mối quan hệ đối nghịch với nhau, nó có thể khó để thay đổi từ một suy nghĩ độc lập đến
một phần không thể thiếu của nhóm. Nó có thể khó cho cả lập trình viên và tester để học cách
tin tưởng lẫn nhau.

b. Skills and Adaptability (Các kỹ năng và khả năng thích nghi)
Như đã quan sát thì phần lớn các lập trình viên không thể thích nghi với các thực hành Agile Nhưng các tester xây dựng kịch bản kiểm thử dựa vào tài liệu yêu cầu thì sao? Họ có thể đưa
ra các câu hỏi khi code được build không? Testers không thay đổi cách tiếp cận sẽ làm cho việc
kiểm thử khó có thể làm việc chặt chẽ với phần còn lại của nhóm phát triển.
Các tester chỉ sử dụng manual testing (kiểm thử thủ công) trên giao diện người dùng sẽ không
hiểu được phương pháp tự động. Những tester đó cần rất nhiều động lực để đối mặt với vai trò
thay đổi của họ, hay bởi sự thay đổi này có nghĩa phải phát triển thêm một tập các kỹ năng mới
ngoài phạm vi lợi thế của họ.

10


c. Factors that help (các nhân tố có thể giúp)
Mặc dù có nhiều vấn đề về văn hóa (cultural issues) cần xem xét, hầu hết các nhóm QA đều tập

trung và cải tiến quy trình, và các dự án Agile khuyến khích cải tiến liên tục và khả năng thích
nghi thông qua việc áp dụng các công cụ như Retrospectives. Hầu hết các chuyên gia đảm bảo
chất lượng đều khao khát nắm giữ những gì họ học được và làm cho nó tốt hơn. Những người
này đủ khả năng thích nghi để không chỉ tồn tại mà phát triển mạnh mẽ trong dự án Agile.
Nếu tổ chức tập trung vào việc đào đạo, nó sẽ khuyến khích cải tiến quy trình liên tục. Nó sẽ có
thể làm theo Agile nhanh chóng hơn tổ chức đặt nhiều giá trị vào việc họ phản ứng lại khủng
hoảng như thế nào hơn là việc cải tiến quy trình của họ.
Nếu bạn là một tester trong một tổ chức không có triết lý chất lượng hiệu quả, bạn có thể đấu
tranh để các thực hành chất lượng được chấp nhận. Phương pháp tiếp cận Agile sẽ đưa cho
bạn một cơ chế giới thiệu các thực hành hướng chất lượng tốt.
Các tester cần thời gian và đào đạo, như tất cả mọi người cần học để làm việc trong một dự án
Agile. Nếu bạn đang quản lý một nhóm bao gồm các testers, hãy chắc chắn ủng hộ họ. Các
tester thường không được đưa vào ngay từ đầu dự án Greenfield và nó chỉ phù hợp với một
nhóm làm việc với nhau trong nhiều tháng. Để giúp tester điều chỉnh, bạn có thể cần nhờ đến
một huấn luyện viên kiểm thử Agile có kinh nghiệm (experienced Agile testing coach). Thuê ai
đó đã từng làm việc trong nhóm Agile và có thể phục vụ như một người cố vấn và giáo viên sẽ
giúp các tester tích hợp với văn hóa Agile mới, cho dù họ có chuyển sang Agile cùng với nhóm
hiện tại hay tham gia vào nhóm phát triển Agile mới.

3.1.2. Sustainable Pace (tốc độ bền vững / tốc độ ổn định)
Những nhóm kiểm thử agile truyền thống thường quen với việc kiểm thử nhanh và mạnh mẽ
vào cuối dự án. Trong giai đoạn kiểm thử cuối dự án (End-of-Project) này, một số tổ chức
thường xuyên yêu cầu nhóm của họ làm việc 50, 60, hay có thể nhiều giờ hơn mỗi tuần để kịp
tiến độ (deadline). Tổ chức thường xem xét làm thêm giờ (overtime) như một thước đo của cam
kết cá nhân. Các mâu thuẫn sẽ được Agile values sẽ được giải quyết bằng cách cho phép con
người có thể làm việc tốt nhất ở bất cứ thời gian nào.
Trong các dự án Agile, khuyến kích làm việc với tốc độ bền vững. Điều này có nghĩa các nhóm
làm việc với tốc độ thích hợp để duy trì tốc độ không đổi (constant velocity) cho phép duy trì
tiêu chuẩn chất lượng cao. Các nhóm Agile mới có xu hướng quá lạc quan về việc họ có thể
thực hiện và đăng ký quá nhiều việc. Sau một iteration hoặc hai, họ học được cách đăng ký đủ

việc để không phải làm thêm mà vẫn hoàn thành công việc. 40 giờ một tuần là tốc độ bền vững
cho các nhóm XP, nó là khối lượng effort bỏ ra, nếu đưa vào từ tuần này đến tuần khác, cho
phép mọi người hoàn thành hầu hết các công việc trong chặng đường dài mà vẫn cung cấp giá
trị tốt.
Các nhóm có thể phải làm việc với tốc độ không ổn định trong giai đoạn ngắn hiện tại và sau
đó, nhưng nó chỉ là ngoại lệ, không phải tiêu chuẩn (norm). Nếu overtime cần thiết trong các

11


giai đoạn ngắn, toàn bộ nhóm có thể làm việc ngoài giờ. Nếu nó là ngày cuối cùng của một
sprint và một số stories không được kiểm thử, toàn bộ nhóm sẽ phải ở lại muộn để kết thúc việc
kiểm thử.

3.1.3. Customer Relationships (Các quan hệ khách hàng)
Trong phát triển phần mềm truyền thống, mối quan hệ giữa nhóm phát triển và khách hàng của
họ giống như mối quan hệ giữa vendor-supplier. Mặc dù nếu khách hàng là người trong nội bộ
tổ chức, nó vẫn có cảm giác như hai công ty riêng biệt hơn là hai nhóm làm việc vì mục tiêu
chung.
Phát triển Agile phụ thuộc vào sự tham gia của khách hàng hoặc ít nhất là người ủy quyền của
họ. Các nhóm Agile mời khách hàng cộng tác, làm việc ở cùng nơi nếu có thể, và nhất trí với
quy trình phát triển. Cả hai đề học hỏi điểm mạnh và điểm yếu của nhau.
Sự thay đổi trong quan hệ này cần được sự đồng thuận của cả hai phía, bất kể khách hàng có
ở trong hay ngoài tổ chức. Một mối quan hệ mở là tác nhân quan trọng dẫn đến thành công của
dự án Agile, nơi mà mối quan hệ giữa nhóm khách hàng và nhóm phát triển giống như đối tác
của nhau hơn là một mối quan hệ vendor-supplier
Có một vài đại diện domain experts, trong khi giữa thông báo liên tục cho các stakeholders, là
một phương pháp để giữ thành công trong sự hợp tác giữa developer-customer. Customers là
tác nhân thành công của dự án Agile. Họ đưa ra thứ tự ưu tiên sẽ được xây dựng và là tiếng
nói cuối cùng trong chất lượng sản phẩm. Các tester làm việc với khách hàng để nghiên cứu

yêu cầu và định nghĩa acceptance tests. Các hoạt động kiểm thử là chìa khóa để phát triển mối
quan hệ giữa nhóm phát triển và khách hàng. Đó là lý do tại sao chuyên môn kiểm thử rất cần
thiết cho các nhóm Agile.

3.1.4. Organization Size
Kích cỡ của một tổ chức tác động lớn đến việc các dự án chạy như thế nào và cấu trúc của
công ty như thế nào. Tổ chức lớn hơn, cấu trúc phân cấp được hướng đến. Kênh giao tiếp topdown được phát triển, cấu trúc báo cáo trở nên thích hợp và ít phù hợp với việc hợp tác giữa kỹ
thuật và thương mai.
a. Communication Challenges
Một số quy trình Agile đưa ra hướng thuận tiện cho việc giao tiếp trong nhóm
Nếu làm việc trong một tổ chức lớn trong đó nhóm kiểm thử độc lập với nhóm lập trình, hãy tìm
hướng để giữ việc kết nối ổn định
Vấn đề khác thường xảy ra với các công ty lớn là khách hàng không thể tham gia liên tục. Nó là
trở ngại lớn để tập hợp các yêu cầu và examples và tìm kiếm sự đồng thuận của khách hàng
vào vòng đời phát triển. Giải pháp là có các tester hay analyst với kinh nghiệm về lĩnh vực hoạt
động như đại diện khách hàng.

12


b. Conflicting Cultures within the Organization
Nếu nhóm Agile phải hợp tác với các nhóm khác sử dụng phương thức khác như phased hoặc
gated development, bạn sẽ phải đối mặt với một tập các thử thách.
Nhóm của bạn cũng có thể gặp sự chống đối của nhóm chuyên gia khi họ cố gắng bảo vệ ý
kiến cá nhân của họ.
Nếu các đối tác thứ 3 đang làm việc trên cùng hệ thống với nhóm bạn, văn hóa của họ cũng có
thể là nguyên nhân gây mâu thuẫn.
c. Advanced Planning
Nếu bạn phải hợp tác với nhóm khác, bạn cần sử dụng thời gian trong quá trình lên kế hoạch
release, hoặc trước khi bắt đầu iteration, để làm việc với họ

d. Act now, Apologize Later
Nó chỉ thường xảy ra trong một tổ chức lớn. Vòng soáy quan liêu có thể làm cho nhóm của bạn
hoàn thành công việc chậm chạp.
Nếu không có kênh nào để lấy những thứ bạn cần, hay có thể tester chưa bao giờ nói chuyện
trực tiếp với khách hàng trước đó. Hãy cố gắng tổ chức cuộc họp, hoặc tìm ai đó là đại diện
của khách hàng

3.1.5. Empower your Team (trao quyền cho nhóm)
Trong dự án Agile, điều quan trọng cho nhóm phát triển là cảm giác được trao quyền tạo quyết
định. Nếu bạn là một manager và bạn muốn nhóm agile thành công, giúp họ cảm thấy tự do
hoạt động và sáng tạo. Văn hóa tổ chức nên thích nghi với sự thay đổi này để giúp dự án Agile
được thành công

3.2. Barriers to Successful Agile Adoption by Test/QA Teams
(Các trở ngại thành công trong việc áp dụng Agile của nhóm test/QA)

3.2.1. Loss of Identify
Các tester luôn cố gắng duy trì nhóm QA độc lập vì nhiều lý do, nhưng lý do chính là sự sợ hãi,
đặc biệt:
- Sợ mất định danh QA
- Sợ rằng nếu họ báo cáo cho quản lý phát triển, họ sẽ không được hỗ trọ, lập trình viên
có quyền ưu tiên hơn
- Sợ họ bị mất đi các kỹ năng làm việc trong nhóm Agile và sẽ mất đi công việc của họ
- Sợ khi họ phân tán vào các nhóm phát triển họ sẽ không nhận được hỗ trợ họ cần
- Sợ họ và quản lý của họ sẽ bị xóa bỏ trong tổ chức mới
Chúng ta thường nghe QA managers hỏi “Công ty của tôi đang hoàn thành phát triển Agile. Vai
trò của tôi trong đó như thế nào?”. Nó liên quan trực tiếp đến các nỗi sợ “Loss of identify”

13

3.2.2. Additional Roles
Chúng ta biết rằng các nhóm mới thường bị thiếu chuyên gia hay một người am hiểu về lĩnh
vực. Có thể bạn cần ai đó có kinh nghiệm trong kiểm thử với một nhóm Agile. Hoặc bạn cần
một chuyên gia kiểm thử hiệu năng. Nó sẽ chiếm thời gian để phân tích vai trò mà bạn cần để
thành công.
Để mọi người trong nhóm thực sự hiểu được vai trò của họ hãy sử dụng thời gian và đào tạo.

3.2.3. Lack of Training
Nếu chúng ta đặt các tester vào một đơn vị phát triển mà không có đào đạo; thì chỉ trong 3
tháng, toàn bộ testers sẽ nghỉ việc vì họ không thể hiểu được vai trò mới của họ trong dự án.

3.2.4. Not Understanding Agile Concepts
Không phải nhóm Agile nào cũng giống nhau. Nó nhiều phương pháp khác nhau để phát triển
Agile như XP, Scrum, Crystal, FDD, DSDM, OpenUP ... . Họ có thể thực hiện các phương pháp
khác nhau này, nhưng nếu họ không theo bất cứ Giá trị và nguyên tắc cốt lõi của Agile nào, thì
đó không phải là phát triển Agile.

3.2.5. Past Experience/Attitude
Một số tổ chức phát triển đã có những thành công nhất định, họ bị mắc kẹt trong những quan
điểm cũ và mô hình thành công của họ. Ngay cả khi họ cố gắng làm một điều gì mới, họ cũng
dễ trở lại với các thói quen cũ khi bị căng thẳng.
Một vài ví dụ về những người chống lại thay đổi do kinh nghiệm cũ và nhận thức về “theo như
vậy - The way things are”:
- Một tester ngồi ở vị trí của mình và không nói các vấn đề của mình với programmer. Anh
ta phàn nàn rằng các programmer không hiểu những gì anh ta muốn.
- Một tester không thể rũ bỏ được thái độ hiện tại của mình mà các programmers thì
không biết làm cách nào để viết code tốt hay làm thế nào để kiểm thử nó. Thái độ hạ
mình của anh ta là rõ ràng, và trách nhiệm của anh ta bị thách thức.
- Một khách hàng đập tay khi các programmer không làm những thứ anh ta muốn, bởi họ

“luôn luôn” làm những thứ họ muốn.
Khi đối mặt với việc chuyển đổi sang phát triển Agile, những người như thế thường để lại mà
không cho quy trình mới một cơ hội. Phát triển Agile không dành cho tất cả mọi người, nhưng
đạo tạo và thời gian để thử nghiệm có thể giúp điều chỉnh thái độ. Yêu cầu mọi người là một
phần của giải pháp và làm việc với nhau để tìm ra những quy trình, những thực hành tốt nhất
phù hợp với tình huống cụ thể của họ. Nhóm tự quản (seft-organizing) là công cụ mạnh mẽ để
trấn an tất cả các thành viên của nhóm phát triển về việc họ có thể kiểm soát mục tiêu của
mình.

3.2.6. Cultural Differences among Roles
Mỗi thành viên trong nhóm Agile mới tạo ra sự chuyển đổi ở những khía cạnh khác nhau. Các
programmer thường sử dụng để viết mã production và release nó ngay khi có thể. System
administrator và database expert (quản trị hệ thống và chuyên gia dữ liệu) có thể được làm việc

14


trong silo riêng của họ, thực hiện các yêu cầu theo tiến độ của riêng họ. Các tester thực hiện
vào cuối dự án và không tương thnhiều với các programmer.
Không có gì ngạc nhiên khi sự chuyển đổi có thể đáng sợ. Nhóm có thể tạo các quy định (rules)
và hướng dẫn (guideline) để giúp họ giao tiếp và làm việc tốt với nhau.
Xác định những điều cần thiết với những người thực hiện các hoạt động khác nhau, hãy tìm
cách cung cấp nó. Khách hàng cần một số cách để biết tiến trình phát triển như thế nào và các
điều kiện mong muốn của họ có được đáp ứng không. Những người phát triển cần biết các
mức độ ưu tiên thương mại và yêu cầu. Các tester cần hướng để nắm bắt examples và chuyển
chúng vào trong kiểm thử. Toàn bộ thành viên nhóm muốn cảm thấy họ có giá trị và thành viên
nhóm hạng nhất. Mỗi thành viên nhóm cũng cần cảm thấy an toàn và tự do để đưa ra các
issues và thử những ý tưởng mới. Hiểu được tầm nhìn của các vai trò giúp nhóm thông qua
việc chuyển đổi.

3.3. Introducing Change
Khi thực hiện bất kỳ thay đổi nào, đều có tác dụng phụ. Giai đoạn đầu tiên có thể hỗn loạn;
nhóm của bạn không chắc chắn về quy trình mới, một số nhóm trung thành với thói quen cũ và
một số người không chắc chắn và gây rối. Mọi người thường nhầm giai đoạn hỗn loạn này do
hiện trạng mới. Để tránh điều này, giải thích sự thay đổi của mô hình và đặt kỳ vọng. Mong đợi
và chấp nhận hỗn loạn khi thực hiện quy trình Agile. Tìm các khu vực khó khăn nhất, và xác
định cần thực hiện gì để giải quyết vấn đề để bạn có thể thoát ngay lập tức ra khỏi hỗn loạn.

3.3.1. Talk about Fears
Khi bạn bắt đầu phát triển lặp, sử dụng retrospectives để cung cấp cho mọi người nơi để nói về
nỗi sợ hãi của họ và nơi để họ đưa ra các Feedback. Giúp mọi người biết sự sợ hãi là hoàn
toàn bình thường. Được mở rộng; dạy họ nói ra những sợ hãi và sự khó chịu của mình. Thảo
luận về nguồn gốc của nỗi sợ hãi, học hỏi từ các cuộc thảo luận, tạo các quyết định và tiến lên.
Nỗi sợ là phản ứng bình thường khi thay đổi. Buộc mọi người làm những thứ họ không muốn,
gây bất lợi cho việc thay đổi tích cực.

3.3.2. Give Team Ownership
Một tác nhân thành công quan trọng là nhóm có quyền sở hữu và có khả năng tùy chỉnh
phương pháp của họ. Mọi người có thể thay đổi thái độ và nhận thức nếu họ được giúp đỡ
ngay.
Lisa đã có thể quan sát Mike Cohn làm việc với đội ngũ của mình như là một huấn luyện viên.
Là một nhóm tự tổ chức, nhóm nghiên cứu đã xác định và giải quyết các vấn đề riêng của
mình. Mike đã chắc chắn họ đã có thời gian và nguồn lực để thử nghiệm và cải thiện. Ông đã
đảm bảo rằng các doanh nghiệp hiểu rằng chất lượng quan trọng hơn số lượng hoặc tốc độ.
Mỗi đội bóng, thậm chí một nhóm tự tổ chức, cần có một nhà lãnh đạo hiệu quả có thể tương
tác với đội ngũ quản lý của tổ chức.

15

3.3.3. Celebrate Success (ca tụng sự thành công)
Thực hiện thay đổi có thể chiếm thời gian và sự bực bội. Vì vậy hãy chắc chắn chào mừng toàn
bộ thành công với những thành quả của nhóm bạn. Vỗ lưng bạn khi hoàn thành mục tiêu đó là
viết các test cases ở mức cao (high-level) cho toàn bộ stories vào ngày thứ tư của vòng lặp
(iteration). Nhóm cùng nhau làm chơi game, ăn trưa khi thực hiện công việc trong iteration.
Thừa nhận là quan trọng nếu bạn muốn hướng đến sự thay đổi.
Đưa các tester vào nhóm phát triển cho phép họ tiếp tục báo cáo với QA manager là một cách
dễ dàng để chuyển đổi sang phát triển Agile. Tester có thể tìm cách để biến quan hệ đối lập với
developer thành hợp tác. Họ có thể cho biết họ có thể giúp nhóm hiểu yêu cầu của khách hàng
như thế nào và mang lại giá trị kinh doanh thích hợp. Họ có thể giữ những hoạt động ưa thích
để xây dựng tương tác nhóm tốt hơn. Có nhiều bánh quy (cookies) hay chocolate có sẵn cho
đồng đội (teammates) là hướng tốt để giúp họ đi ra bàn của bạn! Kiên nhẫn và cảm giác vui vẻ
là một lợi thế lớn.

3.4. Management Expectations
Khi chúng ta nghĩ về các thách thức liên quan đến việc áp dụng Agile, chúng ta thường nghĩ
đến nhóm thực tế và những vấn đề mà nó gặp phải. Tuy nhiên, để áp dụng Agile thành công,
quản lý tham gia vào là rất quan trọng. Trong các dự án theo giai đoạn, quản lý cập nhật
thường xuyên và đóng các văn bản vào cuối mỗi giai đoạn. Những người quản lý cấp trên có
thể không hiểu làm thế nào họ có thể đánh giá các dự án Agile. Họ có thể sợ mất kiểm soát hay
thiếu sót “tiến trình”.

3.4.1. Cultural Changes for Managers
Trong một dự án Agile, thay đổi được kỳ vọng. Trong vòng đời của dự án waterfall, Janet nhớ
đã nghe thấy nội dung “Chức năng này đã hoàn thành 90%” trong nhiều tuần. Kiểu chỉ số này
không có nghĩa trong dự án Agile. Không có sự thỏa hiệp để đánh dấu kết thúc một giai đoạn
và “độ chín” của một dự án không được tính bằng cột/mốc (gate)
Các số liệu hữu ích được xác định bởi mỗi nhóm dự án. Trong Scrum, Sprint và các biểu đồ
release burndown kiểm tra mức độ hoàn thành story và đưa cho manager thước đo tiến độ.
Các số liệu kiểm thử có thể sử dụng để kiểm tra mức độ bao phủ của kiểm thử (test corverage)

nhưng không đưa ra tài liệu hoàn chỉnh.
Thật khó với một số manager để hiểu rằng việc quyết định về mặt kỹ thuật và quản lý công việc
là việc riêng của nhóm. Nó không còn là quyết định của manager nữa. Nhóm (bao gồm cả
khách hàng) sẽ định nghĩa mức độ cần thiết của chất lượng để phát hành ứng dụng thành
công.
Nhóm Agile ước lượng và làm việc trong các khung thời gian ít hơn là nhóm truyền thống. Thay
vì việc phòng bị trước các tình huống bất ngờ, nhóm cần lên kế hoạch để đủ thời gian cho thiết
kế tốt và thực hiện mà vẫn đảm bảo technical debt không tăng. Thay vì quản lý các hoạt động

16


của nhóm ở mức thấp, managers của nhóm Agile cần tập trung vào việc loại bỏ trở ngại cho
các thành viên nhóm để họ có thể làm việc tốt nhất.
Các bên liên quan thương mại (Business stakeholders) không thích bất ngờ. Nếu đã thuyết
phục họ đưa đủ thời gian và nguồn lực để thực hiện quá trình chuyển đổi, họ sẽ thấy phát triển
Agile cho phép họ lập kế hoạch chính xác hơn và đạt được mục tiêu kinh doanh theo từng
bước ổn định.
Đôi khi, việc quản lý thực sự điều hướng việc quyết định bắt đầu thực hiện phát triển Agile. Các
trưởng nhóm kinh doanh (business leaders) ở công ty Lisa chọn phát triển Agile để giải quyết
khủng hoảng phần mềm. Để hiệu quả, họ cần có một tập các kỳ vọng về quản lý khác nhau. Họ
cần nhạy cảm với khó khắn của các thay đổi lớn, đặc biệt là trong một tổ chức đã không hoạt
động tốt.
Trong tất cả các trường hợp, các managers cần kiên nhẫn trong quá trình dài chuyển đổi nhóm
Agile chất lượng cao. Việc của họ là đảm bảo cung cấp đủ nguồn lực cần thiết và cho phép các
cá nhân trog nhóm học hỏi làm thế nào để thực hiện công việc với chất lượng cao.
Nếu bạn là một QA manager, hãy chuẩn bị giúp tester vượt qua nỗi sợ của họ với hoạt động từ
định nghĩa, các giai đoạn kiểm thử liên tục đến các vòng lặp nhanh chóng mặt mà họ phải thực
hiện trong một phạm vi rộng lớn mỗi ngày. Giúp họ thích ứng với việc kiểm thử không còn là
hoạt động riêng xảy ra sau khi phát triển, mà hai hoạt động kiểm thử và coding được tích hợp

với nhau.
Nếu bạn là tester hay một thành viên của nhóm khác mà không nhận được hỗ trợ trong quá
trình chuyển đổi sang phát triển Agile, hãy nghĩ về những khó khăn mà quản lý của bạn có thể
gặp phải trong quá trình tìm hiểu phát triển Agile. Giúp họ hiểu bạn cần hỗ trợ những gì.

3.4.2. Speaking the Manager’s Language
Những nhà quản lý doanh nghiệp hiểu rõ gì nhất? Đó là ROI (lợi nhuận trên vốn đầu tư - Return
On Investment). Để nhận hỗ trợ từ quản lý của bạn, đóng khung yêu cầu của bạn trong bối
cảnh mà họ có thể hiểu được. Tốc độ của nhóm bạn chuyển thành các tính năng mới làm cho
việc kinh doanh thuận lợi hơn. Nếu bạn cần thời gian và kinh phí để học và thực hiện một công
cụ kiểm thử tự động, giải thích với quản lý về thời gian làm thêm và các kiểm thử hồi quy được
tự động sẽ giúp nhóm bạn đi nhanh hơn, phát hành nhiều chức năng hơn trong mỗi vòng lặp.
Giống như toàn bộ thành viên của nhóm Agile, manager cần học các khái niệm mới và tìm cách
phù hợp với các thành viên trong nhóm. Sử dụng biểu đồ lớn để đảm bảo họ có thể thực hiện
theo tiến trình của mỗi vòng lặp và release. Tìm hướng tối đa hóa ROI. Thông thường, các
doanh nghiệp sẽ yêu cầu tính năng phức tạp và tốn kém hơn trong khi có những giải pháp đơn
giản nhanh chóng hơn mà vẫn mang lại giá trị tương tự. Hãy chắc rằng đã giải thích công việc
của nhóm ảnh hưởng đến giai đoạn cuối như thế nào. Phối hợp với họ để tìm cách tốt nhất cho
các bên liên quan để thể hiện các yêu cầu cho mỗi tính năng mới.

17


Các hạn chế về ngân sách (budget limitations) là thực tế mà hầu hết các nhóm phải đối mặt.
Khi nguồn lực bị giới hạn, nhóm cần sáng tạo hơn. Phương pháp tiếp cận toàn nhóm giúp điều
này. Có lẽ giống với nhóm của Lisa, nhóm bạn bị hạn chế về ngân sách mua phần mềm, và do
đó, bạn có xu hướng tìm các công cụ kiểm thử tự động mã nguồn mở. Một công cụ sử dụng
ngôn ngữ giống ứng dụng sẽ không giúp tester không biết lập trình, trừ khi họ hợp tác với lập
trình viên để tự động hóa các kiểm thử. Tận dụng chuyên gia trong nhóm sẽ giúp bạn làm việc
trong điều kiện giới hạn về kinh doanh.

Với toàn bộ thử thách mà nhóm bạn phải đối mặt, hãy thử những hướng mới để phát triển
nhóm và quản lý để xây dựng một sản phẩm có giá trị. Đồng thời, bất kể phương pháp phát
triển nào, bạn vẫn phải đảm bảo một số quy trình, như sự phù hợp để kiểm tra các yêu cầu và
nhận được sự quan tâm cần thiết.

3.5. Change Doesn’t Come Easy
Phát triển Agile có thể nhanh chóng mặt, nhưng thay đổi thì không. Các nhóm mới với Agile sẽ
làm chậm một số thực hành chính mà họ đã cam kết sử dụng. Chúng ta thấy nhiều tester đang
thất vọng về vòng đời phát triển “Agile” của họ thường là vòng đời phát triển mini-waterfall.
Những tester này vẫn đang bị ép buộc; nó xảy ra thường xuyên hơn. Các vòng lặp nhiều hơn
trước khi các story được kiểm thử. Lập trình viên từ chối hoặc không thể làm theo các thực
hành chính như TDD hay làm cặp (pairing). Nhóm đổ trách nhiệm cho chất lượng của các
tester, người có thể thay đổi quy trình.
Không có phép thuật mà bạn có thể sử dụng để giúp nhóm bạn tạo ra những thay đổi, nhưng
chúng ta có một số lời khuyên cho tester, người sẽ đưa nhóm họ thay đổi theo chiều hướng
tích cực.

3.5.1. Be Patient (Hãy kiên nhẫn)
Những kỹ năng mới như TDD thì khó. Tìm hướng giúp nhóm bạn có thời gian để làm chủ nó.
Tìm những thay đổi bạn có thể làm độc lập trong thời gian chờ đợi. Ví dụ, trong khi các lập trình
viên học về việc viết unit tests, bạn có thể giúp đỡ bằng cách thực hiện GUI test tool. Giúp
nhóm thực hiện các bước nhỏ. Nhớ rằng khi mọi người hoảng sợ, họ sẽ quay trở lại thói quen
cũ, mặc dù những thói quen đó không tốt. Hãy tập trung vào những phần tích cực nhỏ.

3.5.2. Let Them Feel Pain (Hãy giúp họ nhận thấy khó khăn)
Đôi khi bạn cần xem các tai nạn xe lửa. Nếu đề xuất của bạn về cải tiến bị từ chối và nhóm thất
bại, đưa đề xuất của bạn ra một lần nữa và hỏi nhóm về việc cân nhắc có cố gắng thực hiện nó
trong một vào vòng lặp không. Mọi người hầu hết bằng lòng thay đổi ở những phần mà họ cảm
thấy khó khăn nhất.

18


3.5.3. Build Your Credibility (Xây dựng tín nhiệm của bạn)
Giờ bạn có thể làm việc với các lập trình viên. Hãy cho họ viết bạn có thể giúp họ như thế nào.
Giúp họ thấy những issues hơn là việc đưa ra bug report. Hỏi họ về việc review code với bạn
trước khi họ check-in nó. Khi họ nhận thấy bạn đang góp phần tạo gia giá trị thực, họ sẽ lắng
nghe ý kiến của bạn.

3.5.4. Work on your Own Professional Development
Đọc sách báo, đi họp nhóm và dự các hội nghị, học công cụ mới hay ngôn ngữ script. Bắt đầu
học ngôn ngữ mà ứng dụng đang được code, và hỏi lập trình viên nếu bạn có thể làm cặp với
họ hoặc họ sẽ chỉ dẫn cho bạn. Nếu đồng nghiệp của bạn sẽ tôn trọng mong muốn của bạn về
việc nâng cao kỹ năng. Nếu nhóm sử dụng cục bộ (local user) bằng lòng lắng nghe bài trình
bày của bạn về Agile testing hay một bản tin phần mềm xuất bản bài viết tự động của bạn, đồng
nghiệp có thể thấy bạn có thứ gì đó đáng nghe.

3.5.5. Beware the Quality Police Mentality (cẩn thận với tâm lý cảnh giác với chất
lượng)
Hãy là một cộng tác viên, không phải một chấp hành viên. Nếu lập trình viên không theo coding
standards, nó không phải công việc của bạn để đảm bảo họ làm như vậy. Đưa ra vấn đề của
bạn với toàn nhóm và yêu cầu giúp đỡ từ họ. Nếu họ lờ đi vấn đề nghiêm trọng (critical
problem) thì điều đó thực sự đang gây tác hại cho nhóm, bạn cần đi đến người huấn luyện
(coach) hoặc manager để được giúp đỡ. Nhưng làm điều này trong mạnh “Làm ơn giúp tôi tìm
một giải pháp” hơn là “Làm cho những người này cư xử lại”. Nếu bạn nhìn thấy một vấn đề, rất
có thể người khác cũng nhìn thấy nó.

3.5.6. Vote with Your Feet (bỏ phiếu bằng cách giơ tay)
Bạn trở nên kiên nhẫn. Bạn cố gắng mọi phương pháp mà bạn đã nghĩ đến, nhưng quản lý của
bạn không hiểu được phát triển Agile. Lập trình viên thì vẫn làm lỗi, code thì không thể “vượt

qua tường” kiểm thử, và code đó được phát hành bất chấp nỗ lực của bạn, gồm cả việc làm 14
giờ một ngày. Không ai quan tâm đến chất lượng, và bạn cảm thấy bất lực. Đó là thời gian để
tìm nhóm tốt hơn. Một số nhóm thấy vui với hướng của họ và chỉ đơn giản là không cảm thấy
khó để muốn thay đổi. Lisa đã làm việc với nhóm tốt để xử lý hỗn loạn, bởi cơ hội tìm ra nguyên
nhân tại sao máy chủ bị hỏng và trở thành anh hùng. Mặc dù một dự án thành công sử dụng
các thực hành Agile, họ muốn quay lại thói quen cũ, và cuối cùng Lisa đã từ bỏ sự cố gắng để
thay đổi họ.

Summary
Trong chương này, chúng ta nói về các vấn đề văn hóa có thể ảnh hưởng đến các tester như
thế nào và nhóm của họ tạo ra chuyển đổi thành công để áp dụng phát triển Agile
-

Hãy xem xét văn hóa tổ chức trước khi đưa ra bất kỳ thay đổi nào.
Testers sẽ tích hợp dễ dàng với nhóm Agile khi toàn bộ tổ chức đánh giá cao chất
lượng, nhưng tester sẽ phải đấu tranh với tư tưởng “quality police”.

19


-

-

-

Một số tester có thể gặp khó khăn khi điều chỉnh việc toàn bộ nhóm sở hữu chất lượng,
nhưng phương pháp toàn nhóm giúp vượt qua những khác biệt văn hóa.
Nhóm khách hàng và nhóm phát triển nên làm việc gần nhau và chúng cho thấy tester
có thể là chìa khóa cho việc thúc đẩy mối quan hệ này.

Tổ chức lớn hướng đến các nhóm chuyên gia cô lập nhiều hơn, sẽ đối mặt với những
khác biệt văn hóa của từng vùng như thông tin liên lạc và hợp tác.
Những rào cản chính đến thành công của tester khi áp dụng Agile bao gồm sự sợ hãi,
mất bản sắc, thiếu đào tạo, kinh nghiệm tiêu cực trước đó với quy trình phát triển mới
và khác biệt văn hóa giữa các vai trò.
Để giúp giới thiệu các thay đổi và thúc đẩy giao tiếp, chúng tôi đề nghị các thành viên
nên thảo luận về nỗi sợ hãi và chào mừng mọi thành công, không vấn đề nhỏ nhứ thế
nào.
Các hướng dẫn như “Test bill of rights” cung cấp cho tester sự tự tin để đưa ra các
issues và giúp họ cảm thấy an toàn để học và đưa ra ý tưởng mới.
Managers đối mặt với những thách thức văn hóa của riêng họ, và họ cần hỗ trợ và đào
tạo để giúp tester thành công trong nhóm Agile.
Tester có thể giúp nhóm thích nghi với các kỳ vọng của manager bằng cách cung cấp
thông tin mà manager cần để theo dõi tiến độ và xác định ROI.
Thay đổi thì không đến dễ dàng, hãy kiên nhẫn, cải thiện kỹ năng của bạn và bạn có thể
giúp được đội của mình.

Chapter 4 - Team Logistics

Việc giao tiếp mặt đối mặt (face-to-face communication) của các nhóm Agile là tác nhân quan
trọng để dự án thành công. Việc sử dụng tiếp cận toàn nhóm (whole-team) cũng được khuyến
khích. Điều này có nghĩa các tester cần làm gì? Chương này nói về một số vấn đề về cấu trúc
nhóm và logic vật lý (team structure and physical logictics). Có nhiều cách để gắn kết nhóm hơn
việc di chuyển bàn và ghế.

20


4.1. Team Structure
Có các nhóm chức năng riêng biệt có thể làm khó các nhóm Agile. Liên lạc liên tục thì quan

trọng. Các thành viên nhóm cần làm việc gần với những người khác; công việc sẽ gần như
hoàn thành hay ở trong cùng vị trí vật lý.
Chúng ta sử dụng “QA team” và “test team” có thể hoán đổi cho nhau. Nó có thể chỉ rõ “QA
team” thực sự thực hiện đảm bảo chất lượng hay không, nhưng mục này trở nên thông dụng
để gắn với test team, vì vậy cung ta cũng có thể sử dụng nó.

4.1.1. Independent QA Teams
Nhiều tổ chức nhỏ và lớn, có nhóm QA hay test độc lập rất quan trọng để nhận được đánh giá
trung thực về chất lượng sản phẩm. Chúng ta thường hỏi câu hỏi “Có nơi nào mà tổ chức kiểm
thử trong tiếp cận toàn nhóm?” và “nếu như vậy, vai trò của nó là gì?”
Có một số lý do mà chúng tôi muốn giữ QA team độc lập với development team:
- Điều quan trọng là phải có kiểm tra và vai trò kiểm tra độc lập.
- Nhóm có thể cung cấp một cái nhìn khách quan và bên ngoài liên quan đến chất lượng
sản phẩm
- Nếu tester làm việc gần với các developers, họ sẽ bắt đầu nghĩ giống developer và mất
đi tầm nhìn của khách hàng.
- Nếu tester và developer báo cáo cho cùng một người, có một nguy cơ là mức độ ưu tiên
trở thành cung cấp bất kỳ code nào hơn là cung cấp mã đã được kiểm thử.
Các nhóm thường nhầm “độc lập - independent” với “riêng biệt - separate”. Nếu cấu trúc báo
cáo, ngân sách, và các quy trình được lưu trữ trong các vùng chức năng khác nhau, sự phân
chia programmer và tester là không tránh khỏi. Nó có thể dẫn đến xích mích, cạnh tranh và thái
độ “so với họ, chúng tôi…”. Thời gian lãng phí vào những cuộc họp trùng lặp, các programmer
và tester không chia sẻ một mục tiêu chung và không tồn tại việc chia sẻ thông tin.
Có nhiều lý do để có một QA manager và một nhóm tester độc lập. Tuy nhiên, chúng tôi đề nghị
thay đổi lý do cũng như cấu trúc. Thay gì giữ các tester riêng biệt như một nhóm độc lập để
kiểm thử ứng dụng sau coding, hãy nghĩ về nhóm như một cộng đồng các tester. Cung cấp một
tổ chức học tập để giúp testers phát triển nghề nghiệp và nơi để họ có thể chia sẻ ý kiến và
giúp đỡ những người khác. Nếu QA manager trỏ thành trưởng nhóm thực hành trong tổ chức,
người đó có thể dạy những kỹ năng để các tester trở nên mạnh mẽ hơn và có khả năng đối phó
với môi trường thay đổi không ngừng.

Chúng tôi không tin việc tích hợp tester với các nhóm dự án ngăn các tester làm tốt công việc
của họ. Trong thực tế, tester trong các nhóm Agile cảm thấy mạnh hơn với vai trò hỗ trợ khách
hàng và họ cũng có thể ảnh hưởng tư duy chất lượng đến các nhóm khác.

21


4.1.2. Integration of Testers into an Agile Project
Tiếp cận toàn nhóm (whole-team) trong phát triển Agile đã làm cho nhiều tổ chức thông qua
việc phát triển Agile để giải tán nhóm QA độc lập và gửi tester của họ đến làm việc với các
nhóm dự án. Điều này rất tuyệt, nhưng một số tổ chức đã thấy nó không hoạt động hiệu quả.
Nhiều tổ chức, không phải tất cả, các tester của họ nghỉ việc khi họ thấy họ không biết họ sẽ
làm gì trong phát triển Agile.
Các developers được đào tạo về lập trình cặp (pair programming), phát triển điều hướng kiểm
thử (test-driven development), và các thực hành Agile khác, trong khi tester thường không
được đào tạo gì. Nhiều tổ chức không nhận ra rằng testers cũng cần đào tạo về kiểm thử cặp
(pair testing), làm việc với các yêu cầu không đầy đủ và thay đổi, tự động hóa và toàn bộ các kỹ
năng mới cần thiết. Điều quan trọng là tester nhận được đào tạo và huấn luyện để họ có được
các kỹ năng và sự hiểu biết để giúp họ thành công, như làm việc với khách hàng như thế nào
để viết các kiểm thử business-facing. Các programmer cũng phải huấn luyện để hiểu được tầm
quan trọng của các kiểm thử business-facing và tiếp cận toàn nhóm và tự động hóa các kiểm
thử.
Janet đã giúp tích hợp một vài nhóm kiểm thử độc lập vào dự án Agile. Cô nhận thấy rằng nó
có thể mất sáu tháng để hầu hết các tester bắt đầu cảm thấy tự tin về công việc với quy trình
mới.
Làm việc cặp giữa programmer và tester có thể chỉ cải tiến giao tiếp về chất lượng sản phẩm.
Các developer cần phải quan sát hành vi của ứng dụng trên máy của tester nếu hành vi đó
không được tái hiện trên môi trường phát triển. Các tester có thể ngồi với developer để tái hiện
lại vấn đề, nó sẽ dễ dàng và nhanh chóng hơn là việc họ cố gắng ghi lại các bước trong defect
(khuyết điểm). Tương tác này giảm thời gian cho việc giao tiếp không bằng lời nói.

Chúng tôi nghe một số ý kiến từ các tester trong dự án như sau:
- “Gần gũi hơn với sự phát triển sản phẩm làm cho tôi trở thành tester tốt hơn”
- “Đi ăn trưa với các developer xây dựng một nhóm tốt hơn, muốn và thích làm việc cùng
với nhau hơn”
Một lợi thế lớn của một nhóm dự án được tích hợp là chỉ có một ngân sách và một lịch
trình.Thời gian “kiểm thử” không bị cắt nếu toàn bộ chức năng không được hoàn thành. Nếu
không có thời gian để kiểm thử chức năng mới, sau đó không có thời gian để phát triển nó ở
nơi đầu tiên. Tiếp cận toàn nhóm chịu trách nhiệm về chất lượng rất mạnh mẽ, khi chúng tôi
nêu trong cuốn sách này.
Các tester cần phải là thành viên chính thức của nhóm phát triển, và các việc kiểm thử cần
được chú ý như các việc khách. Một lần nữa, tiếp cận toàn nhóm để kiểm thử đi một chặng
đường dài hướng đến việc đảm bảo các việc kiểm thử được hoàn thành vào cuối mỗi vòng lặp
và khi phát hành. Hãy chắc chắn sử dụng retrospectives để đánh giá những gì tester cần tích
hợp với nhóm Agile mới của họ và những kỹ năng nào họ cần để đạt được. Ví dụ, tester có thể
cần hỗ trợ nhiều hơn từ programmers, hoặc từ một chuyên gia về một kiểu kiểm thử nào đó.

22


Một tiếp cận thông minh để lập kế hoạch thay đổi tổ chức đến phát triển Agile là làm cho tất cả
các khác biệt được chuyển đổi thành công. Hãy hỏi các QA manager và development manager
để tìm ra vai trò của họ trong tổ chức Agile mới. Giúp họ có kế hoạch làm thể nào họ sẽ giúp
testers và developers trở nên có hiệu quả trong nhóm Agile mới. Đưa ra các đào tạo về các
thực hành Agile mà nhóm chưa biết. Đảm bảo toàn bộ nhóm có thể giao tiếp với nhau. Đưa ra
khung làm việc để mỗi nhóm biết được nó đi như thế nào và thấy được hướng để thành công.

4.1.3. Agile Project Teams
Nhóm dự án Agile thường được coi là nhóm đa (liên) chức năng, bởi mỗi nhóm có các thành
viên từ nhiều nguồn gốc khác nhau. Sự khác biệt giữa nhóm đa chức năng truyền thống và một
nhóm Agile là cách tiếp cận toàn nhóm. Các thành viên không chỉ “đại diện cho” chức năng của

họ trong nhóm mà trở thành thành viên đúng nghĩa trong nhóm lâu như dự án hay tồn tại vĩnh
viễn (xem hình 4-1)
Vì các dự án khác nhau về kích thước, các nhóm dự án cũng có thể có cấu trúc khác nhau. Tổ
chức với các dự án lớn hay nhiều dự án xảy ra đồng thời sử dụng cấu trúc ma trận thành công.
Con người từ các lĩnh vực khác nhau kế hợp để tạo thành một nhóm ảo trong khi vẫn báo cáo
với cơ cấu tổ chức riêng của họ. Trong một tổ chức lớn, một vùng các tester có thể di chuyển
từ dự án này đến dự án khác. Một số chuyên gia, như các kiểm thử bảo mật hay hiệu năng
(security or performance tester), có thể chia sẻ đến một vài nhóm. Nếu bạn bắt đầu một dự án,
xác định toàn bộ nguồn lực mà dự án cần. Xác định số lượng tester cần và kỹ năng yêu cầu
trước khi bắt đầu. Tester bắt đầu với nhóm và giữ công việc cho đến khi dự án hoàn thành, và
họ sẽ đi đến dự án tiếp theo.
Trong khi các tester là một phần của nhóm, công việc hằng ngày của họ được quản lý giống với
công việc của nhóm dự án. Một tester có thể đưa các ý tưởng mới trong cộng đồng tester lớn,
nơi mà các tester đến từ các nhóm dự án khách nhau trong tổ chức lớn. Toàn bộ tester có thể
chia sẻ kinh nghiệm, ý tưởng. Trong tổ chức sẽ đánh giá hiệu suất, QA manager (nếu có) có thể
nhận đánh giá và nhận ý kiến từ các nhóm dự án.

23


Như với bất kỳ nhóm mới nào, nó sẽ chiếm một thời gian để nhóm trở nên ổn định. Nếu chiều
dài của dự án ngắn và nhóm thì thay đổi liên tục, tổ chức cần phải nhận thức được rằng vòng
lặp thứ nhất và thứ hai của mỗi dự án sẽ bao gồm các thành viên trong nhóm mới được sử
dụng để làm việc với nhau. Cấu trúc lại tổ chức nếu cần thiết, và nhớ rằng bao gồm cả các
khách hàng của bạn. Những nhóm tốt nhất là những nhóm học cách làm việc cùng nhau và
phát triển niềm tin vào nhau.

4.2. Physical Logistics
Nhiều tổ chức đang nghĩ việc áp dụng Agile là cố tạo ra các nhóm dự án cùng vị trí trong môi
trường phát triển mở. Để hỗ trợ giá trị và nguyên tắc Agile, các nhóm làm việc tốt hơn khi họ

sẵn sàng tiếp cận tất cả các thành viên trong nhóm, dễ dàng nhìn thấy các bảng xếp hạng tiến
độ dự án và một môi trường thúc đẩy giao tiếp.
Tester và customer ngồi gần với programmer là sự giao tiếp cần thiết. Nếu đội cùng vị trí, nhóm
có thể đầy sáng tạo.
Kích thước nhóm đưa ra các thách thức khác nhau cho tổ chức. Các nhóm nhỏ có nghĩa phạm
vi nhỏ, vì vậy nó dễ dàng để định vị trí các thành viên. Các nhóm lớn có thể trên toàn cầu, và
các công cụ giao tiếp ảo là cần thiết. Các nhóm lớn cùng vị trí thường có nghĩa phải cải tạo
không gian hiện có, mà một số tổ chức không muốn làm. Hiểu những khó khăn của bạn, và cố
gắng tìm các giải pháp cho vấn đề mà nhóm bạn gặp phải chức không phải chấp nhận những
thứ như “The way it is.”
Các nhóm cùng vị trí không luôn luôn sống trong thế giới hoàn hảo, và các nhóm phân phối có
một tập các thử thách. Nhóm phân phối cần kỹ thuật để giúp họ giao tiếp và cộng tác.
Teleconferencing, Video conferencing, webcams, và instant messaging là một số công cụ có thể
thúc đẩy sự hợp tác thời gian thực cho nhóm tại nhiều vị trí khác nhau.
Cho dù nhóm cùng vị trí hay ở những chỗ khác nhau, những câu hỏi thường được đặt như
nguồn lực nào là cần thiết trong một nhóm Agile và làm thế nào để có được chúng. Chúng tôi
sẽ thảo luận trong phần tiếp theo.

4.3. Resources
Thành viên nhóm Agile mới và manager của họ có nhiều câu hỏi về bản chất của nhóm. Chúng
ta có thể sử dụng cùng các tester mà chúng ta đã có với các dự án truyền thống, hoặc chúng ta
cần thuê tester kiểu khác? Chúng ta cần bao nhiêu tester? Chúng ta cần những người có kỹ
năng đặc biệt? Trong chương này, chúng ta nói một chút về những câu hỏi này.

4.2.1. Tester-Developer Ratio
Có nhiều cuộc thảo luận về tỷ lệ “đúng” của số lượng tester và số lượng developer. Tỷ lệ này
được sử dụng bởi các tổ chức để xác định cần bao nhiêu tester cho một dự án để họ có thể

24

thuê cho phù hợp. Như với các dự án truyền thống, không có tỷ lệ “đúng”, và mỗi dự án cần
phải được đánh giá riêng. Số tester cần thiết sẽ thay đổi và phụ thuộc vào sự phức tạp của ứng
dụng, tập kỹ năng của tester và các công cụ được sử dụng.
Chúng tôi đã làm việc trong nhiều nhóm khác nhau với tỷ lệ tester/developer từ 1:20 đến 1:1.
Dưới đây là một vài kinh nghiệm của chúng tôi.
Thay vì tập trung vào một tỷ lệ, nhóm cần đánh giá các kỹ năng kiểm thử mà họ cần và tìm
nguồn lực thích hợp. Một nhóm chịu trách nhiệm kiểm thử có thể liên tục đánh giá xem nó có
chuyên môn và băng thông cần thiết không. Sử dụng retrospective để xác định liệu thuê nhiều
tester có giải quyết được vấn đề hay không.

4.2.2. Hiring an Agile Tester
Như chúng ta thảo luận ở chương 2 “Ten Principles for Agile Testers”, Có một số phẩm chất mà
một tester cần có để phù hợp với một nhóm Agile. Chúng tôi không muốn đi vào chi tiết về kiểu
tester cần thuê, vì nhu cầu của mỗi nhóm là khác nhau. Tuy nhiên, chúng tôi cho rằng thái độ là
yếu tố quan trọng.
Chúng tôi cần phải xem xét nhiều hơn chỉ là vai trò tester và programmer thực hiện trong nhóm.
Không vấn đề chúng ta đang cố gắng bù vai trò nào. Quan trọng nhất vẫn là làm thế nào để
người đó phù hợp với nhóm. Với tiếp cận toàn nhóm Agile, chuyên gia trong nhóm có thể được
yêu cầu bước ra ngoài lĩnh vực chuyên môn của họ và thu được trong các hoạt động khác. Mỗi
thành viên nhóm cần có sự tập trung mạnh vào chất lượng và cung cấp giá trị thương mại. Hãy
xem xét nhiều hơn về các kỹ năng kỹ thuật khi bạn đang mở rộng nhóm.

4.4. Building a Team
Chúng ta đã nói về tiếp cận toàn nhóm (whole-team approach). Nhưng thay đổi như thế không
xảy ra. Chúng tôi nhận được câu hỏi như “Làm thế nào để chúng ta có được một nhóm ổn
định?” hay “làm thế nào để chúng ta thúc đẩy tiếp cận toàn nhóm?” Một trong những câu hỏi
lớn là “Làm thế nào để chúng ta giữ được động lực và tập trung của mọi người vào mục tiêu
cung cấp giá trị thương mại?”

4.4.1. Self-Organizing Team (nhóm tự quản)
Theo kinh nghiệm của chúng tôi, nhóm đưa ra tiến độ tốt nhất khi họ được trao quyền để xác
định và giải quyết các vấn đề của riêng họ. Nếu bạn là một manager, hãy chống lại việc áp đặt
tất cả ý tưởng tốt của bạn vào nhóm. Có những vấn đề, như vấn đề về nhân sự, được giải
quyết tốt nhất bởi các manager, và có lúc một huấn luyện viên cần cung cấp sự khích lệ mạnh
mẽ và dẫn dắt nhóm khi nó cần sự lãnh đạo (leadership). Phải mất thời gian cho nhóm Agile
mới để học làm thế nào để phân mức độ ưu tiên và giải quyết các vấn đề của nó, nhưng nó vẫn
có thể chấp nhận để nhóm tạo ra lỗi (mistakes) và vấp ngã một vài lần.

25