Này Habr!
Chúng ta có một chủ đề quan trọng mới - phát triển các sản phẩm CNTT chất lượng cao. Tại HighLoad++, chúng tôi thường nói về cách làm cho các dịch vụ bận rộn trở nên nhanh chóng và tại Frontend Conf, chúng tôi nói về giao diện người dùng thú vị và không bị chậm. Chúng tôi thường xuyên có các chủ đề về thử nghiệm và DevOpsConf về việc kết hợp các quy trình khác nhau, bao gồm cả thử nghiệm. Nhưng về những gì có thể được gọi là chất lượng nói chung và cách làm việc với nó một cách toàn diện thì không.
Hãy khắc phục điều này bằng cách — chúng tôi sẽ phát triển văn hóa suy nghĩ về chất lượng của sản phẩm cuối cùng cho người dùng ở mọi giai đoạn phát triển. Thói quen không tập trung vào lĩnh vực trách nhiệm của bạn và liên kết chất lượng không chỉ với người thử nghiệm.
Bên dưới phần cắt giảm, chúng tôi sẽ nói chuyện với người đứng đầu ủy ban chương trình, người đứng đầu bộ phận thử nghiệm tại Tinkoff.Business, người tạo ra cộng đồng QA nói tiếng Nga Anastasia Aseeva-Nguyen về tình trạng của ngành QA và sứ mệnh của hội nghị mới.
- Nastia xin chào. Hãy cho chúng tôi biết về bản thân.
Anastasia: Tôi quản lý việc thử nghiệm tại một ngân hàng, tôi chịu trách nhiệm về một nhóm rất lớn - chúng tôi có hơn 90 người. Chúng tôi có một ngành nghề kinh doanh quan trọng, chúng tôi chịu trách nhiệm về hệ sinh thái cho các pháp nhân.
Tôi học cơ khí và toán học và ban đầu muốn trở thành một lập trình viên. Nhưng khi nhận được một lời đề nghị thú vị, tôi quyết định thử sức mình với vai trò là người thử nghiệm. Thật kỳ lạ, đây hóa ra lại là lời kêu gọi của tôi. Bây giờ tôi thấy tất cả công việc của tôi trong ngành này.
Tôi là một người tuân thủ nhiệt thành nguyên tắc Đảm bảo Chất lượng. Tôi không thờ ơ với những sản phẩm được tạo ra, chất lượng được xử lý như thế nào trong công ty, trong nhóm và về nguyên tắc, trong quá trình phát triển.
Với tôi điều đó là hiển nhiên cộng đồng theo hướng này chưa đủ trưởng thành, ít nhất là ở Nga. Không phải lúc nào chúng ta cũng hiểu rằng đảm bảo chất lượng không chỉ là việc kiểm tra mức độ tuân thủ các yêu cầu của một ứng dụng. Tôi muốn thay đổi tình trạng này.
— Bạn sử dụng từ Đảm bảo chất lượng và thử nghiệm. Trong mắt người bình thường, hai thuật ngữ này thường trùng lặp với nhau. Chúng khác nhau như thế nào nếu bạn tìm hiểu sâu?
Anastasia: Đúng hơn là chúng không khác nhau. Kiểm tra là một phần của nguyên tắc Đảm bảo Chất lượng; nó là một hoạt động trực tiếp - thực tế là tôi đang kiểm tra một cái gì đó. Thực tế có rất nhiều loại thử nghiệm và nhiều người chịu trách nhiệm về các loại thử nghiệm khác nhau. Nhưng ở Nga, khi làn sóng người gia công xuất hiện, những người cung cấp người thử nghiệm cho các công ty, việc thử nghiệm đã giảm xuống còn một loại duy nhất.
Trong hầu hết các trường hợp, chúng chỉ giới hạn ở thử nghiệm chức năng: họ kiểm tra xem những gì nhà phát triển đã mã hóa có tuân thủ đặc tả hay không và thế là xong.
— Xin vui lòng cho chúng tôi biết còn những nguyên tắc đảm bảo chất lượng nào khác? Những gì khác, ngoài việc kiểm tra, được bao gồm ở đây?
Anastasia: Đảm bảo chất lượng trước hết là tạo ra một sản phẩm có chất lượng. Nghĩa là, chúng ta tự hỏi sản phẩm của mình nên có những thuộc tính chất lượng nào. Theo đó, nếu hiểu được điều này, chúng ta có thể so sánh xem ai là người ảnh hưởng đến những thuộc tính chất lượng này. Không quan trọng, nhà phát triển, người quản lý dự án hoặc chuyên gia sản phẩm là người có ảnh hưởng đến sự phát triển của sản phẩm, tồn đọng và chiến lược của sản phẩm.
Người thử nghiệm nhận thức rõ hơn về vai trò của mình. Anh ấy hiểu rằng nhiệm vụ của anh ấy không chỉ là kiểm tra mức độ tuân thủ các yêu cầu mà còn kiểm tra các yêu cầu, đặt câu hỏi về các công thức do chuyên gia sản phẩm đưa ra và tiết lộ tất cả các yêu cầu và mong đợi tiềm ẩn của khách hàng. Khi cung cấp chức năng mới cho khách hàng, chúng tôi phải thực sự đáp ứng được mong đợi của họ và giải quyết những khó khăn của họ. Nếu chúng ta nghĩ về tất cả các thuộc tính của chất lượng, khách hàng sẽ hài lòng và hiểu rằng công ty có sản phẩm mà anh ta sử dụng thực sự quan tâm đến lợi ích của anh ta và không hoạt động theo nguyên tắc “chỉ để phát hành một tính năng”.
— Có vẻ như điều bạn vừa mô tả là nhiệm vụ của một chuyên gia sản phẩm. Về nguyên tắc, đây không phải là về thử nghiệm hay chất lượng - nói chung là về quản lý sản phẩm, phải không?
Anastasia: Bao gồm. Đảm bảo chất lượng không phải là một môn học mà một người cụ thể chịu trách nhiệm. Hiện nay có một hướng phổ biến trong thử nghiệm, một phương pháp được gọi là Kiểm tra Agile. Định nghĩa của ông nêu rõ rằng đây là một cách tiếp cận nhóm để thử nghiệm, bao gồm một tập hợp các phương pháp thực hành nhất định. Toàn bộ nhóm chịu trách nhiệm thực hiện phương pháp này; thậm chí không cần thiết phải có người thử nghiệm trong nhóm. Toàn bộ nhóm tập trung vào việc cung cấp giá trị cho khách hàng và đảm bảo rằng giá trị đó đáp ứng được mong đợi của khách hàng.
— Hóa ra chất lượng giao thoa với hầu hết các nguyên tắc xung quanh, áp đặt khuôn khổ cho mọi thứ xung quanh?
Anastasia: Phải. Khi nghĩ về cách tạo ra một sản phẩm chất lượng, chúng ta bắt đầu nghĩ đến các thuộc tính khác nhau của chất lượng. Ví dụ: làm cách nào để kiểm tra xem chúng tôi có thực sự tạo ra tính năng mà khách hàng cần hay không.
Đây là lúc loại thử nghiệm này xuất hiện: UAT (kiểm tra sự chấp nhận của người dùng). Thật không may, nó hiếm khi được thực hiện ở Nga nhưng đôi khi lại xuất hiện trong các nhóm SCRUM dưới dạng bản demo cho khách hàng cuối. Đây là loại hình thử nghiệm khá phổ biến ở các công ty nước ngoài. Trước khi mở chức năng cho tất cả khách hàng, trước tiên chúng tôi thực hiện UAT, nghĩa là chúng tôi mời người dùng cuối kiểm tra và đưa ra phản hồi ngay lập tức - liệu sản phẩm có thực sự đáp ứng mong đợi và giải quyết được vấn đề hay không. Chỉ sau đó việc mở rộng quy mô cho tất cả các máy khách khác mới xảy ra.
Nghĩa là, chúng tôi tập trung vào kinh doanh, vào khách hàng cuối cùng, nhưng đồng thời đừng quên công nghệ. Chất lượng của sản phẩm còn phụ thuộc rất nhiều vào công nghệ. Nếu chúng tôi có kiến trúc tồi, chúng tôi sẽ không thể nhanh chóng đưa ra các tính năng và đáp ứng mong đợi của khách hàng. Có thể có rất nhiều lỗi khi cố gắng mở rộng quy mô hoặc khi cố gắng tái cấu trúc, chúng ta có thể làm hỏng thứ gì đó. Tất cả điều này sẽ ảnh hưởng đến sự hài lòng của khách hàng.
Từ quan điểm này, kiến trúc phải sao cho chúng ta có thể viết mã rõ ràng cho phép chúng ta nhanh chóng thực hiện các thay đổi và không sợ rằng chúng ta sẽ phá vỡ mọi thứ. Vì vậy, việc lặp lại sửa đổi không kéo dài trong vài tháng chỉ vì chúng tôi có quá nhiều di sản và chúng tôi cần thực hiện các giai đoạn thử nghiệm kéo dài.
— Tổng cộng, các nhà phát triển, kiến trúc sư, nhà khoa học sản phẩm, người quản lý sản phẩm và người thử nghiệm đều đã tham gia. Ai khác tham gia vào quá trình đảm bảo chất lượng?
Anastasia: Bây giờ hãy tưởng tượng rằng chúng ta đã cung cấp tính năng này cho khách hàng. Rõ ràng, chất lượng của sản phẩm cần phải được giám sát ngay cả khi nó đã được sản xuất. Ở giai đoạn này, các tình huống có kịch bản không rõ ràng, được gọi là lỗi, có thể xuất hiện.
Câu hỏi đầu tiên là làm cách nào để xử lý những lỗi này sau khi chúng tôi đã phát hành sản phẩm? Ví dụ, chúng ta phản ứng thế nào với căng thẳng? Khách hàng sẽ không hài lòng lắm nếu thời gian tải trang mất hơn 30 giây.
Đây là lúc sự bóc lột phát huy tác dụng hoặc, như người ta gọi bây giờ, DevOps. Trên thực tế, đây là những người chịu trách nhiệm vận hành sản phẩm khi nó đã được sản xuất. Điều này bao gồm nhiều loại giám sát. Thậm chí còn có một loại thử nghiệm phụ - thử nghiệm trên sản xuất, khi chúng tôi cho phép mình không thử nghiệm thứ gì đó trước khi triển khai và thử nghiệm nó ngay trên sản xuất. Đây là một loạt các biện pháp theo quan điểm tổ chức cơ sở hạ tầng cho phép bạn nhanh chóng ứng phó với sự cố, tác động và khắc phục sự cố.
Cơ sở hạ tầng cũng rất quan trọng. Thường có những tình huống khi trong quá trình thử nghiệm, không thể đảm bảo rằng chúng tôi thực sự có mọi thứ mà chúng tôi muốn cung cấp cho khách hàng. Chúng tôi đưa nó vào sản xuất và bắt đầu nắm bắt được những tình huống không rõ ràng. Và tất cả là do cơ sở hạ tầng trong thử nghiệm không tương ứng với cơ sở hạ tầng trong sản xuất. Điều này dẫn đến một loại thử nghiệm mới - thử nghiệm cơ sở hạ tầng. Đây là các cấu hình, cài đặt, di chuyển cơ sở dữ liệu khác nhau, v.v.
Điều này đặt ra câu hỏi - có lẽ nhóm cần sử dụng cơ sở hạ tầng làm mã.
Tôi tin rằng cơ sở hạ tầng ảnh hưởng trực tiếp đến chất lượng sản phẩm.
Tôi hy vọng tại hội nghị sẽ có một báo cáo về một trường hợp thực tế. Hãy viết thư cho chúng tôi nếu bạn sẵn sàng cho chúng tôi biết từ kinh nghiệm của bản thân về việc cơ sở hạ tầng dưới dạng mã ảnh hưởng đến chất lượng như thế nào. Cơ sở hạ tầng dưới dạng mã giúp việc kiểm tra tất cả cài đặt và kiểm tra những thứ đơn giản là không thể thực hiện được dễ dàng hơn. Vì vậy, hoạt động cũng tham gia vào quá trình phát triển một sản phẩm có chất lượng.
— Còn phân tích và tài liệu thì sao?
Anastasia: Điều này áp dụng nhiều hơn cho các hệ thống doanh nghiệp. Khi chúng ta nói về doanh nghiệp, người ta nghĩ ngay đến những người như nhà phân tích và nhà phân tích hệ thống. Đôi khi họ được gọi là người viết kỹ thuật. Họ nhận được nhiệm vụ viết một bản đặc tả và hoàn thành nó, chẳng hạn như trong một tháng.
Người ta đã nhiều lần chứng minh rằng việc viết tài liệu như vậy dẫn đến quá trình lặp lại quá trình phát triển rất lâu và quá trình lặp lại quá trình tinh chỉnh kéo dài, bởi vì trong quá trình thử nghiệm, các lỗi được xác định và bắt đầu trả về. Kết quả là có rất nhiều vòng lặp làm tăng chi phí phát triển. Ngoài ra, điều này có thể gây ra các lỗ hổng. Có vẻ như chúng tôi đã viết mã tham chiếu nhưng sau đó chúng tôi đã thực hiện những thay đổi làm phá vỡ kiến trúc được tính toán hoàn hảo.
Kết quả cuối cùng là một sản phẩm không hoàn toàn có chất lượng cao, bởi vì các bản vá đã xuất hiện trong kiến trúc, mã ở một số chỗ không được kiểm tra đầy đủ, vì thời hạn sắp hết, tất cả các lỗi cần phải được đóng nhanh chóng. Và tất cả là do đặc điểm kỹ thuật ban đầu đã không tính đến tất cả các điểm cần thực hiện.
Các nhà phát triển không phải là loài gây hại và không cố ý viết mã có lỗi.
Nếu ban đầu chúng tôi nghĩ đến một đặc tả có thể bao gồm tất cả các điểm cần thiết thì mọi thứ sẽ được triển khai chính xác như cần thiết. Nhưng đây là một điều không tưởng.
Có lẽ không thể viết được một bản đặc tả hoàn hảo dài 100 trang. Đó là lý do tại sao cần suy nghĩ về những cách viết tài liệu khác, thông số kỹ thuật, thiết lập các nhiệm vụ sẽ đưa chúng ta đến gần hơn với việc đảm bảo rằng nhà phát triển thực hiện chính xác những gì cần thiết.
Ở đây tôi nghĩ đến các phương pháp tiếp cận từ Agile - câu chuyện của người dùng với tiêu chí chấp nhận. Điều này có thể áp dụng nhiều hơn cho các nhóm phát triển theo từng bước lặp nhỏ.
— Còn việc kiểm tra khả năng sử dụng, khả năng sử dụng sản phẩm, thiết kế thì sao?
Anastasia: Đây là một điểm rất quan trọng vì trong nhóm có các nhà thiết kế. Thông thường, các nhà thiết kế được sử dụng như một dịch vụ - bởi bộ phận thiết kế hoặc bởi một nhà thiết kế thuê ngoài. Thường có những tình huống mà có vẻ như nhà thiết kế đã lắng nghe chuyên gia sản phẩm và làm những gì anh ta hiểu. Nhưng khi chúng ta bắt đầu lặp lại, hóa ra những gì đã thực sự được thực hiện không như những gì được mong đợi: nhà thiết kế đã quên điều gì đó, không suy nghĩ thấu đáo về hành vi, bởi vì anh ta không ở trong nhóm và không ở trong bối cảnh hoặc phía trước. -nhà phát triển cuối cùng không hiểu đầy đủ về bố cục của nó. Có thể phải mất vài lần lặp lại chỉ vì nhà phát triển giao diện người dùng có vấn đề trong việc hiểu thiết kế.
Ngoài ra còn có một vấn đề nữa. Hệ thống thiết kế hiện đang trở nên phổ biến. Chúng đang được cường điệu hóa nhưng lợi ích từ chúng không hoàn toàn rõ ràng.
Tôi có ý kiến cho rằng hệ thống thiết kế một mặt giúp đơn giản hóa việc phát triển, nhưng mặt khác, chúng áp đặt rất nhiều hạn chế đối với giao diện.
Kết quả là, chúng tôi không tạo ra tính năng mà khách hàng muốn mà là tính năng thuận tiện cho chúng tôi, bởi vì chúng tôi đã có một số khối nhất định để từ đó chúng tôi có thể tạo ra nó.
Tôi nghĩ đây là một chủ đề đáng để xem xét và tự hỏi liệu khi cố gắng làm cho thiết kế trở nên dễ dàng hơn, chúng ta có thực sự giải quyết được điểm khó khăn của khách hàng hay không.
— Có một số lượng đáng ngạc nhiên các chủ đề liên quan đến Đảm bảo Chất lượng. Có một hội nghị nào ở Nga có thể thảo luận tất cả những vấn đề đó không?
Anastasia: Có hội nghị thử nghiệm lâu đời nhất, sẽ được tổ chức lần thứ 25 trong năm nay và được gọi là Hội nghị Đảm bảo Chất lượng Ngày SQA. Nó chủ yếu thảo luận về các công cụ và phương pháp thử nghiệm cụ thể dành cho người thử nghiệm chức năng. Theo quy định, các báo cáo tại Ngày SQA xem xét sâu sắc các lĩnh vực cụ thể trong phạm vi trách nhiệm của chính người thử nghiệm chứ không phải các hoạt động phức tạp.
Điều này giúp ích rất nhiều trong việc hiểu các công cụ và cách tiếp cận khác nhau, cách kiểm tra cơ sở dữ liệu, API, v.v. Nhưng đồng thời, một mặt, nó không thúc đẩy việc tham gia nhiều hơn việc chỉ thử nghiệm để tạo ra một sản phẩm tốt hơn. Mặt khác, người thử nghiệm không tham gia nhiều hơn vào quá trình suy nghĩ về mục tiêu chung của sản phẩm và thành phần kinh doanh của nó.
Tôi điều hành một bộ phận lớn và thực hiện nhiều cuộc phỏng vấn để thực sự cung cấp cái nhìn sâu sắc về tình hình của toàn ngành. Theo quy định, người của chúng tôi làm việc trong các doanh nghiệp và họ có trách nhiệm rõ ràng. Các đồng nghiệp làm việc trong các dự án nước ngoài sử dụng nhiều loại thử nghiệm khác nhau: bản thân họ có thể thực hiện thử nghiệm tải, thử nghiệm hiệu suất và thậm chí đôi khi là thử nghiệm bảo mật, vì chúng thực sự giúp nhóm đảm bảo chất lượng của sản phẩm.
Tôi muốn những người ở Nga cũng bắt đầu nghĩ rằng ngành công nghiệp này không kết thúc bằng việc thử nghiệm chức năng.
— Với mục đích này, chúng tôi đang tổ chức một hội nghị mới, QualityConf, dành riêng cho chất lượng như một môn học không thể thiếu. Hãy cho chúng tôi biết thêm về ý tưởng, mục tiêu chính của hội nghị là gì?
Anastasia: Chúng tôi muốn tạo ra một cộng đồng gồm những người quan tâm đến việc tạo ra những sản phẩm chất lượng. Cung cấp một nền tảng nơi họ có thể đến, nghe báo cáo và rời đi sau hội nghị với sự hiểu biết cụ thể về những gì cần thay đổi để cải thiện chất lượng.
Ngày nay tôi thường nghe yêu cầu tư vấn về việc phải làm gì khi có vấn đề về kiểm tra và chất lượng. Khi bạn bắt đầu giao tiếp với các nhóm, bạn sẽ thấy rằng vấn đề không nằm ở bản thân những người thử nghiệm mà là ở cách cấu trúc quy trình. Ví dụ: khi các nhà phát triển tin rằng họ chỉ chịu trách nhiệm viết mã, trách nhiệm của họ kết thúc đúng vào thời điểm họ giao nhiệm vụ cho việc kiểm thử.
Không phải ai cũng nghĩ đến thực tế là mã viết kém, chất lượng thấp với kiến trúc kém sẽ đe dọa những vấn đề lớn cho dự án. Họ không nghĩ đến cái giá phải trả cho sai sót, rằng những lỗi phát sinh trong quá trình sản xuất có thể gây ra chi phí lớn cho công ty và nhóm. Không có văn hóa để nghĩ về điều này. Tôi muốn chúng ta bắt đầu phân phát nó tại hội nghị.
Tôi hiểu rằng đây không phải là một sự đổi mới, Edward Deming, tác giả của 14 nguyên lý về chất lượng, đã viết về cái giá phải trả của một sai sót vào thế kỷ trước. Đảm bảo chất lượng như một môn học được dựa trên cuốn sách này, nhưng thật không may, sự phát triển hiện đại đã quên mất nó.
— Bạn có dự định đề cập trực tiếp đến các chủ đề về thử nghiệm và công cụ không?
Anastasia: Tôi thừa nhận rằng sẽ có báo cáo về các công cụ. Có những công cụ khá phổ biến mà các công ty và nhóm có thể sử dụng để tác động đến sản phẩm.
Tất cả các báo cáo sẽ được thống nhất trên toàn cầu bởi một sứ mệnh chung: truyền đạt tới khán giả rằng với sự trợ giúp của phương pháp tiếp cận, công cụ, phương pháp, quy trình, loại thử nghiệm này, chúng tôi đã tác động đến chất lượng sản phẩm và cải thiện cuộc sống của khách hàng.
Chúng tôi chắc chắn sẽ không có báo cáo về một công cụ vì lợi ích của một công cụ. Tất cả các báo cáo có trong chương trình sẽ được thống nhất bởi một mục tiêu chung.
— Ai sẽ quan tâm đến những gì bạn đang nói đến, bạn xem ai là khách mời của hội nghị?
Anastasia: Chúng tôi sẽ có báo cáo dành cho các nhà phát triển quan tâm đến số phận của dự án, sản phẩm, hệ thống của họ. Tương tự như vậy, nó sẽ được những người thử nghiệm quan tâm và đối với tôi, đặc biệt là những người quản lý. Khi nói đến người quản lý, ý tôi là những người đưa ra quyết định và có thể ảnh hưởng đến số phận cũng như sự phát triển của sản phẩm, hệ thống, nhóm.
Đây là những người thắc mắc làm thế nào để cải thiện chất lượng của sản phẩm hoặc hệ thống. Tại hội nghị của chúng tôi, họ sẽ tìm hiểu về nhiều nhóm biện pháp khác nhau và có thể hiểu được điều gì đang xảy ra với chúng và những gì cần phải thay đổi.
Tôi nghĩ tiêu chí chính là phải hiểu rằng có điều gì đó không ổn về chất lượng và muốn tác động đến nó. Chúng tôi có thể sẽ không thể tiếp cận được những người nghĩ rằng điều này sẽ thành công ngay lần đầu tiên.
— Bạn có nghĩ rằng toàn bộ ngành đã chín muồi để nói không chỉ về thử nghiệm mà còn về văn hóa chất lượng không?
Anastasia: Tôi nghĩ tôi đã trưởng thành rồi. Hiện nay nhiều công ty đang chuyển từ cách tiếp cận Thác nước truyền thống sang Agile. Tập trung vào khách hàng, mọi người trong nhóm thực sự bắt đầu nghĩ về cách tạo ra một sản phẩm chất lượng. Ngay cả các công ty doanh nghiệp cũng đang tập trung vào việc cải thiện chất lượng.
Đánh giá theo số lượng yêu cầu phát sinh trong cộng đồng, tôi tin rằng đã đến lúc. Tất nhiên, tôi không chắc đây sẽ là một cuộc cách mạng quy mô lớn, nhưng tôi muốn cuộc cách mạng về ý thức này xảy ra.
- Đã đồng ý! Chúng tôi sẽ thấm nhuần văn hóa và thay đổi ý thức.
Hội thảo phát triển sản phẩm CNTT chất lượng cao sẽ diễn ra ở Moscow vào ngày 7 tháng XNUMX. Bạn biết những công đoạn nào tạo nên một sản phẩm chất lượng cao, chúng tôi có những trường hợp khắc phục lỗi thành công trong sản xuất, chúng tôi đã thử nghiệm các phương pháp phổ biến trong thực tế của mình - chúng tôi cần kinh nghiệm của bạn. của họ nộp đơn trước ngày 1 tháng XNUMXvà Ủy ban Chương trình sẽ giúp tập trung chủ đề vào tính toàn vẹn chung của hội nghị.
Kết nối với , trong đó chúng tôi thảo luận về các vấn đề chất lượng và hội nghị, hãy đăng ký để cập nhật tin tức chương trình.
Nguồn: www.habr.com