Unspoken truths about testing
Time and again, test automation is generally dismissed as a waste of time. This is of course not true.
Test automation is a waste of time if it starts with unstructured unit tests and ends with an automated system test that can only be performed and maintained by an expert.
With automatically generated unit tests, the beginning is still effortless because the developers still have plenty of familiar tools at their disposal.
Tests are automated without the time required for R&D and
the development teams to follow up on interfaces required for automation.
At the system test level, automation is then either no longer automated at all because the degree of complexity seems too high or the system testers have no know-how in the area of development principles and practices. Also, automation is often started in the wrong places.
Especially preconditions for the system deployment (firmware of the devices, bringing the system into a defined initial state, etc.) can be automated very well.
We would be happy to support you in automating the right tests correctly,
but also not to automate the right tests. It is important to keep the test automation frameworks simple and also to make them accessible to project participants who are not part of the core development team
include the possibility to efficiently participate in the test automation.
Test automation is NOT a waste of time.
He that measures a lot measures crap. That's right, of course. We help you to work out the right metrics and to argue them. Only with the right metrics can the test manager judge whether the quality is constantly improving or maintaining the desired level.
It is important to clarify which goals are to be achieved with the metrics, which data must be collected for this purpose and whether the effort of collection and configuration is appropriate in relation to the gain.
Metrics
SUPPORT & ENCOURAGE.
Of course there is the danger of producing a lot of paper with processes. Especially when processes are written for their own sake. But processes never fulfill an end in themselves. We help you define the necessary processes with the scope you need to prevent over-regulation and still achieve the desired level of standardization.
Test processes generate
STRUCTURE.
Of course, visualization is a good way to transport technical issues to the management. In addition to this, the right visualization also has the advantage of condensing multiple data quickly and easily, e.g. during a test run, so that states can be recorded quickly and clearly and required activities can be derived quickly. In this way, a possible test abort or complete failure of a test run can be prevented and costs saved.
Correct visualization
helps you and your TEAM.
New approaches always first trigger a discussion of their usefulness. This is completely normal and even an important part of change processes. BDD represents a further development of TDD and the quality of your products will improve.
BDD demonstrably improves
quality
Responsibility is neither delegable nor divisible. It must always be clear to everyone who wears the "test hat" and who is in charge of quality assurance. Decisions made in Scrum by people from other fields lead to a loss of quality.
Different
experiences and knowledge have to be considered individually
in the project.
The most important point in software testing is the inner attitude. Testing is mainly used to find error states and error effects. It is not in focus to prove that a test object works.