Ефективни най-добри практики за осигуряване на качество

Работейки в Ефективно, участвах в повече от 30 различни проекта. Всички те бяха напълно различни: уеб и мобилни, големи и малки, сложни и прости. Ние изграждахме проекти от нулата, добавяхме нови функции и поддържахме съществуващи проекти.

Имаше много трудни случаи в процеса на осигуряване на качеството, тестване, управление и развитие и сега изглежда, че екипът ни премина Per Aspera ad Astra.

В момента изглежда, че нищо особено не е направено, но сравнявайки Ефективно от време на време мога да кажа, че направихме огромна крачка напред. Анализирайки грешки бяха направени, желания и предложения на екипа, аз подготвих следния списък с най-добри практики за гарантиране на качеството. Целта на този списък е да помогне на младите екипи да разберат какво може да им бъде полезно, без да отделят много време за изследвания. За някои от опитните това може да изглежда като повторно изобретяване на велосипеди :) Ето!

Разберете бизнес целите и изяснете критериите за приемане

Това е крайъгълният камък на един проект и трябва да се изясни преди началото на развитието. Екипът на проекта трябва да разбере какво трябва да се направи, кой е целевата аудитория / потребител на функции и как да разбере, че не остава нищо друго.

Разбирането на бизнес целите ще ви помогне да отговорите на въпроси като „Какво трябва да правим и кой ще ги използва?“. Критериите за приемане ще ви помогнат да разберете дали дадена функция отговаря на бизнес целите или не. От моя опит мога да кажа, че бизнес целите и критериите за приемане трябва да бъдат потвърдени от клиент или представител на клиента. Освен това, въз основа на ясни и прозрачни бизнес цели и критерии за приемане, квалифицираните компании за разработка на софтуер за аутсорсинг могат да надграждат бизнес идея или да предложат по-добро решение.

CI / CD - непрекъсната интеграция / непрекъснато внедряване

Звучи ми познато ... нали? Едно от най-важните неща в настоящата разработка на софтуер, основното предимство на което от гледна точка на QA екипа е, че лесно можем да получим изграждане с най-новите функции или поправки.

По време на цикъла на развитие, нашият екип за разработка може да има много git клонове, свързани с различни функции, но само един клон съдържа най-актуализирания код. Инструментът CI проверява този клон и когато кодът се промени, той създава нова компилация и го споделя на определена услуга за разпространение.

Опитахме TeamCity и Jenkins. И двете са страхотни инструменти. TeamCity има по-красив потребителски интерфейс, но Jenkins е абсолютно безплатен, затова избрахме Jenkins.

Услуги за разпространение на приложения

Като цяло изглежда, че няма нищо особено, но под капака, непрекъснатата интеграция с тунинговани услуги за внедряване на приложения ви дава най-лесния и бърз начин да получите най-новото изграждане на всяко тестващо устройство или среда, която искате. Добре е да качвате изграждане чрез USB на едно устройство. Но какво ще стане, ако трябва да проверите компилацията с помощта на 10 различни устройства? Това е въпросът.

За мобилни проекти сме опитали няколко различни услуги като HockeyApp, Beta by fabric (ex-Crashlytics), Test Flight от Apple, Play Console от Google. Разбира се, има повече услуги, но те са избрани за най-популярни. Сега гласувам за тестовата конзола за полети и игра, тъй като тези услуги са гъвкави, поддръжка на вътрешни и външни функции на тестери и официални услуги от Apple и Google и от тестери е необходим само имейл. Единственото ограничение тук е, че се нуждаете от акаунт за разработчици на Apple и Google, който струва 25 $ за Google (еднократно плащане) и 99 $ за Apple (годишно).

Други услуги като HockeyApp или Beta имат известни затруднения с добавянето на нови тестери към проекта, особено на iOS. Поради грижата за сигурността на Apple, от тестерите е необходимо да предоставят UDID на своите устройства на програмиста и разработчикът трябва да добави тези UDID-и към проекта. Тъй като споделяме разработки на разработчици с нашите клиенти (които обикновено имат много различни устройства и ги сменят редовно), всички ни се умориха от тези дейности по събиране на UDID. Ето защо ние избрахме тестовата конзола за полети и игра.

За уеб проектите всичко е малко по-просто, тъй като използваме специална тестова среда, която се актуализира от инструмента CI при промяна на клона на разработката.

Документация за тестване

През годините нашият екип по QA измисли четири най-ценни документа, които могат да бъдат споделени с клиенти или заинтересовани страни:

  • Поддържани платформи
  • Тестов план
  • Тестови случаи / Контролни списъци
  • Бележки към изданието

