Виктор Славчев е software testing специалист с над 3 години опит в областта. Той има опит в областта на mobile, integration testing, web testing, exploratory и non-functional тестването. На събитието „Exploratory testing: scientific and creative thinking in realtime“ на 20-ти февруари, той ще ни представи какво място има automation в exploratory testing process-а и защо никога не сме чували за automated exploratory testing, как да подобрим exploratory тестването си и много други. Какво мотивира Виктор в работата му и как той вижда софтуерното тестване, прочетете в следващите няколко абзаца.

Как започна да се занимаваш с Quality Assurance?

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

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



 

Събитие на фокус:

Reflective Injection using TypeScript

 


 

Какво те мотивира и вдъхновява в работата ти?

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

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

Кой е най-интересният bug, който си открил?

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

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

Какво представлява софтуерното тестване, през твоят поглед?

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

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

Тестването е разследване – както в детективските романи и криминалните сериали – ние имаме „заподозрени“ – рискове, които мога да костват успеха на софтуерния продукт или да подронят доверието и авторитета на компанията, в която работим или да костват финансови загуби. За да открием тези заподозрени ние:

  • търсим улики – информация, която може да ни помогне да намерим проблеми.
  • „оглеждаме местопрестъплението“ – опознаваме средата, в която работи нашето приложение, опитваме се да разберем как то може да бъде зависимо от нея, как можем да предизвикаме проблеми в него ако променим нещо в нея.
  • Разпитваме свидетели – основна част от работата на един опитен тестер е да задава въпроси и то не какви да е, а правилните въпроси. С цел да предоставим коректна информация за качеството на продукта, ние трябва да съберем правилна информация от правилните хора – клиенти, технически екип, мениджмънт, маркетинг, sales агенти и т.н.

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

Издай ни малко информация. Какви теми ще засегнеш в презентацията си на 20 февруари.

На презентацията ще засегна теми, свързани с грешните представи, които се изграждат за софтуерното тестване, като цяло те клонят около няколко грешни схващания:

  • Че тестването е елементарна задача съставена от стъпки, които трябва да се повторят.
  • Следователно всеки може да я върши.
  • Или да напишем програма, която може да я върши безпогрешно, елиминирайки участието на човека.
  • Че можем да измерим ефективността на един тестер с броя тест кейсове, които е написал или с броя бъгове, които е логнал.
  • Че можем да бъдем успешни без значение на ситуацията, стига да следваме „добрите практики“

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

Стани част от потребителската група Software Quality Assurance. Абонирай се и ще ти изпращаме информация за всичко, което предстои в групата.

Визия: Личен архив

Прочети още:
Предизвикателствата при работа в дистрибутирани екипи
„Характерно за нас, QA-ите, е че не се вписваме в рамки” – Камен Янков, QA Team Lead

Share This