<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Комментарии: План тестирования должен быть внятным, четким, небольшим	</title>
	<atom:link href="https://testitquickly.com/2008/06/13/short-test-plan/feed/" rel="self" type="application/rss+xml" />
	<link>https://testitquickly.com/2008/06/13/short-test-plan/</link>
	<description>про тестирование ПО и всё такое прочее</description>
	<lastBuildDate>Fri, 31 Mar 2017 09:19:37 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.2</generator>
	<item>
		<title>
		Автор: Ann		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4763</link>

		<dc:creator><![CDATA[Ann]]></dc:creator>
		<pubDate>Fri, 31 Mar 2017 09:19:37 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4763</guid>

					<description><![CDATA[есть еще хорошая статья про планирование тестовых активностей http://www.a1qa.ru/blog/obespechivaem-kachestvo-mobilnyh-prilozhenij-shag-2-planirovanie-testovyh-aktivnostej/
кратко и по сути изложены основные моменты, можно использовать как шпаргалку :)]]></description>
			<content:encoded><![CDATA[<p>есть еще хорошая статья про планирование тестовых активностей <a href="http://www.a1qa.ru/blog/obespechivaem-kachestvo-mobilnyh-prilozhenij-shag-2-planirovanie-testovyh-aktivnostej/" rel="nofollow ugc">http://www.a1qa.ru/blog/obespechivaem-kachestvo-mobilnyh-prilozhenij-shag-2-planirovanie-testovyh-aktivnostej/</a><br />
кратко и по сути изложены основные моменты, можно использовать как шпаргалку 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Алексей Лупан		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4762</link>

		<dc:creator><![CDATA[Алексей Лупан]]></dc:creator>
		<pubDate>Tue, 03 Jul 2012 10:03:27 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4762</guid>

					<description><![CDATA[В ответ на &lt;a href=&quot;https://testitquickly.com/2008/06/13/short-test-plan/#comment-4761&quot;&gt;Юрий&lt;/a&gt;.

Вы правы.
Тогда я еще не был способен внятно всё сформулировать.
Сейчас могу, но не буду переписывать. К тому же, у меня тут был расширенный и достаточно исчерпывающий комментарий на эту тему.]]></description>
			<content:encoded><![CDATA[<p>В ответ на <a href="https://testitquickly.com/2008/06/13/short-test-plan/#comment-4761">Юрий</a>.</p>
<p>Вы правы.<br />
Тогда я еще не был способен внятно всё сформулировать.<br />
Сейчас могу, но не буду переписывать. К тому же, у меня тут был расширенный и достаточно исчерпывающий комментарий на эту тему.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Юрий		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4761</link>

		<dc:creator><![CDATA[Юрий]]></dc:creator>
		<pubDate>Tue, 03 Jul 2012 09:51:18 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4761</guid>

					<description><![CDATA[сори! но я так и не увидел наглядной разницы с примерами. описание тест-плана есть а вот  чек листа не наблюдаю!]]></description>
			<content:encoded><![CDATA[<p>сори! но я так и не увидел наглядной разницы с примерами. описание тест-плана есть а вот  чек листа не наблюдаю!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Katerina		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4760</link>

		<dc:creator><![CDATA[Katerina]]></dc:creator>
		<pubDate>Wed, 19 Oct 2011 09:47:29 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4760</guid>

					<description><![CDATA[Большое спасибо за статью и дополняющие комментарии!
У меня на носу сдача базиса и все выше указанное очень помогло! :)]]></description>
			<content:encoded><![CDATA[<p>Большое спасибо за статью и дополняющие комментарии!<br />
У меня на носу сдача базиса и все выше указанное очень помогло! 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Albert Gareev		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4759</link>

		<dc:creator><![CDATA[Albert Gareev]]></dc:creator>
		<pubDate>Thu, 18 Nov 2010 13:26:39 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4759</guid>

					<description><![CDATA[В ответ на &lt;a href=&quot;https://testitquickly.com/2008/06/13/short-test-plan/#comment-4757&quot;&gt;Алексей Лупан&lt;/a&gt;.

К теме.
&quot;The Value of Checklists and the Danger of Scripts: What Legal Training Suggests for Testers.&quot; Cem Kaner
Ссылка: www.kaner.com/pdfs/ValueOfChecklists.pdf
Вроде бы, на software-testing.ru выложили или собираются выложить статью в переводе.]]></description>
			<content:encoded><![CDATA[<p>В ответ на <a href="https://testitquickly.com/2008/06/13/short-test-plan/#comment-4757">Алексей Лупан</a>.</p>
<p>К теме.<br />
&#171;The Value of Checklists and the Danger of Scripts: What Legal Training Suggests for Testers.&#187; Cem Kaner<br />
Ссылка: <a href="http://www.kaner.com/pdfs/ValueOfChecklists.pdf" rel="nofollow ugc">http://www.kaner.com/pdfs/ValueOfChecklists.pdf</a><br />
Вроде бы, на software-testing.ru выложили или собираются выложить статью в переводе.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Serj		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4758</link>

		<dc:creator><![CDATA[Serj]]></dc:creator>
		<pubDate>Wed, 17 Nov 2010 13:56:28 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4758</guid>

					<description><![CDATA[&quot;Или если вам скучно, а заняться на производстве нечем – вам нужно написать документик.&quot; :D
Спосибо большое! :)]]></description>
			<content:encoded><![CDATA[<p>&#171;Или если вам скучно, а заняться на производстве нечем – вам нужно написать документик.&#187; 😀<br />
Спосибо большое! 🙂</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Алексей Лупан		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4757</link>

		<dc:creator><![CDATA[Алексей Лупан]]></dc:creator>
		<pubDate>Tue, 16 Nov 2010 23:46:43 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4757</guid>

					<description><![CDATA[Ну, вот вам четкое определение: упорядоченный список всех дел, логических и физических сущностей, материалов, терминов, целей, понятий которые надо сделать, чтобы протестировать что-то, называется тест-планом.
Это рукописный документ, который нужно сочинять самостоятельно (это первая трудность при работе с подобной документацией).
Зачастую используется в компаниях и ситуациях, когда необходимо очень точно и четко договориться о целях тестирования, о физической или логической наличии возможностей для проведения тестирования...
Блин.
Получается заумно.
В общем, если у вас есть въедливый закащщик, который может взгреть вас за любой промах, или может переложить на вас ответственность за какие-то проблемы, вам нужно написать документик.
Или если у вас разрозненная команда, и нужно составить доступный для обеих сторон перечень целей тестирования, серверов, логинов, и прочих важных вещей, чтобы в итоге все стороны говорили об одном и том же на одном и том же языке - вам нужно написать документик.
Или если вам платят за часы работы по определенному плану, а не &quot;в принципе&quot; и &quot;как получится&quot; - вам нужно написать документик.
Или если вам скучно, а заняться на производстве нечем - вам нужно написать документик.
В нём будет несколько разделов с подробными (ключевое слово - подробными) ответами на ряд вопросов.
Вопросы простые, но ответы бывают очень неоднозначными.
Например:
- что будем тестировать,
- нафига нам это надо тестировать,
- кто именно это будет тестировать, сколько нужно народу,
- где именно мы это будем тестировать (сервера, компьютеры, конфигурация компьютеров, софта, погодных условий и тыды),
- до каких пор мы это будем тестировать,
- в какой последовательности мы это будем тестировать,
- какие области наиболее приоритетны,
- как именно мы это будем тестировать (сюда обычно попадают тест-кейсы),
- на протяжении какого периода суток,
- и тыды, если эта информация кому-то нужна и важна.
В разных школах разработки существуют примерные заготовки тест-планов. Типа как тут http://www.carnegiequality.com/testing/test-plan-template/
Предполагается, что умный человек-тестировщик эту заготовку прочитает, оставит там только то, что ему нужно, вычеркнет то, что не нужно, и план готов. Большинство людей ломаются уже на этом этапе - как, неужели это еще надо самостоятельно писать-то?
Предполагается, что в процессе работы над тест-планом все темные места прояснятся, все детали будут продуманы и все нужные средства будут собраны, чтобы все прошло без проблем.
А потом, мол, этот документ будет нам и ориентиром качества проделанной работы, и отчетом.
&lt;strong&gt;Итого: тест-планом является подробный перечень всего того, что нужно для проведения тестирования чего-то. &lt;/strong&gt;
Указаны цели, задачи, требуемые ресурсы, технические подробности, ответственные лица, и прочее подобное. Приведена вся необходимая информация, ознакомившись с которой любой читатель документа узнает и поймет всё, что ему хотелось узнать и понять.
Еще раз отмечу - туда надо записывать то, что важно, а не всё подряд, &quot;лишь бы было&quot;.
После написания тест-план надо согласовать со всеми участниками разработки, которым это тестирование и было нужно. Тяжелый этап :)
После согласования и внесения коррективов, можно приступать к работе по этому плану.
Отклонения надо подправлять, изменения отражать, итог всей работы делать максимально предсказуемым.
В общем, тест-план - это план действий с техническими подробностями.
Важно понимать, что информации в этом плане может быть очень до хрена. Человек должен решать, что именно в этом плане должно содержаться, ответы на какие вопросы там должны быть, а на какие совершенно не нужны, бо это никому не нужно.
Очень такие документы помогают в борьбе с уродами, которые говорят &quot;&lt;em&gt;А мы думали, что вы будете тестировать и под таким-то нестандартным браузером и нестандартным расширением - это же само по себе подразумевается...&lt;/em&gt;&quot; Ни фига не самоподразумевается, и план помогает подобные пункты отдельно и особо обговорить. Мир во всем мире и свобода слова подразумеваются, а в тестировании все должно быть четким и ясным. Планировали тестировать с расширением 800x600 = получите и распишитесь.
Четкость и ясность приносят только подробные указания, которые &lt;strong&gt;обсуждаются&lt;/strong&gt; заинтересованными сторонами.
Тест-план - инструмент, который помогает достичь ясности и всеобщего согласия.
Но!
Есть ситуации, когда объемный и красивый тест-план нафиг не нужен. И даже - вреден.
Есть компании, в которых тестировать можно без предварительного расписывания адресов серверов, логинов, тест-кейсов и тыды. Бывает, что тестировщиков всего двое на десять программистов, и все мелочи уже всем известны, и все задачи уже обсуждены, и написание тест-плана вызовет только хихиканье и вопросы &quot;&lt;em&gt;Нафига это было нужно? Что, ходил на курсы по написанию тест-планов? Книг начитался?&lt;/em&gt;&quot;
Вообще, самой важной частью документации тестировщиков является перечень проверок, которым тестировщики могут подвергнуть тестируемое приложение.
Иногда это выглядит как список тест-кейсов.
Иногда это список функционала - ну, просто список.
Иногда это расширенный, подробный список - функционал отсортирован по значимости, например, и для каждого пункта отдельно прописаны его проверки.
&lt;strong&gt;Простой список того, что нужно не забыть протестировать - это чек-лист.&lt;/strong&gt;
Чек-листы бывают разными-разными :) Смотрим сюдой - http://nrukol.blogspot.com/2010/11/blog-post_08.html - там указан файлик, который нужно скачать и прочитать.
В файлике указаны, собственно, этапы детализации чек-листа. Можно сделать его простым, и этого достаточно. Можно детализировать, указав не только ЧТО надо протестировать, но и КАК это надо тестировать.
Сила тест-кейса в том, что в нем все расписано очень-очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но когда все это подробное добро приходится обновлять или изменять - становится кисло.
Сила чек-листа в том, что он простой. Там нет детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под &quot;&lt;em&gt;Зачарджить ордер на бэкофисе&lt;/em&gt;&quot; (это где? это как? это что? это откуда и куда?) - невозможно. И степень детализации низка. Глядим, к примеру, на пункт &quot;Проверить чекаут&quot; - там отмечено &#039;Pass&#039;. Ок, а как мне убедиться в том, что чекаут был проверен подробно? Тестировщик, который это проверял, действительно добавил товар в корзину всеми шестью способами, которыми это можно сделать на нашем сайте? Без деталей ИНОГДА кирдык как сложно. А иногда детали как раз и не требуются.
Дык вот.
Иногда тест-план - это просто очень детализированный чек-лист. Понятно, почему?
А иногда планировать тестирование можно только на основе чек-листа - он же может служить отчетом о работе. Понятно, почему?
Следовательно, моя подмена понятий может быть правомочной - в какой-то степени.
Вообще обойтись без тест-плана невозможно - он есть всегда, в любом виде, даже если ничего не расписано детально, и все хранится только в голове тестировщика.
Но иногда вполне можно обойтись без детализированного тест-плана, который подразумевается под &quot;&lt;em&gt;крутой документ, с кучей таблиц, графиков, списков и прочей лабуды&lt;/em&gt;&quot;.
Надеюсь, не запутал.]]></description>
			<content:encoded><![CDATA[<p>Ну, вот вам четкое определение: упорядоченный список всех дел, логических и физических сущностей, материалов, терминов, целей, понятий которые надо сделать, чтобы протестировать что-то, называется тест-планом.<br />
Это рукописный документ, который нужно сочинять самостоятельно (это первая трудность при работе с подобной документацией).<br />
Зачастую используется в компаниях и ситуациях, когда необходимо очень точно и четко договориться о целях тестирования, о физической или логической наличии возможностей для проведения тестирования&#8230;<br />
Блин.<br />
Получается заумно.<br />
В общем, если у вас есть въедливый закащщик, который может взгреть вас за любой промах, или может переложить на вас ответственность за какие-то проблемы, вам нужно написать документик.<br />
Или если у вас разрозненная команда, и нужно составить доступный для обеих сторон перечень целей тестирования, серверов, логинов, и прочих важных вещей, чтобы в итоге все стороны говорили об одном и том же на одном и том же языке &#8212; вам нужно написать документик.<br />
Или если вам платят за часы работы по определенному плану, а не &#171;в принципе&#187; и &#171;как получится&#187; &#8212; вам нужно написать документик.<br />
Или если вам скучно, а заняться на производстве нечем &#8212; вам нужно написать документик.<br />
В нём будет несколько разделов с подробными (ключевое слово &#8212; подробными) ответами на ряд вопросов.<br />
Вопросы простые, но ответы бывают очень неоднозначными.<br />
Например:<br />
&#8212; что будем тестировать,<br />
&#8212; нафига нам это надо тестировать,<br />
&#8212; кто именно это будет тестировать, сколько нужно народу,<br />
&#8212; где именно мы это будем тестировать (сервера, компьютеры, конфигурация компьютеров, софта, погодных условий и тыды),<br />
&#8212; до каких пор мы это будем тестировать,<br />
&#8212; в какой последовательности мы это будем тестировать,<br />
&#8212; какие области наиболее приоритетны,<br />
&#8212; как именно мы это будем тестировать (сюда обычно попадают тест-кейсы),<br />
&#8212; на протяжении какого периода суток,<br />
&#8212; и тыды, если эта информация кому-то нужна и важна.<br />
В разных школах разработки существуют примерные заготовки тест-планов. Типа как тут <a href="http://www.carnegiequality.com/testing/test-plan-template/" rel="nofollow ugc">http://www.carnegiequality.com/testing/test-plan-template/</a><br />
Предполагается, что умный человек-тестировщик эту заготовку прочитает, оставит там только то, что ему нужно, вычеркнет то, что не нужно, и план готов. Большинство людей ломаются уже на этом этапе &#8212; как, неужели это еще надо самостоятельно писать-то?<br />
Предполагается, что в процессе работы над тест-планом все темные места прояснятся, все детали будут продуманы и все нужные средства будут собраны, чтобы все прошло без проблем.<br />
А потом, мол, этот документ будет нам и ориентиром качества проделанной работы, и отчетом.<br />
<strong>Итого: тест-планом является подробный перечень всего того, что нужно для проведения тестирования чего-то. </strong><br />
Указаны цели, задачи, требуемые ресурсы, технические подробности, ответственные лица, и прочее подобное. Приведена вся необходимая информация, ознакомившись с которой любой читатель документа узнает и поймет всё, что ему хотелось узнать и понять.<br />
Еще раз отмечу &#8212; туда надо записывать то, что важно, а не всё подряд, &#171;лишь бы было&#187;.<br />
После написания тест-план надо согласовать со всеми участниками разработки, которым это тестирование и было нужно. Тяжелый этап 🙂<br />
После согласования и внесения коррективов, можно приступать к работе по этому плану.<br />
Отклонения надо подправлять, изменения отражать, итог всей работы делать максимально предсказуемым.<br />
В общем, тест-план &#8212; это план действий с техническими подробностями.<br />
Важно понимать, что информации в этом плане может быть очень до хрена. Человек должен решать, что именно в этом плане должно содержаться, ответы на какие вопросы там должны быть, а на какие совершенно не нужны, бо это никому не нужно.<br />
Очень такие документы помогают в борьбе с уродами, которые говорят &#171;<em>А мы думали, что вы будете тестировать и под таким-то нестандартным браузером и нестандартным расширением &#8212; это же само по себе подразумевается&#8230;</em>&#187; Ни фига не самоподразумевается, и план помогает подобные пункты отдельно и особо обговорить. Мир во всем мире и свобода слова подразумеваются, а в тестировании все должно быть четким и ясным. Планировали тестировать с расширением 800&#215;600 = получите и распишитесь.<br />
Четкость и ясность приносят только подробные указания, которые <strong>обсуждаются</strong> заинтересованными сторонами.<br />
Тест-план &#8212; инструмент, который помогает достичь ясности и всеобщего согласия.<br />
Но!<br />
Есть ситуации, когда объемный и красивый тест-план нафиг не нужен. И даже &#8212; вреден.<br />
Есть компании, в которых тестировать можно без предварительного расписывания адресов серверов, логинов, тест-кейсов и тыды. Бывает, что тестировщиков всего двое на десять программистов, и все мелочи уже всем известны, и все задачи уже обсуждены, и написание тест-плана вызовет только хихиканье и вопросы &#171;<em>Нафига это было нужно? Что, ходил на курсы по написанию тест-планов? Книг начитался?</em>&#187;<br />
Вообще, самой важной частью документации тестировщиков является перечень проверок, которым тестировщики могут подвергнуть тестируемое приложение.<br />
Иногда это выглядит как список тест-кейсов.<br />
Иногда это список функционала &#8212; ну, просто список.<br />
Иногда это расширенный, подробный список &#8212; функционал отсортирован по значимости, например, и для каждого пункта отдельно прописаны его проверки.<br />
<strong>Простой список того, что нужно не забыть протестировать &#8212; это чек-лист.</strong><br />
Чек-листы бывают разными-разными 🙂 Смотрим сюдой &#8212; <a href="http://nrukol.blogspot.com/2010/11/blog-post_08.html" rel="nofollow ugc">http://nrukol.blogspot.com/2010/11/blog-post_08.html</a> &#8212; там указан файлик, который нужно скачать и прочитать.<br />
В файлике указаны, собственно, этапы детализации чек-листа. Можно сделать его простым, и этого достаточно. Можно детализировать, указав не только ЧТО надо протестировать, но и КАК это надо тестировать.<br />
Сила тест-кейса в том, что в нем все расписано очень-очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но когда все это подробное добро приходится обновлять или изменять &#8212; становится кисло.<br />
Сила чек-листа в том, что он простой. Там нет детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под &#171;<em>Зачарджить ордер на бэкофисе</em>&#187; (это где? это как? это что? это откуда и куда?) &#8212; невозможно. И степень детализации низка. Глядим, к примеру, на пункт &#171;Проверить чекаут&#187; &#8212; там отмечено &#8216;Pass&#8217;. Ок, а как мне убедиться в том, что чекаут был проверен подробно? Тестировщик, который это проверял, действительно добавил товар в корзину всеми шестью способами, которыми это можно сделать на нашем сайте? Без деталей ИНОГДА кирдык как сложно. А иногда детали как раз и не требуются.<br />
Дык вот.<br />
Иногда тест-план &#8212; это просто очень детализированный чек-лист. Понятно, почему?<br />
А иногда планировать тестирование можно только на основе чек-листа &#8212; он же может служить отчетом о работе. Понятно, почему?<br />
Следовательно, моя подмена понятий может быть правомочной &#8212; в какой-то степени.<br />
Вообще обойтись без тест-плана невозможно &#8212; он есть всегда, в любом виде, даже если ничего не расписано детально, и все хранится только в голове тестировщика.<br />
Но иногда вполне можно обойтись без детализированного тест-плана, который подразумевается под &#171;<em>крутой документ, с кучей таблиц, графиков, списков и прочей лабуды</em>&#171;.<br />
Надеюсь, не запутал.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Serj		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4756</link>

		<dc:creator><![CDATA[Serj]]></dc:creator>
		<pubDate>Tue, 16 Nov 2010 22:49:27 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4756</guid>

					<description><![CDATA[&quot;Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.&quot;
Могли бы ли Вы (очень Вас прошу) дать чуть более развернутый ответ чем же по сути отличается тест-план от чеклиста и чем чек-лист отличается от тест-кейса?
Зараннее спасибо!
Я хочу сказать что существует понятие чеклиста, но оно очень размытое и я до сих пор не нашел ни одного четкого определения.]]></description>
			<content:encoded><![CDATA[<p>&#171;Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.&#187;<br />
Могли бы ли Вы (очень Вас прошу) дать чуть более развернутый ответ чем же по сути отличается тест-план от чеклиста и чем чек-лист отличается от тест-кейса?<br />
Зараннее спасибо!<br />
Я хочу сказать что существует понятие чеклиста, но оно очень размытое и я до сих пор не нашел ни одного четкого определения.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Алексей Лупан		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4755</link>

		<dc:creator><![CDATA[Алексей Лупан]]></dc:creator>
		<pubDate>Sat, 13 Sep 2008 19:45:45 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4755</guid>

					<description><![CDATA[Спасибо, Saty
Однако рекомендую читать подобные статьи как пропаганадистские агитматериалы за подписью Геббельса, например. То есть, взвешенно и отстраненно, не принимая на веру.]]></description>
			<content:encoded><![CDATA[<p>Спасибо, Saty<br />
Однако рекомендую читать подобные статьи как пропаганадистские агитматериалы за подписью Геббельса, например. То есть, взвешенно и отстраненно, не принимая на веру.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Автор: Saty		</title>
		<link>https://testitquickly.com/2008/06/13/short-test-plan/#comment-4754</link>

		<dc:creator><![CDATA[Saty]]></dc:creator>
		<pubDate>Thu, 11 Sep 2008 17:53:34 +0000</pubDate>
		<guid isPermaLink="false">http://testitquickly.wordpress.com/2008/06/13/%d0%bf%d0%bb%d0%b0%d0%bd-%d1%82%d0%b5%d1%81%d1%82%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%b4%d0%be%d0%bb%d0%b6%d0%b5%d0%bd-%d0%b1%d1%8b%d1%82%d1%8c-%d0%b2%d0%bd%d1%8f%d1%82%d0%bd%d1%8b/#comment-4754</guid>

					<description><![CDATA[Говорю искренне человеческое спасибо за статью!
Статья и приложение к ней открывают глаза нам молодым неопытным;)
пасиб!]]></description>
			<content:encoded><![CDATA[<p>Говорю искренне человеческое спасибо за статью!<br />
Статья и приложение к ней открывают глаза нам молодым неопытным;)<br />
пасиб!</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
