Answer the question
In order to leave comments, you need to log in
Regression autotesting of business processes - how to do it right?
Some time ago I had to face the task of automating testing of multi-user processes.
Conventionally, it was necessary to check a certain web interface where various long and highly branched scenarios take place: user A pressed a button, after that a message was received by user B, then (depending on the actions of users A and B), messages are received by user C or D and etc.
At that time, the means and methods were chosen according to the criteria of simplicity and efficiency of implementation, as a result, a bunch of script files of terrifying length came out on watir-webdriwer, which was launched every day at breakfast (if the script that worked normally yesterday broke down in the middle, then you need to sit down to figure it out: either something has changed or something is broken).
Now it's time to figure it out - but how is it right?
There are no questions with the direct pressing of buttons - instead of watir-webdriver, you can use selenium in any convenient language, I would like to understand how it is reasonable to systematize and document all this (best practices or personal experience with specific frameworks).
At the same time, it is not enough to bind to each function or feature according to the test, the “scenario” (“forks” from different process states that can be obtained only after previous actions is important, just the correct sequence of screens for different users and saving all the necessary data in the process, etc.). d.).
Answer the question
In order to leave comments, you need to log in
1. В тестах развилок не может быть! Другими словами Вы всегда должны разбивать тестируемый код на участки. До условия это один участок кода. Ветка кода с if-true(т.е. когда условие true). И ветка кода с if-false(т.е. когда условие ложно). Это три разных тестовых сценария. Вам будет проще для сопровождения.
Тесты должны быть как можно проще!!! Было А, нажали что-то, Должно быть Б. Если не так, то заводим багу!
2. Прежде чем писать тест надо задаться вопросом "А если здесь будет бага, то что это будет значить для бизнеса?" ответ "Клиенты массово будут просить денег обратно" - значит надо писать тест "Клиент купит, но будет недоволен" - нужно думать стоит ли писать тест? Вдруг есть более важные участки кода
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question