Quan điểm khác biệt giữa “Tester” và “Developer”

Chúng ta sử dụng rất nhiều ứng dụng mỗi ngày. Internet đã trở thành một phần cuộc sống của mỗi người. Phía sau những ứng dụng đó, dù là ứng dụng về shopping, học tập hay đặt vé chúng đều là sự cống hiến của một đội ngũ hùng hậu tạo ra sản phẩm giúp cuộc sống thoải mái hơn. Những người làm nên các ứng dụng đó chính là Testers và Developers.

Trong bài viết này, chúng ta sẽ thấy được những quan điểm khác nhau giữa Testers - Developers và mối quan hệ giữa họ để cùng nhau làm nên một ứng dụng thành công.

Mục tiêu của Testers và Developers là giống nhau chính là cung cấp một sản phẩm chất lượng cho người dùng hay các doanh nghiệp. Nhưng suy nghĩ của họ thì vô cùng khác nhau. Có thể nói chính xác theo một cách khác là “Testers và Developers khác nhau nhưng họ đi theo cùng một con đường để đạt được một mục tiêu chung”.

Developers nghĩ: “Tôi có thể làm ra ứng dụng bằng cách nào?”

Testers nghĩ: “Tôi có thể phá hỏng ứng dụng bằng cách nào?”

Testers và Developers hành động giống như Tom và Jerry. Nhưng kết quả cuối cùng sẽ chỉ tích cực khi họ cùng nhau làm việc mà thôi. Bằng cách nói "Tôi có thể phá vỡ ứng dụng bằng cách nào", điều đó không có nghĩa là phương châm của một tester là làm hỏng công việc được thực hiện bởi các developers.

Điều đó có nghĩa là tester bằng suy nghĩ “think out of the box” và bằng cách “đi guốc trong bụng khách hàng”, áp dụng tất cả các tình huống có thể xảy ra đối với ứng dụng. Điều đó sẽ thực sự được hoàn thành khi ứng dụng đó không bị phá hỏng khi nó tồn tại trong môi trường của chính nó.

Phát triển bất cứ ứng dụng nào, Software Development life Cycle (SDLC) đều đóng vai trò vô cùng quan trọng. Hay nói cách khác, việc kiểm thử một sản phẩm sẽ đóng vai trò là bước cuối cùng trong chu trình phát triển. Tuy nhiên, việc sửa chữa các sai sót/ khiếm khuyết ở giai đoạn cuối cùng đã được chứng minh là rất khó khăn và tốn kém. Vì thế, để tránh những điều phức tạp, kiểm thử phần mềm đã ra đời như một phần quan trọng trong chu trình SDLC. Điều đó có nghĩa là việc kiểm thử sẽ được tiến hành ngay từ bước đầu tiên của chu trình phát triển.

Testers có cái nhìn toàn diện về ứng dụng từ những quan điểm sáng tạo khác nhau, và nếu họ đã thật sự thấu hiểu yêu cầu của khách hàng, họ sẽ tạo nên nhiều điểm khác biệt khác nữa.

Chúng ta hãy cùng xem và có được một ý tưởng ngắn gọn về quan điểm của tester tại các giai đoạn khác nhau của SDLC:

1) Thu thập yêu cầu và phân tích

Trong giai đoạn này, dựa trên yêu cầu của các bên liên quan mà chuẩn bị một số tài liệu về spec. Tài liệu yêu cầu được chia sẻ với đội ngũ kiểm thử để họ nắm vững yêu cầu của ứng dụng bằng cách đặt các câu hỏi của họ dưới dạng “Review comment”.

Các câu hỏi có thể bao gồm mọi chủ đề, có thể là sự hiểu biết về bất kỳ phần cụ thể hoặc dự đoán của một số khả năng trong tương lai có lỗi xảy ra.

Hãy cùng nhau lấy một ví dụ cơ bản: Yêu cầu của người dùng là “Không có ký tự đặc biệt nào trong trường nhập thông tin.”

