From d12ea3a1989c6672073301d1c71d89d27facc58c Mon Sep 17 00:00:00 2001
From: Vlad Putnikov <38841998+UndergroundEnemy@users.noreply.github.com>
Date: Sat, 24 Nov 2018 21:23:06 +0300
Subject: [PATCH] =?UTF-8?q?Add=20the=20text=20"=D0=9A=D1=80=D0=B8=D1=82?=
 =?UTF-8?q?=D0=B5=D1=80=D0=B8=D0=B8=20=D0=BF=D1=80=D0=B8=D1=91=D0=BC=D0=BA?=
 =?UTF-8?q?=D0=B8...".=20(#24002)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Критерии приёмки - это не то же самое, что приёмочные тесты.
---
 guide/russian/agile/acceptance-criteria/index.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/guide/russian/agile/acceptance-criteria/index.md b/guide/russian/agile/acceptance-criteria/index.md
index db68e5899c..66d9e1c415 100644
--- a/guide/russian/agile/acceptance-criteria/index.md
+++ b/guide/russian/agile/acceptance-criteria/index.md
@@ -10,6 +10,8 @@ localeTitle: Критерии приема
 
 Самое главное, если история не соответствует каждому из критериев приема, то владелец продукта не должен принимать историю в конце итерации.
 
+Критерии приёмки - это не то же самое, что приёмочные тесты. 
+
 Критерии приемлемости можно рассматривать как инструмент защиты Команды доставки. Когда Группа доставки обязуется фиксировать множество историй в планировании Спринта, они фиксируют также набор критериев приемлемости. Это помогает избежать ползучести.
 
 Рассмотрим следующую ситуацию: при принятии пользовательской истории владелец продукта предлагает добавить то, что не входит в сферу истории пользователя. В этом случае команда доставки может отклонить этот запрос (как бы мала она ни была) и попросить владельца продукта создать новую историю пользователя, о которой можно позаботиться в другом Sprint.
@@ -19,3 +21,4 @@ localeTitle: Критерии приема
 Nomad8 предоставляет [FAQ по критериям приема](https://nomad8.com/acceptance_criteria/)
 
 Продвинутый переход на [критерии приема](https://www.leadingagile.com/2014/09/acceptance-criteria/)
+