TC for mobile

No.

Module

>>> Sub-Module

>>>Test Case Description

>>>Expected Result

1

Installation



Verify that application can be Installed Successfully.

Application should be able to install successfully.

2

Uninstallation



Verify that application can be uninstalled successfully.

User should be able to uninstall the application successfully.

3

Network Test Cases



Verify the behavior of application when there is Network problem and user is performing operations for data call.

User should get proper error message like “Network error. Please try after some time”

4





Verify that user is able to establish data call when Network is back in action.

User should be able to establish data call when Network is back in action.

5

Voice Call Handling

Call Accept

Verify that user can accept Voice call at the time when application is running and can resume back in application from the same point.

User should be able to accept Voice call at the time when application is running and can resume back in application from the same point.

6



Call Rejection

Verify that user can reject the Voice call at the time when application is running and can resume back in application from the same point.

User should be able to reject the Voice call at the time when application is running and can resume back in application from the same point.

7



Call Establish

Verify that user can establish a Voice call in case when application data call is running in background.

User should be able to establish a Voice call in case when application data call is running in background.

8

SMS Handling



Verify that user can get SMS alert when application is running.

User should be able to get SMS alert when application is running.

9





Verify that user can resume back from the same point after reading the SMS.

User should be able to resume back from the same point after reading the SMS.

10

Unmapped keys



Verify that unmapped keys are not working on any screen of application.

Unmapped keys should not work on any screen of application.

11

Application Logo



Verify that application logo with Application Name is present in application manager and user can select it.

Application logo with Application name should be present in application manager and user can select it.

12

Splash



Verify that when user selects application logo in application manager splash is displayed.

When user selects application logo in application manager splash should be displayed.

13





Note that Splash do not remain for fore than 3 seconds.

Splash should not remain for fore than 3 seconds.

14

Low Memory



Verify that application displays proper error message when device memory is low and exits gracefully from the situation.

Application should display proper error message when device memory is low and exits gracefully from the situation.

15

Clear Key



Verify that clear key should navigate the user to previous screen.

Clear key should navigate the user to previous screen.

16

End Key



Verify that End Key should navigate the user to native OEM screen.

End Key should navigate the user to native OEM screen.

17

Visual Feedback



Verify that there is visual feedback when response to any action takes more than 3 seconds.

There should be visual feedback given when response time for any action is more than 3 second.

18

Continual Keypad Entry



Verify that continual key pad entry do not cause any problem.

Continual key pad entry should not cause any problem in application.

19

Exit Application



Verify that user is able to exit from application with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.

User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.

20

Charger Effect



Verify that when application is running then inserting and removing charger do not cause any problem and proper message is displayed when charger is inserted in device.

When application is running then inserting and removing charger should not cause any problem and proper message should be displayed when charger is inserted in device.

21

Low Battery



Verify that when application is running and battery is low then proper message is displayed to the user.

When application is running and battery is low then proper message is displayed to the user telling user that battery is low.

22

Removal of Battery



Verify that removal of battery at the time of application data call is going on do not cause interruption and data call is completed after battery is inserted back in the device.

Removal of battery at the time of application data call is going on should not cause interruption and data call should be completed after battery is inserted back in the device.

23

Battery Consumption



Verify that application does not consume battery excessively.

The application should not consume battery excessively.

24

Application Start/ Restart



1. Find the application icon and select it 2. “Press a button” on the device to launch the app. 3.Observe the application launch In the timeline defined

Application must not take more than 25s to start.

25

Application Side Effects



Make sure that your application is not causing other applications of device to hamper.

Installed application should not cause other applications of device to hamper.

26

External incoming communication – infrared



Application should gracefully handle the condition when incoming communication is made via Infra Red [Send a file using Infrared (if applicable) to the device application presents the user]

When the incoming communication enters the device the application must at least respect one of the following: a) Go into pause state, after the user exits the communication, the application presents the user with a continue option or is continued automatically from the point it was suspended at b) Give a visual or audible notification The application must not crash or hung.

[note for me] TC for ATM