Vai trò của dev: Viết code chèn vào một trường bằng cách kiểm tra xem khi người dùng nhập bất kỳ ký tự đặc biệt nào thì hiển thị thông báo lỗi thích hợp.

Quan điểm của Tester: Tester đầu tiên sẽ kiểm tra các yêu cầu được nêu ra, sau đó sẽ đặt ra nhiều kịch bản trong đầu. Họ sẽ có những câu hỏi như:

• Điều gì sẽ xảy ra nếu có ký tự đặc biệt trong ô nhập? Nó sẽ hiển thị cùng một tin nhắn hay một tin nhắn khác cho người sử dụng?
• Điều gì sẽ xảy ra nếu người dùng copy và paste kết hợp ký tự đặc biệt và ký tự số vào ô nhập đó?

Có rất nhiều kịch bản khác như đã đề cập ở trên mà testers phải suy nghĩ trong quá trình đọc tài liệu yêu cầu của khách hàng.

Để đánh giá bất kỳ sản phẩm hoặc ứng dụng nào, kiểm thử có nghĩa là đặt câu hỏi về một sản phẩm để bao quát tất cả các kịch bản vì người dùng cuối có thể là bất cứ ai và có thể sử dụng ứng dụng theo bất kỳ cách nào mà họ muốn.

2) Thiết kế hệ thống/ ứng dụng

Sau khi thu thập dữ liệu và hoàn tất các yêu cầu, dev bắt đầu thiết kế ứng dụng. Điều này bao gồm việc xem xét các tài liệu thiết kế trước khi thực hiện.

Tester từ những hiểu biết của bản thân và những suy nghĩ sáng tạo mà phân tích tất cả các kịch bản cho tất cả các các tính năng mới, cải tiến, tích hợp, cập nhật giao diện người dùng, tất cả mọi thứ được đề cập trong tài liệu yêu cầu. Họ tạo ra test cases, checklist và dữ liệu để đến khi ứng dụng đã sẵn sàng được test, họ cũng sẵn sàng với các thông số kiểm thử của chính mình.

3) Giai đoạn thực hiện

Trong giai đoạn này, dev thực sự code hệ thống hoàn chỉnh.

Khi chúng ta nhìn từ quan điểm của dev, họ đang tập trung vào việc xây dựng các chức năng - đó là yêu cầu. Theo quan điểm của họ, chức năng sẽ làm việc một cách hoàn hảo và hiệu quả.

Nhưng khi chúng ta nhìn từ góc độ của một tester, quan điểm đó hoàn toàn đối ngược với quan điểm của dev. Trong khi các dev tập trung vào việc thực hiện với các chức năng, tester lại áp dụng tất cả sự sáng tạo của bản thân mình vào việc kiểm tra các chức năng. Cũng có các trường hợp khi dev hiểu sai yêu cầu, và trong trường hợp đó testers lại áp dụng các kịch bản của họ vào việc test, ứng dụng sẽ hoàn toàn thất bại.

4) Kiểm tra hệ thống

Trong giai đoạn này, các dev deploy ứng dụng lên môi trường / môi trường QA (môi trường có sẵn cho các testers thực hiện việc test).

Dev deploy ứng dụng với quan điểm rằng các chức năng thực hiện được phát triển một cách hoàn hảo theo các yêu cầu đã được nêu ra; họ chỉ đưa các ứng dụng này cho testers để xác nhận lại.

Nhưng đối với các tester, khác với các chức năng mong muốn, có rất nhiều cách khác nhau khác nhau mà người dùng có thể nghĩ ra khi sử dụng một ứng dụng cụ thể. Đó là nhiệm vụ của các tester nhằm sử dụng tư duy sáng tạo của chính mình và khám phá các kịch bản mang tính khả thi nhất.

5) Giai đoạn duy trì

Giai đoạn này là để kiểm tra nỗ lực hợp tác giữa dev và testers.

