Giới thiệu về Software Testing ~ Xóm Tester

Giới thiệu về Software Testing

Software là gì?

- Software là một thuật ngữ chung chỉ các phần mềm máy tính bao gồm các hướng dẫn cho phép người dùng tương tác với phần cứng của máy tính hay thực hiện những tác vụ liên quan đến công việc.

- Các loại software:

Phần mềm hệ thống: Đây là phần mềm chính chạy trên máy tính. Phần mềm này sẽ chịu trách nhiệm kích hoạt phần cứng và điều khiển, điều phối hoạt động khi bạn mở máy tính. Tất cả các chương trình ứng dụng cũng được điều khiển bởi phần mềm hệ thống. Một số phần mềm hệ thống rất quen thộc đối với chúng ta đó là:
Vd: Device drivers, Operating Systems, Servers, Utilities, ...
Phần mềm ứng dụng: Phần mềm lập trình là một tập hợp hoặc tập hợp các công cụ giúp các nhà phát triển viết phần mềm hoặc chương trình khác. Phần mềm lập trình hỗ trợ tạo, gỡ lỗi và bảo trì phần mềm, ứng dụng hoặc chương trình
Vd: compilers, debuggers, interpreters, ...
Phần mềm ứng dụng: Phần mềm ứng dụng là một tập hợp các chương trình được thiết kế để thực hiện một nhiệm vụ cụ thể. Phần mềm ứng dụng không kiểm soát hoạt động của máy tính nên máy tính vẫn chạy bình thường khi không có phần mềm ứng dụng.
Vd: Web Applications, Mobile Apps, Desktop Applications etc.

Kiểm thử phần mềm là gì?

Kiểm thử phần mềm là quá trình xác minh và xác thực xem phần mềm, ứng dụng không có lỗ, đáp ứng các yêu cầu kỹ thuật như được hướng dẫn bởi thiết kế, phát triển và đáp ứng các yêu cầu của người dùng một cách hiệu quả bằng cách xử lý tất cả các trường hợp ngoại lệ và biên.

Software Testing có thể được chia thành 2 bước:

Xác minh: đề cập đến tập hợp các nhiệm vụ đảm bảo rằng phần mềm thực hiện chính xác một chức năng cụ thể
Xác thực: đề cập đến các nhiệm vụ khác nhau để đảm bảo rằng phần mềm đã được xây dựng có thể thực hiện được các yêu cầu của khách hàng

Issure - Error - Fault - Failure - Defect - Bug

Issue: là bất cứ vấn đề gì liên quan đến dự án trong quá trình Implement hoặc giai đoạn chuyển giao. Chẳng hạn như về nhân sự, tiến độ, chiến lược, quản lí, hệ thống, thiết bị, Q&A, …

Error: Là hành động của con người dẫn đến kết quả sai.

Ví dụ: Developer đặt tên biến cho 1 function sai cú pháp, dẫn đến khi gọi biến này thì không ra kết quả.

Fault: Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu.
Ví dụ: khi bạn test API, bạn muốn login thành công vào 1 app thì sẽ luôn có 1 token được trả về từ server.
Fault => Server không có token trả về, và bạn vẫn login thành công.

Failure: Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả, là sự khác biệt giữa kết quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc service nào đó.

Ví dụ: khách hàng yêu cầu server có thể hoạt động tốt khi có 1000 user.

Tuy nhiên trên thực tế server chỉ có thể hoạt động tốt khi có 900 user.

Chú ý: Không phải 100% failure là do bug gây ra, trong quá trình test cấu hình sai, test sai môi trường hoặc làm thiếu bước có thể dẫn đến failure

Defect: Lỗi trong quá trình phát triển hoặc lỗi logic(coding or logic) làm cho chương trình hoạt động sai yêu cầu đề ra.(Về cơ bản là giống định nghĩa bug).

Ví dụ: Trong quá trình coding, developer nên get data từ A để hiển thị lên màn hình, tuy nhiên developer hiểu sai logic và get data từ C để hiển thị lên màn hình, dẫn đến bug hiển thị sai data.

Bug: Là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng.

Một bug, nếu gặp phải trong quá trình hệ thống hoạt động, có thể gây ra failure trong thành phần hoặc hệ thống đó.

Tại sao phần mềm lại thường xuyên có bug?

