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

In the world of software development, the term agile typically refers to any approach to project management that strives to unite teams around the principles of collaboration, flexibility, simplicity, transparency, and responsiveness to feedback throughout the entire process of developing a new program or product. And agile testing generally means the practice of testing software for bugs or performance issues within the context of an agile workflow. Đây là bản dịch từ quyển AddisonWesleyAgileTestingAPracticalGuideforTestersandAgileTeams2009

- 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:

- 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

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

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ử

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

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

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ử

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.

- 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

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

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ọ

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

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 top-down đượ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

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”

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

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

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

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

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

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”

- 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ế

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

độ “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

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 đó

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

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ể

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

Chúng tôi nghĩ rằng một đội hoạt động tốt phải phát triển chính bản thân nó Nếu bạn là một tester, bạn có một vị trí tốt để giúp nhóm có được phản hồi (feedbacks) nhanh, sử dụng các thực hành như retrospectives để định mức độ ưu tiên và địa chỉ cho các vấn đề, và tìm những

kỹ thuật giúp nhóm tạo ra phần mềm tốt hơn

4.4.2 Involving Other Teams (Gồm nhiều nhóm)

Bạn có thể cần các nhóm khác để nhóm bạn hoạt động thành công Hãy thiết lập các cuộc họp; tìm hướng giao tiếp càng nhiều càng tốt Sử dụng Scrum của Scrum để giữ nhiều nhóm phối hợp, hay chỉ tham gia như các nhóm khác Nếu bạn đưa vào một chuyên gia để giúp kiểm thử bảo mật (security testing), làm cặp với chuyên gia và tìm hiểu càng nhiều càng tốt, và giúp họ học về dự án của bạn

Nếu nhóm nằm rải rác ở các địa điểm và múi giờ khác nhau, tìm cách để có thể giao tiếp trực tiếp càng nhiều càng tốt Có lẽ các đại diện từ mỗi nhóm có thể điều chỉnh giờ của họ một hoặc hai lần một tuần để họ có thể hội nghị (teleconference) một lần một tuần Thực hiện cuộc gọi thay cho một email khi có thể Nhóm của Lisa điều chỉnh thời gian họp lên kế hoạch (planning meeting) để gộp một thành viên nhóm từ xa đã làm việc muộn vào ban đêm Họ lên lịch họp một thời gian, nơi ngày của anh ta trùng với ngày của nhóm

4.4.3 Every Team Member has Equal Value (mỗi thành viên trong nhóm thì ngang

nhau)

Mỗi thành viên nhóm có giá trị ngang nhau Nếu tester hay bất kỳ thành viên nhóm nào cảm thấy bị loại ra hay ít có giá trị, tiếp cận toàn nhóm (whole-team approach) sẽ bị tiêu diệt Đảm bảo tester được mời đến tất cả các cuộc họp Nếu bạn là một tester và ai đó quên không mời bạn đến cuộc họp, hãy mời chính mình Những tester không có kỹ thuật có thể nghĩ họ sẽ được đưa ra khỏi chỗ hoặc quá tải trong một cuộc họp thiết kế (a design meeting), nhưng đôi khi họ đặt câu hỏi tốt mà các chuyên gia không nghĩ đến

Các tester có quyền yêu cầu và nhận sự giúp đỡ Nếu bạn là một tester bị kẹt trong vấn đề tự động hóa, hãy cam đảm đề nghị thành viên nhóm giúp đỡ Người đó có thể bận lúc bấy giờ, nhưng anh ta/cô ý phải cam kết giúp đỡ bạn trong một khoảng thời gian hợp lý Nếu bạn là một manager hay leader trong nhóm, hãy chắc chắn nó được thực hiện và nêu vấn đề cho nhóm nếu ngược lại

4.4.4 Performance an Rewards (Thưởng cho hiệu quả công việc)

Việc đo đạc và đánh giá hiệu quả dựa trên cơ sở cá nhân có nguy cơ phá hoại hợp tác nhóm Chúng tôi không muốn programmer cảm thấy cô ấy không nên thực hiện việc kiểm thử (testing task) bởi cô ấy muốn tập trung vào việc cung cấp mã sản phẩm Chúng tôi không muốn quản trị

hệ thống (system administrator) không quá bận rộn để đảm bảo hoàn thành mục tiêu cá nhân của cô ấy, khiến cô ấy không thể giúp đỡ khi xảy ra vấn đề với môi trường kiểm thử

Ngược lại, một người thực hiện tốt luôn cố gắng làm việc tốt nhất với nhóm mà không bị đánh bại bởi phần còn lại của nhóm không kéo lại với nhau Đây là thời điểm mà một manager cần bước lên và giúp nhóm tìm ra hướng đi Nếu lỗi lớn được đưa lên production, không ai nên đổ lỗi cho tester Thay vào đó, toàn nhóm nên phân tích điều gì đã xảy ra và bắt đầu các bước để ngăn ngừa tái phát.

Nhóm phát triển (development team) cần giữ những yêu cầu nghiệp vụ trong đầu Thiết lập mục tiêu cho việc kinh doanh, tăng lợi nhuận, và làm cho khách hàng hạnh phúc hơn Làm việc chặt chẽ với doanh nghiệp để thành công của bạn và cũng là giúp cho cả công ty thành công

Như chúng tôi đã đề cập trong chương 3 “Cultural challenges”, ăn mừng mỗi khi thành công, tuy nhỏ Một lễ kỷ niệm có thể là một high-five, một bữa ăn trưa do công ty cung cấp, hay có thể cho phép nghỉ sớm hơn một chút Scrum Master trong nhóm Lisa đưa ra các ngôi sao vàng trong cuộc họp hằng ngày (stand-up meeting) cho những thành tích đặc biệt Sự thừa nhận của mọi người giúp bạn và nhóm của bạn

Nhóm có thể tìm ra hướng mới lạ để nghi nhận các đóng góp của mọi người trong nhóm Trong các cuộc họp xem xét và trình bày vòng lặp (Iteration review và demonstration meeting), cả nhóm phát triển và nhóm khách hàng đều có mặt, là một thiết lập tốt để công nhận cả hai thành tích cá nhân và nhóm

4.4.5 What can you do? (Bạn có thể làm gì?)

