Меню

Моето неочаквано пътуване до превръщането в софтуерен тестер (от начално ниво до мениджър)

my unexpected journey becoming software tester

Опитайте Нашия Инструмент За Премахване На Проблемите

'Вие изграждате успешен живот ... Ден в даден момент ...'

Пътуването ми като тестер на софтуер започна малко неочаквано.

Появих се на първоначалните кръгове на интервюта, като предположих, че това е възможност за развитие. За да бъда честен, като всеки друг завършил компютърни науки, бях малко скептичен по отношение на тестването.

Но накрая реших да опитам. Само с надеждата, че любопитният ми характер ще ми помогне в тази област.

Не можах да приема офертата, без да задам този въпрос - ще получа ли възможност да премина към разработка, в случай че тестването не ме интересува? :).

Повярвайте ми - дори никога не ми хрумна да напускам Тестване след това.

как да отворите MKV файлове на Windows

моето пътуване-като-софтуер-тестер

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

Това беше първото ми обучение в тестването - разбрах как ние ( освежители ) бяха оценени.

Дори и днес използвам подобни техники, докато наемам освежители за моя екип. Проверявам тяхната логика, упоритост и подход към даден проблем над всичко друго.

Препоръчително четене => 4 важни неща, които научих по време на пътуването си като QA Test Manager

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

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

За известно време преди нови попълнения в екипа за тестване бях срещу силен екип от 15-16 членове за разработка. Дори след допълненията, QC: Dev съотношението не беше много здравословно и все още мога с гордост да кажа, че това беше успешно пътуване, като се има предвид всичко, което тествахме, доставяхме и обработвахме.

Важният момент, който искам да подчертая тук, е- Всичко това беше от разбирането на Тестването на практика, а не само от теорията.

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

В момента работя като старши QA мениджър, като се грижа за 5-6 продукта и модула. Но това, което ми доставя истинска радост и щастие, е да ръководя екип от 30+ щастливи и страстни тестери.

Разбира се, много хора са допринесли за моето обучение, но все пак мога да кажа, че по-голямата част от моя опит и знания са дошли по трудния начин (и може би най-добрият начин), т.е. да се науча / решавам сам.

„Опитът е най-добрият учител.“

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

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

Примери - Как подходих в различни ситуации

Позволете ми да обясня това с помощта на проблеми / ситуации, срещу които бях изправен и как подходих към тях.

# 1) Бизнес разбирането е много по-високо от тестовете за разбиране

Е, вие всички знаете това. Тестването не е само тестване на няколко проверки и извършване на известна проверка.

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

За всичко това, трябва да разберем бизнеса докрай.

Няма да е погрешно, ако кажа, че трябва да разбираме бизнес и потребителската база толкова, колкото и дори повече, отколкото разбира бизнес аналитикът.

Бях изправен пред подобни шансове.

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

За да разберете по-добре бизнеса и да проектирате по-добре вашите сценарии / случаи, нищо не работи като писалка и хартия.

Прочетете също => 5 Трябва да има инструменти за тестване за тестери, за да улеснят живота

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

Когато пишете / рисувате, това влиза в съзнанието ви с по-голяма яснота и след това умът ви работи върху тази информация и създава повече сценарии и дава по-голяма яснота. Това продължава, докато не почувствате ГОТОВО !!!

# 2) Изпълнение срещу шансовете и под натиск

Работих по продукт, който беше / е достатъчно огромен и сложен, за да накарам екип от 30 инженери да работят непрекъснато в продължение на три дълги години, за да го достигнат до продаваемо ниво.

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

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

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

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

Разбира се, това изискваше истинска бърза и агресивна работа, но при мен се получи.

Това, което имам предвид под агресивен кръг е, насочвате едно по едно (Кажете един елемент от формуляр наведнъж) и го тествайте независимо и заедно с други свързани елементи / неща.

как да пиша потребителски истории и критерии за приемане

Препоръчително четене => Как да бъда наркоман за производителност (особено като тестер)

E.g. Как да тествате текстова кутия.

Това, което можете да тествате тук, е:

  1. Независимо дали приема и съхранява данни такива, каквито са
  2. Проверка на типа данни
  3. Проверка на максимална дължина
  4. Работа със специални знаци
  5. XSS обработка
  6. Многоезична обработка на данни
  7. Обработка на празни пространства / няма данни
  8. Поведение на клавишите tab и enter
  9. Обработка на грешки (кръстосан браузър)
  10. Подравняване на потребителския интерфейс (кръстосан браузър)
  11. Копирайте данните за поставяне / плъзгане на връзки в текстовото поле
  12. Най-важното - поведението на това поле w.r.t. други свързани елементи (всяко бизнес очакване, свързано с това поле, като попълване на нещо в друго поле въз основа на данните в това поле)

Дали мисленето за горното тестване ви дава увереност, че нищо особено не може наистина да се обърка с това поле?

Е, насочването на едно нещо в даден момент винаги работеше за мен и аз също получавах завършване на работа.

# 3) Когато се изправите срещу „неочакваното“

Коя книга мислите, че изведнъж ще ви помогне с „Как да“, когато трябва да направите нещо, което никога досега не сте правили?

Ако говорим конкретно тогава- Няма.

Спомням си времето, когато в отсъствието на нашия продукт олово, аз, заедно с няколко други младши и средни членове трябваше да разгърнем приложението си в демонстрационен (беше производство за нас тогава) за първи път. Беше много критично за първата по рода си демонстрация на нашия продукт.