Có rất nhiều lý do cho lỗi phần mềm. Lý do phổ biến nhất là những sai lầm của con người trong việc thiết kế phần mềm và mã hóa. Một khi bạn đã biết nguyên nhân gây ra lỗi thì bạn sẽ dễ dàng khắc phục và giảm thiểu các lỗi này.

Dưới đây tôi sẽ chia sẻ 10 lý do mà deverloper hay tester hay mắc phải và cũng có thể bạn cũng dễ mắc phải những điều này.

1. Thiếu hoặc không nhận được thông tin chính xác

Thành công của bất kỳ ứng dụng phần mềm nào đều phụ thuộc vào quá trình giao tiếp giữa các bên liên quan, giữa đội ngũ phát triển và kiểm thử phần mềm. Unclear requirements - Yêu cầu không rõ ràng và giải thích sai các yêu cầu là 2 yêu tố chính gây ra lỗi trong phần mềm.

=> Làm rõ ràng thông tin ngay khi nhận được nó. Đảm bảo tính đúng đắn của thông tin mà bạn nhận được.

2. Phần mềm phức tạp

Sự phức tạp của các ứng dụng hiện tại có thể khó để hiểu cho bất cứ ai không có kinh nghiệm trong việc phát triển phần mềm.Các giao diện kiểu Windows, client-server và distributed applications, cơ sở dữ liệu quan trọng và kích thước các ứng dụng làm tăng size ứng dụng, hệ thống hay việc sử dụng các kỹ thuật hướng đối tượng phức tạp ngay từ ban đầu.=> Một dự án được thiết kế kỹ lưỡng ngay từ ban đầu thì sẽ có thể được đơn giản hóa đi rất nhiều.

3. Lỗi lập trình

Các lập trình viên thì cũng giống như bất kỳ con người nào trên thế giới và đều có thể mắc lỗi. Không phải tất cả nhà phát triển đều là chuyên gia. Các lập trình viên thiếu kinh nghiệm hoặc kiến thức không tốt có thể mắc những sai lầm trong khi code. Hoặc họ không có giải pháp để viết dòng code đơn giản, hay kiểm tra hay gỡ lỗi. Đó cũng là 1 lý do phổ biến cho hầu hết các vấn đề trong giai đoạn phát triển

=> Hãy học hỏi và áp dụng những công nghệ mới nhất vào dòng code của mình. Nhưng cần đảm bảo được chất lượng dòng code của mình.

4. Yêu cầu thay đổi liên tục

Khách hàng họ không hiểu hoặc có thể hiểu được tác động của những thay đổi, thiết kế lại phần mềm, thay đổi kế hoạch, thời gian khi mà yêu cầu từ ban đầu bị thay đổi. Khi mà công việc từ yêu cầu ban đầu đã xong nhưng vẫn bị ném đi hoặc yêu cầu chỉnh sửa, thay đổi to hay nhỏ thì đều ảnh hưởng tới phần mềm và dễ dàng dẫn đến lỗi phần mềm khi lập trình viện không thể giải quyết hết những vấn đề liên quan, hoặc không thể nhận ra những thay đổi có tầm ảnh hưởng tới chức năng khác như thế nào. Lý do này ngày càng trở nên phổ biến trong hiện nay.

=> Trong môi trường hiện nay, các yêu cầu liên tục được thay đổi để phù hợp hơn với cuộc sống và nó cũng là một thực tế. Trong trường hợp này thì người quản lý cần đưa ra những rủi ro khi sửa đổi, QA và DEV cần phải lên kế hoạch cho việc phát triển và kiểm thử những thay đổi này để không bị ảnh hưởng hay gây lỗi cho chức năng liên quan.

5. Hạn chế thời gian

Việc lên kế hoạch cho các dự án phần mềm là khó khăn nhất, thường là những tính toán phỏng đoán. Khi deadline đến và khủng hoảng xảy ra, sẽ có những sai lầm. Scheduling được lên trước và dựa theo kinh nghiệm của lập trình viên, kiểm thử viên, thiết kế phần mềm. Nếu như họ không thể đảm bảo được đúng theo kế hoạch đã gửi khách hàng ban đầu, họ sẽ không đủ thời gian để code, kiểm tra, thiết kế dự án một các đúng đắn thì khi đó dự án sẽ sót bug.

=> Bạn nên estimate thời gian theo từng phần nhỏ của công việc, như vậy sẽ đảm bảo cho plan của bạn theo đúng tiến độ mà bạn đề ra.

