Đang tải... (xem toàn văn)
Bản dịch chương 2 của quyển Agile testing A practical guide for testers and Agile teams của Addison Wesley (2009); 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.
Part II - Organizational Challenges Khi tổ chức định áp dụng Agile 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, chuyển sang mô hình Agile mới, họ khó thích nghi với văn hóa Trong Part II, nói thay đổi rào cản mà bạn phải đối mặt chuyển đổi sang Agile Đào tạo (Training) phần to quan trọng trình chuyển đổi sang Agile thường bị quên lãng Nó khó để thấy quy trình đánh giá (Audits) khung cải tiến (Improvement Framework) làm việc môi trường Agile Đi từ nhóm QA độc lập đến nhóm agile thay đổi lớn Chapter - Cultural Challenges Nhiều tác nhân tổ chức ảnh hưởng đến dự án, sử dụng An Agile hay a traditional phased hay gated approach Văn hóa tổ chức nhóm ngăn cản chuyển đổi mềm dẻo đến phương thức Agile Trong chương này, thảo luận tác nhân (factors) ảnh hưởng trực tiếp đến vai trò Tester nhóm Agile 3.1 Organizational Culture Văn hóa tổ chức định nghĩa giá trị (values), quy tắc (norms) giả định (assumptions) Văn hóa tổ chức định cách giao tiếp, hướng tương tác, tạo định nào, dễ dàng thấy qua việc quan sát hành vi employee Văn hóa tổ chức ảnh hưởng đến thành công nhóm Agile Các nhóm Agile phù hợp với tổ chức cho phép suy nghĩ độc lập Ví dụ như, công ty có kiến trúc phân lớp khuyến kích phong cách (kiểu) quản lý huy nhóm Agile chắn đối nghịch lại điều Các kinh nghiệm khứ tổ chức ảnh hưởng đến thành công nhóm Agile Nếu công ty cố gắng áp dụng agile có kết không tốt, người không cố gắng áp dụng lại đưa trích dẫn không hiệu Họ không thực lại lần Chúng ta nói xác Văn hóa tổ chức ảnh hưởng đến việc tester làm việc môi trường Agile Thư mục chứa tài nguyên giải 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 tổ chức nằm mục làm để xác định mức độ chấp nhận chất lượng phần mềm Nó cho phép chất lượng không? Nó có nhớ yêu cầu chất lượng khách hàng không hay quan tâm đến việc bàn giao sản phẩm cho khách hàng nhanh có thể? Khi tổ chức thiếu triết lý chất lượng tổng thể ép nhóm đưa sản phẩm mà không quan tâm đến chất lượng tester cảm thấy bị gò ép Lúc cố gắng phát triển Agile nhóm đối mặt với thách thức khó khăn Một số tổ chức có nhóm kiểm thử độc lập, mạnh mẽ đầy lực Những nhóm đó, quản lý họ nhận thấy việc phát triển Agile làm lực họ Họ sợ Agile trái với triết lý chất lượng họ Đánh giá triết lý chất lượng tổ chức triết lý nhóm thi hành Các công ty có nhân viên đề cao chất lượng dễ dàng để chuyển đổi sang Agile Nếu nhóm sở hữu chất lượng, họ phải học cách chia sẻ chúng với 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 “What Is Agile Testing, Anyway?”, 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 QA, điều có nghĩa thay đổi suy nghĩ việc sở hữu chất lượng đến việc có vai trò xác định việc xác định trì chất lượng Một thay đổi mạnh mẽ khó khăn có nhiều nhóm tests QA Những tester làm việc môi trường truyền thống có khoảng thời gian khó khăn để điều chỉnh sang vai trò hoạt động họ Nếu họ đến từ tổ chức mà việc phát triển QA có mối quan hệ đối nghịch với nhau, khó để thay đổi từ suy nghĩ độc lập đến phần thiếu nhóm Nó khó cho lập trình viên tester để học cách tin tưởng lẫn b Skills and Adaptability (Các kỹ khả thích nghi) Như quan sát phần lớn lập trình viên thích nghi với thực hành Agile - Nhưng tester xây dựng kịch kiểm thử dựa vào tài liệu yêu cầu sao? Họ đưa câu hỏi code build không? Testers không thay đổi cách tiếp cận làm cho việc kiểm thử khó làm việc chặt chẽ với phần lại nhóm phát triển Các tester sử dụng manual testing (kiểm thử thủ công) giao diện người dùng không hiểu phương pháp tự động Những tester cần nhiều động lực để đối mặt với vai trò thay đổi họ, hay thay đổi có nghĩa phải phát triển thêm tập kỹ phạm vi lợi họ c Factors that help (các nhân tố giúp) Mặc dù có nhiều vấn đề văn hóa (cultural issues) cần xem xét, hầu hết nhóm QA tập trung cải tiến quy trình, dự án Agile khuyến khích cải tiến liên tục khả thích nghi thông qua việc áp dụng công cụ Retrospectives Hầu hết chuyên gia đảm bảo chất lượng khao khát nắm giữ họ học làm cho tốt Những người đủ khả thích nghi để không tồn mà phát triển mạnh mẽ dự án Agile Nếu tổ chức tập trung vào việc đào đạo, khuyến khích cải tiến quy trình liên tục Nó làm theo Agile nhanh chóng tổ chức đặt nhiều giá trị vào việc họ phản ứng lại khủng hoảng việc cải tiến quy trình họ Nếu bạn tester tổ chức triết lý chất lượng hiệu quả, bạn đấu tranh để thực hành chất lượng chấp nhận Phương pháp tiếp cận Agile đưa cho bạn chế giới thiệu thực hành hướng chất lượng tốt Các tester cần thời gian đào đạo, tất người cần học để làm việc dự án Agile Nếu bạn quản lý nhóm bao gồm testers, chắn ủng hộ họ Các tester thường không đưa vào từ đầu dự án Greenfield phù hợp với nhóm làm việc với nhiều tháng Để giúp tester điều chỉnh, bạn cần nhờ đến huấn luyện viên kiểm thử Agile có kinh nghiệm (experienced Agile testing coach) Thuê làm việc nhóm Agile phục vụ người cố vấn giáo viên giúp tester tích hợp với văn hóa Agile mới, cho dù họ có chuyển sang Agile với nhóm hay tham gia vào nhóm phát triển Agile 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 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, số tổ chức thường xuyên yêu cầu nhóm họ làm việc 50, 60, hay nhiều tuần để kịp tiến độ (deadline) Tổ chức thường xem xét làm thêm (overtime) thước đo cam kết cá nhân Các mâu thuẫn Agile values giải cách cho phép người làm việc tốt thời gian Trong dự án Agile, khuyến kích làm việc với tốc độ bền vững Điều có nghĩa nhóm làm việc với tốc độ thích hợp để trì tốc độ không đổi (constant velocity) cho phép trì tiêu chuẩn chất lượng cao Các nhóm Agile có xu hướng lạc quan việc họ thực đăng ký nhiều việc Sau iteration hai, họ học cách đăng ký đủ việc để làm thêm mà hoàn thành công việc 40 tuần tốc độ bền vững cho nhóm XP, khối lượng effort bỏ ra, đưa vào từ tuần đến tuần khác, cho phép người hoàn thành hầu hết công việc chặng đường dài mà cung cấp giá trị tốt Các nhóm phải làm việc với tốc độ không ổn định giai đoạn ngắn sau đó, ngoại lệ, tiêu chuẩn (norm) Nếu overtime cần thiết giai đoạn ngắn, toàn nhóm làm việc Nếu ngày cuối sprint số stories không kiểm thử, toàn nhóm 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ệ nhóm phát triển khách hàng họ giống mối quan hệ vendor-supplier Mặc dù khách hàng người nội tổ chức, có cảm giác hai công ty riêng biệt hai nhóm làm việc mục tiêu chung Phát triển Agile phụ thuộc vào tham gia khách hàng người ủy quyền họ Các nhóm Agile mời khách hàng cộng tác, làm việc nơi có thể, trí với quy trình phát triển Cả hai đề học hỏi điểm mạnh điểm yếu Sự thay đổi quan hệ cần đồng thuận hai phía, khách hàng có hay tổ chức Một mối quan hệ mở tác nhân quan trọng dẫn đến thành công dự án Agile, nơi mà mối quan hệ nhóm khách hàng nhóm phát triển giống đối tác mối quan hệ vendor-supplier Có vài đại diện domain experts, thông báo liên tục cho stakeholders, phương pháp để giữ thành công hợp tác developercustomer Customers tác nhân thành công dự án Agile Họ đưa thứ tự ưu tiên xây dựng tiếng nói cuối 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 định nghĩa acceptance tests Các hoạt động kiểm thử chìa khóa để phát triển mối quan hệ nhóm phát triển khách hàng Đó lý chuyên môn kiểm thử cần thiết cho nhóm Agile 3.1.4 Organization Size Kích cỡ tổ chức tác động lớn đến việc dự án chạy cấu trúc công ty Tổ chức lớn hơn, cấu trúc phân cấp hướng đến Kênh giao tiếp top-down phát triển, cấu trúc báo cáo trở nên thích hợp phù hợp với việc hợp tác kỹ thuật thương mai a Communication Challenges Một số quy trình Agile đưa hướng thuận tiện cho việc giao tiếp nhóm Nếu làm việc tổ chức lớn nhóm kiểm thử độc lập với nhóm lập trình, tìm hướng để giữ việc kết nối ổn định Vấn đề khác thường xảy với công ty lớn khách hàng tham gia liên tục Nó trở ngại lớn để tập hợp yêu cầu examples tìm kiếm đồng thuận khách hàng vào vòng đời phát triển Giải pháp có tester hay analyst với kinh nghiệm lĩnh vực hoạt động đạ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 nhóm khác sử dụng phương thức khác phased gated development, bạn phải đối mặt với tập thử thách Nhóm bạn gặp chống đối nhóm chuyên gia họ cố gắng bảo vệ ý kiến cá nhân họ Nếu đối tác thứ làm việc hệ thống với nhóm bạn, văn hóa họ 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 trình lên kế hoạch release, trước bắt đầu iteration, để làm việc với họ d Act now, Apologize Later Nó thường xảy tổ chức lớn Vòng soáy quan liêu làm cho nhóm bạn hoàn thành công việc chậm chạp Nếu kênh để lấy thứ bạn cần, hay tester chưa nói chuyện trực tiếp với khách hàng trước Hãy cố gắng tổ chức họp, tìm đại diện 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 cảm giác trao quyền tạo định Nếu bạn manager bạn muốn nhóm agile thành công, giúp họ cảm thấy tự hoạt động sáng tạo Văn hóa tổ chức nên thích nghi với thay đổi để giúp dự án Agile thành công 3.2 Barriers to Successful Agile Adoption by Test/QA Teams (Các trở ngại thành công việc áp dụng Agile nhóm test/QA) 3.2.1 Loss of Identify Các tester cố gắng trì nhóm QA độc lập nhiều lý do, lý sợ hãi, đặc biệt: • Sợ định danh QA • Sợ họ báo cáo cho quản lý phát triển, họ không hỗ trọ, lập trình viên có quyền ưu tiên • Sợ họ bị kỹ làm việc nhóm Agile công việc họ • Sợ họ phân tán vào nhóm phát triển họ không nhận hỗ trợ họ cần • Sợ họ quản lý họ bị xóa bỏ tổ chức Chúng ta thường nghe QA managers hỏi “Công ty hoàn thành phát triển Agile Vai trò nào?” Nó liên quan trực tiếp sợ “Loss of identify” 3.2.2 Additional Roles Chúng ta biết nhóm thường bị thiếu chuyên gia hay người am hiểu lĩnh vực Có thể bạn cần có kinh nghiệm kiểm thử với nhóm Agile Hoặc bạn cần chuyên gia kiểm thử hiệu Nó chiếm thời gian để phân tích vai trò mà bạn cần để thành công Để người nhóm thực hiểu vai trò họ sử dụng thời gian đào tạo 3.2.3 Lack of Training Nếu đặt tester vào đơn vị phát triển mà đào đạo; tháng, toàn testers nghỉ việc họ hiểu vai trò họ dự án 3.2.4 Not Understanding Agile Concepts Không phải nhóm Agile giống Nó nhiều phương pháp khác để phát triển Agile XP, Scrum, Crystal, FDD, DSDM, OpenUP Họ thực phương pháp khác này, họ không theo Giá trị nguyên tắc cốt lõi Agile nào, phát triển Agile 3.2.5 Past Experience/Attitude Một số tổ chức phát triển có thành công định, họ bị mắc kẹt quan điểm cũ mô hình thành công họ Ngay họ cố gắng làm điều mới, họ dễ trở lại với thói quen cũ bị căng thẳng Một vài ví dụ người chống lại thay đổi kinh nghiệm cũ nhận thức “theo - The way things are”: • Một tester ngồi vị trí không nói vấn đề với programmer Anh ta phàn nàn programmer không hiểu muốn • Một tester rũ bỏ thái độ mà programmers làm cách để viết code tốt hay làm để kiểm thử Thái độ hạ rõ ràng, trách nhiệm bị thách thức • Một khách hàng đập tay programmer không làm thứ muốn, họ “luôn luôn” làm thứ họ muốn Khi đối mặt với việc chuyển đổi sang phát triển Agile, người thường để lại mà không cho quy trình hội Phát triển Agile không dành cho tất người, đạo tạo thời gian để thử nghiệm giúp điều chỉnh thái độ Yêu cầu người phần giải pháp làm việc với để tìm quy trình, thực hành tốt phù hợp với tình cụ thể họ Nhóm tự quản (seft-organizing) công cụ mạnh mẽ để trấn an tất thành viên nhóm phát triển việc họ kiểm soát mục tiêu 3.2.6 Cultural Differences among Roles Mỗi thành viên nhóm Agile tạo chuyển đổi khía cạnh khác Các programmer thường sử dụng để viết mã production release System administrator database expert (quản trị hệ thống chuyên gia liệu) làm việc silo riêng họ, thực yêu cầu theo tiến độ riêng họ Các tester thực vào cuối dự án không tương thnhiều với programmer Không có ngạc nhiên chuyển đổi đáng sợ Nhóm tạo quy định (rules) hướng dẫn (guideline) để giúp họ giao tiếp làm việc tốt với Xác định điều cần thiết với người thực hoạt động khác nhau, tìm cách cung cấp Khách hàng cần số cách để biết tiến trình phát triển điều kiện mong muốn họ có đáp ứng không Những người phát triển cần biết mức độ ưu tiên thương mại yêu cầu Các tester cần hướng để nắm bắt examples chuyển chúng vào kiểm thử Toàn thành viên nhóm muốn cảm thấy họ có giá trị thành viên nhóm hạng Mỗi thành viên nhóm cần cảm thấy an toàn tự để đưa issues thử ý tưởng Hiểu tầm nhìn vai trò giúp nhóm thông qua việc chuyển đổi 3.3 Introducing Change Khi thực thay đổi nào, có tác dụng phụ Giai đoạn hỗn loạn; nhóm bạn không chắn quy trình mới, số nhóm trung thành với thói quen cũ số người không chắn gây rối Mọi người thường nhầm giai đoạn hỗn loạn trạng Để tránh điều này, giải thích thay đổi mô hình đặt kỳ vọng Mong đợi chấp nhận hỗn loạn thực quy trình Agile Tìm khu vực khó khăn nhất, xác định cần thực để giải vấn đề để bạn thoát 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 người nơi để nói nỗi sợ hãi họ nơi để họ đưa Feedback Giúp người biết sợ hãi hoàn toàn bình thường Được mở rộng; dạy họ nói sợ hãi khó chịu Thảo luận nguồn gốc nỗi sợ hãi, học hỏi từ thảo luận, tạo định tiến lên Nỗi sợ phản ứng bình thường thay đổi Buộc người làm 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 nhóm có quyền sở hữu có khả tùy chỉnh phương pháp họ Mọi người thay đổi thái độ nhận thức họ giúp đỡ Lisa quan sát Mike Cohn làm việc với đội ngũ huấn luyện viên Là nhóm tự tổ chức, nhóm nghiên cứu xác định giải vấn đề riêng Mike chắn họ có thời gian nguồn lực để thử nghiệm cải thiện Ông đảm bảo doanh nghiệp hiểu chất lượng quan trọng số lượng tốc độ Mỗi đội bóng, chí nhóm tự tổ chức, cần có nhà lãnh đạo hiệu tương tác với đội ngũ quản lý tổ chức 3.3.3 Celebrate Success (ca tụng thành công) Thực thay đổi chiếm thời gian bực bội Vì chắn chào mừng toàn thành công với thành nhóm bạn Vỗ lưng bạn hoàn thành mục tiêu viết test cases mức cao (high-level) cho toàn stories vào ngày thứ tư vòng lặp (iteration) Nhóm làm chơi game, ăn trưa thực công việc iteration Thừa nhận quan trọng bạn muốn hướng đến thay đổi Đưa 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 cách dễ dàng để chuyển đổi sang phát triển Agile Tester tìm cách để biến quan hệ đối lập với developer thành hợp tác Họ cho biết họ giúp nhóm hiểu yêu cầu khách hàng mang lại giá trị kinh doanh thích hợp Họ giữ hoạt động ưa thích để xây dựng tương tác nhóm tốt Có nhiều bánh quy (cookies) hay chocolate có sẵn cho đồng đội (teammates) hướng tốt để giúp họ bàn bạn! Kiên nhẫn cảm giác vui vẻ lợi lớn 3.4 Management Expectations Khi nghĩ thách thức liên quan đến việc áp dụng Agile, thường nghĩ đến nhóm thực tế vấn đề mà gặp phải Tuy nhiên, để áp dụng Agile thành công, quản lý tham gia vào quan trọng Trong dự án theo giai đoạn, quản lý cập nhật thường xuyên đóng văn vào cuối giai đoạn Những người quản lý cấp không hiểu làm họ đánh giá dự án Agile Họ sợ kiểm soát hay thiếu sót “tiến trình” 3.4.1 Cultural Changes for Managers Trong dự án Agile, thay đổi kỳ vọng Trong vòng đời dự án waterfall, Janet nhớ nghe thấy nội dung “Chức hoàn thành 90%” nhiều tuần Kiểu số nghĩa dự án Agile Không có thỏa hiệp để đánh dấu kết thúc giai đoạn “độ chín” dự án không tính cột/mốc (gate) Các số liệu hữu ích xác định nhóm dự án Trong Scrum, Sprint biểu đồ release burndown kiểm tra mức độ hoàn thành story đưa cho manager thước đo tiến độ Các số liệu kiểm thử sử dụng để kiểm tra mức độ bao phủ kiểm thử (test corverage) không đưa tài liệu hoàn chỉnh Thật khó với số manager để hiểu việc định mặt kỹ thuật quản lý công việc việc riêng nhóm Nó không định manager Nhóm (bao gồm khách hàng) định nghĩa mức độ cần thiết chất lượng để phát hành ứng dụng thành công Nhóm Agile ước lượng làm việc khung thời gian nhóm truyền thống Thay việc phòng bị trước tình bất ngờ, nhóm cần lên kế hoạch để đủ thời gian cho thiết kế tốt thực mà đảm bảo technical debt không tăng Thay quản lý hoạt động nhóm mức thấp, managers nhóm Agile cần tập trung vào việc loại bỏ trở ngại cho thành viên nhóm để họ làm việc tố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 nguồn lực để thực trình chuyển đổi, họ thấy phát triển Agile cho phép họ lập kế hoạch xác đạt mục tiêu kinh doanh theo bước ổn định Đôi khi, việc quản lý thực điều hướng việc định bắt đầu thực 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 khủng hoảng phần mềm Để hiệu quả, họ cần có tập kỳ vọng quản lý khác Họ cần nhạy cảm với khó khắn thay đổi lớn, đặc biệt tổ chức không hoạt động tốt Trong tất trường hợp, managers cần kiên nhẫn trình dài chuyển đổi nhóm Agile chất lượng cao Việc họ đảm bảo cung cấp đủ nguồn lực cần thiết cho phép cá nhân trog nhóm học hỏi làm để thực công việc với chất lượng cao Nếu bạn QA manager, chuẩn bị giúp tester vượt qua nỗi sợ họ với hoạt động từ định nghĩa, giai đoạn kiểm thử liên tục đến vòng lặp nhanh chóng mặt mà họ phải thực phạm vi rộng lớn ngày Giúp họ thích ứng với việc kiểm thử không hoạt động riêng xảy sau phát triển, mà hai hoạt động kiểm thử coding tích hợp với Nếu bạn tester hay thành viên nhóm khác mà không nhận hỗ trợ trình chuyển đổi sang phát triển Agile, nghĩ khó khăn mà quản lý bạn gặp phải trình tìm hiểu phát triển Agile Giúp họ hiểu bạn cần hỗ trợ 3.4.2 Speaking the Manager’s Language Những nhà quản lý doanh nghiệp hiểu rõ nhất? Đó ROI (lợi nhuận vốn đầu tư Return On Investment) Để nhận hỗ trợ từ quản lý bạn, đóng khung yêu cầu bạn bối cảnh mà họ hiểu Tốc độ nhóm bạn chuyển thành tính làm cho việc kinh doanh thuận lợi Nếu bạn cần thời gian kinh phí để học thực công cụ kiểm thử tự động, giải thích với quản lý thời gian làm thêm kiểm thử hồi quy tự động giúp nhóm bạn nhanh hơn, phát hành nhiều chức vòng lặp Giống toàn thành viên nhóm Agile, manager cần học khái niệm tìm cách phù hợp với thành viên nhóm Sử dụng biểu đồ lớn để đảm bảo họ thực theo tiến trình vòng lặp release Tìm hướng tối đa hóa ROI Thông thường, doanh nghiệp yêu cầu tính phức tạp tốn có giải pháp đơn giản nhanh chóng mà mang lại giá trị tương tự Hãy giải thích công việc nhóm ảnh hưởng đến giai đoạn cuối Phối hợp với họ để tìm cách tốt cho bên liên quan để thể yêu cầu cho tính Các hạn chế ngân sách (budget limitations) thực tế mà hầu hết 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 Phương pháp tiếp cận toàn nhóm giúp điều Có lẽ giống với nhóm Lisa, nhóm bạn bị hạn chế ngân sách mua phần mềm, đó, bạn có xu hướng tìm 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 không giúp tester lập trình, trừ họ hợp tác với lập trình viên để tự động hóa kiểm thử Tận dụng chuyên gia nhóm giúp bạn làm việc điều kiện giới hạn kinh doanh Với toàn thử thách mà nhóm bạn phải đối mặt, thử hướng để phát triển nhóm quản lý để xây dựng sản phẩm có giá trị Đồng thời, phương pháp phát triển nào, bạn phải đảm bảo số quy trình, phù hợp để kiểm tra yêu cầu nhận quan tâm cần thiết 3.5 Change Doesn’t Come Easy Phát triển Agile nhanh chóng mặt, thay đổi không Các nhóm với Agile làm chậm số thực hành mà họ cam kết sử dụng Chúng ta thấy nhiều tester thất vọng vòng đời phát triển “Agile” họ thường vòng đời phát triển mini-waterfall Những tester bị ép buộc; xảy thường xuyên Các vòng lặp nhiều trước story kiểm thử Lập trình viên từ chối làm theo thực hành TDD hay làm cặp (pairing) Nhóm đổ trách nhiệm cho chất lượng tester, người thay đổi quy trình Không có phép thuật mà bạn sử dụng để giúp nhóm bạn tạo thay đổi, có số lời khuyên cho tester, người đư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ỹ TDD khó Tìm hướng giúp nhóm bạn có thời gian để làm chủ Tìm thay đổi bạn làm độc lập thời gian chờ đợi Ví dụ, lập trình viên học việc viết unit tests, bạn giúp đỡ cách thực GUI test tool Giúp nhóm thực bước nhỏ Nhớ người hoảng sợ, họ quay trở lại thói quen cũ, thói quen không tốt Hãy tập trung vào 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 bạn cần xem tai nạn xe lửa Nếu đề xuất bạn cải tiến bị từ chối nhóm thất bại, đưa đề xuất bạn lần hỏi nhóm việc cân nhắc có cố gắng thực vào vòng lặp không Mọi người hầu hết lòng thay đổi phần mà họ cảm thấy khó khăn 3.5.3 Build Your Credibility (Xây dựng tín nhiệm bạn) Giờ bạn làm việc với lập trình viên Hãy cho họ viết bạn giúp họ Giúp họ thấy issues việc đưa bug report Hỏi họ việc review code với bạn trước họ check-in Khi họ nhận thấy bạn góp phần tạo gia giá 4.4.4 Performance an Rewards (Thưởng cho hiệu công việc) Việc đo đạc đánh giá hiệu dựa sở cá nhân có nguy phá hoại hợp tác nhóm Chúng không muốn programmer cảm thấy cô không nên thực việc kiểm thử (testing task) cô muốn tập trung vào việc cung cấp mã sản phẩm Chúng không muốn quản trị hệ thống (system administrator) không bận rộn để đảm bảo hoàn thành mục tiêu cá nhân cô ấy, khiến cô giúp đỡ xảy vấn đề với môi trường kiểm thử Ngược lại, người thực tốt cố gắng làm việc tốt với nhóm mà không bị đánh bại phần lại nhóm không kéo lại với Đây thời điểm mà manager cần bước lên giúp nhóm tìm hướng Nếu lỗi lớn đưa lên production, không nên đổ lỗi cho tester Thay vào đó, toàn nhóm nên phân tích điều xảy bắt đầu bước để ngăn ngừa tái phát Nhóm phát triển (development team) cần giữ yêu cầu nghiệp vụ đầu Thiết lập mục tiêu cho việc kinh doanh, tăng lợi nhuận, làm cho khách hàng hạnh phúc Làm việc chặt chẽ với doanh nghiệp để thành công bạn giúp cho công ty thành công Như đề cập chương “Cultural challenges”, ăn mừng thành công, nhỏ Một lễ kỷ niệm high-five, bữa ăn trưa công ty cung cấp, hay cho phép nghỉ sớm chút Scrum Master nhóm Lisa đưa vàng họp ngày (stand-up meeting) cho thành tích đặc biệt Sự thừa nhận người giúp bạn nhóm bạn Nhóm tìm hướng lạ để nghi nhận đóng góp người nhóm Trong họp xem xét trình bày vòng lặp (Iteration review demonstration meeting), nhóm phát triển nhóm khách hàng có mặt, thiết lập tốt để công nhận hai thành tích cá nhân nhóm 4.4.5 What can you do? (Bạn làm gì?) Nếu bạn tester nhóm Agile, đặc biệt nhóm Agile mới, bạn cần phải làm để giúp nhóm vượt qua thách thức tổ chức thành công? Bạn thích nghi với nhóm đóng góp kỹ kinh nghiệm bạn nào? Đặt 10 nguyên tắc mà mô tả chương để làm việc Cam đảm phần đặc biệt quan trọng Hãy đứng dậy nói chuyện với người; hỏi xem bạn giúp Tiếp cận thành viên nhóm nhóm khách cách giao tiếp trực tiếp Chú ý trở ngại yêu cầu nhóm giúp loại bỏ chúng Phát triển Agile hiệu quả, loại bỏ chướng ngại vật khỏi đường giúp nhóm làm việc tốt Chúng cảm thấy tự hào hài lòng, cá nhân toàn nhóm Khi làm theo nguyên tắc Agile, hợp tác tốt, sử dụng phản hồi để giúp cải tiến việc làm, luôn tìm kiếm hướng tốt để hoàn thành mục tiêu Tất có nghiaxchungs liên tục nâng cao chất lượng sản phẩm Summary Trong chương này, tìm cách để xây dựng nhóm cấu trúc để kiểm thử phát triển Agile thành công • Hãy xem xét tầm quan trọng cấu trúc nhóm; tester cần suy nghĩ độc lập, đặt họ vào nhóm riêng phản tác dụng • Các tester cần truy cập vào cộng đồng tester rộng lớn để học hỏi đưa ý tưởng Nhóm QA tạo cộng đồng tổ chức • Điều quan trọng toàn nhóm ngồi nhau, để thúc đẩy hợp tác; nhóm bị chia tách, cung cấp 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 xác Câu trả lời “Nó phụ thuộc vào tình hình bạn.” • Các nhóm cần tự quản, xác định tìm giải pháp cho vấn đề mình, tìm kiếm hướng cải tiến Họ chờ nói với họ phải làm • Quản lý nên thưởng cho hiệu suất theo hướng thúc đẩy nỗ lực nhóm để mang lại giá trị thương mại, không nên phạt thành tích cá nhân nhóm gặp khó khăn • Các tester sử dụng nguyên tắc Agile để cải thiện kỹ thân tăng giá trị họ nhóm Họ cần chủ động tìm cách đóng góp cho nhóm Chapter - Transitioning Typical Processes Chuyển đổi quy trình đặc thù Có nhiều quy trình dự án truyền thống không chuyển đổi sang Agile, chúng yêu cầu nhiều văn (documentation) hay phần cố hữu thuộc phased gated process, yêu cầu đóng cuối giai đoạn Giống điều gì, quy tắc cứng nhắc nhanh chóng để chuyển quy trình bạn sang quy trình nhẹ nhanh nhẹn Trong chương này, thảo luận vài quy trình, đưa cho bạn thay hướng dẫn làm để làm việc với chúng dự án Agile Bạn thấy nhiều ví dụ chi tiết thay đổi phần III, IV, V 5.1 Seeking Lightweight Processes Tìm kiếm quy trình hạng nhẹ Khi nhóm học làm để sử dụng quy trình Agile, số quy trình truyền thống xóa bỏ lộn xộn Hầu hết tester quen làm việc với phương pháp phát triển theo giai đoạn (phased) cột mốc (gated) truyền thống để tạo sử dụng số liệu, nghi lại lỗi (defects) hệ thống theo dõi lỗi (formal defect tracking system), viết kế hoạch kiểm thử (test plan) chi tiết Những điều phù hợp chỗ 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á mô hình quy trình chất lượng Những yêu cầu không thường biến bạn bắt đầu sử dụng thực hành phát triển Agile Trong thực tế, số người lo lắng phát triển Agile không thương thích mô hình chuẩn CMMI ISO 9000 Nó thú vị để nói thứ khác kiểm thử dự án Agile, cần hướng để đo đạc tiến độ (measure progress), theo dõi lỗi (track defects) kế hoạch kiểm thử (plan testing) Chúng ta cần chuẩn bị làm việc với mô hình chất lượng tổ chức Điều quan trọng giữ quy trình đủ nhẹ để giúp cung cấp giá trị cách kịp thời Hãy bắt đầu cách nhìn vào số liệu 5.2 Metrics Số liệu gây tranh cãi, sử dụng nhiều thời gian để nói Số liệu nơi đưa nguồn lực bị lãng phí, nhóm mục đích số (metrics can be a pit of wasted effort, numbers for the sake of numbers) Đôi chúng sử dụng theo cách có hại, chúng xấu Chúng hướng dẫn nhóm bạn giúp đo đạc tiến độ bạn so với mục tiêu Chúng ta xem làm để sử dụng số liệu để giúp Agile tester nhóm 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 thước đo tìm thước đo thúc đẩy hành vi đắ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), Mary Tom Poppendiek, nguồn tuyệt vời để dạy làm để áp dụng bước đầu lean vào kiểm thử bạn phát triển nguồn lực (effort) Theo Poppendiecks [2007], phép đo đạc lean thời gian cần “từ ý tưởng đến tiền mặt”, từ yêu cầu tính khách hàng đến phần mềm phát hành Họ gọi phép đo “chu kỳ thời gian - cycle time” Tập trung vào khả nhóm để cung cấp giá trị thương mại “lặp lại nhiều lần đáng tin cậy” Sau đó, nhóm cố gắng liên tục cải tiến quy trình họ giảm thời gian chu kỳ Việc đo lường thời gian chu kỳ đòi hỏi toàn nhóm khiến bạn hướng đến thành công phép đo bị hạn chế vai trò nhóm riêng biệt Nó thường lâu để sửa lỗi (defect)? Nhóm làm để giảm độ trễ, lượng thời gian cần thiết? Những số liệu kiểu khuyến khích phối hợp để tạo cải tiến Đo lường lean khác, theo Poppendiecks giải thích sách họ lợi nhuận tài Nếu nhóm phát triển sản phẩm có lợi, cần phải hiểu làm để đạt lợi nhuận tốt Ngay nhóm phát triển phần mềm nội hay số sản phẩm phi lợi nhuận khác, cần xem xét ROI để đảm bảo cung cấp giá trị tốt Xác định mục tiêu thương mại tìm hướng đo mà nhóm cung cấp Công ty cố gắng để thu hút khách hàng không? Giữ việc theo dõi tài khoản đăng ký tính 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 mục tiêu toàn phát triển phần mềm Poppendiecks đưa ví dụ cách đơn giản, bạn đo lường xem liệu khách hàng có hài lòng không Chúng thích số liệu lean, chúng phù hợp với mục tiêu để cung cấp giá trị thương mại Tại quan tâm đến số liệu? Chúng ta đến phần 5.2.2 Why We Need Metrics (Tại cần số liệu) Có nhiều lý tốt để tập hợp theo dõi số liệu Cũng có số lý xấu Bất sử dụng số liệu tốt theo cách khủng khiếp, chẳng hạn sử dụng chúng sở để đánh giá hiệu suất thành viên nhóm Tuy nhiên, số liệu, mà bạn đo đạc tiến độ bạn nào? Khi số liệu sử dụng thông báo hướng dẫn - nói với nhóm bỏ theo dõi hay cung cấp phản hồi mà theo dõi - chúng tập hợp đáng giá Số lượng unit tests tăng lên ngày? Tại code coverage lại giảm từ 75% đến 65%? Nó lý tốt - Có lẽ khỏi mã không sử dụng bao phủ kiểm thử Các số liệu cảnh báo cho vấn đề, tách chúng thường giá trị Số liệu để đo cột mộc (milestones) theo hành trình để đạt mục tiêu nhóm hữu ích Nếu mục tiêu tăng độ bao phủ mã kiểm thử đơn vị (unit test code coverage) lên 3%, chạy độ bao phủ mã (code coverage) lần check-in để đảm bảo không buông lơi kiểm thử đơn vị (unit tests) Nếu không đạt cải tiến mong đợi, điều quan trọng đưa lý than thở mức thưởng bị giảm Thay tập trung vào thước đo cá nhân, nên tập trung vào mục tiêu hướng đến việc đạt mục tiêu Số liệu giúp nhóm, khách hàng theo dõi tiến độ vòng lặp (interation) lần phát hành (release) epic Nếu sử dụng burndown chart, đưa lên thay xuống, cờ đỏ để dừng lại, nhìn vào điều xảy ra, chắn hiểu giải vấn đề Có lẽ nhóm thiếu thông tin story Số liệu, bao hàm burndown charts, không sử dụng hình thức trừng phạt hay nguồn đổ lỗi Ví dụ, câu hỏi “Tại ước lượng bạn thấp?”, “Tại bạn hoàn thành stories?” tốt đến từ nhóm diễn đạt “Tại ước lượng lại thấp?” “Tại không hoàn thành stories?” Số liệu, sử dụng cách, thúc đẩy nhóm Nhóm Lisa theo dõi số lượng kiểm thử đơn vị chạy 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ý để ăn mừng Số lượng kiểm thử đơn vị tăng lên ngày phản hồi tốt cho nhóm phát triển khách hàng Tuy nhiên, điều quan trọng nhận thân số ý nghĩa Ví dụ, kiểm thử viết cách nghèo nàn, để có sản phẩm kiểm thử tốt, có lẽ cần 10,000 kiểm thử Các số không hữu ích đứng riêng biệt Khi bạn cố gắng để tìm xem cần phải đo đạc gì, hiểu vấn đề mà bạn cần giải Khi bạn biết vấn đề gặp phải, bạn cần đưa mục tiêu Những mục tiêu đo đạc “Giảm thời gian đáp ứng trung bình ứng dụng XYZ xuống 1.5 giây với 20 người dùng đồng thời” tốt “Cải tiến hiệu ứng dụng XYZ” Nếu mục tiêu bạn đo đạc được, phép đo mà bạn cần thu thập để theo dõi rõ ràng Hãy nhớ sử dụng số liệu động lực không dập xuống tinh thần nhóm Xin nhắc lại lần nữa: Tập trung vào mục tiêu, số liệu Có lẽ bạn không sử dụng số liệu xác để đo cho dù bạn đạt mục tiêu nhóm, hay bạn không giải thích chúng ngữ cảnh Số lượng báo cáo lỗi (defect) tăng có nghĩa nhóm làm việc kiểm thử tốt hơn, nghĩa họ viết nhiều mã nguồn lỗi Nếu số liệu bạn không giúp bạn hiểu tiến độ hướng tới mục tiêu bạn, bạn có số liệu sai 5.2.3 What not to Do with Metrics (không nên làm với số liệu) Câu nói phổ biến Mark Twain, “Có ba loại nói dối: Nói dối, nói dối bị nguyền rủa, thống kê” (there are three kinds of lies: lies, damned lies, and statistics) Mục tiêu đo đạc tốt; bạn đánh giá chúng theo số cách đó, bạn nói có bạn không đạt chúng Mặt khác, sử dụng số liệu để đánh giá hiệu cá nhân hay nhóm thực nguy hiểm Theo thống kê xoắn vào giải thích sử dụng cách bất lợi Đưa số dòng mã (line of code), thước đo phần mềm truyền thống Có nhiều dòng mã tốt, có nghĩa nhóm hoạt động có hiệu quả, xấu, có nghĩa nhóm viết đoạn mã không hiệu Như số lượng lỗi tìm thấy? Nó có nghĩa đánh giá tester số lượng lỗi họ tìm thấy không? Làm để giúp họ hoàn thành tốt công việc mình? Là an toàn để nói nhóm phát triển tạo số lượng lỗi số dòng code cao làm công việc tệ không? Hay nhóm tìm nhiều lỗi làm việc tốt hơn? Ngay nghĩ xảy ra, làm để thúc đẩy cho nhóm để đánh mạnh vào số? Sẽ làm cho 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 biết điều đo bị giới hạn để thay đổi Bao nhiêu kiểm thử chạy pass? Bao nhiêu ngày cần “build on the sheft”? Toàn build pass? Số liệu thấy dễ giải thích giá trị Nếu bạn muốn theo dõi số lượng kiểm thử pass, chắn số liệu nhìn theo hướng đúng, với người Bảng xếp hạng lớn nhìn theo cách hiệu hiển thị số liệu mà biết Số liệu bạn có đánh giá xấu không? Đừng đo lợi ích số liệu sản phẩm Nghĩ mà bạn học từ số Phần tiếp theo, xem xét lợi nhuận đầu tư mà bạn mong đợi từ số liệu 5.2.5 Metrics ROI Khi bạn xác định số liệu mà bạn cần, chắn bạn lấy chúng với giá hợp lý Nếu build liên tục bạn cung cấp số liệu có ích, mang lại giá trị tốt Bạn chạy build, đưa cho thêm thông tin, 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ỏi bạn rắc rối Nhóm Lisa thử theo dõi thời gian thực tế dành cho story so với thời gian ước lượng Họ học khác việc ước lượng? Không nhiều Một số nhóm có kinh nghiệm thấy họ bỏ qua sprint burndown chart bảng công việc cho họ đủ thông tin để đánh giá tiến độ họ Họ sử dụng thời gian để ước lượng công việc tính lại vào hoạt động hiệu Điều nghĩa khuyên bạn dừng theo dõi phép đo Những nhóm cần hiểu tốc độ tỷ lệ burndown họ, để họ cải tiến Tỷ lệ lỗi (defect) số liệu phần mềm truyền thống, chúng nhiều giá trị với nhóm nhằm đến zero defects Không có nhiều giá trị việc biết tỷ lệ lỗi tìm thấy sửa thời gian phát triển, việc tìm sửa chúng phần thiếu phát triển Nếu tester đưa defect cho programmer, kiểm thử đơn vị viết lỗi sửa theo hướng đúng, thường không cần ghi lại defect Mặt khác, nhiều defect đến production mà không bị phát ra, có giá trị việc theo dõi số để biết nhóm cải tiến Khi bắt đầu viết lại ứng dụng lỗi, nhóm Lisa đặt mục tiêu không nhiều lỗi nghiêm trọng code sau code đưa lên production khoảng thời gian tháng Có 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 cách để loại bỏ lỗi trình phát triển vượt qua mục tiêu Hình dung lợi nhuận đầu tư số liệu định có nên theo dõi hay trì không Nguồn lực sử dụng để tập hợp khẳng định giá trị mà mang lại không? Nó dàng truyền đạt hiểu không? Như khi, làm cho tình hình bạn Thử nghiệm với việc giữ số liệu cụ thể cho vài sprint đánh giá liệu 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 tỷ lệ defect Trong phần tiếp theo, xem xét lý để theo dõi defect, hay không theo dõi defect, học từ chúng 5.3 Defect Tracking Một câu hỏi hỏi nhóm Agile “Chúng ta theo dõi bugs defect tracking system chứ?” câu trả lời đơn giản, đưa đề suất cho vấn đề đề nghị số thay đổi để bạn xác định phù hợp với nhóm bạn 5.3.1 Why should We Use a Defect Tracking System (DTS) - Tại nên sử dụng hệ thống theo dõi lỗi (DTS) Có nhiều tester sử dụng defect tracking hướng để truyền đạt vấn đề (issues), dễ sử dụng với công cụ tương tự Một DTS nơi thích hợp để theo dõi không defect mà độ ưu tiên (priorities), mức độ nghiêm trọng (severities) trạng thái (status), giao việc (assigned) xử lý defect Nhiều học viên Agile nói không cần làm điều nữa, theo dõi defect theo thẻ (card) hay số chế đơn giản khác Chúng viết kiểm thử để đưa lỗi (failure), sửa mã, giữ kiểm thử hồi quy Tuy nhiên, có nhiều lý để sử dụng công cụ ghi lại defect chúng sửa chữa Hãy khám phá số chúng a Convenience (sự tiện lợi) Một mối quan tâm việc không giữ DTS nơi để giữ tất chi tiết lỗi (bug) Các tester ghi lại lỗi với nhiều thông tin, làm để tái (reproduce) nó, tìm thấy môi trường nào, hay sử dụng hệ điều hành (operating system) trình duyệt (browser) Toàn thông tin vừa thẻ (card), bạn nắm bắt chi tiết nào? Nếu bạn dựa vào thẻ, bạn cần trao đổi Nhưng với trao đổi, chi tiết bị đi, tester quên xác thực hiện, đặc biệt lỗi tìm vài ngày trước programmer giải vấn đề Một DTS nơi phù hợp để giữ tất tài liệu bổ sung, chẳng hạn hình hay tập tin (file) tải lên b Knowledge Base (dựa vào tri thức) Chúng nghe lý để theo dõi defect như, “Chúng ta cần thấy báo cáo lỗi cũ” Chúng cố gắng nghĩ lý bạn nên nhìn vào báo cáo cũ, làm việc chương này, Janet tìm thấy ví dụ Janet’s Story Khi kiểm thử thuật toán WestJet, tìm thấy bất thường Tôi hỏi Sandra, tester khác, cô gặp vấn đề trước Sandra mơ hồ nhớ lại không xác Cô nhanh chóng tìm kiếm Bugzilla tìm thấy vấn đề Nó bị đóng không hợp lệ (invalid) doanh nghiệp định không thích hợp để sửa, mức ảnh hưởng thấp Việc giúp tránh việc đặt câu hỏi nhập lại lỗi nhận lại bị đóng Bởi thành viên nhóm gồi gần nhau, câu chuyện dẫn tới thảo luận khác với nhà phân tích nghiệp vụ nhóm Cuộc thảo luận làm dấy lên ý tưởng trang FAQ, danh sách vấn đề bật, theo dòng cung cấp cho tester tìm thấy vấn đề xác định, mà định thực không giải chúng Câu chuyện cho thấy sở liệu lỗi sử dụng sở tri thức, có chế khác để giữ định nghiệp vụ thông tin tảng họ Nếu vấn đề theo dõi đủ lâu, có lẽ nên viết đưa lại lần Các trường hợp thay đổi, doanh nghiệp định đáng để sửa chữa Các loại loại lỗi hay bị gián đoạn thời gian lâu để theo dõi thích hợp sử dụng DTS Những lỗi thể không thường xuyên, 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 nơi thông tin nắm bắt làm Nó chứa ghi, dấu nhiều Đây thông tin hữu ích nhóm có thời gian để xem xét vấn đề hay vấn đề trở nên quan trọng Thông tin báo cáo lỗi sử dụng sau cho vài mục đích Đây câu chuyện nhóm Lisa việc làm để sử dụng thông tin Lisa’s Story Một developer nhóm phục vòng xoay “hỗ trợ production” vòng lặp Yêu cầu hỗ trợ Production đến từ phía nghiệp vụ cho sửa lỗi sai lầm khứ (past mistakes) hay vấn đề production cần can thiệp tay “Người hỗ trợ production” tìm kiếm vấn đề ghi lại sửa lỗi báo cáo lỗi chưa Những thích thường gồm trạng thái SQL (SQL statement) thông tin nguyên nhân Nếu gặp phải lỗi tương tự tình sau đó, giải pháp dễ dàng tìm thấy DTS Nếu số kiểu vấn đề xảy thường xuyên, nhóm sử dụng DTS để nghiên cứu phân tích Mặc dù nhóm nhỏ, đối phó với nhiều mã di sản (legacy code), dựa vào trí nhớ người để theo dõi vấn đề sửa chữa Nhớ lại nguyên nhân defect thực để làm xong yêu cầu đặc biệt khó khăn nhóm đặc biệt lớn không vị trí Các khách hàng không quan tâm đến giải pháp cho vấn đề họ c Large or Distributed Teams Nếu dự án lớn mà defect tìm thấy nhóm ảnh hưởng đến nhóm khác DTS có lẽ lựa chọn tốt Tất nhiên, để có ích, toàn thành viên nhóm phải truy cập vào Liên lạc mặt đối mặt (face-to-face communication) lựa chọn đầu tiên, hoàn cảnh không cho phép vậy, cần hỗ trợ từ DTS d Customer Support Khi có defects báo cáo từ khách hàng sau phát hành, khách hàng muốn biết chúng sửa chữa Nó vô giá cho phận hỗ trợ hỗ trợ kỹ thuật để biết sửa chữa lần phát hành Họ tìm defect nợ thời gian phát hành cho khách hàng biết Một DTS làm cho trở nên đơn giản để lấy thông tin e Metrics Có nhiều lý để theo dõi tỷ lệ defect Ngoài có lý bạn không nên theo dõi defect Ví dụ, không nghĩ bug tính defect không lặp lại Tất nhiên, điều đưa thảo luận khác việc nên theo dõi sao, không đưa f Traceability (khả truy vết - v Trace) Lý khác, nghe DTS khả truy vết, liên kết defect đến trường hợp kiểm thử (test cases) Chúng không chắn lý đáng Không phải toàn defect liên kết với test case, mà chúng không nên Ví dụ, lỗi giống spelling mistakes (lỗi tả) không cần test case đặc biệt Có thể sản phẩm trực quan để sử dụng; lỗi thực tế mà thường không báo cáo Bạn viết kiểm thử để xác định xem điều sử dụng? Exploratory testing (kiểm thử thăm dò) tìm lỗi điều kiện biên, giá trị để tạo kiểm thử tự động Nếu trường hợp kiểm thử tự động để bắt lỗi, gần ghi lại defect, bắt lại không đưa Nhu cầu truy vết kết thúc Vì vậy, có lẽ không cần theo dõi defect 5.3.2 Why shouldn’t We Use a DTS? Agile Lean cung cấp cho thực hành nguyên tắc, giúp làm giảm yêu cầu DTS Nếu trình vững chắc, tất người cam kết phân phối sản phẩm chất lượng, defects trở nên hoi theo dõi đơn giản a As a Communication Tool DTS chắn không thúc đẩy giao tiếp programmer tester Chúng làm cho dễ dàng để tránh nói chuyện trực tiếp với b Waste of Time and Inventory Chúng ta có xu hướng đưa nhiều thông tin vào DTS bước để tạo lỗi Phụ thuộc vào bug, thời gian dài để viết bước sau để programmer tái lại Sau phân loại, số người đưa 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 số ý kiến, gán lại cho người báo cáo Cuối việc sửa chữa xác nhận Toàn chu kỳ tăng lên gấp đôi programmer hiểu sai vấn đề lần Giá báo cáo defect đơn giản trở nên cao Nó dễ dàng tester nói chuyện với programmer đưa mà họ tìm thấy cho developer sau sửa chữa defect theo hướng đúng? Chúng nói sau Các defects DTS trở thành hàng đợi hay Product Backlog nhỏ Theo nguyên tắc lean, hàng tồn defect lãng phí Là nhóm, nên nghĩ hướng giảm lãng phí 5.3.3 Defect Tracking Tools Nếu bạn định sử dụng DTS, chọn cẩn thận Hiểu nhu cầu bạn làm cho trở nên đơn giản Bạn muốn người học cách sử dụng Nếu trở nên cao hay khó để sử dụng, người tìm hướng để làm việc xung quanh Như toàn công cụ sử dụng nhóm phát triển Agile, bạn nên xem xét ý kiến toàn nhóm Nếu từ nhóm khách hàng chuyển báo cáo lỗi, lấy ý kiến anh ta/cô Một công cụ đơn giản mà Janet sử dụng Alcea’s FIT IssueTrack Nó cấu hình, không cần bạn theo quy trình sẵn có, dễ dàng để có số liệu Làm tập nhà bạn tìm công cụ làm việc cho bạn Có loại hệ thống defect-tracking mã nguồn mở, hệ thống lưu trữ, 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 nhìn thấy Chúng thường khuyên bạn thử nghiệm với công cụ khác nhau, sử dụng vài vòng lặp (iteration), hệ thống bug-tracking phức tạp hơn, bạn cần chuyển toàn lỗi hệ thống sang hệ thống mà bạn cố gắng Sử dụng thời gian để suy nghĩ điều mà bạn cần với DTS, phục vụ mục đích nào, đánh giá thay đổi cách thận trọng Như với toàn công cụ tìm kiếm, tìm chỗ khác cộng đồng bạn, nhóm người dùng danh sách email, để lấy số lời khuyên Xác định tiêu chuẩn bạn trước tìm kiếm, thử nghiệm bạn Nếu bạn chọn công cụ sai, cắt lỗi bắt đầu nghiên cứu lại 5.3.4 Keep Your Focus Các định báo cáo theo dõi defects quan trọng, không theo dõi mục tiêu bạn Bạn muốn cung cấp sản phẩm chất lượng tốt bạn có thể, bạn muốn phân phối giá trị cho doanh nghiệp cách kịp thời Dự án thành công người phéo làm việc tốt công việc họ Tập trung vào việc cải tiến giao tiếp xây dựng hợp tác Nếu bạn gặp nhiều defect, điều tra nguồn gốc vấn đề Nếu bạn cần DTS để thực điều này, sử dụng Nếu nhóm bạn làm việc tốt cách ghi defect kiểm thử thực sửa chúng lập tức, làm điều Nếu số kết hợp cho phép bạn liên tục cải tiến, làm với Điều phải nó phải làm việc cho toàn 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 quy trình chất lượng tiêu biểu mà tạo hầu hết câu hỏi tranh cãi thử nghiệm nhanh nhẹn Một nguồn lớn nhầm lẫn liệu dự án nhanh nhẹn cần tài liệu kế hoạch kiểm tra ma trận truy xuất nguồn gốc Hãy xem xét bên cạnh Defect tracking quy trình chất lượng tiêu biểu mà tạo hầu hết câu hỏi tranh cãi Agile testing Nguồn gốc nhầm lẫn lớn dự án Agile có cần tài liệu test plans hay 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 giai đoạn (phased) truyền thống nhấn mạnh tầm quan trọng test plan (kế hoạch kiểm thử) phần yêu cầu tài liệu tổng thể Chúng định hướng để đưa mục tiêu, phạm vi, phương pháp tiếp cận, tập trung vào nguồn lực kiểm thử phần mềm cho bên liên quan Tài liệu hoàn thành nhằm mục đích giúp người nhóm kiểm thử hiểu “Tại sao” “làm nào” để xác nhận sản phẩm Trong phần này, xem xét kế hoạch kiểm thử khía cạnh khác việc chuẩn bị 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ử 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 mà tester cần làm Các tester làm việc với phần lại nhóm, nguồn lực kiểm thử thấy tất thẻ nhiệm vụ Câu hỏi thường đặt cho “Vẫn cần test plan không?” để trả lời câu hỏi đó, nhìn vào khác biệt kế hoạch kiểm thử chiến lược hay phương pháp tiếp cận kiểm thử Có nhiều thông tin chứa tài liệu, khả có đọc hết Hãy xem xét thông tin thực cần thiết cho bên liên quan Suy nghĩ cách thường sử dụng sử dụng cho Chúng thích suy nghĩ, chiến lược kiểm thử tài liệu thay đổi, kế hoạch kiểm thử tạo xác định cho dự án a Test Strategy Một chiến lược kế hoạch hành động lâu dài, từ khóa “long-term” Nếu tổ chức bạn muốn tài liệu phương pháp tiếp cận kiểm thử tổng thể cho dự án, xem xét thông tin đặt 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 dự án cụ thể tách thành tài liệu chiến lược kiểm thử phương pháp tiếp cận kiểm thử Tài liệu sử dụng tài liệu tham khảo cần cập nhật quy trình thay đổi Một tài liệu chiến lược kiểm thử sử dụng để đưa cho nhân viên mới, cung cấp hiểu biết cao cách quy trình kiểm thử bạn làm việc b Test Plan Sức mạnh kế hoạch xác định vấn đề phụ thuộc, mang lại rủi ro cho phần bề mặt nhắc đến giải quyết, nghĩ tranh lớn Kế hoạch kiểm thử không khác Một nhóm nghĩ rủi ro phụ thuộc, tranh lớn cho dự án trước bắt đầu Cho dù nhóm bạn định tạo tài liệu kế hoạch kiểm thử hay không, kế hoạch hoàn thành Mỗi dự án khác nhau, không mong đợi giải pháp phù hợp với tất Đôi khách hàng nhấn mạnh tài liệu kế hoạch kiểm thử Nếu bạn ký hợp đồng để phát triển ứng dụng, kế hoạch kiểm thử nên phần tập hợp phân phối, bao gồm mục tài liệu yêu cầu tài liệu thiết kế Thảo luận kế hoạch kiểm thử thường dẫn đến nói truyện truy vết Có thực toàn kế hoạch kiểm thử hành vi mong muốn mã phân phối không? Làm để yêu cầu kế hoạch kiểm thử liên quan đến kiểm thử thực đế chức cuối cùng? 5.4.2 Traceability Trong dự án truyền thống, cần dùng ma trận truy vết để xác định kiểm thử toàn yêu cầu hay không Nếu yêu cầu bị thay đổi, cần biết thay đổi trường hợp kiểm thử tương ứng chưa Với văn yêu cầu lớn, cách để nhóm kiểm thử biết có bao phủ tốt hay không Trong dự án Agile, hạn chế Chúng ta xây dựng chức nhỏ, bước xác định tốt Chúng ta làm việc với đội ngũ chặt chẽ biết thay đổi Nếu programmer làm việc kiểm thử (test-first), biết có kiểm thử đơn vị cho tất khối công việc nhỏ Chúng ta hợp tác với khách hàng để định nghĩa kiểm thử chấp nhận (acceptance tests) Chúng ta kiểm thử story programmer làm việc, biết không kiểm thử Nếu số ngành công nghiệp đòi hỏi phải có traceability Nếu có, đề nghị bạn nhìn vào vấn đề mà người quản lý cố gắng giải Khi bạn hiểu yêu cầu gì, bạn tạo giải pháp đơn giản Có nhiều cách để cung cấp traceability Các lời bình (comments) check-in mã nguồn tham khảo từ trang wiki, chứa yêu cầu hay test cases hay số defect Bạn đưa lời bình (comments) kiểm thử đơn vị (unit test) để xác định kiểm thử xác định yêu cầu Các kiểm thử tích hợp trực tiếp với yêu cầu công cụ FitNesse Nhóm bạn dễ dàng tìm cách làm việc phù hợp với yêu cầu khách hàng Các tài liệu ma trận traceability cần thiết để thực đầy đủ yêu cầu đưa chuẩn đánh giá tổ chức hay mô hình chất lượng Hãy xem xét làm để hướng dẫn xuyên suốt 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 quy trình chất lượng truyền thống tồn với phương thức phát triển Agile không?” Về lý thuyết, lý chúng Trong thực tế, thường lựa chọn Các mô hình chất lượng thường rơi vào lĩnh vực nhóm QA truyền thống, chúng theo tester vào cấu trúc Agile Nó không dễ dàng để thích hợp với mô hình phát triển Agile Hãy xem vài quy trình chất lượng tiêu biểu tester nhóm họ phải thích nghi 5.5.1 Audits Các ngành công nghiệp khác có yêu cầu đánh giá (audit) khác Nhóm đảm bảo chất lượng tổ chức phát triển truyền thống thường giao nhiệm vụ cung cấp thông tin cho kiểm toán viên (auditors) đảm bảo tuân thủ yêu cầu kiểm toán Đạo luật Sarbanes-Oxley năm 2002, ban hành để đáp ứng với bê bối tài tập đoàn cao, đưa yêu cầu cho việc trì hồ sơ kinh doanh Đảm bảo tuân thủ không bị rơi vào phòng IT SAS 70 chuẩn kiểm toán công nhận rộng rãi cho tổ chức dịch vụ Đây vài ví dụ 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 có nhóm chuyên gia kiểm soát việc tuân thủ làm việc với kiểm toán viên, nhóm phát triển thường yêu cầu cung cấp thông tin Ví dụ kiểm thử thực lần release phần mềm, chứng minh tài khoản khác hòa hợp Tester giao nhiệm vụ viết test plan để đánh giá hiệu hoạt động kiểm soát Các tester phần nhóm Agile, nên cống hiến riêng cho nhóm Nếu giúp đỡ họ cần thiết việc cung cấp thông tin cho kiểm toán giúp đảm bảo việc tuân thủ Viết story cho lên kế hoạch với phần lại không việc nhóm Làm việc tuân thủ kiểm toán nội nhóm để hiểu trách nhiệm nhóm bạn 5.5.2 Frameworks, Models, and Standards Có nhiều mô hình chất lượng, xem xét hai bạn thấy bạn cần điều chỉnh quy trình Agile để phù hợp với ràng buộc Capability Maturity Model Integration (CMMI) nhằm giúp tổ chức cải thiện quy trình họ, mà không đưa thực hành phát triển cụ thể để thực cải tiến Information Technology Infrastructure Library (ITIL) tập thực hành tốt cho quản lý dịch vụ IT nhằm giúp tổ chức phát triển quy trình chất lượng hiệu Cả hai mô hình tồn với phát triển Agile Chúng bắt nguồn từ mục đích, làm cho dự án phát triển phần mềm thành công Hãy nhìn vào CMMI, khung để đo trưởng thành quy trình bạn Nó định nghĩa mức độ cách đo trình ẩn số, định nghĩa, tài liệu, lâu dài, hay tối ưu Các dự án Agile có trình định nghĩa, toàn nhóm làm tài liệu thứ họ làm Ví dụ, quản lý yêu cầu với số thẻ bảng kế hoạch phát hành (release) với khách hàng tạo định trình định nghĩa miễn bạn làm tất thời gian Các retrospectives nhằm mục đích cải thiện quy trình liên tục, nhóm tìm hướng để tối ưu hóa quy trình Nếu điều nhóm bạn thiếu tài liệu, nghĩ việc gộp quy trình bạn vào tài liệu chiến lược kiểm thử Hãy hỏi thân xem số lượng tài liệu tối thiểu mà bạn đáp ứng yêu cầu CMMI Janet thành công với việc sử dụng biểu đồ (diagram) hình 52 Nếu ITIL giới thiệu tổ chức bạn tác động đến việc thay đổi quản lý, lắp quy trình bạn để chứa Bạn tìm thấy lợi ích từ quy trình Nếu tổ chức bạn sử dụng số kiểu mô hình quy trình hay quản lý tiêu chuẩn chất lượng, học làm việc với chuyên gia thích hợp tổ chức bạn Duy trì tập trung nhóm vào việc cung cấp phần mềm chất lượng cao, cung cấp giá trị thương mại thực sự, biết làm để làm việc mô hình Các mô hình cải tiến quy trình khung làm việc nhấn mạnh ký luật xử lý phù hợp Vài phương pháp phát triển phần mềm yêu cầu kỷ luận phát triển Agile Các chuẩn đơn giản cho phép bạn đo lường tiến trình để hướng đến mục tiêu Điểm tập trung Agile làm công việc tốt cải tiến liên tục Phát triển Agile tương thích với việc đạt tiêu chuẩn mà bạn đặt cho hay vay mượn từ công cụ đo lường cải tiến quy trình Tách mục tiêu đo lường tiêu chuẩn bạn từ phương tiện để cải thiện thước đo Thiết lập mục tiêu, biết số liệu mà bạn cần đo thành công lĩnh vực cần cải tiến Cố gắng sử dụng thẻ công việc cho hoạt động cung cấp cải tiến theo thứ tự đảm bảo họ có tầm nhìn mà họ cần Làm việc với quy trình mô hình chất lượng có vấn đề văn hóa lớn mà bạn phải đối mặt chuyển sang phát triển Agile Toàn thay đổi khó, toàn nhóm tham gia vượt qua Summary Trong chương này, xem xét quy trình hướng chất lượng truyền thống làm để điều chỉnh chúng môi trường Agile • • • • • • • • Các số liệu xác giúp bạn đảm bảo nhóm bạn hướng để đạt mục tiêu cung cấp lợi nhuận tốt Số liệu thấy được, cung cấp mốc quan trọng đưa định Những lý để sử dụng hệ thống theo dõi lõi (defect tracking system - DTS) bao gồm thuận tiện, sử dụng sở tri thức truy xuất nguồn gốc Các DTS thường sử dụng công cụ giao tiếp, nhập theo dõi lỗi không cần thiết, coi lãng phí Toàn công cụ, bao gồm DTS, cần sử dụng toàn nhóm, nên xem xét tất quan điểm lựa chọn công cụ Một chiến lược kiểm thử phương pháp kiểm thử tổng thể lâu dài đưa vào tài liệu tĩnh; kế hoạch kiểm thử cho dự án Hãy suy nghĩ thay đổi trước nhắm mắt chấp nhận yêu cầu cho tài liệu cụ thể Ví dụ, phương pháp tiếp cận Agile để phát triển khối nhỏ gia tăng, làm việc chặt chẽ với nhau, loại bỏ yêu cầu tài liệu truy xuất nguồn gốc thống Liên kết hệ thống kiểm soát mã nguồn giải kiểm thử theo cách khác Các quy trình chất lượng truyền thống mô hình cải tiến quy trình, chẳng hạn kiểm toán SAS 70 chuẩn CMMI, tồn với phát triển kiểm thử Agile Các nhóm cần mở rộng suy nghĩ bên làm việc để giải vấn đề họ