Nếu bạn là một tester mới trong nhóm Agile, đặc biệt là nhóm Agile mới, bạn cần phải làm gì để giúp nhóm vượt qua các thách thức của tổ chức và thành công? Bạn có thể thích nghi với nhóm và đóng góp các kỹ năng và kinh nghiệm của bạn như thế nào?

Đặt ra 10 nguyên tắc mà chúng tôi đã mô tả trong chương 2 để làm việc Cam đảm là phần đặc biệt quan trọng Hãy đứng dậy và nói chuyện với mọi người; hỏi xem bạn có thể giúp được gì Tiếp cận các thành viên nhóm và nhóm khách bằng cách giao tiếp trực tiếp Chú ý những trở ngại và yêu cầu nhóm giúp loại bỏ chúng

Phát triển Agile hiệu quả, bởi nó loại bỏ các chướng ngại vật ra khỏi đường đi và giúp nhóm làm việc tốt nhất Chúng tôi có thể cảm thấy tự hào và hài lòng, cá nhân cũng như toàn nhóm Khi chúng tôi làm theo các nguyên tắc Agile, chúng tôi hợp tác tốt, sử dụng phản hồi để giúp cải tiến việc chúng tôi làm, và luôn luôn tìm kiếm hướng mới và tốt hơn để hoàn thành mục tiêu Tất cả có nghiaxchungs tôi liên tục nâng cao chất lượng của sản phẩm

- Các tester cần truy cập vào một cộng đồng các tester rộng lớn để học hỏi và đưa ra các

ý tưởng mới Nhóm QA có thể tạo ra cộng đồng này trong tổ chức

- Điều quan trọng là toàn nhóm được ngồi cùng nhau, để thúc đẩy sự hợp tác; nếu nhóm

bị chia tách, cung cấp các công cụ để thúc đẩy liên lạc

- Hãy trả tiền cho thái độ

- Không có tỷ lệ tester-developer chính xác Câu trả lời đúng là “Nó phụ thuộc vào tình hình của bạn.”

- Các nhóm cần tự quản, xác định và tìm các giải pháp cho vấn đề của mình, và tìm kiếm hướng cải tiến Họ không thể chờ ai đó nói với họ phải làm gì

- Quản lý nên thưởng cho hiệu suất theo hướng thúc đẩy nỗ lực của nhóm để mang lại giá trị thương mại, chứ không nên phạt thành tích cá nhân nếu nhóm gặp khó khăn

- Các tester có thể sử dụng các nguyên tắc Agile để cải thiện kỹ năng bản thân và tăng giá trị của họ trong nhóm Họ cần chủ động và tìm cách đóng góp cho nhóm

Chapter 5 - Transitioning Typical Processes

Chuyển đổi các quy trình đặc thù

Có nhiều quy trình trong dự án truyền thống không chuyển đổi được sang Agile, bởi chúng yêu cầu nhiều văn bản (documentation) hay một phần cố hữu thuộc về phased và gated process, và yêu cầu đóng ở cuối mỗi giai đoạn

Giống như bất cứ điều gì, không có quy tắc cứng nhắc và nhanh chóng để chuyển các quy trình của bạn sang quy trình nhẹ và nhanh nhẹn hơn Trong chương này, chúng ta thảo luận về một vài quy trình, và đưa cho bạn sự thay thế và hướng dẫn làm thế nào để làm việc với chúng trong dự án Agile Bạn sẽ thấy nhiều ví dụ và chi tiết những thay đổi trong phần III, IV, V

5.1 Seeking Lightweight Processes

Tìm kiếm các quy trình hạng nhẹ

Khi các nhóm học làm thế nào để sử dụng các quy trình Agile, một số quy trình truyền thống có thể xóa bỏ sự lộn xộn Hầu hết các tester đều quen làm việc với phương pháp phát triển theo giai đoạn (phased) và cột mốc (gated) truyền thống để tạo ra và sử dụng số liệu, nghi lại các lỗi (defects) trong hệ thống theo dõi lỗi (formal defect tracking system), và viết kế hoạch kiểm thử (test plan) chi tiết Những điều đó phù hợp chỗ nào với phát triển Agile?

Nhiều tổ chức phần mềm nên tuân thủ hệ thống đánh giá và mô hình quy trình chất lượng Những yêu cầu đó không thường biến mất bởi bạn chỉ mới bắt đầu sử dụng các thực hành phát triển Agile Trong thực tế, một số người lo lắng rằng phát triển Agile sẽ không thương thích các

mô hình và các chuẩn như CMMI và ISO 9000

Nó có thể thú vị hơn để nói về những thứ mới và khác khi kiểm thử trong dự án Agile, nhưng chúng tôi vẫn cần hướng để đo đạc tiến độ (measure progress), theo dõi lỗi (track defects) và

kế hoạch kiểm thử (plan testing) Chúng ta cũng cần chuẩn bị làm việc với mô hình chất lượng của tổ chức Điều quan trọng là giữ các quy trình đủ nhẹ để giúp chúng ta cung cấp giá trị một cách kịp thời Hãy bắt đầu bằng cách nhìn vào số liệu

5.2 Metrics

Số liệu có thể gây tranh cãi, và chúng ta sử dụng nhiều thời gian để nói về nó Số liệu có thể là nơi đưa ra những nguồn lực bị lãng phí, những nhóm mục đích của các con số (metrics can be

a pit of wasted effort, numbers for the sake of numbers) Đôi khi chúng được sử dụng theo cách

có hại, mặc dù chúng không phải xấu Chúng có thể hướng dẫn nhóm bạn và giúp đo đạc tiến

độ của bạn so với các mục tiêu Chúng ta hãy xem làm thế nào để sử dụng các số liệu để giúp Agile tester và nhóm của họ

5.2.1 Lean Measurements (Những đo lường lean)

Những học viên phát triển phần mềm Lean tìm cách giảm số lượng các thước đo và tìm các thước đo thúc đẩy hành vi đúng đắn Thực hành phát triển phần mềm Lean: từ ý tưởng đến tiền mặt (Implementing Lean Software Development: From Concept to Cash), của Mary và Tom Poppendiek, là nguồn tuyệt vời để dạy làm thế nào để áp dụng những bước đầu lean vào kiểm thử của bạn và phát triển các nguồn lực (effort)

