The first thing to start with when accepting a job is to open the TK. If you want something, but this is not in the TOR, these are just “wishes” that do not apply to errors. But if it is written, but does not work or does not work correctly, this already needs to be corrected.

I will give an example of one error. Here is a description of the authorization screen in the application for the sale of flowers.

I share information gained from my own experience: I myself accept applications from my programmers using manual testing - most often we launch MVP versions for startups, and there usually no money is allocated for automatic testing in the first versions.

So, let's move on to how best to check the finished application with your programmers, especially if you work not with studios, but directly with private programmers. I'm talking about the application, because this is my specialty, but the principle applies to websites as well.

What gives the structure of software checks

clarity,

transparency,

uniformity

the ability to provide the necessary coverage,

the possibility of rapid modification.

One of the significant additional advantages is the use of this approach in autotesting. For example, this is a must-have when working with Flutter inside widget tests. Every element in Flutter is a widget (whether it's a screen or an element): widget tests map nicely to our tests, which cover each element or screen in detail.

The article describes only component checks - for each element. They come in handy at the beginning of testing: such a structure covers more elements, provides confidence in the quality of the product.

When QA works with sanity or smoke testing, it makes no sense to spend time checking each element in detail. Scenario checks are needed that will cover the entire user path. We will talk about how to work with scenario checks in the next article.

Additional software checklist

Added to every final run. It can be extended individually on a project.

Run the app without internet access at all

Pressing the block button when a splash is shown

Launching and immediately minimizing the application

Minimizing the application while displaying the Apple/Google/Samsung/Huawei Pay system payment window

Display on tablets (in compatibility mode if no tablet support)

Auto-substitution of code from SMS (sometimes it is the default in iOS projects)

Application operation when push notification of another third-party application (Facebook message, Twitter, and so on)

Application operation after alarm / timer / sms / other system application

Operation of an open application after unlocking the application

How a minimized app works after unlocking an app

Application operation when a low battery message is reported

Application operation while charging

Application operation after disconnection from charging

App behavior while playing music

Application operation with 3G / 4G mobile Internet / weak Internet connection

Working with the picture-in-picture feature (if supported)