Kiểm tra tính năng Email của một ứng dụng

Trong hầu hết các ứng dụng web và ứng dụng di động, kiểm tra tính năng Email được coi là một trong những phần quan trọng, để đảm bảo chất lượng trong chức năng gửi nhận Email cũng như các chức năng khác của hệ thống.

Các email được kích hoạt dưới các tình huống khác nhau được coi là hợp lệ bằng cách kiểm tra tất cả các thành phần của nó trong đó bao gồm mẫu Email, Liên kết / nút trong các trường Email, Từ, Tới, Cc, Bcc, Tệp đính kèm, Nội dung theo Email, vv

1. Tại sao chúng ta cần kiểm tra Email?

Mỗi thành phần trong hệ thống (ứng dụng Web / ứng dụng trên điện thoại di động) có thể có các mục đích khác nhau để gửi email. Tích hợp giữa các thành phần và email đóng một vai trò quan trọng trong việc tiếp cận người dùng cuối với các thông báo phù hợp. Bất kỳ sơ suất nào khi chúng ta kiểm tra tính năng này sẽ dẫn đến sự hiểu nhầm, ấn tượng xấu từ khách hàng, hacking, v.v.

Ví dụ: hãy tưởng tượng tình huống người dùng đã nhận được email để đặt lại mật khẩu. Điều gì sẽ xảy ra nếu liên kết / nút đặt lại mật khẩu hoặc URL được cung cấp để sao chép dán trong một trình duyệt không hoạt động? Tùy chọn duy nhất còn lại ở đây là liên hệ với bộ phận hỗ trợ khách hàng, điều này có thể trở thành một điều rất bất tiện hoặc tưởng tượng một tình huống mà người dùng vẫn tiếp tục nhận được Email hàng ngày thông báo ngày đến hạn thanh toán hóa đơn từ 10-15 ngày trước đó hoặc nhận được lời nhắc sau ngày đáo hạn đã hoàn thành. - Điều này rất khó chịu phải không??

Có rất nhiều tình huống mà email đã trở thành một phần không thể tách rời của cuộc sống của chúng ta vì chúng có mục đích cập nhật thông tin chính xác cho người dùng.

2. Các kịch bản thực tế phổ biến và điểm xác nhận cho email

Các điểm xác nhận trong kiểm thử tính năng của email khác nhau tùy từng loại, và từ ứng dụng đến ứng dụng. Thông thường tất cả các Email phải được xác nhận hợp lệ cho email mẫu (bao gồm logo ứng dụng, tên ứng dụng, địa chỉ người dùng, Nội dung cuối trang - Bản quyền, Thông tin hỗ trợ khách hàng), ngày tháng và thời gian cho các múi giờ khác nhau.

Ở đây, chúng ta sẽ thảo luận về một số loại Email phổ biến mà hầu hết mọi người đều biết (tất cả các điểm xác nhận được đưa ra dưới đây là cơ bản mà tester phải thực hiện trong khi kiểm tra Email của ứng dụng).

2.1. Email kích hoạt

Khi người dùng đăng ký vào ứng dụng lần đầu tiên, họ cần phải kích hoạt tài khoản bằng cách nhấp vào liên kết kích hoạt được gửi bằng Email. Điều này cũng xác minh địa chỉ email đã cho của người dùng là hợp lệ và có thể truy cập được.

Các điểm kiểm tra như sau: Link/ nút kích hoạt - Khi click vào thì cần:

• Đưa người dùng đến trang ứng dụng tương ứng với tài khoản người dùng đã đăng nhập.
• Tài khoản email của người dùng sẽ tự động được xác minh nếu trang ứng dụng được truy cập thành công qua email.
• Thời gian - Kiểm tra khoảng thời gian mà liên kết được nhấp vào và xác nhận trong khoảng thời gian đã chỉ định.
• Hãy thử kiểm tra sau khoảng thời gian chỉ định - Tài khoản không được kích hoạt và email vẫn không được xác nhận.

2.2. Link đặt lại mật khẩu:

• Nhấp vào link đặt lại mật khẩu sẽ đưa người dùng đến trang của ứng dụng tương ứng để đặt lại mật khẩu.
• Một số ứng dụng sẽ yêu cầu người dùng trả lời câu hỏi bảo mật trước khi hiển thị trang đặt lại mật khẩu và một số sẽ có câu hỏi bảo mật được tích hợp với trang đặt lại mật khẩu và một số sẽ không có tính năng này.
• Nếu người dùng đặt lại mật khẩu thành công, liên kết trong email đặt lại mật khẩu đã nhận được sẽ bị vô hiệu hoá và không hoạt động.
• Nếu người dùng hủy đặt lại mật khẩu, liên kết trong email quên mật khẩu đã nhận được sẽ vẫn hoạt động được.
• Thời gian - Kiểm tra khoảng thời gian mà liên kết được nhấp vào để thiết lập lại mật khẩu.
• Nhấp vào liên kết và đặt lại mật khẩu thành công trong khoảng thời gian xác định.
• Hãy thử nhấp vào liên kết sau khoảng thời gian chỉ định - Liên kết phải bị vô hiệu hóa và hết hạn.