Theo Poppendiecks [2007], phép đo đạc lean cơ bản là thời gian cần đi “từ ý tưởng đến tiền mặt”, từ yêu cầu tính năng của khách hàng đến phần mềm được phát hành Họ gọi phép đo này là “chu kỳ thời gian - cycle time” Tập trung vào khả năng của nhóm để cung cấp giá trị thương mại mới “lặp lại nhiều lần và đáng tin cậy” Sau đó, nhóm cố gắng liên tục cải tiến quy trình của họ và giảm thời gian chu kỳ

Việc đo lường như thời gian chu kỳ đòi hỏi toàn bộ nhóm có thể khiến bạn hướng đến thành công hơn là các phép đo bị hạn chế trong những vai trò và nhóm riêng biệt Nó thường mất bao nhiêu lâu để sửa một lỗi (defect)? Nhóm có thể làm gì để giảm độ trễ, lượng thời gian cần thiết? Những số liệu kiểu này khuyến khích phối hợp để tạo ra các cải tiến.

Đo lường lean khác, theo Poppendiecks giải thích trong sách của họ là lợi nhuận tài chính Nếu nhóm đang phát triển một sản phẩm có lợi, cần phải hiểu rằng làm thế nào để nó đạt được lợi nhuận tốt nhất Ngay cả khi nhóm đang phát triển phần mềm nội bộ hay một số sản phẩm phi lợi nhuận khác, nó vẫn cần xem xét ROI để đảm bảo nó cung cấp giá trị tốt nhất Xác định mục tiêu thương mại và tìm hướng đo những gì mà nhóm cung cấp Công ty đang cố gắng để thu hút khách hàng mới đúng không? Giữ việc theo dõi bao nhiêu tài khoản mới được đăng ký như tính năng mới cần phát hành

Phát triển lean tìm cách để hài lòng khách hàng, nó nên là mục tiêu của toàn bộ phát triển phần mềm Poppendiecks đưa ra ví dụ về cách đơn giản, bạn có thể đo lường xem liệu khách hàng

có hài lòng không

Chúng tôi thích số liệu lean, bởi chúng phù hợp với mục tiêu của chúng tôi để cung cấp giá trị thương mại Tại sao chúng tôi quan tâm đến các số liệu? Chúng ta đi đến phần tiếp theo

5.2.2 Why We Need Metrics (Tại sao chúng ta cần các số liệu)

Có nhiều lý do tốt để tập hợp và theo dõi các số liệu Cũng có một số lý do xấu Bất cứ ai cũng

có thể sử dụng những số liệu tốt theo cách khủng khiếp, chẳng hạn như sử dụng chúng như cơ

sở để đánh giá hiệu suất của mỗi thành viên nhóm Tuy nhiên, không phải số liệu, mà bạn đo đạc tiến độ của bạn như thế nào?

Khi số liệu được sử dụng như các thông báo hướng dẫn - nói với nhóm khi nó bỏ theo dõi hay cung cấp phản hồi mà nó là theo dõi đúng - chúng là tập hợp đáng giá Số lượng unit tests của chúng ta tăng lên mỗi ngày? Tại sao code coverage lại giảm từ 75% đến 65%? Nó có thể là lý

do tốt - Có lẽ chúng ta đã thoạt khỏi mã không sử dụng nữa nhưng được bao phủ bởi các kiểm thử Các số liệu có thể cảnh báo cho chúng ta về các vấn đề, nhưng nếu tách ra chúng thường không có giá trị

Số liệu để đo các cột mộc (milestones) theo hành trình để đạt được mục tiêu của nhóm rất hữu ích Nếu mục tiêu là tăng độ bao phủ của mã kiểm thử đơn vị (unit test code coverage) lên 3%, chúng ta có thể chạy độ bao phủ mã (code coverage) mỗi lần chúng ta check-in để đảm bảo chúng ta không buông lơi các kiểm thử đơn vị (unit tests) Nếu chúng ta không đạt được cải tiến mong đợi, điều quan trọng là đưa ra lý do tại sao hơn là than thở về mức thưởng bị giảm Thay vì tập trung vào thước đo cá nhân, chúng ta nên tập trung vào mục tiêu và hướng đến việc đạt được mục tiêu đó

Số liệu giúp nhóm, khách hàng theo dõi tiến độ trong vòng lặp (interation) và trong lần phát hành (release) hoặc epic Nếu chúng ta đang sử dụng burndown chart, và chúng ta đang đưa

lên thay vì xuống, đó là một cờ đỏ để dừng lại, hãy nhìn vào những điều đang xảy ra, và chắc chắn rằng chúng ta hiểu và giải quyết các vấn đề Có lẽ nhóm đã thiếu thông tin về story Số liệu, bao hàm các burndown charts, sẽ không được sử dụng như hình thức trừng phạt hay nguồn đổ lỗi Ví dụ, các câu hỏi như “Tại sao ước lượng của bạn quá thấp?”, hoặc “Tại sao bạn không thể hoàn thành các stories?” sẽ tốt hơn đến từ nhóm và được diễn đạt như “Tại sao ước lượng của chúng ta lại thấp?” và “Tại sao chúng ta không hoàn thành stories?”

Số liệu, sử dụng đúng cách, có thể thúc đẩy một nhóm Nhóm của Lisa theo dõi số lượng các kiểm thử đơn vị chạy trong mỗi lần build Các mộc lớn (big milestones) - 100 kiểm thử (tests),

1000 kiểm thử, 3000 kiểm thử - là lý do để ăn mừng Số lượng kiểm thử đơn vị tăng lên mỗi ngày là phản hồi tốt cho nhóm phát triển và khách hàng Tuy nhiên, điều quan trọng là nhận ra bản thân các con số không có ý nghĩa gì cả Ví dụ, các kiểm thử được viết ra một cách nghèo nàn, hoặc để có sản phẩm được kiểm thử tốt, có lẽ chúng ta cần 10,000 kiểm thử Các con số không hữu ích khi đứng riêng biệt

Khi bạn cố gắng để tìm xem cần phải đo đạc cái gì, đầu tiên hãy hiểu vấn đề mà bạn cần giải quyết là gì Khi bạn biết được vấn đề gặp phải, bạn cần đưa ra một mục tiêu Những mục tiêu này có thể đo đạc được “Giảm thời gian đáp ứng trung bình của ứng dụng XYZ xuống 1.5 giây với 20 người dùng đồng thời” tốt hơn “Cải tiến hiệu năng của ứng dụng XYZ” Nếu mục tiêu của bạn có thể đo đạc được, các phép đo mà bạn cần thu thập để theo dõi sẽ rõ ràng

