<?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"
	>
<channel>
	<title>Comments on: Development 2.0</title>
	<atom:link href="http://kaloyan.info/blog/490/development-20/feed/" rel="self" type="application/rss+xml" />
	<link>http://kaloyan.info/blog/490/development-20/</link>
	<description>The Chaos Ruler &#38; The Dead Poets Society</description>
	<pubDate>Sat, 11 Oct 2008 01:13:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Peter</title>
		<link>http://kaloyan.info/blog/490/development-20/#comment-28027</link>
		<dc:creator>Peter</dc:creator>
		<pubDate>Sun, 13 Jan 2008 12:00:44 +0000</pubDate>
		<guid isPermaLink="false">http://kaloyan.info/blog/490/development-20/#comment-28027</guid>
		<description>Често срещано явление.

Обикновенно работата на QA е да тестват последните версии. И да обявяват че е достатъчно стабилна.

Конкретно аз правя така - когато имам релийз дата седмица предварително замразявам нещата за правене които няма да станат в рамките на датата или ще станат ама бъгави и т.н. след което се пуска един дълъг тест и се пипат само малките детайли без много-много нововъведения. Тогава проектите се разделят - стабилна и нестабилна. През седмицата се продължава работата по нестабилната версия и се пипа малко по-малко стабилната (с тенденция все по-малко да се пипа). Така на релийз датата (обикновенно гледам на седмица да е) има една стабилна версия (може с по-малко възможности но СТАБИЛНА) и нестабилна (с повече възможности но НЕСТАБИЛНА). Само има малко ядове по обединяването на промените между версиите, но се свиква (освен ако не са някакви гигантски, но за това си има фаза на проектиране където се преценяват внимателно нещата).</description>
		<content:encoded><![CDATA[<p>Често срещано явление.</p>
<p>Обикновенно работата на QA е да тестват последните версии. И да обявяват че е достатъчно стабилна.</p>
<p>Конкретно аз правя така - когато имам релийз дата седмица предварително замразявам нещата за правене които няма да станат в рамките на датата или ще станат ама бъгави и т.н. след което се пуска един дълъг тест и се пипат само малките детайли без много-много нововъведения. Тогава проектите се разделят - стабилна и нестабилна. През седмицата се продължава работата по нестабилната версия и се пипа малко по-малко стабилната (с тенденция все по-малко да се пипа). Така на релийз датата (обикновенно гледам на седмица да е) има една стабилна версия (може с по-малко възможности но СТАБИЛНА) и нестабилна (с повече възможности но НЕСТАБИЛНА). Само има малко ядове по обединяването на промените между версиите, но се свиква (освен ако не са някакви гигантски, но за това си има фаза на проектиране където се преценяват внимателно нещата).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.110 seconds -->
