Съвременно тестване - Еволюцията на ролята на QA
Разработката на софтуер се е развила от дните на водопада, Agile и сега DevOps. Естествено, тестването като дисциплина също е видяло няколко основни промени, за да се приспособят новите начини за работа и предоставяне на софтуер.
Все още обаче има огромно недоразумение и неправилно възприемане на ролята на тестерите и осигуряването на качеството като цяло.
В тази публикация ще разгледаме как се е развило тестването, особено през последното десетилетие, и какво трябва да направят специалистите по QA, за да останат по-напред в играта.
Тестването може да стане само по-интересно!
Докато дейностите по тестване на софтуера се промениха, за да се адаптират към новите начини на работа, все още виждам много старомодни възгледи за тестване и ролята на QA.
Обезсърчително е да се види, че все още има много хора в ИТ индустрията, които гледат на QA или Testers като на дъното. Тестерите често се възприемат като просто функционални тестери, които тестват едва след като разработчиците приключат работата си по дадена функция. „Осигуряване на качеството“ се възприема като тестване, намиране и докладване на грешки и даване на зелена светлина за пускане.
Още по-тревожното е, че това възприятие за ролята на QA е от първостепенно значение сред тестерите и самите QA специалисти.
Традиционно тестване на софтуер
Исторически погледнато, воденето в последните фази на проект за водопад, тестването ще застане здраво вдясно от жизнения цикъл на проекта. След предварително определяне на изискванията тестерите ще вземат щафетата от екипа за разработка в края на фазата на разработка и ще изпълняват дълги, подробни скриптове за тестове, често ръчно и обикновено чрез затворени екипи и групи от МСП.
Случаите на тестовете бяха предварително щателно планирани, скриптове бяха изпълнени от специалисти, дефектите бяха открити и докладвани, а тестовите цикли бяха изпълнени и повторени, докато не се постигнат предварително зададените нива на качество.
Най-забележителното винаги е било ясно разделение между разработчици и тестери, без припокриване на отговорности или дейности. Всъщност, по време на отделната, оградена с фаза фаза на тестване, дейностите бяха фокусирани чисто върху функционалната валидация на софтуера с основната цел да се открият и докладват дефекти.
QA в ерата на пъргавите
Появата на гъвкави методологии и начини на работа обедини дейностите по разработка и тестване до такава степен, че тестването на софтуер вече не беше самостоятелна фаза. Вместо това тестването се превърна в неявна дейност по време на кодирането и разработването на софтуер.
В някои случаи би било трудно да се види разграничението между „изпитател“ и „разработчик“, тъй като всеки ще има способността безпроблемно да извършва взаимни дейности.
„Качеството“ престава да се превръща в единствената отговорност на тестерите и става споделена отговорност на всички, участващи в разработването и доставянето на продукта.
Заедно с тази еволюция дойде промяна на тестовите отговорности вляво от разработката, което по същество печеше качеството от самото начало.
Фокусът се премести от намирането на дефекти в вградения софтуер, за да предотврати навлизането на дефекти в софтуера.
Със споделена цел да се гарантира не само, че продуктът или характеристиката са функционални и отговарят на изискванията, но също така са годни за целта и осигуряват високо ниво на удовлетвореност на потребителите.
Свързани:
Участието на тестерите в усъвършенстването на историята, рецензиите на партньорски кодове, тестовете на единици и практики като TDD, BDD и непрекъснатото тестване, гарантира, че тестовете и качеството са на първо място и е вградено в разработката.
Но докато Agile измина дълъг път, за да комбинира дейностите и практиките на разработка и тестване, оперативният екип все още беше затворен. Двата потока работа (Dev & Ops) често не са знаели за дейностите на другия.
Ако нещо се обърка в производството, разследването ще отнеме много време. Разработчиците не са имали представа за ефективността на тяхното приложение в производството в дългосрочен план; нямаше прозрачност или яснота на сътрудничеството между двата екипа.
Добре дошли в DevOps
DevOps се отнася до сътрудничеството на екипите за разработка и експлоатация при създаването, доставката, поддръжката и поддръжката на софтуер. То се отнася до непрекъснато обединение на ресурсите, процесите и самия продукт.
DevOps позволява методи за непрекъсната интеграция и доставка на стойност до крайния потребител.
Движението DevOps даде нова перспектива за тестване и създаде нови възможности за самите тестери.
В тази нова ера тестерите трябва да бъдат съобразени както с разработката, така и с операциите.
Правото на тестване вече не се ограничава до продукта, но също така и до тестването на инфраструктурата, където продуктът в крайна сметка се изпълнява.
Непрекъснатата интеграция (CI) и непрекъсната доставка (CD) се превърнаха в де факто стандарт при разработването и доставянето на софтуер и следователно голяма част от усилията за тестване сега се изразходват за осигуряване на CI / CD тръбопровод, среди и инфраструктура.
Това е гръбначният стълб, който подпомага както развитието, така и доставката.
Ако тестването им бъде пренебрегнато, това може да доведе до нестабилна среда, много усилия се губят за разследване на повтарящи се инфраструктурни проблеми и в крайна сметка висок риск за развитието и бърза доставка.
Съвременни тестове - Качествено развитие
Въпреки че е направено много за вграждане на качеството на всеки етап от развитието и в резултат на това тестването има много по-широк обхват, все още вярвам, че QA прекарват по-голямата част от времето си в търсене на функционални проблеми и се фокусират върху проверката на софтуера.
Повечето QA не осъзнават важността на своята роля и въздействието, което могат да окажат върху развитието и доставката.
Въпреки значителните промени в практиките за разработка през последните десет години, чувствам, че тестерите все още възприемат старомоден поглед върху своята роля и по този начин остават утвърдени в старата ера на тестване.
Изпитването като професия и ролята на изпитател е подложено на атака от известно време с нарастването на „автоматизираното тестване“. И наистина, много професионалисти в индустрията все още вярват, че ролята на тестера е просто да тества приложението, което разработчиците изграждат, като всички те могат да бъдат автоматизирани.
Ако разработчиците са по-подходящи и по-разумни да напишат кода, необходим за автоматизирано тестване, тогава каква нужда изобщо има за тестер в екипа?
Време е да променим това възприятие. Трябва да признаем разликата в стойността и уменията между „тестване“ и „осигуряване на качеството“, тъй като когато тестването е функционална проверка и валидиране на софтуера, осигуряването на качеството не е единична дейност. QA е поредица от процеси, включително тестване и най-добри практики, за да се гарантира, че на потребителите се доставя качествен продукт.
Трябва да се стремим към качествено ориентирано развитие и да разглеждаме QA професията като централна и основна функция в разработването и доставката на софтуер, следователно Съвременно тестване .
QA сега е ключов компонент на разработката от началото до края, като работи през целия процес. И въпреки че обикновеният език казва, че всеки в екипа за доставка е отговорен за доставката на качествен продукт, аз твърдо вярвам, че отговорността на QA е да гарантира, че екипът спазва практиките за качество.
Кой е модерният QA
Там, където тестовата професия често се възприема като път за достъп до разработки, управление на проекти или други - обикновено по-доходоносни - дисциплини, новата QA е висококвалифицирана роля, която изисква цялостно познаване на практиките за развитие.
Изисква широко разбиране на предизвикателствата на практиките за кодиране, оценка на методите и средите за внедряване, както и стандартите, методите и предизвикателствата за производителност и сигурност.
Това е Т-образна роля с ресурса, способен не само да приложи своя дълбок опит и опит, за да изпълни основната си задача, но и да приложи по-широки контекстуални знания в архитектурата и развитието.
Разположен в центъра на всеки проект, модерният QA трябва добре да разбира архитектурата, производителността, сигурността и облачните предложения, да бъде технически издържан и да има жажда за изучаване на нови технологии, за да остане в играта.
Забележка:Друга област, която бързо се превръща в много популярна и съществена проверка на качеството на данните, тестване на големи данни, езера и складове за данни.Дойде време да променим възприятието за ролята на QA и какво правят тестерите. Това трябва да започне от самите тестери. Отправната точка е дълбоката грижа за качеството.
Тестерите не са там само за да извършват функционални тестове и да докладват за грешки. QA ролята е много по-голяма от тази. Ние сме поставени на проект за осигуряване на практики за качество .
Когато дълбоко тестваме приложение, трябва да имаме интимни познания за цялата работа на системата, а не просто да гледаме на приложението като на черна кутия.
За да имаме тези интимни знания, ние трябва непрекъснато да се учим и да сме в крак с новите технологии и начини на работа. Най-важното QAs трябва да бъдат адаптивни.
Когато QA разберат предназначението си на даден проект и започнат да вярват, че тяхната роля е в центъра на разработването и доставката на софтуер, когато възприемем съвременните принципи на тестване, едва тогава можем да променим възприятието на другите.
