The testing phase can be called the most negative of the entire process of creating an application. Sometimes it takes as much, if not more, than it takes for the development itself. During testing, a lot of conflicts arise between the customer and the contractor.

The client may be angry with the programmer: he, they say, is a fool, does not see obvious errors. On the other hand, he may consider it a bug that the programmer did not put into the final product things that were obvious to him, although they were not in the technical specification. In his opinion, it was “clear and so”, but the developer did not know this - and therefore did not add.

If you are a conditional Sberbank, that it is almost impossible to run the test by hand due to the amount of functionality, then overpaying 50% of the development cost for this is normal. If a startup, where 500-700 thousand rubles are pledged for MVP, then getting another 200, so as not to check with your hands, seems like excessive wastefulness - it is more profitable to invest this money in promotion.

If you go for the second option, then you will have to deal with manual testing - a process in which the developer himself (and you along with him) does all the testing. Such testing can drag on for a long time: first the programmer will find bugs, then you will find those that he missed, then he will notice others again, then new ones will appear, and so on many, many times.

→ Mandatory checklist of checks

Added to every feature run and regression run. It can be extended individually on a project.

Change font size from device settings

Change theme from device settings

Change language from device settings

Change time from device settings

Using custom Android keyboard (specifically for fields and search bar)

Incoming call/SMS during flow feature

Device Rotation

Exit the application by double "Back" on Android

Close the app and start again

Minimize the application while waiting for a response to a request

Turn off the Internet while waiting for a response to a request

Do not forget about checking for subscroll to invalid fields if:

There are multiple fields or different elements on the same screen that could potentially not fit to be displayed with an error if a value is not entered successfully

These fields or elements are validated by a button

Inserting invalid values ​​into a field

Field size limit

Technique of Equivalence Classes and Boundary Values

Empty field (if required)

→ Element operation logic

Name examples

General actions with the element and its reaction to them

Examples:

→ Opening a certain kind of keyboard when a field is activated

→ Field expansion when filling

→ Putting the cursor at the end of the filled line when the field is activated

→ Field validation on defocus

→ Field validation on button click

→ Mask (for a phone number, for example)

→ Correct activation/deactivation of the checkbox/radio button

→ Looped carousel / Unlooped carousel