Признаки хорошего тестового сценария SIGNS OF A GOOD SCENARIO

Написание тестового сценария является одной из основных и наиболее важных обязанностей инженера по тестированию. Тестовые сценарии пишутся на раннем этапе тестового цикла и, если что-то пойдет не так при написании тестовых сценариев, то это обязательно окажет влияние на дальнейшие действия и результаты в цикле тестирования. Хорошо написанные тестовые сценарии экономят время на дальнейших этапах, позволяют легко подключать дополнительных инженеров по тестированию к работам, снижают риски, связанные с пропущенными ошибками. Writing a testing scenario is one of the main and most important responsibilities of a test engineer. Testing scenarios are written at the early stage of the test cycle and if something goes wrong when writing the testing scenarios, this will definitely affect the further actions and results of the testing. Well written testing scenarios save time at the consequent stages, allow easily engaging additional testing engineers, lower the risks to miss a bug.

Все мы пишем тестовые сценарии. Некоторые хорошие, некоторые не очень. Мне хотелось бы рассказать о некоторых простых правилах, которые позволят вам улучшить ваши тестовые сценарии и сделать их более пригодными для работы с ними не только вас, но и ваших коллег. На мой взгляд, данные правила, закрепленные во внутренних, регламентирующих документах компании являются «musthave», для любой компании-разработчика программного обеспечения и, тем более, для компании, где тестирование программного обеспечения является основным направлением деятельности. We all write testing scenarios. Some of them are good some are not so good. I want to tell you about some simple rules that will help you to improve your testing scenarios and make them more suitable for working with them not only for you but also for your colleagues. In my opinion, these rules put into the regulatory documents of a company are a must have for any company - software developer, for which software testing is the main business activity.

Правила, которых стоит придерживаться при создании тестовых сценариев: The rules one should follow when making testing scenarios:

1. Разработайте правила наименования тестового сценария. Если у вас еще нет правил наименования тестовых сценариев, то выработайте единый подход к именованию тестовых сценариев на всех проектах. Поверьте, это сильно поможет вам и вашей команде в будущем. Хорошим тоном будет именовать тестовые сценарии так, чтобы они отражали проект, имя модуля или функциональной области, которую вы тестируете. 1. Develop the rules of test scenario naming. If you still do not have the naming rules for the testing scenarios, develop a unified approach to naming all scenarios for all projects. Trust me, this will help you and your team a lot in the future. It is also a good idea to name the testing scenarios in such a way that they reflect the project, the name of the module or of the functional area you are testing.

2. Указывайте предопределенные условия. Когда вы пишете тестовый сценарий, указывайте предусловия которые должны быть выполнены. Например, пользователь, под которым необходимо зайти, зависимости от тестового окружения, зависимости от других тестовых сценариев, которые должны быть пройдены. 2. Indicate the predefined conditions. When you are writing a testing scenario, indicate the predefined conditions that must be fulfilled. For example, the user, under which to enter depending on the testing environment, dependences on other testing scenarios that should be followed.

3. Указывайте описание тестового сценария. Описание тестового сценария должно содержать информацию, что проверяется данным тестовым сценарием. Описание должно быть понятным и однозначным. 3. Specify the description of the testing scenario. The description of the testing scenarios must include the information about what is to be checked by this testing scenario. The description should be clear and simple.

4. Прикладывайте необходимые документы. Если, например, сложно понять прохождение тестового сценария без скриншота и/или без спецификации – приложите их. 4. Attach the required documents. For example, if it is hard to understand the testing scenario without a screenshot and/or a specification, attach them.

5. Прописывайте действия и ожидаемый результат после каждого выполняемого действия в тестовом сценарии. Ожидаемый результат выполнения тестового сценария должен быть описан однозначно и ясно. Он должен описывать не только изменения, происходящие на экране, но и изменения, которые происходят в базе данных или в интегрированных системах. 5. Describe the actions and the expected results after each action in the testing scenario. The expected result of running the testing scenario should be clear and simple. It should describe not only the changes happening on the screen but also the changes in the database or in the integrated systems.

6. Тестовые сценарии должны быть простыми для понимания. Необходимо понимать, что тестовые сценарии пишутся не только для использования их автором. Тестовые сценарии могут быть использованы любым иным специалистом по тестированию. Таким образом, тестовые сценарии должны быть легко читаемыми и понятными для любого инженера по тестированию, знакомому с правилами тестирования в компании. Не нужно создавать в тестовых сценариях большую описательную часть, это может запутать. Сценарии должны быть точечными, т.е. тестировать какой-либо небольшой кусок функционала, но при этом быть полными. 6. Testing scenarios should be easy to understand. It is important to realize that the testing scenarios are written to be used not only by the author. Testing scenarios may be written by any other testing expert. Thus, the testing scenarios should be easy to read and clear for any test engineer who is aware of the testing rules in the company. Do not add a lot of descriptions to the testing scenarios, as this may lead to confusion. Scenarios should be local, i.e. test a small part of the functional, but also complete at the same time.

7. Выработайте и задокументируйте процесс пересмотра тестовых сценариев кем-то, кроме автора. Пусть готовые тестовые сценарии посмотрит руководитель отдела тестирования, аналитик или разработчик. Это поможет сделать их более понятными и, возможно, после проведения ревью тестовых сценариев покрытие ими разработанного функционала увеличится. 7. Develop and document the process of reviewing testing scenarios by someone except for the author. When the scenarios are ready, the head of the testing department, and analyst or a developer can review them. This will help to make them more clear and probably after the review the testing scenarios will cover a wider functional.

8. Пишите тестовые сценарии для повторного использования. При создании тестовых сценариев, имейте в виду их повторное использование на другом проекте или системе. Прежде чем писать их «с нуля», попробуйте найти уже существующие подобные тестовые сценарии в корпоративной системе. Например, проверка логина используется повсеместно. 8. Write testing scenarios for recycling When creating the testing scenarios, keep in mind that they can be used again for another project or system. Before writing the scenarios from the scratch try to find existing similar testing scenarios in the corporate system. For example, login testing is used everywhere.

Я очень надеюсь, что данные несложные правила, принятые в вашей компании помогут вам в тестировании и позволят повысить качество производимого продукта. I hope these simple rules, adopted in your company, will help you in testing and increase the quality of your product.

2017-05-10

Признаки хорошего тестового сценария SIGNS OF A GOOD SCENARIO

Напишите намSend us an E-mail

Обратная связьCONTACT US

Ваше письмо отправлено!Your letter has been sent!