Е, направихме го, но с много пробни и грешки. Причината е, че никой от нас не е имал опит Linux и скриптове на черупки . Спомням си, имаше наши опасения, повдигнати от нашия ИТ отдел (всички добросъвестни) на моя тогавашен мениджър за това, че изпълнявам грешни команди на производствени сървъри. Може би това беше просто катализатор и скриптове на черупки / Linux беше моят естествен интерес, но след малко след това накрая поех отговорността да поддържам и надграждам пет до шест среди едновременно.

Shell и Linux привлякоха интереса ми толкова добре, че скоро аз започнах да провеждам вътрешни обучителни сесии по него.

# 4) Когато ефективността ви се измерва, опитът ви не е такъв

Много рано в кариерата си бях сравняван и измерван с много еволюиралите и опитни тестери наоколо. Вярвам, че много от вас трябва да са имали подобна ситуация и да знаят какво ви правят тези допълнителни очаквания.

Лекът тук беше да Натиснете се и се развийте .

Единственият път напред беше да не мисля колко по-малко съм опитен, не се ограничавах от световните стандарти за измерване колко бавно / бързо трябва да растя / да се уча. Не се ограничавам до световните критерии колко скоро човек трябва да започне да води и заглавието, от което се нуждае, преди да го направи.

Е, около тази точка, трябва да кажа, независимо към коя област принадлежите, препоръчвам ви да прочетете „Лидерът, който нямаше заглавие“ на Робин Шарма. Това ще ви помогне да разгърнете онова, което се крие във вас. Ще ви каже, че никой освен себе си не може да ви задържи.

Ако трябва да обвържа опита си с няколко изречения, това става по следния начин:

„Вашето любопитство, внимание към детайлите, дисциплина, логическо мислене, страст към работата и способност за дисекция на нещата е всичко, което е важно, за да бъдете разрушител и успешен тестер. Работи за мен и силно вярвам, че ще работи и за вас. Ако притежавате тези качества, това трябва да работи за вас. '

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

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

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

Ученето е неизбежно.

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

Прочетете повече => Ръководството от A до Z за избор на най-добрата автоматизация

Заключение

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

  • Тестването е много трудно да се определи. Някой може да направи превъзходно тестване и може да не е в състояние да го определи с думи. Той е такъв, какъвто го виждате.
  • Всеки може да има своя собствена дефиниция за тестване. Моят беше прост- „Дадено ви е нещо - Намерете грешки и го направете по-добро.“
  • Не е задължително да имате нужда от големи теории, сложни матрици или ISTQB, за да бъдете деструктивен тестер. Трябва да си любопитен , съсредоточени и страстни, мислят логично и имат способност за дисекция. Но познаването на допълнителното не вреди, но не с цената на загубата на същността.
  • Традиционните подходи / концепции също имат своето значение и аз ги уважавам еднакво, като се има предвид фактът, че има добра част от света, където това е просто необходимост. Самото тестване не може да се развие; заобикалящите също трябва да се развият за това.
  • Като тестер става също толкова важно да научете ново инструменти, техники и методологии, докато напредвате . Планиране на тестове, по-добри подходи за извършване на различни видове тестове, Ситуационни тестове са няколко, които трябва да назовем.
  • Тъй като тестването е нестабилно, определението за подходящ вариант също се различава значително от организация до организация. Да бъдеш деструктивен или отличен тестер може да е достатъчно добър, за да получиш проверка за заплата, ако имаш късмет, или може да изисква допълнителни знания за това как тестването работи в традиционните компании. И двамата са точно на своето място.e.g.Наемам хора според моята дефиниция за тестване (което варира малко според опита на кандидата и профила, разбира се).
  • Тъй като има стил на кодиране, шофиране, готвене; има и стил на тестване. Може да не ви хареса, освен ако не го правите по ваш начин. Това, което искам да кажа, е, че тестването може да има насоки, но не трябва да бъде твърдо свързано с микропроцесите.
  • Ефективното олово трябва да накара екипа му да избере работата, вместо да възлага. Понякога може да го променя за подобряване на Продукта.
  • Опитайте се да обучавате хората си в тяхната област на интерес и заедно с това къде искате да бъдат обучени. Съобразете мислите и усилията на вашия екип с крайната цел, която е „Най-доброто качество“.
  • Не се опитвайте да управлявате хората си, водете ги. Бъдете приятелски настроени и достъпни, това значително улеснява работата.
  • Всеки член на вашия екип трябва да обича работата, която върши, да има привързаност към продукта и да е привързан към хората наоколо. Тогава ще излязат само най-добрите от тях.
  • Тестващият свят трябва да се развива. Значителна част от Света се насочва към по-практични подходи като Изследователско тестване, Контекстно тестване (което много хора правят, без да знаят, че е това), което дори други трябва да опитат и разработят повече техники като
  • Трябва да се създадат повече тестващи общности и съмишлениците да се събират в по-голям мащаб. Има толкова много неща за споделяне, учене, адаптиране и иновации.

Надявам се, моят опит и констатации да ви помогнат да станете по-добър тестер или да ви помогне да разберете по-добре тестването.

Допълнително четене => От начинаещ до професионалист: Пълно ръководство за успешно пътуване на тестващ професионалист

За автора: Тази статия е написана от член на екипа на STH Mahesh C. В момента той работи като старши мениджър за осигуряване на качеството, имащ опит в воденето на фронт за тестване на множество сложни продукти и компоненти.

Ще се радвам да чуя в отговор. Коментирайте тук или се свържете с нас. Благодаря много за четенето.

Препоръчително четене

^