Поддържаният документ за платформи трябва да бъде подготвен възможно най-рано, когато проектът започне и се подпише с клиента. Той трябва да съдържа информация за поддържаните хардуерни и софтуерни конфигурации, известни ограничения и ограничения. Той се основава и на устройствата на целевата аудитория, тъй като пазарите на устройства са различни в различните страни.

Подписвайки това с нашите клиенти, ние гарантираме, че първата версия на даден продукт работи перфектно върху изброените конфигурации, освен това уведомяваме нашите клиенти, че продуктът може да работи и върху другите конфигурации, но може да се появят някои проблеми. И ако продуктът и целевата аудитория нарастват, ще можем да анализираме и внедряваме допълнителна поддръжка на платформи. В бъдеще този документ ще ни позволи да се съсредоточим върху определените платформи в разработката и корекцията.

Тестовият план също трябва да бъде подготвен в началото и да бъде споделен с клиента. Този документ трябва да съдържа всички видове тестове, които ще бъдат използвани при разработването на продукта с описана цел за всеки тип. В плана за тестване екипът по QA трябва да реши какво да използва за тестване, тестови случаи или контролни списъци. Обикновено това зависи от продължителността на проекта и функционалната сложност. Поддържаните платформи също трябва да бъдат свързани с тестовия план. И накрая, планът за изпитване трябва да съдържа информация за планираните тестови дейности по дати, следващи разработването на проекта и времевата линия на освобождаване.

Тестови случаи / контролни списъци е задължително нещо за всеки проект. Разбира се, отнема известно време за подготовката на тези резултати и може да отнеме допълнително време за поддръжка на тази документация, но ви дава някакъв вид ствол на дърво и с помощта на този багажник можете лесно да си представите и създадете нови сценарии за тестване, само като добавите клонове към багажника си. По-късно можете да споделите подготвени тестови случаи с UAT екипа от страна на клиента или с бета тестери или дори да покажете тестови случаи на екипа за разработка на проекта. Екипът на Dev може да използва тестовите случаи като част от изискванията и наистина може да им помогне да избегнат някои проблеми.

В Effective ние опитахме много TMS (система за управление на тестове) и избрахме TestRail като един от най-популярните, адаптивни, бързи и удобни инструменти за управление на тестови случаи и управление на тестове. Използването на TestRail ни позволява лесно да актуализираме тестовите случаи и контролните списъци. За нас този инструмент е страхотен, но все още има много алтернативи. Основният съвет тук е да използвате правилния TMS и да не използвате Google Документи и Електронни таблици за тестови случаи и тестови дневници :)

Бележки за изданието е документът, подготвен от нашия екип по QA за клиенти и съдържащ актуална информация за проекта. Какви функции бяха завършени в конкретния спринт, какво все още е в ход, какви са известни проблеми, къде и как може да бъде изтеглена демонстрацията. Ние винаги подготвяме бележки за изданието чрез спринт и чрез издаване. Това дава на нашите клиенти допълнителна прозрачност относно напредъка на развитието.

Изследователски тестове

Последното нещо, което не бива да се забравя, е изследователски тестове. Основната цел на това тестване е да разбере по-добре вашия продукт и да го погледне от гледна точка на потребителя. Комбинирайки проучвателно и скриптирано тестване (под скриптирано тестване имам предвид тестови случаи или използване на контролни списъци), комбиниране на възприемането на тестера и потребителя на продукта и като се имат предвид бизнес целите, можете да направите продукта, върху който работите, възможно най-съвършен.

Като част от проучвателните тестове използваме и подхода за тестване на рояка. Използвайки конзолата за тестване на полети и игри, ние каним външни тестери, които обикновено са ефективни служители, които са извън проекта и могат да действат като бета тестери. Това ни позволява да получим преглед на продукта от гледна точка на потребителя и да обърнем внимание на използваемостта.

Обобщение на ефективните QA Best Practices:

  • Разберете бизнес целите
  • Изяснете критериите за приемане
  • Познайте поддържаните от вас платформи
  • Подгответе тестов план
  • Използвайте тестови случаи / контролни списъци
  • Използвайте непрекъсната интеграция + непрекъснато внедряване
  • Поддържайте актуализирани тестови случаи / контролни списъци
  • Споделете бележки за версиите с вашите клиенти
  • Никога не забравяйте за проучвателните тестове

Благодаря за четенето! Чувствайте се свободни да коментирате, ако искате да знаете повече, не сте съгласни или имате някакви въпроси :)