0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Для нас сейчас постоянные обновления приложений на нашем смартфоне, на нашем компьютере или даже смарт-телевизоре, это нормальная реальность. Но так было не всегда. Компьютеры появились только во второй половине 20 века, а персональные компьютеры и того позднее - в конце 20 века. Потребность изменений тогда, на заре информационных технологий, была не такой, как сейчас. Так что водопадная модель разработки была самой первой придуманной и прекрасно удовлетворяла реалиям жизни тогда. Водопадная модель понятна и проста, да и отлично работает, когда есть бюджет и точная идея, что надо сделать.</p>
1
<p>Для нас сейчас постоянные обновления приложений на нашем смартфоне, на нашем компьютере или даже смарт-телевизоре, это нормальная реальность. Но так было не всегда. Компьютеры появились только во второй половине 20 века, а персональные компьютеры и того позднее - в конце 20 века. Потребность изменений тогда, на заре информационных технологий, была не такой, как сейчас. Так что водопадная модель разработки была самой первой придуманной и прекрасно удовлетворяла реалиям жизни тогда. Водопадная модель понятна и проста, да и отлично работает, когда есть бюджет и точная идея, что надо сделать.</p>
2
<h2>Тестирование в водопадной модели</h2>
2
<h2>Тестирование в водопадной модели</h2>
3
<p>Как мы говорили в предыдущем уроке, у водопадной модели есть один важный минус. Чтобы по такой модели сделать качественный продукт, нужно потратить слишком много времени и ресурсов.</p>
3
<p>Как мы говорили в предыдущем уроке, у водопадной модели есть один важный минус. Чтобы по такой модели сделать качественный продукт, нужно потратить слишком много времени и ресурсов.</p>
4
<p>Это показывает знаменитый проектный треугольник:</p>
4
<p>Это показывает знаменитый проектный треугольник:</p>
5
<p>По этому треугольнику наглядно видно, что чем больше скоуп, тем больше денег и времени тратится. Почему же так выходит? Дело в том, что все процессы линейны и последовательны.</p>
5
<p>По этому треугольнику наглядно видно, что чем больше скоуп, тем больше денег и времени тратится. Почему же так выходит? Дело в том, что все процессы линейны и последовательны.</p>
6
<p>Представим, что мы работаем над продуктом для заказчика. Сначала заказчик сформулировал свои требования, а затем мы изучили его требования и спроектировали будущее приложение. Мы завершили этап проектирования и начали разработку.</p>
6
<p>Представим, что мы работаем над продуктом для заказчика. Сначала заказчик сформулировал свои требования, а затем мы изучили его требования и спроектировали будущее приложение. Мы завершили этап проектирования и начали разработку.</p>
7
<p>И тут выясняется, что требования к продукту меняются. Это может произойти по разным причинам:</p>
7
<p>И тут выясняется, что требования к продукту меняются. Это может произойти по разным причинам:</p>
8
<ul><li>Заказчик не смог точно сформулировать, что ему надо</li>
8
<ul><li>Заказчик не смог точно сформулировать, что ему надо</li>
9
<li>Мы не до конца поняли требования заказчика</li>
9
<li>Мы не до конца поняли требования заказчика</li>
10
<li>У заказчика появились какие-то новые условия</li>
10
<li>У заказчика появились какие-то новые условия</li>
11
</ul><p>В любом случае мы не можем внести правки в проект. Надо сначала завершить первый цикл, а уже потом начинать второй. В водопадной модели порядок этапов важнее всего: нельзя вернуться назад и переделать.</p>
11
</ul><p>В любом случае мы не можем внести правки в проект. Надо сначала завершить первый цикл, а уже потом начинать второй. В водопадной модели порядок этапов важнее всего: нельзя вернуться назад и переделать.</p>
12
<p>Поэтому все этапы длятся очень долго, ведь нужно все тщательно обсудить и согласовать с заказчиком. В итоге фазы будут огромными:</p>
12
<p>Поэтому все этапы длятся очень долго, ведь нужно все тщательно обсудить и согласовать с заказчиком. В итоге фазы будут огромными:</p>
13
<ul><li>Сначала мы долго проектируем и составляем большой список требований</li>
13
<ul><li>Сначала мы долго проектируем и составляем большой список требований</li>
14
<li>Из-за большого списка требований разработка затянется надолго</li>
14
<li>Из-за большого списка требований разработка затянется надолго</li>
15
<li>Из-за долгой разработки придется потратить очень много времени на тестирование</li>
15
<li>Из-за долгой разработки придется потратить очень много времени на тестирование</li>
16
</ul><p>Таким образом, на разработку готового продукта уйдет много времени, сил и денег.</p>
16
</ul><p>Таким образом, на разработку готового продукта уйдет много времени, сил и денег.</p>
17
<h2>Современные подходы к тестированию</h2>
17
<h2>Современные подходы к тестированию</h2>
18
<p>В водопадной модели тестирование идет отдельным этапом, поэтому разработка получается дорогой и долгой. Намного эффективнее работают гибкие методологии, в которых команда тестирует продукт на всех этапах жизненного цикла.</p>
18
<p>В водопадной модели тестирование идет отдельным этапом, поэтому разработка получается дорогой и долгой. Намного эффективнее работают гибкие методологии, в которых команда тестирует продукт на всех этапах жизненного цикла.</p>
19
<p>Чем раньше мы начинаем анализировать, тем легче и дешевле исправить ошибки.</p>
19
<p>Чем раньше мы начинаем анализировать, тем легче и дешевле исправить ошибки.</p>
20
<p>Представим, что на этапе проектирования мы забыли про какое-то требование заказчика. В результате программисты не узнают об этом требовании и не разработают нужную фичу. Эту проблему заметит тестировщик на этапе активного тестирования.</p>
20
<p>Представим, что на этапе проектирования мы забыли про какое-то требование заказчика. В результате программисты не узнают об этом требовании и не разработают нужную фичу. Эту проблему заметит тестировщик на этапе активного тестирования.</p>
21
<p>Из-за одной маленькой ошибки команде придется проводить еще один цикл проектирования, программирования и тестирования. То есть продукт дойдет до заказчика позже, да и стоимость разработки вырастет.</p>
21
<p>Из-за одной маленькой ошибки команде придется проводить еще один цикл проектирования, программирования и тестирования. То есть продукт дойдет до заказчика позже, да и стоимость разработки вырастет.</p>
22
<p>Теперь усложним ситуацию и представим, что даже тестировщик не обнаружил проблему. Тогда ее увидит заказчик в готовом продукте. Это негативно скажется на репутации фирмы-производителя ПО. Более того, если мы разрабатываем ПО для авиации или медицины, такая небольшая ошибка в проектировании может сказаться на безопасности.</p>
22
<p>Теперь усложним ситуацию и представим, что даже тестировщик не обнаружил проблему. Тогда ее увидит заказчик в готовом продукте. Это негативно скажется на репутации фирмы-производителя ПО. Более того, если мы разрабатываем ПО для авиации или медицины, такая небольшая ошибка в проектировании может сказаться на безопасности.</p>
23
<p>За пределами каскадной модели тестирование внедряется на всех этапах жизненного цикла:</p>
23
<p>За пределами каскадной модели тестирование внедряется на всех этапах жизненного цикла:</p>
24
<ul><li>Дизайн и требования проверяются до начала разработки - так можно на раннем этапе выявить просчеты и дыры в дизайне</li>
24
<ul><li>Дизайн и требования проверяются до начала разработки - так можно на раннем этапе выявить просчеты и дыры в дизайне</li>
25
<li>Код тестируется прямо на этапе разработки - программисты проводят статическое тестирование, ревью кода и юнит-тестирование</li>
25
<li>Код тестируется прямо на этапе разработки - программисты проводят статическое тестирование, ревью кода и юнит-тестирование</li>
26
<li>Приложение тестируется на разных этапах разработки. Необязательно ждать полностью готовое приложение, ведь все можно проверить заранее. Еще до завершения разработки можно провести тестирование функциональностей, бета-тестирование, а также компонентное, модульное, интеграционное или системное тестирование</li>
26
<li>Приложение тестируется на разных этапах разработки. Необязательно ждать полностью готовое приложение, ведь все можно проверить заранее. Еще до завершения разработки можно провести тестирование функциональностей, бета-тестирование, а также компонентное, модульное, интеграционное или системное тестирование</li>
27
<li>На этапе приемки проводится еще одно тестирование - приемочное. Во время него приложение проверяется по сценариям, близким к реальным действиям пользователей (такие сценарии называются use cases)</li>
27
<li>На этапе приемки проводится еще одно тестирование - приемочное. Во время него приложение проверяется по сценариям, близким к реальным действиям пользователей (такие сценарии называются use cases)</li>
28
</ul>
28
</ul>