2.3. Các thông báo về ngày đến hạn

Email này là để nhắc nhở người dùng về việc thao tác trong một số ngày cụ thể. Đó thường là hóa đơn thanh toán, thực hiện thao tác đối với các mục đang chờ xử lý (ví dụ: chấp nhận hoặc từ chối lời mời đến một số sự kiện trong một số ngày cụ thể, gửi biểu mẫu, v.v ...).

Các điểm xác nhận như sau:

• Số ngày đến hạn / Ngày đáo hạn
  • Nếu email thông báo về một số ngày đến hạn, số đó phải là 0 hoặc lớn hơn, 0 ngày có nghĩa là ngày hiện tại là đến hạn, không được hiển thị là số âm. Nếu email thông báo về Ngày đến hạn thì ngày phải là ngày hiện tại hoặc tương lai.
• Loại hành động:
  • Kiểm tra loại hành động được yêu cầu. Cần phải nêu rõ rõ loại hành động mà người dùng phải thực hiện. Có thể là thanh toán hóa đơn, bài nộp, phản hồi, v.v.

2.4. Thông báo quá hạn

Email này thông báo cho người dùng về ngày đáo hạn đã trôi qua. Điều này thường là để thông báo cho người sử dụng rằng họ đã không thực hiện hành động đúng hạn.

• Số ngày quá hạn
  • Kiểm tra xem số ngày quá hạn phải là một hoặc nhiều. Không bao giờ được là số 0 hoặc số âm.
• Tần số
  • Một số ứng dụng sẽ có điều khoản để tùy chỉnh email quá hạn được gửi hàng ngày / hàng tuần / hàng tháng, một khi ngày đáo hạn đã trôi qua, cho đến khi người dùng hoàn tất hành động. Một số ứng dụng khác thì thông báo chuẩn được gửi chỉ một lần chỉ sau ngày hết hạn đã trôi qua.

2.5. Subscriptions - Đăng ký

Chức năng thay đổi theo yêu cầu của người dùng. Người dùng có thể chọn một trong số các lựa chọn đăng ký hàng ngày, hàng tuần, hàng tháng. Chức năng này thường sử dụng trong bản tin, cập nhật, phiếu mua hàng, v.v ...

• Tần số
  • Email phải được gửi theo lựa chọn người dùng cho thuê bao. Nếu người dùng chọn hàng ngày, sau đó gửi email subscription chỉ được gửi một lần trong một ngày. Nếu hàng tuần, thì một tuần gửi 1 lần. Và tương tự ...
• Liên kết
  • Bất kỳ liên kết nào trong email phải chuyển đến trang tương ứng của ứng dụng. Nếu email được cập nhật, thì liên kết sẽ chuyển hướng đến trang nơi bản cập nhật sẽ được hiển thị. Nếu email cho Offer, thì liên kết phải được chuyển hướng đến trang Offers của ứng dụng. Nó hoàn toàn phụ thuộc vào loại subscription mà người sử dụng đã đăng ký.

2.6. Biểu mẫu

Email này dành cho người dùng cung cấp phản hồi thông qua các biểu mẫu / liên kết tới biểu mẫu. Các điểm cần xác nhận như sau:

• Liên kết
  • Liên kết trong email nên chuyển hướng người dùng đến trang gửi mẫu của ứng dụng theo kiểu người dùng được yêu cầu phải gửi Khi đã gửi, nhấp vào liên kết một lần nữa sẽ thông báo cho người dùng rằng biểu mẫu đó đã được gửi. Không nên cho phép người dùng gửi lại biểu mẫu.

2.7. Email xác nhận

Email này để thông báo cho người dùng về xác nhận của hành động được thực hiện. Đây thường là xác nhận đặt chỗ, xác nhận đơn đặt hàng, xác nhận truy vấn, v.v ...

Các điểm xác nhận như sau:

• Chi tiết xác nhận:
  • Mã đơn đặt hàng / mã đặt chỗ phải chính xác và khớp với mã được hiển thị trong giao diện người dùng. Vì nó là định danh để theo dõi các đơn đặt hàng / đặt chỗ, mã này là duy nhất (được xác nhận trong backend - DB) trong suốt ứng dụng.
  • Cùng với mã số thì nó cũng cần được xác nhận cho các loại đặt hàng, thông tin người dùng, địa chỉ thanh toán, địa chỉ vận chuyển, và giá cả. Tất cả thông tin phải chính xác tương ứng như những gì người dùng đã cung cấp trong màn hình ứng dụng.
• Liên kết:
  • Liên kết trong email phải chuyển hướng người dùng đến trang chi tiết đơn hàng trong giao diện ứng dụng của người dùng . Cần có kết hợp chính xác giữa thông tin trong Email và giao diện ứng dụng của người dùng.

2.8. Email với tệp đính kèm

Người dùng nhận được email với tệp đính kèm. Các tệp đính kèm có thể được bảo vệ/ không được bảo vệ bằng mật khẩu. Đây thường là các thông báo từ các lĩnh vực tài chính, Thỏa thuận Giấy phép Người dùng để tham khảo, Điều khoản & Điều kiện để tham khảo, v.v.

