QA đã hết thời?

Test tự động không phải là một khái niệm mới. Hầu hết các nhóm phát triển phần mềm đang cố gắng test tự động bằng cách này hay cách khác, đặc biệt là thay thế cho việc test thủ công với các chu kỳ kiểm tra hồi quy dài. Nếu bạn là QA, bạn có thể đã tự hỏi điều này có ý nghĩa gì đối với công việc của bạn. Trong thế giới của 'tự động hoá tất cả mọi thứ' - nơi nào thích hợp với bạn? Vai trò của QA đã không còn? Hãy bắt đầu bằng cách nói về những lợi ích rõ ràng của test tự động.

Máy tính test nhanh hơn con người.

Một trong những lợi ích đầu tiên mà người ta thấy từ test tự động là nó làm giảm đáng kể thời gian cần bỏ ra để kiểm thử một hệ thống. Bạn viết một kịch bản test một lần và nó có thể được chạy lặp đi lặp lại trong vòng chưa đầy một phút, thậm chí song song với các hoạt động test khác. Các nhóm test hồi quy tự động của họ sớm nhận ra rằng họ có thể làm hầu hết các hoạt động test hồi quy, mà trước đó mất nhiều ngày, thì bây giờ chỉ mất vài phút. Các nhóm có thể nhận phản hồi nhanh hơn và thường xuyên hơn, vì vậy bug sẽ sớm được tìm thấy và code có thể được đưa vào xử lý sớm hơn.

Máy tính phù hợp hơn so với con người.

Con người mắc sai lầm. Đó là một phần bản chất của chúng ta. Một người kiểm tra thủ công, khi đi qua cùng một trường hợp test lần thứ 100, rất có thể dễ dàng bỏ lỡ một bước hoặc quên mất một scenario. Bạn có thể quên ghi lại một kịch bản cụ thể. Các hoạt động test tự động là một dạng tài liệu sống. Máy tính thực thi những gì được lập trình sẵn, và chúng có thể làm điều đó nhiều lần mà hầu như không có độ lệch.

Những lợi ích này là rất lớn và thực sự giúp các nhóm xây dựng và phát triển chất lượng phần mềm nhanh hơn. Nhưng chúng không thực sự là những điều hiệu quả nhất trong test tự động.

Checking không phải là Testing.

Tại hội nghị OnAgile năm 2015, Elisabeth Hendrickson đã nêu rõ những phân biệt rất hữu ích khi cô mô tả những gì các hoạt động test tự động thực hiện: Họ check các chức năng, nhưng chỉ check thôi không thể gọi là test.

Test tự động là dumb, chúng tôi viết cho họ check scenarios về những cái mà chúng tôi biết. Họ chạy và kiểm tra xem liệu hệ thống vẫn làm những gì chúng tôi mong đợi theo đúng scenarios . Vậy các scenarios có từ đâu? Từ sự hiểu biết về những gì có thể sai lầm trong một hệ thống. Ai hiểu được hệ thống?

Có hai điều con người thực hiện tốt hơn các máy tính ở mọi thời điểm - sự sáng tạo và học tập. Hai yếu tố này tạo thành cái mà chúng ta gọi là exploratory testing. Khi chúng tôi khám phá một hệ thống, chúng tôi nghĩ về những cách khác thường mà chúng ta có thể tương tác với nó. Khi chúng tôi làm điều này, chúng tôi quan sát cách hệ thống hoạt động. Hendrickson chỉ ra rằng những quan sát này chúng ta thực hiện tìm hiểu về những gì chúng ta sẽ test, điều này sẽ là cơ sở cho chúng ta thực hiện trong lần test tiếp theo.

Test tự động là check hệ thống, những bug mà bạn biết nó tồn tại. Test thủ công là check những bug mà bạn không biết đến sự tồn tại của nó. Test tự động sẽ giúp bạn có nhiều thời gian, thay vì bạn cứ phải lặp đi lặp lại những hành động test giống nhau. Mỗi lần bạn tìm thấy một bug mới, bạn có thể sử dụng test tự động cho nó. Bằng cách đó, bạn sẽ không phải kiểm tra lại bằng tay một lần nữa và có thể tập trung vào việc tìm các lỗ hổng khác.