Hãy nhớ sử dụng số liệu như một động lực và không dập xuống tinh thần của nhóm Xin nhắc lại một lần nữa: Tập trung vào mục tiêu, không phải số liệu Có lẽ bạn không sử dụng số liệu chính xác để đo cho dù bạn đạt được mục tiêu của nhóm, hay có thể bạn không giải thích chúng trong ngữ cảnh Số lượng báo cáo lỗi (defect) tăng có nghĩa nhóm đang làm việc kiểm thử tốt hơn, không có nghĩa họ đang viết nhiều mã nguồn lỗi hơn Nếu số liệu của bạn không giúp bạn hiểu tiến độ hướng tới mục tiêu của bạn, có thể bạn đang có các số liệu sai

5.2.3 What not to Do with Metrics (không nên làm gì với số liệu)

Câu nói phổ biến của Mark Twain, “Có ba loại nói dối: Nói dối, nói dối bị nguyền rủa, và thống kê” (there are three kinds of lies: lies, damned lies, and statistics) Mục tiêu đo đạc là tốt; nếu bạn không thể đánh giá chúng theo một số cách nào đó, bạn không thể nói có nếu bạn không đạt được chúng Mặt khác, sử dụng số liệu để đánh giá hiệu quả cá nhân hay nhóm thì thực sự nguy hiểm Theo thống kê có thể được xoắn vào bất kỳ giải thích và sử dụng trong các cách bất lợi

Đưa ra số dòng mã (line of code), một thước đo phần mềm truyền thống Có nhiều dòng mã thì

là tốt, có nghĩa nhóm hoạt động có hiệu quả, hoặc là xấu, có nghĩa nhóm đang viết những đoạn

mã không hiệu quả

Như thế nào về số lượng lỗi được tìm thấy? Nó có nghĩa khi đánh giá tester bằng số lượng lỗi

họ tìm thấy không? Làm thế nào để giúp họ hoàn thành tốt hơn công việc của mình? Là an toàn

để nói nhóm phát triển tạo ra số lượng lỗi trên số dòng code cao hơn đang làm công việc rất tệ không? Hay nhóm tìm nhiều lỗi hơn thì làm việc tốt hơn? Ngay cả khi nghĩ nó xảy ra, làm thế

nào để thúc đẩy đó cho nhóm để đánh mạnh vào các con số? Sẽ làm cho các thành viên nhóm bắt đầu viết mã không khuyết điểm?

5.2.4 Communiting Metrics

Chúng tôi biết rằng bất cứ điều gì chúng ta đo được đều bị giới hạn để thay đổi Bao nhiêu kiểm thử đang chạy và pass? Bao nhiêu ngày cho đến khi chúng ta cần “build on the sheft”? Toàn bộ build đều pass? Số liệu chúng ta không thể thấy và dễ giải thích là không có giá trị Nếu bạn muốn theo dõi số lượng các kiểm thử pass, chắc chắn rằng số liệu được nhìn theo hướng đúng, với đúng người Bảng xếp hạng lớn được nhìn theo cách hiệu quả nhất là hiển thị các số liệu mà chúng ta biết

Số liệu của bạn có được đánh giá xấu không? Đừng đo vì lợi ích của các số liệu sản phẩm Nghĩ về những gì mà bạn học được từ những số đó Phần tiếp theo, chúng ta xem xét lợi nhuận đầu tư mà bạn có thể mong đợi từ các số liệu

5.2.5 Metrics ROI

Khi bạn xác định các số liệu mà bạn cần, hãy chắc chắn bạn có thể lấy chúng với giá cả hợp lý Nếu build liên tục của bạn cung cấp các số liệu có ích, nó sẽ mang lại giá trị tốt Bạn đang chạy build, và nếu nó đưa cho chúng ta thêm thông tin, cái này là nước sốt (gravy) Nếu bạn cần thêm nhiều công việc để lấy thông tin, hãy hỏi chính bạn nếu nó quá rắc rối

Nhóm của Lisa đã thử theo dõi thời gian thực tế dành cho mỗi story so với thời gian ước lượng

Họ đã học được gì khác ngoài việc ước lượng? Không nhiều Một số nhóm có kinh nghiệm thấy

họ có thể bỏ qua sprint burndown chart bởi bảng công việc cho họ đủ thông tin để đánh giá tiến

độ của họ Họ có thể sử dụng thời gian để ước lượng công việc và tính giờ còn lại vào những hoạt động hiệu quả hơn

Điều này không có nghĩa chúng tôi khuyên bạn dừng theo dõi các phép đo Những nhóm mới cần hiểu tốc độ và tỷ lệ burndown của họ, để họ có thể cải tiến dần dần

Tỷ lệ lỗi (defect) là số liệu phần mềm truyền thống, và chúng không có nhiều giá trị với một nhóm nhằm đến zero defects Không có nhiều giá trị trong việc biết tỷ lệ lỗi được tìm thấy và được sửa trong thời gian phát triển, bởi việc tìm và sửa chúng là một phần không thể thiếu trong sự phát triển Nếu một tester đưa ra defect cho programmer, và một kiểm thử đơn vị đã được viết ra và lỗi được sửa theo hướng đúng, thường không cần ghi lại defect Mặt khác, nếu nhiều defect đi đến production mà không bị phát hiện ra, có thể có giá trị trong việc theo dõi số

để biết nếu nhóm được cải tiến

Khi bắt đầu viết lại ứng dụng lỗi, nhóm của Lisa đặt mục tiêu không nhiều hơn 6 lỗi nghiêm trọng trong code mới sau khi code được đưa lên production trong khoảng thời gian 6 tháng Có một mục tiêu thẳng thắn, dễ dàng để theo dõi giuips tạo động lực cho nhóm tìm ra cách để loại

bỏ lỗi trong quá trình phát triển và vượt qua mục tiêu này

Hình dung lợi nhuận đầu tư mỗi số liệu và quyết định có nên theo dõi hay duy trì nó không Nguồn lực sử dụng để tập hợp nó khẳng định giá trị mà nó mang lại không? Nó có dễ dàng truyền đạt và hiểu không? Như mọi khi, làm cái gì cho tình hình của bạn Thử nghiệm với việc giữ số liệu cụ thể cho một vài sprint và đánh giá liệu nó có trả hết không (pay off).