Các điểm xác nhận như sau:

• Loại tập tin đính kèm
  • Các loại tệp hợp lệ phải được gửi dưới dạng tệp đính kèm. Tất cả các tệp đính kèm đang mở sẽ được quét virus trước khi tải về/ mở tệp. Điều này lại có thể được tùy chỉnh ở cấp ứng dụng ở phần phụ trợ, như quét virus chỉ được thực hiện khi tải xuống, hoặc khi mở, hoặc cho cả việc tải xuống và mở.
  • Các tập tin đính kèm được bảo vệ bằng mật khẩu sẽ được tải xuống mà không yêu cầu mật khẩu. Nhưng trong khi mở nó từ chính email hoặc mở các bản sao đã tải xuống thì luôn luôn cần mật khẩu.

3. Các loại email

Email có thể là HTML (đầy màu sắc và hấp dẫn đối với người dùng, người dùng quan tâm đọc toàn bộ email) hoặc Plain Text (chỉ một đoạn văn bản).

HTML là những trang ưa thích nhất và thường được đặt làm mặc định trong hầu hết các ứng dụng ở backend. Nếu được yêu cầu, ứng dụng có thể chọn gửi email văn bản Plain đến người dùng, một lần nữa điều này đòi hỏi phải thay đổi ở backend.

3.1. Kích hoạt gửi email:

Email có thể được gửi trực tiếp như là tóm tắt / gửi đồng loạt. Email gửi trược tiếp được kích hoạt bởi hành động của người dùng. Đây thường là các email kích hoạt, đặt lại mật khẩu email, email xác nhận, v.v. nghĩa là các email này được kích hoạt dựa trên cài đặt ở backend của ứng dụng.

Điểm Kích hoạt Email sẽ được xác định để kích hoạt tại thời điểm cụ thể (ví dụ như ngày thứ 3 hàng tuần lúc 12:00 sáng). Đây thường là các thông báo từ các lĩnh vực tài chính (Sao kê ngân hàng), thông báo ngày đến hạn cho hóa đơn, thông báo quá hạn, đăng ký, v.v.,

3.2. Boundbacks

Một tình huống rất phổ biến đó là email bị trả lại khi được gửi đến địa chỉ email không hợp lệ. Thông thường sẽ xảy đối với những địa chỉ email bị hủy kích hoạt / không còn sử dụng hoặc không tồn tại.

3.3. Kiểm tra phạm vi đa ngôn ngữ

Khi ứng dụng hỗ trợ nhiều ngôn ngữ, thì email cũng như vậy.

Tất cả các email gửi đi phải là ngôn ngữ của người dùng đang sử dụng trên ứng dụng. Nếu người dùng đã đặt tiếng Anh làm ngôn ngữ mặc định, thì tất cả các email gửi cho họ phải bằng tiếng Anh. Nếu ngôn ngữ mặc định của người dùng là tiếng Pháp, thì tất cả các email được gửi cho người đó phải bằng tiếng Pháp. Ngôn ngữ của người dùng có thể là cài đặt một lần hoặc có thể thay đổi theo thời gian và khi được yêu cầu, tùy thuộc vào cài đặt của người dùng trên ứng dụng.

Các điểm xác nhận hợp lệ cho việc kiểm tra đa ngôn ngữ trong Email như sau:

• Chủ đề
• Cơ thể của Email
  • Nội dung
  • Tên button/ link
  • Thông tin bản quyền
  • Chi tiết hỗ trợ khách hàng

3.4. Tiêu chuẩn / Tuỳ chỉnh email

Email có thể được tùy chỉnh ở backend.

Ví dụ: Một số ứng dụng hỗ trợ người dùng tùy chỉnh email khi chúng được gửi đi. Người dùng có thể thay đổi chủ đề, nội dung của email sao cho thuận tiện hoặc nhằm mục đích dễ dàng nhận biết. Trong trường hợp này, tester phải tiến hành kiểm tra kỹ lưỡng vì cơ hội xâm nhập là rất cao.

4. Kết luận

Kiểm thử tính năng email là một phần quan trọng vì hầu hết các thành phần của ứng dụng được tích hợp với chức năng này.

Cần có sự hỗ trợ của cả team để kiểm tra toàn bộ tính năng email của ứng dụng. Cần phải có kế hoạch tốt trước khi bắt đầu thử nghiệm thực tế trong khi thử nghiệm từng thành phần liên quan.

Kiểm tra tính năng email nên có các trường hợp thử nghiệm riêng biệt được viết cho mỗi loại email bao gồm tất cả các khía cạnh để kiểm tra. Điều này cần được thực hiện trong tất cả các loại thử nghiệm kiểm thử hồi quy, kiểm thử Adhoc, kiểm thử Localization, kiểm thử UAT, và kiểm thử production.

Bất cứ điều gì sai sót trong email trên thực tế sẽ để lại ấn tượng không tốt về ứng dụng của người dùng. Vì vậy, kiểm thử email là rất quan trọng và rất cần thiết trong kiểm thử phần mềm.

Bài viết được tham khảo và dịch từ nguồn http://www.softwaretestinghelp.com/email-validation-testing/