6. Người tự tin thái quá

Một số người này thường hay cho rằng những thay đổi yêu cầu trong dự án là :

K vấn đề
Chuyện nhỏ
Làm tý thì xong …
Thay đổi code cũ chút là xong... Nhưng dù có thay đổi nhỏ nhặt không phức tạp thì chúng ta vẫn nên cẩn thận vẫn hơn

=> Thay vì cách nghĩ trên thì nên nghĩ rằng:

Vấn đề này rất phức tạp,chúng ta sẽ dễ dàng mắc nhiều lỗi
Tôi không thể estimate thời gian hoàn thành nó trong bao lâu,...
Chúng ta không thể hiểu được những dòng code cũ,...

7. Tài liệu code nghèo nàn

Thật khó khăn trong việc duy trì và sửa đổi code cũ hay code kém. Kết quả là lỗi phần mềm. Trong dự án thì quản lý sẽ yêu cầu dev viết tài liệu hoặc code rõ ràng dễ hiểu, nhưng thực tế thì điều đó khó thực hiện được. Họ chỉ quan tâm làm sao nhanh chóng hoàn thành công việc, và code đó là an toàn nếu không ai khác có thể hiểu được.
Bất kỳ lập trình viên mới bắt đầu làm việc trên dòng code này thì có thể bị lẫn lỗn do sự phức tạp của dự án và tài liệu kém. Họ sẽ phải mất nhiều thời gian hơn để học và thực hiện những thay đổi nhỏ trong dòng code này

=> Tạo thói quen viết tài liệu cho dòng code của mình, đon giản hóa dòng code của mình.

8. Công cụ phát triển phần mềm

Visual tools, class libraries, compilers, scripting tools,...thường đưa ra lỗi của họ nhưng docmented ghi chép lại thì sơ xài, dẫn đến người dùng khi dùng công cụ trên thì vẫn gặp lỗi. Thay đổi liên tục công cụ phần mềm thường được lập trình viên sử dụng. Giữ tiến độ giữa các versions khác nhau và tính tương thích của chúng cũng chính là một vấn đề.

=> Khi thay đổi versions của công cụ bạn cần đảm bảo những nơi bạn dùng công cụ đều không bị lỗi, hạn chế update versions theo trào lưu.

9. Kịch bản tự động hóa lỗi thời

Viết kịch bản test tự động mất rất nhiều thời gian, đặc biệt là các kịch bản phức tạp. Nếu các nhóm tự động record/write bất kỳ kịch bản kiểm thử nào nhưng quên không cập nhật nó trong 1 khoảng thời gian thì kịch bản test có thể bị lỗi thời. Nếu các kịch bản test tự động không phải là xác nhận dựa trên yêu cầu đúng đắn nhất thì nó không thể kiểm tra hết các lỗi được.

=> Thường xuyên cập nhật kịch bản test tự động, nếu không có thời gian cập nhật thì chỉ nên kế thừa kịch bản test này.

10. Kinh nghiệm test còn non kém

Tester có tay nghề với kiến thức là vô cùng quan trọng cho sự thành công của bất kỳ dự án. Nhưng việc chỉ định tất cả các tester có kinh nghiệm là không thể cho tất cả các công ty.

=> Kiến thức và khả năng tìm lỗi tốt có thể tạo ra phần mềm chất lượng cao. Các Tester ít kinh nghiệm có làm việc cặp cùng với một Tester kinh nghiệm để đảm bảo chất lượng phần mềm, vừa tăng kinh nghiệm của những Tester non kém. Và quan trọng họ cần phải tự bổ sung kiến thức còn thiếu của bản thân mình.Một vài lý do cũng có thể sẽ ảnh hưởng tới chất lượng phần mềm:

Không có môi trường test
Viết code hoặc test case mà không hiểu rõ yêu cầu
Thiết kế không chính xác dẫn đến các vấn đề trong tất cả các giai đoạn của quy trình phát triển phần mềm
Releasing software và các bản vá phần mềm mà không cần tuân theo vòng đời phát triển phần mềm
Không đào tạo nguồn lực có kỹ năng cần thiết để phats triển hay kiểm thử phần mềm
Không dành thời gian cho kiểm thử hồi quy
Không ưu tiên việc kiểm thử
Thay đổi trong phút chót

Xóm Tester

SF