Một số liệu thông thường liêu quan đến chất lượng phần mềm là tỷ lệ defect Trong phần tiếp theo, chúng ta xem xét lý do để theo dõi các defect, hay không theo dõi các defect, và chúng ta

có thể học gì từ chúng

5.3 Defect Tracking

Một trong các câu hỏi được hỏi bởi nhóm Agile mới là “Chúng ta vẫn theo dõi bugs trong defect tracking system chứ?” không có câu trả lời đơn giản, nhưng chúng tôi sẽ đưa ra đề suất cho vấn đề này và đề nghị một số thay đổi để bạn có thể xác định những gì phù hợp với nhóm bạn

5.3.1 Why should We Use a Defect Tracking System (DTS) - Tại sao chúng ta nên sử

dụng một hệ thống theo dõi lỗi (DTS)

Có nhiều tester đã sử dụng defect tracking như hướng duy nhất để truyền đạt các vấn đề (issues), và nó dễ sử dụng với các công cụ tương tự nhau Một DTS là nơi thích hợp để theo dõi không chỉ defect mà cả độ ưu tiên (priorities), mức độ nghiêm trọng (severities) và trạng thái (status), và ai được giao việc (assigned) xử lý defect Nhiều học viên Agile nói rằng chúng tôi không cần làm điều này nữa, chúng tôi có thể theo dõi defect theo thẻ (card) hay một số cơ chế đơn giản khác Chúng tôi có thể viết một kiểm thử để đưa ra lỗi (failure), sửa mã, và giữ kiểm thử trong bộ hồi quy của chúng tôi

Tuy nhiên, có nhiều lý do để sử dụng các công cụ ghi lại defect và chúng được sửa chữa như thế nào Hãy cùng khám phá một trong số chúng

a Convenience (sự tiện lợi)

Một trong những mối quan tâm về việc không giữ DTS là không có nơi để giữ tất cả các chi tiết của lỗi (bug) Các tester ghi lại lỗi với nhiều thông tin, như làm thế nào để tái hiện (reproduce)

nó, nó được tìm thấy trong môi trường nào, hay đã sử dụng hệ điều hành (operating system) hoặc trình duyệt (browser) nào Toàn bộ thông tin không thể vừa trên một thẻ (card), bạn nắm bắt những chi tiết đó như thế nào? Nếu bạn chỉ dựa vào thẻ, bạn cũng cần trao đổi Nhưng với trao đổi, những chi tiết đó sẽ bị mất đi, và đôi khi tester quên chính xác những gì đã được thực hiện, đặc biệt nếu các lỗi đã được tìm một vài ngày trước khi programmer giải quyết vấn đề

Một DTS cũng là nơi phù hợp để giữ tất cả các tài liệu bổ sung, chẳng hạn như màn hình hay những tập tin (file) được tải lên

b Knowledge Base (dựa vào tri thức)

Chúng tôi đã nghe lý do để theo dõi defect như, “Chúng ta cần thấy các báo cáo lỗi cũ” Chúng tôi cố gắng nghĩ các lý do tại sao bạn nên nhìn vào các báo cáo cũ, và như chúng tôi làm việc trong chương này, Janet tìm thấy một ví dụ

Janet’s Story

Khi tôi đang kiểm thử thuật toán tại WestJet, tôi tìm thấy một bất thường Tôi đã hỏi Sandra, một tester khác, nếu cô ấy đã từng gặp vấn đề này trước đó Sandra mơ hồ nhớ lại nó nhưng không chính xác Cô ấy nhanh chóng tìm kiếm trong Bugzilla và tìm thấy vấn đề ngay lập tức

Nó đã bị đóng như không hợp lệ (invalid) vì doanh nghiệp đã quyết định nó không thích hợp

để sửa, và mức ảnh hưởng thấp

Việc này đã giúp tôi tránh việc đặt câu hỏi hoặc nhập lại lỗi và nhận được là nó lại bị đóng Bởi các thành viên trong nhóm gồi gần nhau, câu chuyện của chúng tôi dẫn tới cuộc thảo luận khác với nhà phân tích nghiệp vụ trong nhóm Cuộc thảo luận này làm dấy lên những ý tưởng về một trang FAQ, một danh sách các vấn đề nổi bật, hoặc một cái gì đó theo dòng sẽ cung cấp cho các tester mới tìm thấy những vấn đề đã được xác định, nhưng mà quyết định

đã được thực hiện là không giải quyết chúng

Câu chuyện này cho thấy mặc dù cơ sở dữ liệu lỗi có thể được sử dụng như cơ sở tri thức, có thể có các cơ chế khác để giữ các quyết định nghiệp vụ và thông tin nền tảng của họ Nếu một vấn đề mất theo dõi đủ lâu, có lẽ chúng ta nên viết nó và đưa nó ra lại một lần nữa Các trường hợp có thể đã thay đổi, và các doanh nghiệp có thể quyết định nó đáng để sửa chữa

Các loại loại lỗi hay bị gián đoạn và mất thời gian lâu để theo dõi thì thích hợp khi sử dụng DTS Những lỗi này thể hiện không thường xuyên, và thường có khoảng thời gian trống để điều tra việc thiếu sót thông tin Một DTS là nơi thông tin được nắm bắt những gì đã làm cho đến nay Nó cũng có thể chứa các bản ghi, dấu về và nhiều hơn nữa Đây có thể là thông tin hữu ích khi ai đó trong nhóm có thời gian để xem xét các vấn đề hay vấn đề trở nên quan trọng hơn

Thông tin trong các báo cáo lỗi có thể được sử dụng sau cho một vài mục đích Đây là câu chuyện của nhóm Lisa về việc làm thế nào để sử dụng thông tin của nó

Lisa’s Story

Một developer của nhóm phục trên một vòng xoay “hỗ trợ production” ở mỗi vòng lặp Yêu cầu hỗ trợ Production đến từ phía nghiệp vụ cho các bản sửa lỗi của sai lầm trong quá khứ (past mistakes) hay những vấn đề trên production cần can thiệp bằng tay “Người hỗ trợ

