Parallel run of Automated tests is not just a wish, but a real necessity, standard task which sooner or later any project meets. Sometimes, parallel run becomes very difficult or even not possible task. How to avoid that situation? What recommendations are used for paralleling tests, what tools are better to use and what architecture for automated tests should be chosen at the beginning? Anton will try to answer all those pertinent questions and of course will look at a ton of examples to consolidate the proposed material.
Anton has already talked about "good" ways of parallel run of automated tests. He will start from the opposite and talk about 10 ways of "bad" — hard, slow, expensive, not effective parallel run of tests on real examples. The discussion is devoted to failed approaches, detailed argumentation and recommendations how and why the problem could and should be solved the other way. It's going to be interesting.
DPI.Solutions; EPAM; COMAQA; CoreHard
COMAQA.BY automation community activist, COREHard.BY hardcore development community activist, co-founder of DPI.Solutions company. More than 13 years of experience in IT. Main specializations: automated testing, C++ low-level development and lower. Management, sales.