To become a tester, it is not necessary to spend 4-6 years at a university. You can get an up-to-date education on your own by finding information on Google, or at specialized courses, which is much faster and more convenient. Training with a teacher will take approximately 1 year.

The employer does not care how old you are, and in what specialty you worked before. The main thing is your professionalism and practical skills.

It will be great if you manage to get a job at the start in an IT company, where you will gain experience under the guidance of mentors. This will give a powerful impetus to the development

More about this source textSource text required for additional translation information

Send feedback

Side panels

The goal of the tester is a digital product that will not give errors, no matter what the user does. There is also an element of psychology here: a tester needs to be able to think like a user who is far from IT, to put himself in his place. Therefore, companies value beginners: they notice such details that professionals do not see from the height of experience.

Pros and cons of this approach to autotests

Pros

The tests are both native and cross-platform. Active framework support.

Access to the architecture and entities allows you to set locators for the necessary elements yourself,

without involving anyone.

Changes to files in the mobile application are always visible to the autotester. Developers also see

component and scenario tests and can fix their own bugs in time.

Cons

The new framework is updated on its own clock and is not always in sync with native tools. In fact, only

native tools for autotesting do not have this minus. But Calabash or Appium has it.

I would like to note that the Flutter community makes contact without any problems. They respond

quickly and fix issues.

The tests are inside the mobile application and are completely dependent on it. If the application breaks,

the tests will break: for example, if the version of the package has been updated and the dependencies

are broken.

Changes in the code force you to constantly build (for E2E).

Every element in Flutter is a Widget, so testing Widget elements maps to component tests that cover

each element or screen in detail. Entire user scripts map well to E2E tests.

I think it is now clearly clear why it is more convenient to write both types of tests for the QA department:

all scripts are needed for manual activities. Widget and E2E tests are capable of facilitating the work of

manual testing, such as regression or full testing.

Benefits of our strategy

Stable quick Widget tests. This allows them to be run on pull-requests and prevents bugs from getting

into builds for testing. They are easy to maintain: you can always see if the test breaks when you change

the code in the mobile application.

E2E tests cover user scenarios. They can be run at night and make life easier for a manual tester by

covering sanity or smoke runs.

Component and integration testing. Two types of tests help to work with mock data and with a real

server in one project. This approach allows you to measure the coverage of code, scripts and technical

requirements.