production” tìm kiếm vấn đề và ghi lại nó đã được sửa lỗi trong báo cáo lỗi chưa Những chú thích thường gồm trạng thái SQL (SQL statement) và thông tin nguyên nhân Nếu bất cứ ai gặp phải lỗi tương tự hoặc tình huống sau đó, giải pháp dễ dàng được tìm thấy trong DTS Nếu một số kiểu vấn đề xảy ra thường xuyên, nhóm sử dụng DTS để nghiên cứu và phân tích Mặc dù nhóm thì nhỏ, chúng tôi đối phó với nhiều mã di sản (legacy code), và chúng tôi không thể dựa vào trí nhớ của mọi người để theo dõi mọi vấn đề và sửa chữa

Nhớ lại nguyên nhân của defect và những gì được thực hiện để làm xong yêu cầu đặc biệt sẽ khó khăn hơn khi nhóm đặc biệt lớn và không cùng vị trí Các khách hàng cũng không quan tâm đến các giải pháp cho vấn đề của họ

c Large or Distributed Teams

Nếu các dự án lớn mà các defect được tìm thấy bởi một nhóm có thể ảnh hưởng đến nhóm khác DTS có lẽ là lựa chọn tốt Tất nhiên, để có ích, toàn bộ thành viên của nhóm phải truy cập

vào nó Liên lạc mặt đối mặt (face-to-face communication) luôn là lựa chọn đầu tiên, nhưng khi hoàn cảnh không cho phép như vậy, chúng ta cần hỗ trợ từ một DTS.

e Metrics

Có nhiều lý do để theo dõi tỷ lệ defect Ngoài ra còn có những lý do tại sao bạn không nên theo dõi một defect Ví dụ, chúng tôi không nghĩ một bug sẽ được tính như một defect nếu nó không bao giờ lặp lại Tất nhiên, điều này sẽ đưa ra ở cuộc thảo luận khác về việc chúng ta nên theo dõi cái gì và tại sao, nhưng chúng tôi không đưa ra ở đây

f Traceability (khả năng truy vết - v Trace)

Lý do khác, chúng tôi đã nghe về DTS là khả năng truy vết, liên kết các defect đến các trường hợp kiểm thử (test cases) Chúng tôi không chắc chắn đây là lý do chính đáng Không phải toàn

bộ defect đều liên kết với test case, mà chúng cũng không nên như vậy Ví dụ, các lỗi giống như spelling mistakes (lỗi chính tả) không cần test case đặc biệt Có thể sản phẩm không phải trực quan để sử dụng; đây là một lỗi rất thực tế mà thường không được báo cáo Bạn viết một kiểm thử như thế nào để xác định xem điều gì có thể sử dụng? Exploratory testing (kiểm thử thăm dò) có thể tìm lỗi ở điều kiện biên, nó không có giá trị để tạo các kiểm thử tự động

Nếu nó là một trường hợp kiểm thử tự động để bắt lỗi, thì gần ghi lại defect, bởi nó sẽ bắt được lại nếu không được đưa ra Nhu cầu truy vết đã kết thúc Vì vậy, có lẽ chúng ta không cần theo dõi defect

5.3.2 Why shouldn’t We Use a DTS?

Agile và Lean cung cấp cho chúng ta những thực hành và nguyên tắc, giúp làm giảm yêu cầu

về một DTS Nếu quá trình này vững chắc, và tất cả mọi người cam kết phân phối sản phẩm chất lượng, defects sẽ trở nên hiếm hoi và theo dõi rất đơn giản

a As a Communication Tool

DTS chắc chắn không thúc đẩy giao tiếp giữa programmer và tester Chúng có thể làm cho nó

dễ dàng để tránh nói chuyện trực tiếp với nhau

b Waste of Time and Inventory

Chúng ta có xu hướng đưa nhiều thông tin vào DTS ngoài các bước để tạo lỗi Phụ thuộc vào bug, nó có thể mất một thời gian dài để viết các bước sau đó để programmer tái hiện lại Sau khi phân loại, một số người đưa ra nhận xét, giải thích defect, cố gắng để tái hiện, (lý tưởng) sửa chữa nó, viết một số ý kiến, và gán lại cho người báo cáo Cuối cùng việc sửa chữa được

xác nhận Toàn bộ chu kỳ có thể tăng lên gấp đôi nếu programmer hiểu sai vấn đề ngay lần đầu tiên Giá của một báo cáo defect đơn giản trở nên quá cao.

Nó sẽ dễ dàng hơn bao nhiêu nếu tester có thể nói chuyện với programmer và đưa ra những gì

mà họ tìm thấy cho developer sau đó sửa chữa defect theo hướng đúng? Chúng tôi sẽ nói về

nó sau

Các defects trong một DTS trở thành hàng đợi hay một Product Backlog nhỏ Theo nguyên tắc lean, hàng tồn của defect là một sự lãng phí Là một nhóm, chúng ta nên nghĩ hướng giảm sự lãng phí này

5.3.3 Defect Tracking Tools

Nếu bạn quyết định sử dụng một DTS, hãy chọn cẩn thận Hiểu được nhu cầu của bạn và làm cho nó trở nên đơn giản Bạn muốn mọi người học cách sử dụng nó Nếu nó trở nên quá cao hay khó để sử dụng, mọi người sẽ tìm hướng để làm việc xung quanh nó Như toàn bộ công cụ được sử dụng bởi nhóm phát triển Agile, bạn nên xem xét ý kiến của toàn bộ nhóm Nếu ai đó

từ nhóm khách hàng chuyển báo cáo lỗi, hãy lấy ý kiến của anh ta/cô ấy

Một trong những công cụ đơn giản nhất mà Janet đã sử dụng là Alcea’s FIT IssueTrack Nó được cấu hình, không cần bạn theo một quy trình sẵn có, và dễ dàng để có số liệu Làm bài tập

về nhà của bạn và tìm những công cụ làm việc cho bạn Có một loại các hệ thống

defect-tracking mã nguồn mở, hệ thống lưu trữ, và hệ thống doanh nghiệp tích hợp sẵn

Bạn có sử dụng DTS hay không, bạn muốn tạo defect ngay khi nhìn thấy

Chúng tôi thường khuyên bạn thử nghiệm với các công cụ khác nhau, sử dụng nó trong một vài vòng lặp (iteration), hệ thống bug-tracking thì phức tạp hơn, bởi bạn cần chuyển toàn bộ lỗi trong hệ thống sang hệ thống mới mà bạn đang cố gắng Sử dụng thời gian để suy nghĩ về những điều mà bạn cần với DTS, nó sẽ phục vụ mục đích nào, và đánh giá những thay đổi một cách thận trọng

