At the beginning of the project, when hopefully we have already decided for which group of end users we want to create an application, we are choosing tools with which we would like to create our software. Usually the team is spending a lot time deciding how the architecture of the app will look like. If we should go with micro services, use graphQL or REST for the API, how the DB will look like and how the CI/CD pipeline should be defined. But if we will ask about testing stuff there then usually the only thing that is discussed is the question if we need automated tests and if yes then what framework we will use for test automation. And that is the begging of big QA problems.

First of all: we will always need automated tests when we are considering to work on a serious project. They are extremely important. We have to cover the main functionalities with them. To minimise the risk and to do the regression tests for us. We need automated unit tests, automated integration tests (most of our tests should be the integration tests, as here we have the best ratio in terms of work needed and stuff covered) and automated E2E tests. Automated tests are also the best form of the documentation. With well written tests we can quickly check what is that part of the app doing just by looking on the tests. Second thing which is quite often forgotten on such early stage is performance testing. We will definitely need to check that to make sure that our users will not get stuck on loading screens.

And the above decisions have consequences about which we have to say on that early stage of the upcoming project. For automated tests we will need an open API (it can be available only on the testing environment) or an ORM to be able to prepare data for our E2E tests and our performance tests. Why? Because if we will forget about that then our tests will be extremely long. Without the ability to prepare data directly through API or ORM, the tests will have to contain additional steps to prepare the data. Which means that the tests will be very long, they will be hard to read and understand and in the end they will be very hard to maintain. We need tests that are short and quick, that are checking concrete feature (and only that feature), and that are easy to maintain. That will allow us to minimise the time needed for our automated tests, thanks to that we will spare a lot of money cause the CI builds will be quicker. We will also need testing environments which will be copies of prod envs (thanks to that we will never had to do the prod tests). And we (QA engineers) have to communicate all of the above loudly and clearly! Without that early steps we wouldn't be able to introduce minimalistic QA in our project.

Todays observation section:

The moon is totally awesome today. Enormous and shiny. With the clouds on the dark sky and with the reflection of it all in the river water, the view is totally magnificent! 🌕☁️🏞️

Brought to you proudly by the /ᐠ｡ꞈ｡ᐟ\ and the ʕ•ᴥ•ʔ

Prev	Next