|
|
|
|
|
|
by ajeet_dhaliwal
1117 days ago
|
|
|
CI plays a huge part in supporting test automation so I can see why this is a pain point. This also impacts deployments in general. Speaking specifically to test automation I find that most companies simply prefer to make the calculation that they'll take the risk of an issue occurring over investing in test automation (and testing in general) until the problems become so large and financially catastrophic, or a regulatory issue, that it gets embarrassing for a VP/Exec and then the decision is made to properly invest. That's not an ideal approach because building this out as you go is more efficient. The typical other problems are how best to shape the testing pyramid. Having large number of unit tests > medium number of integration tests and a small number of end-to-end tests is always proposed but I find in most cases the pyramid becomes inverted due to the natural issues associated with problems really being only of concern if they actually impact an end user and the end-to-end issues cast a wide net even though they are very challenging to maintain and do require appropriate investment in resources. I want to mention Tesults (https://www.tesults.com) with which I am involved to tackle another issue. Clarity around test results and what is actually being tested due to bad reporting and trouble accessing relevant results data. Understanding testing across the systems for a team is essential to knowing what's actually running, how often and what the output is. This helps understand what additional testing may be needed and identifying what's failing. Overall, most of the issues related to test automation stem from the calculation made too often mentioned above. |
|
|