Когато за първи път се сблъскват с задачата пред мен се направи план за тестване на софтуер, аз се опитвам колкото и да, но намирането на подготовката на пробата и не може по каноните на стандарти. Повечето от момчетата в по-голямата bolgarskogovoryaschego интернет се опитва да се обадя тест тестови скриптове, които съдържат набор от тестови случаи и, че той е прав.
Аз трябваше да се отнасят до стандартите, за да се създаде план за изпитването. След като се запознах с препоръките на RUP (Rational Unified Process) и IEEE 829 разбрах, че аз съм поддръжник на RUP и затова планът на теста започва да композира, като се започне от техните препоръки.
Когато пишете на план за изпитване и проучване на данните, които трябва да са налице, останах с впечатлението, че и методологията или двете стандарти (както ви харесва), прикрепени към методологията на каскада от разработка на софтуер (софтуер). Въпросът стана, и това, което правя тези, които работят за Agile Разработка на софтуер (наричан Agile), включително нас? Много хора могат да възкликнат: тук не се нуждаят от план! Грешите. Планът за тест е необходимо във всеки случай, защото тя описва целия процес на тестване на софтуер (тук не е предназначен към детайла, инструкции стъпка по стъпка за "nesmyshlonyshey"). И тази информация е полезна, а в някои случаи и това е важно за новия човек, който е включен в проекта, както и най-вече на тестер.
Реших да напиша план така, както се препоръчва, забравил да се свърже с методологията на разработване на софтуер. В размер на план за изпитване се проверява тяхната работа и да се отрази на писмено, дойдох до заключението, че планът се прилага за Agile, достатъчно е да се изключат от теста на времето план - това ме притесни през цялото време, когато пишете на план за изпитване. Също така, защото смятам да се елиминира риска. Аз вярвам, че рисковете в плана могат да бъдат направени с дейностите по проекта и методологията на каскада от разработката на софтуер и пъргав с нас, те не трябва да се планира. Ние - това означава екип, в който работя. Може да се наложи и описание на рисковете.
Като направи някаква работа, аз бях създаден софтуер тест план. Това включва, можете да се запознаете в RUP или IEEE 829 стандартни препоръки, както и разглеждане на плана за изпитване, които съм прикрепен към тази статия.
Аз вярвам, че във всеки проект за разработване на софтуер, за да бъде тест план за нови тестери дойде на проекта може скоро да се запознаят с методите за изпитване, разработени софтуер, който те трябва да бъдат тествани и с други нюанси, които при липса на план те трябва да се изтеглят от хората, работи по проект, но не и преди да прекарате доста време в търсене на носителя на информация или множество превозвачи.
Downloads