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 chúng ta. 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.
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ó.
Với việc phát triển bất cứ ứng dụng nào, Software Development life Cycle (SDLC) đó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 các phần khác của 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ó một cái nhìn toàn diện về tất cả các ứ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 hoàn toàn 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 theo yêu cầu của các bên liên quan và bằng cách tích lũy những điểm cần thiết của ứng dụng mà một tài liệu về các yêu cầu được chuẩn bị. Tài liệu yêu cầu được chia sẻ với đội ngũ kiểm thử để có được quan điểm của họ về các yêu cầu mà họ mong muốn cũng như gửi 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: Điều rõ ràng là, viết code chèn 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, một lỗi hoặc thông báo lỗi thích hợp được hiển thị.
Quan điểm của Tester: Tester đầu tiên sẽ kiểm tra các yêu cầu được nêu ra, nhưng 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 chỉ bao gồm 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 bất cứ các kết hợp nào của 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 các ứ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ế của họ trên ứ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 chúng bởi dev.
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 các 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, các dev thực sự thực hiện việc thiết kế 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 tải các ứng dụng lên để dàn dựng 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) với định nghĩa thiết lập các chức năng đã được thực hiện bởi các nhà phát triển trong các chu trình khác/release.
Dev tải lên ứ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 các nỗ lực hợp tác giữa dev và testers.
Sau khi hoàn thiện việc thực hiện, các ứng dụng được gửi đến người dùng để nó có thể tồn tại. 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 đonạ bảo trì.
Testers và dev cùng nhau tạo nên một team hiệu quả như thể nó là một 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 sẽ đạ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ếu 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 các dev là những “chuyên gia” trong vùng 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, và chúng ta không yêu cầu có ý kiến của người thứ 2 hay các phản hồi.
“Tester” là người không bị ảnh hưởng bởi các ứng dụng được phát triển và họ test dựa trên kinh nghiệm thực tế mà tiến hành sử dụng các ứng dụng với tất cả các tình huống có thể.
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 học tập và 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 diễn ra 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.
Techtalk via Viblo