Như với toàn bộ công cụ tìm kiếm, hãy tìm những chỗ khác trong cộng đồng của bạn, như nhóm người dùng và danh sách email, để lấy một số lời khuyên Xác định tiêu chuẩn của bạn trước khi tìm kiếm, và thử nghiệm ngay khi bạn có thể Nếu bạn chọn công cụ sai, cắt lỗi và bắt đầu nghiên cứu lại

5.3.4 Keep Your Focus

Các quyết định về báo cáo và theo dõi defects thì quan trọng, nhưng không mất theo dõi mục tiêu chính của bạn Bạn muốn cung cấp sản phẩm chất lượng tốt nhất bạn có thể, và bạn muốn phân phối giá trị cho doanh nghiệp một cách kịp thời Dự án thành công khi mọi người được phéo làm việc tốt nhất công việc của họ Tập trung vào việc cải tiến giao tiếp và xây dựng sự hợp tác Nếu bạn gặp nhiều defect, điều tra nguồn gốc của vấn đề Nếu bạn cần một DTS để thực hiện điều này, thì hãy sử dụng đi Nếu nhóm bạn làm việc tốt hơn bằng cách ghi các defect trong các kiểm thử thực thì và sửa chúng ngay lập tức, hãy làm điều này Nếu một số kết

hợp cho phép bạn liên tục cải tiến, hãy làm với nó Điều chính phải nó là nó phải làm việc cho toàn bộ nhóm bạn.

Defect tracking is one of the typical quality processes that generate the most questions and controversy in agile testing Another big source of confusion is whether agile projects need documents such as test plans or traceability matrices Let’s consider that next

theo dõi lỗi là một trong những quy trình chất lượng tiêu biểu mà tạo ra hầu hết các câu hỏi và tranh cãi trong thử nghiệm nhanh nhẹn Một nguồn lớn của sự nhầm lẫn là liệu các dự án nhanh nhẹn cần tài liệu như kế hoạch kiểm tra hoặc ma trận truy xuất nguồn gốc Hãy xem xét rằng bên cạnh

Defect tracking là một trong những quy trình chất lượng tiêu biểu mà tạo ra hầu hết các câu hỏi

và tranh cãi trong Agile testing Nguồn gốc của sự nhầm lẫn lớn là các dự án Agile có cần các tài liệu như test plans hay các ma trận truy vết (traceability matrices) Hãy xem xét ở phần sau

5.4 Test Planning

Các phương pháp phần mềm theo từng giai đoạn (phased) truyền thống nhấn mạnh tầm quan trọng của test plan (kế hoạch kiểm thử) như một phần của yêu cầu tài liệu tổng thể Chúng định hướng để đưa ra các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nguồn lực kiểm thử phần mềm cho các bên liên quan Tài liệu được hoàn thành nhằm mục đích giúp người ngoài nhóm kiểm thử hiểu được “Tại sao” và “làm thế nào” để xác nhận sản phẩm Trong phần này, chúng ta xem xét kế hoạch kiểm thử và những khía cạnh khác của việc chuẩn bị và theo dõi nguồn lực kiểm thử cho dự án Agile

5.4.1 Testing Strategy vs Test Planning (chiến lược kiểm thử và kế hoạch kiểm thử)

Trong dự án Agile, nhóm không dựa vào tài liệu để truyền đạt những gì mà các tester cần làm Các tester làm việc với phần còn lại của nhóm, vì thế nguồn lực kiểm thử có thể thấy trong tất

cả các thẻ nhiệm vụ Câu hỏi thường đặt ra cho chúng tôi như “Vẫn cần test plan đúng không?”

để trả lời câu hỏi đó, đầu tiên hãy nhìn vào sự khác biệt giữa một kế hoạch kiểm thử và một chiến lược hay phương pháp tiếp cận kiểm thử

Có nhiều thông tin chứa trong một tài liệu, ít khả năng có ai đó sẽ đọc hết Hãy xem xét những thông tin thực sự cần thiết cho các bên liên quan Suy nghĩ về cách nó thường được sử dụng

và nó được sử dụng cho cái gì

Chúng tôi thích suy nghĩ, chiến lược kiểm thử như một tài liệu ít khi thay đổi, trong khi một kế hoạch kiểm thử được tạo mới và được xác định cho mỗi dự án mới

a Test Strategy

Một chiến lược là một kế hoạch hành động lâu dài, từ khóa là “long-term” Nếu tổ chức của bạn muốn tài liệu về phương pháp tiếp cận kiểm thử tổng thể cho dự án, xem xét thông tin và đặt nó vào tài liệu tĩnh, nơi mà không làm thay đổi nhiều theo thời gian Có nhiều thông tin không phải

của dự án cụ thể và có thể tách ra thành tài liệu chiến lược kiểm thử hoặc phương pháp tiếp cận kiểm thử.

Tài liệu này có thể được sử dụng như tài liệu tham khảo và cần cập nhật khi các quy trình thay đổi Một tài liệu chiến lược kiểm thử có thể được sử dụng để đưa cho nhân viên mới, cung cấp

sự hiểu biết cao về cách các quy trình kiểm thử của bạn làm việc

b Test Plan

Sức mạnh của kế hoạch là xác định các vấn đề có thể và các phụ thuộc, mang lại rủi ro cho phần bề mặt đã được nhắc đến và giải quyết, và nghĩ về một bức tranh lớn Kế hoạch kiểm thử không khác Một nhóm sẽ nghĩ về rủi ro và những phụ thuộc, bức tranh lớn cho mỗi dự án trước khi nó bắt đầu

Cho dù nhóm của bạn quyết định tạo tài liệu kế hoạch kiểm thử hay không, kế hoạch sẽ vẫn hoàn thành Mỗi dự án thì khác nhau, vì vậy không mong đợi cùng giải pháp sẽ phù hợp với tất cả

Đôi khi khách hàng nhấn mạnh tài liệu kế hoạch kiểm thử Nếu bạn đang ký hợp đồng để phát triển một ứng dụng, một kế hoạch kiểm thử nên là một phần trong tập hợp các phân phối, cũng bao gồm những mục như tài liệu yêu cầu và tài liệu thiết kế