Sau khi hoàn thiện việc thực hiện, ứng dụng được gửi đến người dùng. Sẽ không có vấn đề gì xảy ra nếu nó hoạt động như mong muốn, nhưng nếu có bất kỳ sai sót nào, nó lại đòi hỏi sự nỗ lực hợp tác của cả dev và tester trong giai đoạn bảo trì.

Testers và dev cùng nhau tạo nên một team hiệu quả như thể nó là trách nhiệm cần hoàn thành nhằm đảm bảo có sản phẩm tốt nhất. Điều này đạt được nếu cả hai cùng phối hợp làm việc với những hiểu biết đúng đắn và thu thập những ý kiến phản hồi tích cực.

Hãy cùng xem một vài điểm quan trọng để xác định vai trò của Testers và Dev.

Trong khi dev cần đảm bảo sẽ không có lỗi trong những gì họ phát triển, Testers phải chắc chắn rằng nó vẫn có lỗi, chúng phải được thông báo và sửa đúng lúc.

Dev nên lấy ý kiến từ tester một cách tích cực và có tính xây dựng.

Có thể nói dev là những "chuyên gia" về kỹ thuật riêng và họ có thể sử dụng tất cả các kỹ năng kỹ thuật của mình để phát triển dự án theo yêu cầu. Tester là bên thứ 3 (giả sử là người sử dụng ảo ứng dụng) người sẽ thông báo lỗi và các khiếm khuyết một cách hiệu quả. Trên cơ sở đó chất lượng của ứng dụng sẽ được xác định và cải thiện.

• Làm việc như một Tester:

Đó là điều tất nhiên, rất nhiều dev giỏi có thể tự test rất tốt. Điểm quan trọng là một người thì không nên tự test cái mà mình đã tạo ra/ ứng dụng của riêng mình.

"Tester" là người không bị ảnh hưởng bởi ứng dụng được phát triển và họ test dựa trên kinh nghiệm thực tế khi tiến hành sử dụng ứng dụng với tất cả các tình huống có thể xảy ra.

Một Tester tốt sẽ biết rằng người dùng có thể tạo ra trăm ngàn lỗi khi sử dụng một sản phẩm. Người dùng thực sự sẽ học cách sử dụng sản phẩm bằng cách thử và xem điều gì đã xảy ra hơn là chỉ ngồi đọc hướng dẫn sử dụng.

Vì vậy, mục tiêu chính mà Testers hướng đến là "Cái gì đang sai". Trọng tâm chính của các dev là vận hành dự án đúng với yêu cầu.

Một Tester giỏi và một dev giỏi:

Một tester giỏi là người luôn tỏ ra thoải mái với các cuộc xung đột. Nếu nhiều lần, nó sẽ trở nên khó khăn trong việc xác định nguồn gốc của lỗi. Ví dụ, nó có thể là lỗi mã hóa, lỗi tài liệu, lỗi thiết kế và thậm chí nó có thể chẳng phải là lỗi. Nhưng công việc của Tester là việc thông báo lỗi.

Một dev giỏi là người nhận ấy phản hồi một cách tích cực và có tính xây dựng, chuẩn đoán các vấn đề, và debugs chúng. Nhưng thường thì dev sẽ tránh các xung đột có thể gây ra trở ngại.

Kết luận:

Dù bạn là test hay là dev, dù bạn đứng trên lập trường của ai thì cũng đều mong sẽ có một sản phẩm hữu ích. Thiếu dev bạn sẽ không thể tạo ra sản phẩm, thiếu test bạn sẽ không thể có sản phẩm ít lỗi nhất. Vì vậy, test và dev dù tưởng như đối đầu nhưng lại gán kết với nhau và hỗ trợ cho nhau. Thông qua bài viết tôi mong 2 bên có thể hiểu nhau hơn, từ đó hợp tác vui vẻ để cùng làm nên kỳ tích.

Reference

Bài viết được tham khảo từ trang: http://www.softwaretestinghelp.com/the-difference-in-perspective-of-testers-and-developers/