Developer làm tester

Vòng đời phát triển sản paharm ( Software Development Life Cycle  – SDLC), các loại phương pháp lập trình khác nhau dần xuất hiện. Từ Waterfall cho đến Agile và giờ là DevOps.

Mọi người có xu hướng nghĩ rằng, với tất cả các phương pháp hiện tại, họ chỉ cần dùng automate testing và release sản phẩm một cách nhanh chóng. Trước hết, tôi đồng ý với James Bach, cái mà mọi người thường gọi là Automated ‘Testing’ nhưng thực chất cái họ làm lại là Automated Checking, vốn khá tuyệt vời cho complement testing nhưng vẫn còn thiếu một vài yếu tố quan trọng.

Testing cần được thực hiện bởi con người với tư duy sâu sắc. Dựa trên kinh nghiệm của tôi, một số tổ chức muốn theo kịp xu hướng nhưng không làm điều đó một cách chính xác.

Ví dụ, một công ty muốn đề cập rằng họ đang sử dụng phương pháp Agile, nhưng thực tế, những gì họ đã làm chỉ là “Waterfall” và sau đó họ đã thêm một cuộc họp ‘scrum’ và bảng ‘Kanban’. Trong khi mọi thứ khác vẫn dựa trên mô hình “Waterfall”. Điều này vẫn đang xảy ra ở một số doanh nghiệp lớn hơn.

Đối với tự động hóa, tôi biết một MNC chính ở Malaysia hiện vẫn đang vật lộn để thiết lập khuôn khổ tự động hóa của họ, thậm chí sau khi đã mất hơn 3 năm. Bạn không thể giải quyết mọi thứ bằng cách tự động hóa. Tự động hóa có thể giúp bạn thực hiện các tác vụ lặp đi lặp lại nhanh hơn và dễ dàng hơn, nhưng nó khó có thể phát hiện và tìm lỗi cho bạn. Nói cách khác Automation testing không thể suy nghĩ và hành động như người dùng thực sự!

Chi phí và thời gian

Điều đầu tiên là chi phí. Lý do chính khiến một công ty không thực hiện testing bài bản là do các vấn đề liên quan đến chi phí. Để thuê một đội ngũ QA hoặc outsourcing sẽ đội chi phí lên một khoản tiền khá.

Nhưng nếu bạn đã đầu tư quá nhiều thời gian và tiền bạc vào việc phát triển ứng dụng của mình, tại sao bạn sẵn sàng bỏ qua testing và phát hành một ứng dụng chưa được kiểm tra kĩ lưỡng? Bạn có biết rằng chi phí sửa chữa lỗi trong sản xuất là tốn kém hơn rất nhiều so với trong quá trình phát triển? Dựa trên dữ liệu của IBM, chi phí của việc tìm lỗi là tốn kém gấp 30 lần ở các giai đoạn sau so với các giai đoạn thiết kế và phát triển.

Không chỉ vậy, đừng quên tất cả những tổn thất khác có thể xảy ra, chẳng hạn như mất niềm tin của người dùng.

Chúng tôi là một công ty startup / nhỏ / mới và vì vậy chúng tôi không thể đủ khả năng để testing

Hãy để tôi nói với bạn điều này, nếu công ty không có bất kỳ quá trình testing nào thì về cơ bản sẽ là một công thức cho thảm họa. Bạn nghĩ rằng bạn đang tiết kiệm một số tiền, nhưng, có thể hóa ra bạn đang mất nhiều hơn nữa.

Hiện tại, hầu hết các ứng dụng đều giống nhau, nếu bạn là người chơi mới, điều gì khiến bạn khác biệt? Theo tôi đó sẽ là chất lượng ứng dụng của bạn! Việc có ứng dụng chất lượng sẽ giúp bạn giữ chân người dùng hiện tại bằng cách tạo dựng lòng tin của họ, nó cũng sẽ giúp bạn có được người dùng mới!

Có thể một số bạn có một cách suy nghĩ như thế, “được rồi. chúng tôi mới và chúng tôi được phép có ứng dụng bị lỗi”. Bây giờ, hãy tự đặt mình từ góc nhìn của người dùng. Tôi có thể đặt cược rằng bạn không quan tâm việc startup này có phải là mới hay không hoặc nếu ứng dụng của nó mới thế nào bởi vì những gì bạn quan tâm là ứng dụng có hoạt động như dự định không thôi.

Thời gian

Hầu hết, nếu không phải tất cả, các công ty muốn phát hành sản phẩm hoặc ứng dụng của họ sớm nhất. Đôi khi, họ nghĩ rằng, chỉ cần thực hiện testing một cách qua loa hoặc thậm chí tệ nhất, bỏ qua giai đoạn thử nghiệm, sẽ không cản trở việc phát hành ứng dụng. Thông thường, hầu hết các công ty sẽ nghĩ rằng việc thêm testing vào SDLC sẽ tốn thời gian và trì hoãn việc ra mắt sản phẩm.

Tuy vậy, nếu bạn sử dụng đúng chuyên môn và phương pháp kiểm tra, testing có thể được thực hiện một cách chính xác mà không tốn quá nhiều thời gian. Điều quan trọng nhất là chất lượng! Bạn sẽ muốn có một ứng dụng chất lượng cao để đảm bảo sự hài lòng của khách hàng và người dùng tối đa!

Điều gì tồi tệ nhất có thể xảy ra nếu chúng ta không thử nghiệm?

Vâng, hãy xem các sự kiện thực tế đã xảy ra do lỗi phần mềm hoặc ứng dụng.

• Toyota phải thu hồi lại 625.000 xe hơi do lỗi phần mềm.
• Công ty Nissan Motor đã phải thu hồi hơn một triệu xe hơi do lỗi phần mềm trong máy dò cảm biến túi khí.
• 60% Starbucks ở Mỹ và Canada buộc phải đóng cửa vì họ không thể xử lý các giao dịch thanh toán do lỗi trong hệ thống POS.
• Hãy nhìn vào khu vực Đông Nam Á của chúng tôi
  • Lỗi hệ thống sinh trắc học của Malaysia vào năm 2011: Du khách rất bực mình sau khi bị buộc phải đợi gần một tiếng rưỡi để đi qua các trạm kiểm soát nhập cư của Malaysia. Nhiều người trong số họ đã phải thay đổi hoặc hủy bỏ kế hoạch du lịch, thậm chí tệ hơn là điều này xảy ra trong mùa lễ cao điểm.

• • Trong năm 2014, Jollibee mất hàng triệu peso một ngày do một hệ thống trục trặc buộc một số cửa hàng của nó phải đóng cửa.

Tương lai của testing

Khi tôi bắt đầu sự nghiệp của mình trong lĩnh vực testing, đã có một cuộc thảo luận lớn cho việc manual testing sẽ được thay thế bằng automation checking. Vâng, cho đến bây giờ, manual testing vẫn có nhu cầu rất cao! Điều này là do thực tế việc automation checkingg không thể thay thế bộ não con người. Tất cả việc ra quyết định, phân tích dữ liệu thử nghiệm và phần quan trọng nhất, suy nghĩ, không thể được thực hiện bởi script!

Software testing đã phát triển và sẽ tiếp tục phát triển. Với tư cách là software tester, bạn cần thực hiện theo các thay đổi. Bạn không thể cứ khăng khăng không đổi trong 10 năm qua! Hãy đặt nỗ lực vào việc học những điều mới, làm một số nghiên cứu, v.v.

Nguồn: Techtalk via