1) Insertion of ATM card with success.
2) Incorrect ATM Card Insertion – Leading to unsuccessful operation.
3) ATM Card of an invalid account – Leading to unsuccessful operation.
4) Successful feeding of ATM PIN Number.
5) Incorrect ATM PIN Number feeding 3 times - Leading to unsuccessful operation.
6) Selection of language of operation, with success.
7) Selection of Type of Bank Account with success.
8) Incorrect Bank Account type Selection in respect to the type of ATM Card inserted - Leading to unsuccessful operation.
9) Selection of withdrawal option with success.
10) Selection of Amount to be withdrawn with success.
11) Incorrect Currency denominations - Leading to unsuccessful operation.
12) Successful completion of withdrawal of money.
13) Amount to be withdrawn in excess of the available Balance - Leading to unsuccessful operation.
14) Shortage of Currency Notes in ATM - Leading to unsuccessful operation.
15) Amount to be withdrawn in excess of the daily withdrawal limit - Leading to unsuccessful operation.
16) ATM link to the Bank Server not available at the moment - Leading to unsuccessful operation.
17) Clicking of the Cancel button after inserting the ATM card - Leading to unsuccessful operation.
18) Clicking of the Cancel button after feeding the ATM PIN Number - Leading to unsuccessful operation.
19) Clicking of the Cancel button after selection of language of operation - Leading to unsuccessful operation.
20) Clicking of the Cancel button after selection of Type of Bank Account - Leading to unsuccessful operation.
21) Clicking of the Cancel button after selection of Amount of withdrawal - Leading to unsuccessful operation.
22) Clicking of the Cancel button after feeding the amount to be withdrawn - Leading to unsuccessful operation.

note for me [mind map]

[annotation] Make a Test Plan by JMeter tool

Make a Test Plan by Jmeter tool [11/11/2014]

Before testing a project, we’re make a Test Plan which is support Jmeter. We have to note Thread groups, Listener, Assertions, Sample generating controllers, logic controllers, etc

Remember: one Test Plan have a thread group at least

Explain keyword below

1.      Samplers: Elements that send request to servers; there are some request: HTTP/ HTTPS, FTP, SOAP, JDBC, “java”

2.      Listeners: there’re collected results of your’s Run test

3.      Timers : Being use to which insert (độ trễ) giữa những request “to have make your’s test “hiện thực hơn” more real *.*

