And again about software testing

In recent years it is becoming less and less companies where you can meet dedicated test teams working with different development teams under the same product. This is most likely due to financial reasons because there are not so many companies who can afford to keep a team dedicated exclusively to testing and everything related to it. Nowadays a majority of software development companies work using Agile & Scrum, where all team members (software engineers, architects, programmers, analysts, QA experts, testers and etc.) are sitting together and doing their best to meet the goals of the sprint. In such projects testers, in principle, may know nothing about work of their colleagues from other teams because their areas of responsibilities intersect not very often or do not intersect at all. It can work fine until we are not starting talking about organizing automation testing and everything related to it: planning, design, implementation of frameworks and tests, support. I

I had to work in different projects and different teams with completely different approach to automation and places of storage of UI automation tests and the most common are: Keep UI automation tests in the same repository with code of the application Keep UI automation tests in different repositories saving the link between them (e.g. maven pom.xml) Don’t store automation in the repository in general I don’t want to talk about the last approach since it is NOT a correct way of working. Let’s describe pros and cons of the first two.  Keep UI automation tests in the same repository Pros You don’t need to update the link between versions of code and tests Higher standards to quality of the automation since failures are highly visible and very sensitive Developers will become aware if test are breaking after applying application code changes. Easier to involve developers in test development and maintenance  Easier to add test execution to CI/CD pipelines Cons If you want

Why do you write automated tests? Many people say "to find bugs" but it is not true. Tests are not looking for bugs. They just verify correspondence of actual and expected results. - So? Where is the “looking for bugs” here? -No, I haven’t seen. Some time ago I had a conversation about unit and integration tests with one of our developers. In the result we've come to conclusion that they are writing tests to verify contracts between components for convenience, access, usage of the defined data types and some other aspects. When you are writing a new code the test will be your first client. If it is easy and comfortable it means that everything is fine.When you are writing test on existing code but facing issues all the time and have to write a lot of workarounds it means that existent code is crap and it requires improving it. The same is applicable for other automation tests written by testers. You are writing them on the framework which works with the application

- What is our automation test coverage? - 42 - What is “42”? - What is automation test coverage? Asking about test coverage you have to be ready to have such conversation. In general the question about test coverage is very slippery. The person who is asking it has to realize all issues related to testing: Testing can be endless if it is not limited. It can be limited by time frame (Session based exploratory testing) or by cutting the scope (scripted testing). You can cut the scope by limiting the number of features to be tested or by using test design techniques. Due to the fact that we cannot automate exploratory testing the definition of automation test coverage will be treated to the scripted testing and it will show the percentage of automated manual tests. Let’s look at one small example: There is a simple application consists of a couple of pages, forms, linked between each other entities, functions and so on (I'm not talking about infrastructure). To pe