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
Part I - Introduction Chapter - What is Agile Testing, Anyway? 1.1 Agile values Bàn giao phần nhỏ , có giá trị mặt business vòng đời phát triển ngắn Agile manifesto: - Cá nhân tương tác quan trọng quy trình công cụ - Phần mềm hoạt động quan trọng tài liệu sản phẩm - Cộng tác với khách hàng quan trọng đàm phán hợp đồng - Đáp ứng với thay đổi quan trọng bám theo kế hoạch có sẵn 1.2 What Do We Mean by “Agile Testing”? Tester team Agile phải làm nhiều tasks tester thông thường (Tham từ đầu, liên hệ với KH, gợi ý cho KH, PO để giúp họ đưa tính rõ ràng hơn, guide đội phát triển cách test ) Test theo hướng business-facing customer-facing Test nhằm đảm bảo team bàn giao cho khách hàng sản phẩm có chất lượng Vẫn bao gồm kiểu truyền thống thêm phần kiểm thử thăm dò (1 khái niệm thừa kế từ Agile) Không mang ý nghĩa test Agile Projects Agile Testing Lập kế hoạch để vừa test vừa học sản phẩm >> guide để test phần 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 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âu hỏi, đưa ví dụ, review kết thúc story Tester thành viên thiếu team 1.3.2 Developer Team Bao gồm toàn thành phần liên quan đến việc coding(programmers, security specialists, system administrator,DB administrators, architects ) Tester thành phần đội phát triển Tester hỗ trợ team để deliver sản phẩm với giá trị lớn đảm bảo chất lượng dựa yêu cầu khách hàng 1.3.3 Interaction between Customer and Developer Teams Làm việc gần với toàn thời gian Customer đưa mức độ ưu tiên dựa vào ý kiến developer Đội developer định take công việc Tester team có vai trò riêng biệt: hiểu viewpoint khách hàng hiểu phức tạp 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 việc đảm bảo quality dự án Việc testing thường xảy vào giai đoạn cuối, trước delivery Thời gian coding testing tương đương nhau, thực tế thời gian test thường coding chậm thời gian so với dự định Xảy vòng lặp code-fix vào cuối dự án 1.4.2 Working on Agile Teams Tester thường test sau coding cycle ngắm lần lặp Trong mô hình Agile, thường áp dụng TDD (DEV viết unit test cho chức sau sửa code chạy đúng) Sản phẩm bàn giao kết hợp both customer developer team Tester thực kiểm thử thăm dò thủ công Tester pair với developer để thực automation testing story 1.5 Whole-Team Approach Là khác biệt lớn Agile với mô hình khác Khi tham gia Agile không nghĩ phòng ban, nghĩ skills resources cần thiết để bàn giao sản phẩm tốt Mọi người có trách nhiệm cho testing tasks Trong Agile team, người hỏi nhận giúp đỡ người khác (mọi người bình đẳng) Summary Hiểu hoạt động mà tester cần thực nhóm Agile, giúp bạn thể cho nhóm bạn giá trị mà tester thêm vào Học thực hành cốt lõi 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 bạn Trong chương này, giải thích muốn nói sử dụng từ “Agile testing” - Chúng trình bày Agile Manifesto liên quan đến kiểm 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 khách hàng đáp ứng với thay đổi - Chúng cung cấp số ngữ cảnh sách này, bao gồm số mục mà sử dụng “Tester”, “Programmer”, “Customer”, mục liên quan Do nói với ngôn ngữ chung - Chúng giải thích Agile Testing nào, với việc tập trung vào giá trị nghiệp vụ phân phối chất lượng theo yêu cầu khách hàng, khác với kiểm thử truyền thống, mà nhấn mạnh vào phù hợp yêu cầu khách hàng - Chúng giới thiệu phương pháp tiếp cận “Whole team” đến Agile testing, có nghĩa người tham gia vào việc phân phát phần mềm có trách nhiệm phân phát phần mềm chất lượng cao - Chúng khuyên bạn nên tiếp cận việc thực hành cách áp dụng giá trị nguyên tắc Agile để vượt qua trở ngại Agile testing xuất chỗ làm bạn Chapter - Ten principles for Agile Testers 2.1 What Is Agile Testing, Anyway? Agile tester người : - Có thể bao quát thay đổi - Hợp tác tốt với developer business team - Hiểu khái niệm test, để document lại requirements định hướng phát triển - Agile testers phải có kỹ kỹ thuật tốt - Biết hợp tác với người khác để tự động kiểm thử - Có kinh nghiệm 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 khách hàng Ai đảm nhận vai trò Agile tester? - Là member team mà định hướng Agile Testing - Có nhiều Agile tester bắt nguồn từ lĩnh vực khác - Kỹ quan trọng thái độ quan trọng - Tester có xu hướng nhìn thấy tranh toàn cảnh - Tester đứng quan điểm khách hàng, hướng tới khách hàng 2.2 The Agile Testing Mind-Set Agile team làm việc tốt deliver sản phẩm tốt Một dự án thành công kết người tốt làm tốt công việc Agile tester không coi cảnh sát chất lượng, bảo vệ khách hàng khỏi mã nguồn không đầy đủ Luôn sẵn sàng thu thập chia sẻ thông tin, làm việc với customer PO để giúp họ mô tả yêu cầu cách đầy đủ Agile tester phải có kỹ mind-set cần thiết, tìm kiếm cách thức để team cung cấp sản phẩm tốt Đối với Agile tester, thích học hỏi kỹ mới, đảm nhiệm thách thức mới, không bị giới hạn thân việc giải vấn đề kiểm thử Có thể cung cấp thông tin giúp team nhìn lại làm chưa làm Luôn sáng tạo, đưa ý tưởng sẵn sàng đảm nhận vai trò công việc nào, focused vào khách hàng, có nhìn tranh tổng thể Một tester tốt có hiểu phần mềm lỗi đâu nào, làm để theo dõi failures Mindset Agile testing kết theo định hướng, giống nghệ nhân, hợp tác, mong muốn tìm hiểu, đam mê để mang lại giá trị nghiệp vụ cách kịp thời 2.3 Applying Agile Principles and Values Những nguyên tắc giá trị team hướng dẫn bạn cách chọn lựa định bạn muốn làm việc 2.3.1 Provide Continuous Feedback Feedback đóng vai trò lớn Agile team Một đóng góp Agile tester giúp PO customer làm rõ requirements cách thực test đưa ví dụ Tester members khác phải kiểm thử sớm để đưa feedback có ý nghĩa Khi team gặp trở ngại, FB giúp team loại bỏ trở ngại 2.3.2 Deliver Value to the Customer Phát triển Agile đem lại giá trị cho khách hàng việc release nhỏ, cung cấp xác chức mà khách hàng ưu tiên gần Để đảm bảo mang lại giá trị cho interation, team cần xem lại story để xác định “critical path” or “thin slice” cho chức cần thiết Chúng ta cần bắt đầu việc đảm bảo chức hoạt đông Việc test tự động, case fail thêm vào sau 2.3.3 Enable Face-to-Face Communication Agile tester tìm cách giao tiếp tốt để giúp công việc tốt Trong buổi discuss, phải có đầy đủ tester, programmer, PO Agile tester cần giúp cho khách hàng developer có ngôn ngữ chung Có thể thảo luận whileboard Tester liên tục cộng tác thảo luận với nhóm khác hàng nhóm kỹ thuật 2.3.4 Have Courage Chúng ta phải có cam đảm để trả lời vấn đề: - Chúng ta hoàn thành việc test cho story khoảng thời gian ngắn không? - Thực test với việc phát triển nào? - Test đủ? Cần cam đảm để chấp nhận thất bại mình, học hỏi từ thất bại tìm cách để đảm bảo không xảy Cần cam đảm để chấp nhận lỗi người khác, cách để học hỏi Cần cam đảm để không ngại hỏi yêu cầu giúp đỡ từ người khác Agile team open chấp nhận ý tưởng 2.3.5 Keep It Simple Làm việc đơn giản mà làm Cần có cách tiếp cận đơn giản để đảm bảo phần mềm đáp ứng yêu cầu khách hàng Agile testing thực test cách đơn giản với tool, kỹ thuật đơn giản bảng tính danh sách kiểm tra để xác nhận chức có tiêu chuẩn chất lượng khách hàng đáp ứng.Thự test tự động mức thấp Thậm chí case test smoke đơn giản đủ Việc đơn giản hóa giúp tập trung vào rủi ro, ROI, giảm thiểu khó khăn gặp phải 2.3.6 Practice Continuous Improvement Mindset tester tìm kiếm cách làm cho công việc tốt nhóm phải nghĩ điều Việc sử dụng cải tiến quy trình, buổi retrospective backlogs chứa chở ngại ,nhóm đạt cải tiến định lĩnh vực test lĩnh vực khác Nếu không giải được, bỏ qua tiếp tục Agile team tìm kiếm công cụ, kỹ thực hành giúp họ có thêm nhiều values Các iteraction ngắn dễ dàng cho việc thử vài mới, đánh giá hiệu sử dụng lâu dài Retrospectives cách thực hành Agile, giúp cho team sử dụng kinh nghiệm có để làm công việc tới tốt hơn.Agile tester nhân hội đưa vấn đề liên quan đến testing, yêu cầu team đưa cách giải chúng 2.3.7 Respond to Change So sánh waterfall & agile iteration: - Waterfall: Khi có thay đổi requirement, từ chối thay đổi thực lần sau Như khiến khách hàng không hài lòng - Agile iteration: Khi có thay đổi requirement, tiếp nhận làm iteration release Phản ứng trước thay đổi giá trị cốt lõi Agile, điều khó khăn cho tester Tester mong ổn định Việc thay đổi requirement thường xuyên ác mộng với tester Tuy nhiên Agile tester phải welcome thay đổi Agile tester phải team thích nghi với thay đổi Test tự động giải pháp cho thay đổi 2.3.8 Self-Organize Agile tester phần Agile team tự quản Programmers, system administrators, analysts, database experts customer team suy nghĩ testing, test tự động Test tự động vấn đề khó, dễ dàng nhiều team làm việc Bất kỳ vấn đề testing dễ giải người có nhiều kỹ giải Khi Agile team đối mặt với vấn đề lớn, không vần đề riêng Tất team thảo luận để đưa cách giải , định làm nào, fix 2.3.9 Focus on People Các giá trị nguyên tắc Agile tạo với mục tiêu cá nhân toàn đội đạt thành công Thành viên nhóm Agile tôn trọng công nhận thành tích cá nhân Mỗi người có hội trưởng thành phát triển kỹ họ Agile tester biết giá trị định họ đem lại cho nhóm Đội phát triển nhận thấy họ thành công team có người có kỹ test 2.3.10 Enjoy Làm việc nhóm mà người cộng tác, nơi bạn tham gia vào dự án từ đầu đến cuối, nơi mà đội nghiệp vụ làm việc 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 người nên tìm thấy niềm vui công việc họ Sự đam mê công việc Agile tester phần thưởng xứng đáng 2.4 Adding Value Các nguyên tắc mang lại giá trị nghiệp vụ người đảm nhận nhiều vai trò dự án Trong Agile team, toàn team có trách nhiệm cung cấp phần mềm có chất lượng cao nhất, không đáp ứng khách hàng mà khiến cho công việc có nhiều lợi nhuận.Và mang lại lợi cho doanh nghiệp Thực test định hướng lập trinh, giúp ngăn chặn việc tạo khác biệt khách hàng mong đợi nhóm cung cấp Agile tester thường đặt câu hỏi cho nhóm khách hàng nhóm phát triển cách thường xuyên, giúp họ hình thành câu trả lời theo cách test Agile tester áp dụng kỹ kinh nghiệm cho dự án, đảm bảo khách hàng cung cấp requirement cách rõ ràng Họ đưa issue, đề cập tới vần đề liên quan đến bảo mật, hiệu suất độ tn cậy với khách hàng Không có phân biệt vai trò Agile team, nhiên nhóm hưởng lợi nhiều từ kỹ kiểm thử Agile tester mang lại giá trị cho nhóm tổ chức quan điểm độc đáo , cách tiếp cận hướng đồng đội Summary Trong chương này, đưa toàn nguyên tắc cho Agile tester giá trị mà nghĩ Agile tester cần để làm việc hiệu nhóm Agile - Mind set Agile testing focused vào khách hàng, kết theo định hướng, giống nghệ nhân, hợp tác, sáng tạo , ham học hỏi đam mê để mang lại giá trị nghiệp vụ thời điểm - Thái độ quan trọng, phân biệt vai trò Agile team - Agile tester áp dụng giá trị nguyên tắc Agile : feedback, giao tiếp, can đảm, đơn giản hóa, yêu thích mang lại giá trị giúp nhóm xác định yêu cầu khách hàng story - Agile tester mang lại giá trị cho team tổ chức với quan điểm cách tiếp cận hướng team 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ọ 10 Hãy sáng tạo việc đối phó với tình xảy với nhóm bạn thực tế dự án Trong lên kế hoạch, công việc mong đợi, kế hoạch trowcs giúp bạn đảm bảo người đưa phù hợp để cung cấp sản phẩm kịp thời 20.6 Deliverables Trong phần đầu chương, nói điều tạo sản phẩm Câu trả lời phụ thuộc vào khán giả (audience): người chấp nhận sản phẩm, mong muốn họ gì? Nếu khách hàng bạn cần đáp ứng yêu cầu tuân thủ SOX (Sarbanes-Oxley), có phân phối yêu cầu Ví dụ, khách hàng mà Janet làm việc, cảm thấy kết kiểm thử nên ghi chép kỹ lưỡng, tạo kết kiểm thử cho điểm đo lường việc tuân thủ SOX họ, khách hàng khác không đo kết kiểm thử Làm việc với việc tuân thủ nhân viên kiểm toán để xác định báo cáo yêu cầu bạn bắt đầu dự án Làm bao nhiều tài liệu đủ? Janet hỏi hai câu hỏi trước trả lời “Nó dành cho ai?” “Họ sử dụng cho gì?” Nếu câu trả lời thỏa đáng cho câu hỏi, xem xét xem liệu tài liệu có thực cần thiết Các phân phối không dành cho khách hàng đầu cuối, chúng không hình thức phần mềm Có nhiều khách hàng nội bộ, chẳng hạn thành viên nhóm hỗ trợ 234 production Họ cần thực đề công việc họ dễ dàng hơn? Workflow diagrams giúp họ hiểu tính Họ muốn biết công việc chỗ họ giúp khách hàng vượt qua vấn đề Janet thường hỏi độ bao phủ kiểm thử mã nguồn, thường cách quản lý Bao nhiêu ứng dụng kiểm thử unit tests hay regression tests? Vấn đề số lượng số, có nhiều lý cao hay thấp Ngoài ra, độ bao phủ mã nguồn không nói cho bạn tính bị bỏ qua, mà chưa có có mã nguồn tồn Dự thích cho phân phối độ bao phủ mã nguồn không cần quản lý, tự nhóm làm điều Nó sử dụng để xem vùng mã nguồn không kiểm thử Đào tạo coi chuyển giao tốt Nhiều ứng dụng yêu cầu phiên đào tạo tùy chỉnh cho khách hàng Những khác cần giúp đỡ trực tuyến hướng dẫn sử dụng Đào tạo xác định thành công sản phẩm, quan trọng để xem xét Nhóm Lisa thường viết task cards cho tester hay PO để đảm bảo tài liệu phiên đào tạo xếp Một số người cảm thấy đào tạo công việc tester hay khác nhóm phát triển Tuy nhiên, nhóm Agile nhằm mục tiêu làm việc gần với nghiệp vụ tốt Tester thường có kinh nghiệm chuyên môn để xác định đào tạo cần thiết cho tính hay cập nhật Thậm chí đào tạo trách nhiệm tester, cô nêu vấn đề doanh nghiệp kế hoạch đào tạo Nhiều nhóm Agile có người viết kỹ thuật phần nhóm, họ viết giúp đỡ trực tuyến hay tài liệu điện tử Thậm ứng dụng có tài liệu đào tạo video để giúp bạn bắt đầu thành viên khác nhóm nhà đào tạo Nó trách nhiệm nhóm để tạo sản phẩm thành công 20.7 Releasing the Product Khi nói việc phát hành sản phẩm, có nghĩa làm cho sẵn sàng để khách hàng nắm bắt Tổ chức bạn có website để đưa ứng dụng tùy chỉnh cập nhật phân phối đến vài khách hàng lớn Có thể sản phẩm thu nhỏ gửi tới hàng triệu máy tính giới, tải từ internet 20.7.1 Release Acceptance Criteria Làm để bạn biết bạn hoàn thành? Các tiêu chí chấp nhận cách truyền thống để chấp nhận sản phẩm Tiêu chí hiệu nâng đáp ứng Chúng nắm bắt story bắt đầu vòng lặp, xác định chúng cho tập tính lớn bắt đầu theme hay epic Khách hàng thiết lập tiêu chí chất lượng phần trăm chắn độ bao phủ mã nguồn kiểm thử tự động, hay kiểm thử phải pass Các mục có lỗi nguy hiểm (zero critical bugs), không lỗi (zero bugs) ảnh hưởng nghiêm trọng đến hệ thống, thường phần tiêu chí phát hành Khách hàng cần định làm để họ biết đủ giá trị sản phẩm Các tester giúp họ xác định tiêu chí phát hành phù hợp với mục tiêu họ 235 Các nhóm Agile làm việc để đạt mục tiêu chất lượng Họ không hạ mức nghiêm trọng lỗi đến trung bình để họ đạt tiêu chí không lỗi nghiêm trọng cao (no high-severity bugs) Thay vào đó, họ thường tìm xu hướng lỗi nghĩ cách để đảm bảo lỗi nghiêm trọng không xảy production Mức chất lượng bạn nên đàm phán với khách hàng trước đó, để bất ngờ khó chịu với họ Các kiểm thử chấp nhận mà nhóm khách hàng định nghĩa, sử dụng examples thực tế, phục vụ mốc tiến độ hướng tới phát hành Nếu khách hàng có khả chịu đựng lỗi thấp, 100% kiểm thử chấp nhận phải pass, tốc độ vòng lặp bạn nên xem xét điều Nếu tính quan trọng việc sửa lỗi, bạn di chuyển với lỗi Mỗi dự án, nhóm, nghiệp vụ Các nhóm Agile làm việc với chuyên gia nghiệp vụ để định xem họ sẵn sàng để đưa phần mềm lên production Nếu thời hạn phát hành (release deadline) đặt cố định, doanh nghiệp phải thay đổi phạm vi Nếu đủ mềm dẻo để phát hành phần mềm đủ giá trị, nhóm định tiêu chí chất lượng đáp ứng phần mềm đưa lên production Phát triển phần mềm truyền thống làm việc theo khung thời gian dài, với thời hạn đưa từ lâu trở ngại cần loại bỏ từ giai đoạn Phát triển Agile cho phép phát triển phần mềm chất lượng tăng trưởng phát hành nhỏ cần thiết Các nhóm phát triển khách hàng làm việc gần để định nghĩa định phát hành phát hành Các tester đảm nhiệm vai trò quy trình thiết lập mục tiêu 20.7.2 Release Management Nhiều tổ chức có nhóm quản lý phát hành, bạn không có, làm việc Nhiều lần tổ chức nhỏ, QA manager đảm nhiệm vai trò Người quản lý việc phát hành tổ chức họp để chuẩn bị phát hành với bên liên quan để đánh giá sẵn sàng A release readiness checklist is a great tool to use to walk through what is important to your team The intention of this checklist is to help the team objectively determine what was completed and identify the risks associated with not completing a task Một danh sách kiểm tra sẵn sàng phát hành công cụ tuyệt vời để sử dụng để qua quan trọng đội bóng bạn Mục đích danh sách kiểm tra để giúp đội khách quan xác định hoàn thành xác định rủi ro liên quan không hoàn thành nhiệm vụ Ví dụ, đào tạo không cần thiết thay đổi với sản phẩm minh bạch với người dùng cuối (end user), rủi ro thấp Tuy nhiên, có thay đổi quan trọng đến quy trình làm để user tạo hệ thống, rủi ro cao production hỗ trợ hay giúp đỡ nhóm gây trễ Các yêu cầu bên liên quan nên xem xét 236 Các ghi phát hành quan trọng phát hành sản phẩm Các hình thức phụ thuộc vào khán giả (audience) Nếu sản phẩm bạn nhằm mục đích dành cho người phát triển, văn “read me” có lẽ tốt Trong trường hợp khác, bạn muốn làm cho chúng thức Dù phương tiện truyền thông nào, chúng cần phải giải yêu cầu khán giả (audience) Không cung cấp nhiều thông tin không cần thiết Khi Janet có phát hành mới, thứ cô làm kiểm tra phiên (version) toàn thành phần “Tôi có nhận mà họ đưa cho không? Có hướng dẫn đặc biệt mà cần xem trước cài đặt, phụ thuộc hay kịch nâng cấp?” Đó câu hỏi đơn giản để trả lời cho ghi phát hành Những thứ khác bao gồm chức khách hàng tìm kiếm Các ghi phát hành nên đặc biệt xem xét đến thành phần phần nhóm phát triển bạn phân phối, tập tin trợ giúp (help file) hay hướng dẫn sử dụng chuẩn bị nhóm khác Đôi ghi phát hành cũ tồn phương tiện truyền thông phát hành, không hữu ích với người dùng cuối (end user) Hãy xem xét phù hợp với nhóm bạn ứng dụng bạn 20.7.3 Packaging Chúng nói tích họp liên tục Chúng ta có xu hướng đưa cho cấp quên quản lý cấu hình tốt có nghĩa “Xây dựng lần, triển khai nhiều lần (build once, deploy multiple times)” phần tạo nên niềm tin phát hành Chúng ta biết build kiểm thử staging build mà khách hàng kiểm thử UAT build dùng để release lên production Điều quan cho release thành công Nếu sản phẩm dành cho khách hàng bên ngoài, cài đặt trở nên dễ dàng, việc cài đặt nhìn sản phẩm mà khách hàng có Biết đối tượng (audience) bạn mức độ cho phép (tolerance) lỗi Sản phẩm bàn giao nào? Ví dụ, tải từ internet, sau đơn giản tải cài đặt (download and install) Nếu hệ thống doanh nghiệp lớn (a huge enterprise system), sau tổ chức bạn cần gửi người hỗ trợ để giúp họ cài đặt 20.8 Customer Expectations Trước mang phần mềm cho khách hàng, tốt nên chắn sẵn sàng Chúng ta phải chắn họ biết chức mong đợi họ có số phương tiện để đối phó với vấn đề phát sinh 20.8.1 Production Support Nhiều tổ chức có nhóm hỗ trợ production operation để trì mã nguồn hỗ trợ khách hàng sau đưa phần mềm lên production Nếu công ty bạn có nhóm hỗ trợ production, nhóm khách hàng bạn Làm thật tốt cho đối tác bạn Các nhóm hỗ 237 trợ production nhận báo cáo defect yêu cầu nâng cấp từ khách hàng, họ làm việc với nhóm bạn để xác định vùng có nguy cao Thường nhóm hỗ trợ production nhóm chấp nhận việc phát hành từ nhóm phát triển Nếu tổ chức bạn có kiểu tay này, quan để nhóm phát triển làm việc gần với nhóm hỗ trợ production để làm cho việc chuyển đổi suôn sẻ Hãy nhóm hỗ trợ production hiểu làm để sử dụng tài liệu log hệ thống hệ thống thông báo giám sát hoạt động xác định vấn đề nhanh chóng 20.8.2 Understand Impact to Business Mỗi lần triển khai lên production yêu cầu ngưng trệ, sản phẩm không khả dụng cho khách hàng bạn Nếu sản phẩm website, ảnh hưởng lớn Nếu sản phẩm bạn sản phẩm độc lập tải PC, ảnh hưởng thấp Các nhóm Agile phát hành liên tục đến giá trị tối đa thương mại, phát hành nhỏ có rủi ro thấp ảnh hưởng tiêu cực lớn Đó lẽ thường để làm việc với doanh nghiệp phát hành xa sưa giai đoạn trước để giảm thiểu gián đoạn Quy trình triển khai tự động tinh giản nhiều tốt để giữ thời gian chết nhỏ lại Quy trình triển khai nhanh hữu dụng trình phát triển vòng lặp nhỏ mà triển khai hàng chục lần ngày Các phát hành minh bạch cho khách hàng Một vài phát hành khẩn cấp vá lỗi cần thiết sau phát hành, nhiều niềm tin từ khách hàng có với hai nhóm sản phẩm phát triển Tìm hiểu từ phát hành có hành động để thực trôi chảy Nhận toàn vai trò Quản trị sở liệu hệ thống, người tham gia vào việc lập kế hoạch Đánh giá phát hành nghĩ cách cải tiến Summary Chương trình bày điểm sau: - Phân phối thành công môt sản phẩm gồm nhiều ứng dụng mà bạn xây dựng Lên kế hoạch cho phân phối khác tài liệu, thông báo hợp pháp đào tạo - End game hội để đưa vào spit (nhổ) polish (đánh bóng), liên quan đến kết thúc cuối (final finishing touches) sản phẩm bạn - Các nhóm khác phải chịu trách nhiệm môi trường, công cụ thành phần khác end game release Hợp tác với họ trước thời hạn - Hãy chắn kiểm thử kịch cập nhật liệu, chuyển đổi liệu phần khác cài đặt - UAT hội cho khách hàng để kiểm thử lại liệu họ xây dựng niềm tin họ sản phẩm - Ngân sách thời gian (budget time) cho chu kỳ thêm vào cần thiết, chu kỳ sau phát triển (post-development cycles) để phối hợp kiểm thử với đối tác bên 238 - Xây dựng tiêu chí chấp nhận phát hành buổi lên kế hoạch phát hành để bạn biết bạn thực sẵn sàng để phát hành Các tester thường liên quan đến quản lý phát hành kiểm tra bao bì Khi phát hành sản phẩm, xem xét gói phần nềm - khách hàng yêu cầu mong muốn Tìm hiểu từ lần phát hành, thích nghi để cải tiến quy trình bạn Part VI - Summary Chapter 21 - Key Success Factors Sau qua vòng lặp, Agile tester tham gia vào nhiều hoạt động khác nhau, chọn số nhân tố chủ chốt để giúp tester thành công nhóm Agile giúp nhóm Agile cung cấp thành công sản phẩm chất lượng cao Chúng ta nghĩ Agile tester có đặc biệt để cung cấp Các “Agile-infected” tester nghiên cứu cách áp dụng thực hành nguyên tắc Agile để giúp nhóm hoàn thành sản phẩm tốt Các lập trình viên “Test-infected” nhóm Agile nghiên cứu cách sử dụng kiểm thử để sản phẩm làm việc tốt Ranh giới vai trò bị mờ nhạt, tốt Mọi người tập trung vào chất lượng Chúng có số hướng dẫn kiểm thử quan trọng cho nhóm Agile tester từ việc dùng thử lỗi trình làm việc với Những hướng dẫn xây dựng ma trận kiểm thử Agile, kinh nghiệm việc nghiên cứu để vượt qua rào cản văn hóa tổ chức, phiêu lưu việc thực vai trò tester nhóm Agile, kinh nghiệm để tìm cách tốt để sử dụng tự động hóa kiểm thử Chúng thích số may mắn, chương trình bày yếu tố quan trọng để giúp Agile tester thành công 239 Chúng hỏi nhóm nhỏ, xem xét số chương để đưa số thứ tự để trình bày yếu tố Kết khác nhau, nhiều (không phải toàn bộ) đồng ý hai đầu Chọn yếu tố thành công cung cấp cho bạn đầu tư tốt nhất, bắt đầu làm việc từ ngày hôm 21.1 Success Factor 1: Use the Whole-Team Approach Khi toàn nhóm phát triển có trách nhiệm kiểm thử chất lượng, bạn có lượng lớn tập hợp kỹ mức độ kinh nghiệm tham gia vào vấn đề kiểm thử Kiểm thử tự động vấn đề lớn nhóm có kỹ lập trình Khi kiểm thử ưu tiên nhóm, nhận testing tasks, nhóm thiết kế mã nguồn kiểm thử Đưa tester phần thực nhóm phát triển, có nghĩa đưa cho họ hỗ trợ, đào tạo mà họ cần để thích nghi cách nhanh chóng với phát triển Agile Họ có thời gian để có kỹ để cộng tác chặt chẽ với thành viên hai nhóm phát triển khách hàng Nếu bạn quản lý nhóm Agile, sử dụng Part II, “Organizational Challenges”, để giúp nhóm bạn thông qua phương pháp toàn nhóm (Whole team approach) Hãy nhớ chất lượng, tốc độ, mà mục tiêu phát triển agile Nhóm bạn cần tester để giúp khách hàng làm rõ yêu cầu, biến chúng trở thành kiểm thử để điều hướng phát triển, cung cấp quan điểm để thúc đẩy cung cấp sản phẩm tốt Hãy tester chuyển giao kỹ chuyên môn họ cho phần lại nhóm Hãy họ không đóng khung vai trò thực kiểm thử thủ công Hãy họ có nhu cầu cần giúp đỡ (đòi hỏi cam đảm đáng kể từ họ), thành viên nhóm sẵn sàng giúp họ Điều ngược lại đúng; tester bước lên lúc có cần giúp đõ mà họ cung cấp Nếu bạn tester nhóm Agile, có họp lên kế hoạch (planning meeting) thảo luận thiết kế (design discussion) xảy mà bạn, người dùng nghiệp vụ gặp khó khăn định nghĩa stories yêu cầu mình, thời gian để đưa nói với toàn nhóm Ngồi với lập trình viên, mời thân bạn vào họp đề nghị “Power of Three” với tham gia tester, lập trình viên chuyên gia nghiệp vụ Hãy trở nên có ích, đưa phản hồi giúp khách hàng đưa examples Làm cho vấn đề bạn vấn đề nhóm, làm vấn đề họ vấn đề bạn Hỏi đồng nghiệp để định Whole-team Approach 21.2 Success Factor 2: Adopt an Agile Testing Mind-Set Trong chương 2, “Ten Principles for Agile Testers”, cảnh báo Agile tester tư “Quality Police” Bạn nhóm Agile, lập trình viên kiểm thử đâu tester làm điều mà họ nghĩ giúp nhóm cung cấp sản phẩm tốt Như nhấn mạnh chương 2, thái độ kiểm thử Agile chủ động, 240 sáng tạo, cởi mở với ý tưởng mới, sẵn sàng chấp nhận công việc Các Agile tester mài dũa nghề nghiệp cô ấy, sẵn sàng hợp tác, tin tưởng vào khả thân, đam mê với việc giúp nhóm doanh nghiệp thành công Chúng nghĩa bạn nên đặt mục tiêu vào Super Tester bảo vệ giới khỏi bugs Không có chỗ cho lớn với nhóm Agile Chia sẻ niềm đam mê bạn chất lượng với người nhóm Tập trung vào mục tiêu nhóm thực mà bạn giúp người để họ làm việc tốt Sử dụng nguyên tắc giá trị Agile để dẫn đường cho bạn Luôn cố gắng thực tiếp cận đơn giản để đáp ứng nhu cầu kiểm thử Hãy cam đảm việc tìm kiếm giúp đỡ thử nghiệm với ý tưởng Tập trung vào việc cung cấp giá trị Giao tiếp trực tiếp thường xuyên tốt Hãy mềm dẻo việc đáp ứng thay đổi Hãy nhớ với phát triển Agile người làm trung tâm, tất nên tận hưởng công việc Khi gặp khó khăn, xem lại giá trị nguyên tắc để định nên làm Một thành phần quan trọng tư kiểm thử agile điều hướng liên tục tìm kiếm cách để làm việc tốt Một Agile tester thành công liên tục nâng cao kỹ thuật Đọc sách, blogs, báo tốt để tiếp thu ý tưởng kỹ Tham dự họp nhóm với người dùng nội Tham gia vào thảo luận qua mail list để lấy phản hồi vấn đề hay ý tưởng Nếu công ty bạn không trả cho bạn để tham dự hội nghị tốt, đưa mà bạn học vào báo cáo để trao đổi hội thảo tổ chức miễn phí Đưa đến cộng đồng kiểm thử phát triển agile bạn, giúp bạn phát triển thân Thử nghiệm với thực hành, công cụ, kỹ thuật Khuyến khích nhóm bạn cố gắng thực phương pháp tiếp cận Các vòng lặp ngắn lý tưởng để thực thử nghiệm Bạn thất bại, nhanh thôi, bạn cố gắng lại khác lần Nếu bạn quản lý Agile tester nhóm Agile, đưa cho họ thời gian để nghiên cứu đưa hỗ trợ đào tạo mà họ cần Loại bỏ trở ngại để giúp họ làm việc tốt Khi bạn đối mặt với vấn đề mà ảnh hưởng đến kiểm thử, mang vấn đề với nhóm Hỏi nhóm để suy nghĩ cách vượt qua trở ngại ngày Retrospectives nơi để nói vấn đề làm để giải chúng Giữ impediment backlog (danh sách trở ngại) giải hai vòng lặp Sử dụng biểu đồ lớn, biểu đồ điện tử tương đương, để đảm bảo người nhận thức vấn đề phát sinh người theo dõi tiến độ viết mã kiểm thử 21.3 Success Factor 3: Automate Regression Testing Một nhóm Agile thành công không kiểm thử tự động? Có thể, nhóm thành công mà biết dựa vào kiểm thử hồi quy tự động Như thường nói sách này, bạn sử dụng toàn thời gian bạn vào kiểm thử hồi 241 quy thủ công, bạn thời gian để kiểm thử thăm dò quan trọng mà đưa hành vi nguy hiểm tiềm ẩn mã nguồn Phát triển Agile sử dụng kiểm thử để điều hướng phát triển Để viết mã làm cho kiểm thử pass, bạn cần cách nhanh chóng dễ dàng để chạy kiểm thử Nếu chu kỳ phản hồi ngắn mạng lưới an toàn mà hồi quy mang lại, nhóm bạn sớm trở nên ngập ngụa nợ kỹ thuật, với hàng dài defect tốc độ ngày chậm Các kiểm thử hồi quy tự động khả nhóm Toàn nhóm nên chọn công cụ thích hợp cho loại kiểm thử Nghĩ kiểm thử trước cho phép lập trình viên thiết kế mã dễ dàng cho kiểm thử tự động Sử dụng Agile testing quadrants test automation pyramid để giúp bạn tự động kiểu kiểm thử khác cho hiệu Hãy nhớ đơn giản Bạn ngạc hiên giá trị mà kiểm thử smoke tự động hay kiểm thử đơn vị tự động mang lại Tự động kiểm thử lực Nó khó, lần Thường có “hump of pain” lớn cần vượt qua Nếu bạn quản lý nhóm phát triển hay nhóm kiểm thử, bạn cung cấp đủ hỗ trợ mặt thời gian, đào tạo động lực Nếu bạn tester nhóm tự động hóa lập trình viên điên cuồng để cố gắng viết mã nguồn production phải dừng lại nghĩ kiểm thử, bạn có thách thức lớn phải đối mặt Thử nghiệm cách khác để nhận hỗ trợ từ quản lý từ thành viên nhóm để bắt đầu với chút cố gắng tự động hóa 21.4 Success Factor 4: Provide and Obtain Feedback Phản hồi giá trị cốt lõi Agile Các vòng lặp ngắn Agile thiết kế để cung cấp phản hồi liên tục để giữ nhóm đường đua Các tester vị trí cung cấp phản hồi hình thức kết kiểm thử tự động, khám phá kiểm thử thăm dò quan sát người dùng thực hệ thống Agile Is All about Feedback Bret Pettichord, CTO of WatirCraft and co-author of Lessons Learned in Software Testing, shared these thoughts on the importance of feedback to agile development Agile methods allow your team to get feedback regarding the software you are building That’s the point The feedback works on several levels Pair programming gives developers instant feedback on their code Stories represent units of work where testers and analysts can give feedback to developers Iteration releases facilitate feedback from outside the team Most agile practices are valuable because they create feedback loops that allow teams to adapt A lot of teams adopt Agile with a grab-bag approach without quite realizing the point of the practices They pair-program without discussion or changing drivers They send code to QA that the testers can’t test because the story boundaries are arbitrary; they can’t tell whether they found a bug or just the end of the story Iterations become schedule milestones rather than real opportunities to improve alignment and adjust 242 objectives The reason Agile teams can with less planning is because feedback allows you to make sure that you are on course If you don’t have meaningful feedback, then you’re not agile You’re just in a new form of chaos On my last project, we defined our stories so that they made sense to everyone on the team Our analysts, testers, and developers could all understand and review individual stories But we found that we had to create a larger grouping, which we called features, to facilitate meaningful review from outside our team We made sure all the stories in a feature were complete before soliciting feedback from outside the team Being able to give and receive meaningful feedback is often a challenge for people Yet it is crucial to success with Agile Agile teams get into terrible binds when executives or clients hand them a list of requirements at the start, tell them to use Agile (because it’s faster), and then don’t want to participate in the feedback process Agile isn’t faster all by itself Agile is only a benefit in a world that acknowledges the value of adapting And that adaptability needs to go all the way to whoever is funding the project It is not enough for the team to be agile The sponsors need to be agile too Are all of the requirements really required? Do we know exactly what the software needs to look like from the start? Agile is faster because feedback allows you to find and focus on the most valuable features If you are certain you know what needs to be built, don’t use Agile If you don’t have time to gather and act on feedback from customers, then don’t use Agile If you are sure that everyone understands exactly what needs to be done from the start, then don’t use Agile Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down To us, the value of agile development isn’t that it’s faster but that it delivers enough value quickly enough to help the business grow and succeed Testers play a key role in providing the feedback that allows that to happen Các tester cần phản hồi Làm thê snafo để bạn biết bạn có examples với hành vi mong muốn khách hàng? Làm để bạn biết trường hợp kiểm thử bạn viết phản ánh xác examples? Các lập trình viên hiểu phải viết mã gì, cách nhìn vào examples bạn nắm bắt kiểm thử bạn tạo không? Một kỹ có giá trị mà bạn học hỏi làm để yêu cầu phản hồi công việc bạn Yêu cầu lập trình viên họ có đủ thông tin để hiểu yêu cầu thông tin có hướng dẫn việc viết mã họ không Hỏi khách hàng họ cảm thấy 243 tiêu chí chất lượng họ đáp ứng Dành thời gian với họp iteraction planning retrospectives để nói vấn đề đề nghị cách cải tiến 21.5 Success Factor 5: Build a Foundation of Core Practices Câu nói cũ nghiệp vụ kiểm thử “Bạn kiểm thử chất lượng sản phẩm” Tất nhiên, thật phát triển Agile Chúng cảm thấy bạn phân phối phần mềm chất lượng cao mà không tuân theo thực hành Trong nghĩ thực hành Agile, chúng tồn lâu mục “Phát triển Agile”, chúng thực hành cốt lõi phát triển phần mềm thành công 21.5.1 Continuous Integration Mỗi nhóm phát triển cần quản lý mã nguồn tích hợp liên tục để thành công Bạn kiểm thử hiệu bạn bạn kiểm thử gì, bạn kiểm thử toàn bạn mã nguồn triển khai Toàn thành viên nhóm kiểm tra công việc bạn lần môt ngày Mỗi tích hợp nên xác định build tự động mà bao hàm kiểm thử để cung cấp phản hồi nhanh tình trạng phần mềm Thực quy trình tích hợp liên tục ưu tiên hàng đầu nhóm phát triển phần mềm Nếu nhóm bạn verified build ngày, dừng bạn đnag làm bắt đầu với việc tạo Điều thực quan trọng Nó không cần hoàn hảo để bắt đầu Nếu bạn có hệ thống lớn để tích hợp, chắn khó khăn Tuy nhiên, nhìn chung không khó Có nhiều công cụ tốt, mã nguồn mở thương mại, có sẵn cho mục đích 21.5.2 Test Environments Cạn kiểm thử hiệu mà môi trường kiểm thử kiểm soát Bạn cần biết build triển khai, schema liệu sử dụng, cập nhật schema đó, tiến trình chạy máy Phần cứng tốn nhất, nhiều phần mềm mã nguồn mở có sẵn để sử dụng cho môi trường kiểm thử Nhóm bạn nên đầu tư để bạn tiến hành kiểm thử tự động thăm dò nhanh chóng hiệu Nếu có vấn đề với môi trường kiểm thử, lên tiếng để vấn đề nhóm để giải cách sáng tạo 21.5.3 Manage Technical Debt Ngay nhóm phát triển phần mềm tốt, cảm thấy áp lực thời gian, lãng tái cấu trúc (refactoring) hay dùng đến cách sửa chữa nhanh từ bỏ việc giải vấn đề nhanh chóng Khi mã nguồn trở nên khó hiểu khó trì, nhiều lỗi xảy ra, không nhiều thời gian trước tốc độ nhóm bị tiêu tan việc sửa lỗi cố gắng làm cho mã nguồn có nghĩa để thêm tính Nhóm bạn nên đánh giá liên tục khoản nợ kỹ thuật kéo xuống làm việc để giảm thiểu ngăn chặn 244 Người ta thường nói, “Quản lý không cung cấp cho thời gian để làm thứ xác, thời gian để cấu trúc lại (refactor), bị áp lực thời hạn (deadline) sít sao” Tuy nhiên, không khó để làm rõ ràng toán kinh doanh thấy làm tăng nợ kỹ thuật, mà chi phí công ty Có nhiều cách để đo mã nguồn tỷ lệ defects (nó chuyển nợ kỹ thuật thành ảnh hưởng cuối chu kỳ) Chỉ đến việc tốc độ giảm đủ Các doanh nghiệp cần nhóm phát triển phần mềm họ hiệu mong muốn Họ phải giảm phạm vi (scope) hay tính mong muốn để đủ thời gian cho việc thiết kế mã nguồn hướng kiểm thử tốt thực hành hiệu tái cấu trúc nhỏ liên tục Độ bao phủ tốt từ kiểm thử hồi quy tự động chìa khóa để giảm thiểu nợ kỹ thuật Nếu thiếu, thời gian ngân sách vòng lặp để xây dựng kiểm thử tự động, lên kế hoạch “vòng lặp tái cấu trúc (refactoring interation)” để ngân cấp thêm công cụ cần thiết, viết kiểm thử, thực khả tái cấu trúc Trong vòng lặp, dành thời gian để điều hướng mã nguồn với kiểm thử, tái cấu trúc mã nguồn mà bạn nắm bắt cần, thêm vào kiểm thử tự động nơi chúng bị thiếu Tăng ước tính bạn để tính toán cho công việc Về lâu dài, nhóm nhanh 21.5.4 Working Incrementally Một lý mà nhóm Agile tạo sản phẩm chất lượng họ làm việc với quy mô nhỏ Các stories đưa vài ngày làm việc, story chia thành vài lát mỏng sợi thép xây dựng bước Điều cho phép kiểm thử mảnh nhỏ sau kiểm thử tăng trưởng mảng đặt lại với Nếu thành viên nhóm bạn bị cán dỗ để đưa vào mảng lớn chức lúc, khuyến khích họ tìm kiếm phương pháp tiếp cận bước Đặt câu hỏi: “Giá trị thương mại tập trung vào với story này? Hướng thông qua mã nguồn gì? Điều xảy tiếp theo?” Đề nghị viết task card để viết mã kiểm thử phần nhỏ, có mô tả nội dung thiết kế bạn, xác nhận chiến lược kiểm thử tự động kiểm thử bạn 21.5.5 Coding and Testing Are Part of One Process Những người với Agile thường hỏi Agile tester “Bạn làm toàn stories hoàn thành bạn kiểm thử?” Các nhà thực hành Agile có kinh nghiệm nói “Testers nên tham gia vào toàn vòng lặp, toàn trình phát triển Nếu không không làm việc.” Các tester viết kiểm thử, dựa vào example cung cấp customer, để giúp programmers hiểu story bắt đầu Các kiểm thử examples cung cấp ngôn ngữ chung mà tất người tham gia vào sản phẩm phần mềm hiểu Tester programmer hợp tác chặt chẽ mã nguồn tiếp diễn, họ hợp tác chặt chẽ với customer Programmer cho tester thấy chức mà họ viết, tester cho programmer thấy hành vi không mong muốn mà họ tìm thấy Tester viết nhiều kiểm thử mã nguồn tiếp tiễn, programmer làm cho chúng pass, tester thực nhiều kiểm thử thăm dò (exploratory testing) để tìm xem giá trị 245 phân phối có không Mỗi vòng lặp Agile chứa hàng chục vòng lặp test-code-test-code-test liên tục, nhanh chóng tăng trưởng Khi chu kỳ hợp tác phản hồi bị phá vỡ, kiểm thử bị tách khỏi phát triển, điều xấu xảy Nếu story kiểm thử vòng lặp sau viết mã lỗi tìm thấy, programmer phải dừng công việc story mới, phải nhớ lại mã nguồn làm việc với story vòng lặp cũ, sửa đợi kiểm thử việc sửa chữa Một vài ảnh hưởng phát triển phần mềm, biết lỗi rẻ chúng sửa chúng tìm thấy Khi viết mã liên tục điều hướng kiểm thử, kiểm thử với việc viết mã, có khả đạt hành vi mong muốn cung cấp giá trị thích hợp Kiểm thử trách nhiệm toàn nhóm Nếu nhóm bạn không chia sẻ quan điểm này, yêu cầu người suy nghĩ chất lượng, mong muốn họ việc phân phối sản phẩm tốt có thể, bước để họ đảm bảo nhóm đạt mục tiêu 21.5.6 Synergy between Practices Một thực hành phát triển Agile tích hợp liên tục có chút khác biệt, kết hợp nhiều thực hành Agile tuyệt vời tổng phần Thiết kế điều hướng kiểm thử (test-driven design), tập hợp mã nguồn riêng, tích hợp liên tục với để đưa phản hồi nhanh chóng, liên tục cải tiến thiết kế mã khả phân phối nhanh giá trị thương mại Tự động hóa kiểm thử tốt, sử dụng kiểm thử tự động để điều hướng phát triển, theo sau kiểm thử thăm dò để phát khoảng chống điểm điếu, mức độ to lớn Một số thực hành không làm việc tốt cô lập Tái cấu trúc kiểm thử tự động Nó thực phát hành nhỏ với kiểu mini-waterfall tránh toàn lợi ích phát triển nhanh Nếu khách hàng chỗ lực để tạo định, giá trị cô nhóm bị giới hạn Các thực hành Agile thiết kế để bổ sung cho Hãy dành thời gian để hiểu mục đích khác, xem xét cần thiết để tận dụng lợi đầy đủ thực hành đưa định chu đáo việc làm cho nhóm bạn 21.6 Success Factor 6: Collaborate with Customers Một giá trị tuyệt vời mà tester đóng góp cho nhóm Agile giúp khách hàng làm rõ phân mức ưu tiên cho yêu cầu, minh hoa yêu cầu examples hành vi mong muốn kịch người dùng, chuyển examples vào kiểm thử thực thi Các tester nói ngôn ngữ lĩnh vực nghiệp vụ ngôn ngữ kỹ thuật nhóm phát triển Chúng ta tạo nhà hỗ trợ dịch giả tốt Không có cách giao tiếp trực tiếp programmer customer Khuyến khích nhiều giao tiếp trực tiếp Sử dụng “Năng lực ba - Power of Three” Khi yêu cầu bị thiếu hiểu nhầm, customer, programmer, tester phải làm 246 với để đưa câu trả lời câu hỏi Để customer nói chuyện trước whiteboard thiết bị tương đương cần thiết Nếu customer nằm rải rác xung quanh khu đại học, quốc gia, toàn cầu, sử dụng công cụ mà bạn tìm thấy để tăng cường giao tiếp hợp tác Teleconferences, instant messages, wikis thay lý tưởng cho đối thoại face-to-face, chúng vượt qua cách gửi email hay không nói 21.7 Success Factor 7: Look at the Big Picture Tất nhiên, tổng quát, thấy tester có xu hướng nhìn vào tranh lớn, thường từ điểm nhìn khách hàng Các programmer phải tập trung vào việc phân phối story mà họ làm việc, họ sử dụng kiểm thử để điều hướng chúng, họ phải tập trung vào việc thực kỹ thuật yêu cầu Điểm nhìn tranh lớn đóng góp lớn nhóm Phát triển điều hướng kiểm thử (test-driven development), hoàn thành tốt, phân phối đoạn mã chắn, cô lập, tự của defects Điều xảy chức làm cho số phần không liên quan đến ứng dụng bị phá vỡ? Ai phải xem xét ảnh hưởng từ hệ thống lớn khiến nhóm phải quan tâm đến Điều xảy bỏ qua vài chi tiết nhỏ kích thích khách hàng? Giao diện người dùng trở nên hoàn hảo để viết mã, màu làm cho văn khó đọc, làm cho người dùng cuối ý Sử dụng Agile testing quadrants hướng dẫn để giúp bạn lên kế hoạch kiểm thử để bao phủ toàn góc Sử dụng ý tưởng test pyramid để đảm bảo ROI tốt từ kiểm thử tự động bạn Điều hướng phát triển với kiểm thử giúp đảm bảo bạn không quên thứ lớn, hoàn hảo Sử dụng kiểm thử thăm dò để tìm hiểu nhiều ứng dụng làm việc nào, kiểm thử bạn phải thực theo hướng Làm cho môi trường kiểm thử tương tự với production có thể, sử dụng liệu phản ánh từ giới thực Hãy siêng để tạo lại trạng thái production-style cho hoạt động với kiểm thử tải (load testing) Thật dễ dàng cho người nhóm để tập trung vào task hay story Nó nhược điểm cách làm việc dựa phần nhỏ chức thời điểm Hãy giúp nhóm bạn bước sau đánh giá stories bạn phù hợp với lược đồ lớn doanh nghiệp Hãy hỏi thân, làm để bạn làm việc tốt để cung cấp giá trị thực Summary Kiểm thử chất lượng trách nhiệm toàn nhóm, tester mang quan điểm đặc biệt kỹ độc đáo Là tester, niềm đam mê bạn cung cấp sản phẩm tốt Đừng ngại để trở thành tác nhân cải tiến liên tục Hãy để nguyên tắc giá trị điều hướng bạn bạn làm việc với khách hàng nhóm phát triển 247 Trong chương cuối, nhìn vào yếu tốt quan trọng dẫn đến thành công Agile testing: - Use the whole-team approach (Sử dụng tiếp cận toàn nhóm) Adopt an agile testing mind-set (Chấp nhận tư Agile testing) Automate regression testing (Tự động Kiểm thử hồi quy) Provide and obtain feedback (Cung cấp đạt phản hồi) Build a foundation of core practices (Xây dựng tảng thực hành cốt lõi) Collaborate with customers (Hợp tác với khách hàng) Look at the big picture (Nhìn tranh tổng thể) 248