4.      Logic Controllers: Nếu: những request được định nghĩa trong Test Plan của bạn sẽ thực thi  phụ thuộc vào 1 vài logic thì bạn cần đền Logic controllers ( if requests are define in your’s Test Plan that will execute and depend on some logic then you need Logic Controllers. We’re appropriate with if-then-else structure and loop in java or whatever (bất cứ) programming language other.

5.      Configuration Elements: that work with Samplers anyway (bằng cách) insert/ update information general with requests

6.      Assertions: permiting you test ( nếu phản ứng/ responses bạn lấy chứa dữ liệu mong đợi hay nhận trong phạm vi/ area thời gian đã định)

Tutorial set up and testing

Step 01: Running Jmeter file

Step 02: Create a Thread group by right-click mouse Test Plan element => selected “ADD” choose Thread group option ( next step, we’re assume number of count users and users quantity are repeat – giả lập SL user và SL lặp cho test plan)

Viewing the screen was create below:

Maybe a number of attributes setting/ establish below:

1.      Name: we can create any of name for Thread group

2.      Number of Threads: we can input more threads to have assume. Each users independent ( được đại diện bởi mỗi Thread). So we wanna assume with five users then we have to input data for it

3.      Ramp-Up Period: (cho biết time đưa ra bởi Jmeter để tạo tất cả những Thread cần thiết. Ex: If we establishs about ten minutes for five Threads then Jmeter will be perform in ten minutes to which creates five Threads. Moreover, 

[annotation about security]

- About public key and private key [newsfeed]

1. Using public key which to comfirm about  a signature
2. Using private key that to create a signature ( ký 1 thông điệp)

-----------------------------------------
1. Tổ hợp khóa dùng chung chỉ có 2 người biết

Thuật toán mã hoá Quy Ước

[discussion] Agile design - the ultimate test case tool

[annotation]

[http://tectonic.marketing/]

[An toàn an ninh mạng] Cách thức làm việc của public key và private key

Quan sát hình ảnh học nhanh hơn là chữ :3 [note]

Note for me ( try to learn en and this work) :\

which tool is better for performing regression and functional testing for banking domain?

"the main question is: is it the database to test or is it an client application to test?"

                   ***

1.

if the databases are tested then SQL queries saved to use later are good in regression and functional testing

however if we are talking about some app(ie: brower app to use later are good in regression and what can be automated is good:

Selenium for WebApps, TestComplete or something similar for the rest.

2. 

it's not easy to say but...

as we know - all the banks works on database which have table for accounts, deposits, customers, charges, etc

everything what is made in a bank is written in a database, so..

if we want to see if some charges are taken from account 1234 we can see in the table where have account history with account_nr = 1234 and date = [date of charges]

this is testing uusing SQL queries with database

the same problem with app used by worker of the bank

we must find account 1234 (most cases by the customer), then go into the history of this account and find the history in a day [date of charges] to see is it ok or not.

when we know we will recently check it we can save the SQL query for the later use (database make automatic script (ie. with selenium IDE) which will look for the result automatically.

practice with on discuss

search and research Parasoft SOAtest & Virtualize ( this's a financal organisations for API testing which has been recognised by Wealth & Finance International magazine's Wealth & Money Management Awards 2014 and being named Most Innovative Software Vendor).

Agile (Agile Software Development) - Ngắn gọn súc tích

Agile (Agile Software Development) - Cách thức phát triển phần mềm linh hoạt

Quan điểm Agile trong lĩnh vực người làm test (tester):

Khi tìm hiểu về Testing trong Agile, bạn thường đi vào tìm hiểu chi tiết cụ thể luôn như: 

- Agile áp dụng kỹ thuật gì?

- Sử dụng phương pháp ra sao?

- Cần tool gì?

- Hoạt động như thế nào?

- .....

Bước này rất quan trọng trước khi bước vào tiến hành 1 dự án, Tester cần bắt buộc phải nắm rõ, ít nhất là các đầu mục câu hỏi trên. Nếu không chúng ta sẽ gặp nhiều khó khăn trong quá trình làm việc.

Lướt qua 1 vài thông tin chính của Agile:

Agile sử dụng các phương pháp luận phát triển dựa trên nguyên tắc phát triển phân đoạn lặp (iterative) và tăng trường (incremental)

Agile sử dụng cách lập kế hoạch thích ứng (adative planning), phát triển và chuyển giao theo hướng tiến hoá

Agile sử dụng các khung thời gian ngắn và linh hoạt để dễ dàng phản hồi lại với các thay đổi trong quá trình phát triển

Agile đóng góp trong cách thức làm việc/ quản lý/ sản xuất ... ở các ngành sản  xuất (manufacturing), dịch vụ (services), sales, marketing, giáo dục (education),....

"Hiện tại, Agile đang là "mốt", là xu hướng chủ yếu của các công ty phần mềm. Bên cạnh 1 RUP (Rational Unified Process) đã từng là quy trình phổ biến nhất của các công ty trong khoảng vài 3 năm trước.

Nhưng như thế nào là Agile? Vận dụng Agile trong Testing như nào cho hiệu quả thì vẫn đang là vấn đề đau đầu cùa nhiều công ty

Agile hiệu quả, chính xác. Nếu không hiệu quả thì nó không thể thay thế hay kế thừa RUP được, và được sử dụng như 1 trào lưu mới bây giờ.

Nhưng có phải lúc nào cũng vận dụng Agile cũng là hiệu quả? Cũng chưa chắc! Đó là con dao 2 lưỡi, kể cả trong phạm vi dự án nói chung và công việc Testing nói riêng!" - trích đoạn chia sẻ của bạn winter ;)

>>> Agile dưới quan điểm của Tester

Tác động của Agile lên đội phát triển phần mềm là "khổng lồ". Với đội Test thì điều này còn rõ ràng hơn, đặc biệt đối với dự án trong quá trình phát triển gặp nhiều vấn đề.

Việc chuyển sang Agile có nhiều điểm tích cực, tuy nhiên cũng không ít điểm chúng ta cần xem xét. Vì thông thường lý thuyết luôn màu hồng, còn từ lý thuyết sang thực tế là cả 1 chặng đường.

Agile hay và linh hoạt nhưng nên áp dụng thực tiễn vào công ty bạn như thế nào, vì mỗi công ty có một phương thức áp dụng riêng, không phải công ty nào cũng giống nhau mặc dù củng là Agile

Trước khi làm việc với Agile thực sự phải nắm rõ các khái niệm, và hiểu 1 cách đúng đắn về Agile hay quản lý Developer code như thế nào

Agile có nhiều cách thức thực hiện khác nhau với nhiều người.

Tester cần làm gì để chuẩn bị cho Agile?

Các khía cạnh tập trung ảnh hưởng trực tiếp lên Software Testing?

Giải đáp như sau:

hầu hết các tài liệu hướng dẫn và các bài giảng ngày nay về Agile, Scrum & XP tập trung vào các hoạt động cụ thể (practice) Ví dụ như phương thức TDD (Test Driven Development), Sprint Retrospective và Estimate User Story, nhưng với nội dung bài viết này tôi tập trung vào Software Testing (test theo truyền thống) chứ không theo nghĩa testing acceptance trong User Story

Thứ hai: Cần tập trung và các yếu tố mà Agile thường bị bỏ qua ví dụ như: Tính năng động của Team (Dynamic), khả năng tự định hình ( Seft-forming), Tự định hướng (Seft-Directing), và Tool

Agile: Những điểm tích cực của mô hình

 - Tăng tính tương tác của team member

 - Tập trung nhiều hơn vào việc sắp xếp theo vị trí vật lý

 - Bảo vệ hay tránh được các trường hợp bị ngắt quãng (interupt)

Không gì là hoàn hảo tất cả được. Ngoài những điểm tích cực thì Agile có 1 số hạn chế sau: 

 - Overtime

 - Thiếu tính chất đóng kín (hay kết thúc)

Agile xử lý các vấn đề này không giống như bất kỳ mô hình nào trước đó. Trước Agile chưa có bất kỳ mô hình quản lý dự án nào được phát triển dựa trên việc Team ngồi gần nhau, tập trung xử lý một tập các Task một cách thông minh, thống nhất, và họp daily như vậy.

2.Agile không có nghĩa là nhanh hơn!

Agiletập trung vào yếu tố con người và tính tương tác nhiều hơn là vào Quy trình và Tool, làm việc theo từng bước xác định và dựa trên các team Tự quản lý.

Những người làm việc trong các dự án Agile thường cần hài lòng hơn với công việc của họ, làm theo từng bước xác định và cảm thấy tốt hơn về chất lượng của sản phẩm. Nếu không, có nghĩa là công ty bạn không theo đúng con thuyền Agile. Nếu Agile tại công ty bạn tập trung vào Tool, hay triển khai một tập hợp các Tool nhiều hơn là các yếu tố vừa đề cập, có nghĩa là có điều gì đó chưa đúng ở đây.

3.Tester thường được đưa ra nhiều ý tưởng và các hoạt động trong một thời gian dài:

- "Unit Testing thực sự là tốt - chúng ta nên triển khai nhiều hơn!". CÁc Testers sẽ nói điều này trong bao lâu?

- "Chấp nhận sự thật là chúng ta luôn luôn chấp nhận những thay đổi của dự án dù ở giai đoạn cuối hơn là giả bộ như chúng ta không chấp nhận".

- "Tôi (chính thức trước đây cũng là một QA) không làm nên chất lượng - Chất lượng đến từ tất cả chúng ta!"

- "Các bạn sẽ ngừng gọi chúng tôi là QA Team"

- "Chúng ta cần automate nhiều hơn nữa"

- "Chúng ta cần thiết kế code để sao cho có thể test được"

Thực tế là Test Team đã từng biết đến rất nhiều kinh nghiệm tốt trong việc triển khai Agile trong một thời gian dài. Trong một số trường hợp, sử dụng Agile có thể không hề ảnh hưởng gì tới cách thức làm việc của Tester truyền thống. Bản chất của việc Testing thì có thể không thay đổi nhiều. Nhưng cách thức các dự án được quản lý như thế nào thì lại thay đổi khá nhiều

Với Tester:

Thứ nhất: Agile không có nghĩa là nhanh hơn! Đó không phải là Scrum, XP (Xtreame programming) hay Lean.

Agile không phải là 1 Quy trình phát triển phần mềm (SDLC - Software Development Life Cycle), hay dùng để quản lý 1 dự án.

Bài viết trên mình tổng hợp từ nhiều nguồn từ hanoiscrum và 1 chút hiểu của mình. Rất vui khi Bạn đọc góp ý bổ sung để trao đổi kiến thức nhiều hơn. Thank for reading