QA là gì?

Chức danh của bạn là QA, nhưng bạn thường được gọi là tester. Bạn làm nhiều hơn test, tuy nhiên. QA là gì? Tôi đã nghe một vài câu trả lời khác nhau cho câu hỏi này và tất cả đều chính xác. Tất cả chúng đều đại diện cho một khía cạnh khác nhau của vai trò quan trọng này.

Đảm bảo chất lượng

Thuật ngữ đảm bảo chất lượng là một cách nói mới của chức danh cũ kiểm soát chất lượng. Thuật ngữ Quản lý chất lượng xuất phát từ ngành chế tạo. Một sản phẩm trải qua toàn bộ dây chuyền sản xuất trước khi thông qua bộ quản lý chất lượng. Họ kiểm tra các vấn đề của sản phẩm. Nếu có lỗi, nó cần phải được trả lại hoặc sửa ngay. Nếu sản phẩm tốt, nó sẽ được chuyển đến người tiêu dùng.

Toyota đã quyết định làm việc khác đi. Họ đã sử dụng cái mà chúng tôi gọi là phương pháp Lean để đưa vào quá trình sản xuất xe. Mục đích là để giảm số lượng sản phẩm bị lỗi bằng cách nâng cao chất lượng trong từng bước của quá trình sản xuất.

Một khía cạnh của vai trò đảm bảo chất lượng là giúp xây dựng chất lượng trong quá trình phát triển phần mềm. Bạn không muốn trở thành một người Quản lý Chất lượng. Bạn không muốn các tính năng mới được hoạt động vì chất lượng kém. Vì vậy bạn giúp việc sản xuất sản phẩm diễn ra suôn sẻ với chất lượng cao hơn. Bạn có thể làm điều này bằng cách giúp viết các tài liệu test tự động cho các scenario, có thể làm cho đội phát triển nâng cao khả năng phòng tránh rủi ro.

Phân tích chất lượng.

Viết phần mềm không hề dễ. Một số, phức tạp đến từ bản chất của việc lập trình máy tính, nhưng phức tạp nhất phát sinh từ khía cạnh hệ thống tương tác với: Hệ thống của bạn cần phải tương tác với các hệ thống khác vốn đã rất khó hiểu, người dùng thực hiện các thao tác không mong muốn, kết nối mạng và cơ sở hạ tầng máy tính bị gián đoạn theo những cách không dự đoán trước được.

Một phần vai trò của bạn là giúp nhóm phát triển phần mềm hiểu cách tránh các tình huống xấu kia xảy ra. Bạn có thể tiết kiệm thời gian của nhóm mình bằng cách đặt câu hỏi đúng ngay từ đầu. Tự động hóa giúp bạn dành nhiều thời gian hơn để giúp nhóm cải tiến chất lượng sớm nhất.

Vì vậy, bạn vẫn có việc để làm?

Bạn không dư thừa. Ngược lại,test tự động có nghĩa là bạn có nhiều quyền lực hơn trong vai trò của mình hơn bao giờ hết. Tự động hóa có thể kiểm tra việc kiểm tra lặp đi lặp lại mà bạn thường phải thực hiện. Điều này sẽ tăng thêm thời gian rảnh cho bạn để sử dụng sự sáng tạo của bạn vào việc khám phá những cách mới để test một hệ thống. Bạn sẽ có thể dành ít thời gian hơn trong vai trò một tester và có nhiều thời gian hơn nữa trong vai trò là một QA, Nhà Phân tích Chất lượng và Đại sứ Chất lượng mà nhóm của bạn cần.

Bài viết được dịch lại từ nguồn: https://www.thoughtworks.com/insights/blog/qa-dead