Thảo luận về kế hoạch kiểm thử thường dẫn đến cuộc nói truyện về truy vết Có ai đó thực hiện toàn bộ kế hoạch kiểm thử về hành vi mong muốn trên mã được phân phối không? Làm thế nào để các yêu cầu và kế hoạch kiểm thử liên quan đến kiểm thử thực đế và chức năng cuối cùng?

Nếu trong một số ngành công nghiệp đòi hỏi phải có traceability Nếu có, chúng tôi đề nghị bạn nhìn vào vấn đề mà người quản lý đang cố gắng giải quyết Khi bạn hiểu đó là những yêu cầu

gì, bạn sẽ tạo ra giải pháp đơn giản nhất có thể Có nhiều cách để cung cấp traceability Các lời bình (comments) khi check-in mã nguồn có thể tham khảo từ trang wiki, nó có thể chứa các yêu

cầu hay các test cases hay một số defect Bạn có thể đưa lời bình (comments) trong kiểm thử đơn vị (unit test) để xác định kiểm thử hoặc xác định yêu cầu Các kiểm thử có thể tích hợp trực tiếp với yêu cầu trong một công cụ như FitNesse Nhóm bạn có thể dễ dàng tìm cách làm việc phù hợp nhất với yêu cầu của khách hàng.

Các tài liệu như ma trận traceability có thể là cần thiết để thực hiện đầy đủ các yêu cầu được đưa ra bởi chuẩn đánh giá của tổ chức hay các mô hình chất lượng Hãy xem xét làm thế nào

để những hướng dẫn đó xuyên suốt quá trình phát triển Agile

5.5 Existing Processes and Models

Câu hỏi thường gặp “Các mô hình và quy trình chất lượng truyền thống có thể cùng tồn tại với các phương thức phát triển Agile không?” Về lý thuyết, không có lý do tại sao chúng không thể Trong thực tế, nó thường không phải là một lựa chọn Các mô hình chất lượng thường rơi vào lĩnh vực của nhóm QA truyền thống, và chúng có thể theo các tester đi vào cấu trúc Agile mới

Nó có thể không dễ dàng để thích hợp với mô hình phát triển Agile mới Hãy xem một vài quy trình chất lượng tiêu biểu và các tester và nhóm của họ phải thích nghi như thế nào

5.5.1 Audits

Các ngành công nghiệp khác nhau có yêu cầu đánh giá (audit) khác nhau Nhóm đảm bảo chất lượng trong các tổ chức phát triển truyền thống thường được giao nhiệm vụ cung cấp thông tin cho kiểm toán viên (auditors) và đảm bảo tuân thủ các yêu cầu kiểm toán Đạo luật Sarbanes-Oxley năm 2002, ban hành để đáp ứng với các bê bối tài chính tập đoàn cao, đưa ra các yêu cầu cho việc duy trì hồ sơ kinh doanh Đảm bảo tuân thủ không bị rơi vào phòng IT SAS 70 là một chuẩn kiểm toán được công nhận rộng rãi cho các tổ chức dịch vụ Đây chỉ là một vài ví dụ

về các loại điều khiển kiểm toán có ảnh hưởng đến nhóm phát triển

Các tổ chức lớn hơn có các nhóm chuyên gia kiểm soát việc tuân thủ và làm việc với kiểm toán viên, nhưng các nhóm phát triển thường yêu cầu cung cấp thông tin Ví dụ như những kiểm thử nào được thực hiện trong lần release phần mềm, hoặc chứng minh các tài khoản khác nhau đã hòa hợp Tester có thể được giao nhiệm vụ viết test plan để đánh giá hiệu quả của các hoạt động kiểm soát

Các tester là một phần của nhóm Agile, nên cống hiến riêng cho nhóm đó Nếu sự giúp đỡ của

họ là cần thiết trong việc cung cấp thông tin cho một kiểm toán hoặc giúp đảm bảo việc tuân thủ Viết các story cho nó và lên kế hoạch với phần còn lại không việc của nhóm Làm việc cùng nhau sẽ tuân thủ và kiểm toán nội bộ nhóm để hiểu các trách nhiệm của nhóm bạn

5.5.2 Frameworks, Models, and Standards

Có nhiều mô hình chất lượng, nhưng chúng tôi chỉ xem xét hai để cho bạn thấy bạn cần điều chỉnh quy trình Agile như thế nào để phù hợp với các ràng buộc của nó

1 Capability Maturity Model Integration (CMMI) nhằm giúp các tổ chức cải thiện quy trình của

họ, mà không đưa ra các thực hành phát triển cụ thể để thực hiện những cải tiến đó

2 Information Technology Infrastructure Library (ITIL) là tập các thực hành tốt nhất cho quản lý dịch vụ IT nhằm giúp các tổ chức phát triển quy trình chất lượng hiệu quả.

Cả hai mô hình này cùng tồn tại với phát triển Agile Chúng bắt nguồn từ cùng một mục đích, làm cho các dự án phát triển phần mềm thành công

Hãy nhìn vào CMMI, một khung để đo sự trưởng thành của quy trình của bạn Nó định nghĩa mỗi mức độ bằng cách đo quá trình là ẩn số, định nghĩa, tài liệu, lâu dài, hay tối ưu Các dự án Agile có một quá trình định nghĩa, mặc dù không phải toàn bộ nhóm làm tài liệu những thứ họ làm Ví dụ, quản lý các yêu cầu với chỉ số thẻ trên bảng kế hoạch phát hành (release) với một khách hàng tạo các quyết định là một quá trình định nghĩa miễn là bạn làm nó tất cả thời gian

Các retrospectives nhằm mục đích cải thiện quy trình liên tục, và các nhóm sẽ luôn tìm hướng

để tối ưu hóa các quy trình Nếu điều duy nhất nhóm của bạn thiếu là tài liệu, hãy nghĩ về việc gộp quy trình của bạn vào tài liệu chiến lược kiểm thử

Hãy hỏi bản thân xem số lượng tài liệu tối thiểu mà bạn có thể đáp ứng các yêu cầu của CMMI

là bao nhiêu Janet đã thành công với việc sử dụng biểu đồ (diagram) như hình 5-2

Nếu ITIL đã được giới thiệu trong tổ chức của bạn và tác động đến việc thay đổi của quản lý, lắp quy trình của bạn để chứa nó Bạn có thể tìm thấy lợi ích từ quy trình mới