Меню

Моя несподівана подорож до тестування програмного забезпечення (від початкового рівня до менеджера)

my unexpected journey becoming software tester

Спробуйте Наш Інструмент Для Усунення Проблем

'Ви будуєте успішне життя ... день у день ...'

Моя подорож тестером програмного забезпечення почалася дещо несподівано.

Я з'явився на перших турах співбесіди, припускаючи, що це можливість розвитку. Чесно кажучи, як і будь-який інший випускник комп’ютерних наук, я трохи скептично ставився до тестування.

Але нарешті я вирішив спробувати. Тільки з надією, що моя допитлива натура допоможе мені в цій галузі.

Я не міг прийняти пропозицію, не поставивши цього питання - чи отримаю я можливість перейти на розробку, якщо тестування мене не зацікавить? :).

Повірте, я навіть ніколи не думав залишити тестування після цього.

як запустити файл Java

моя подорож як тестер програмного забезпечення

Коли я з'явився на технічний тур, я не був готовий ні до чого, крім Основна концепція тестування програмного забезпечення . Думаю, єдиним, що мене пронесло, була думка, що мене оцінюють логічно, а не теоретично ”.

Це було моє перше навчання в тестуванні - я зрозумів, як ми ( освіжувачі ) були оцінені.

Навіть сьогодні я використовую подібні прийоми, наймаючи освіжителів для своєї команди. Я перевіряю їх логіку, завзятість і підхід до проблеми над будь-чим іншим.

Рекомендована література => 4 важливі речі, про які я дізнався під час своєї подорожі як менеджер тестування якості

Я приєднався до Zycus як стажер з контролю якості та отримав продукт приблизно на третій-четвертий день. Це був один з найбільших (був у концепції тоді) та найамбітніших продуктів компанії. Поселившись протягом перших кількох тижнів, для мене не було повернення назад.

Ми починали з команди з контролю якості з двох осіб, і незабаром через кілька місяців я був єдиним, хто керував тестуванням. Протягом перших 2–2,5 років я зареєстрував майже 3000 дефектів у різних категоріях, таких як функціональність, продуктивність, безпека, інтерфейс, зручність використання, Багатомовний , Багатоквартирна оренда тощо.

Протягом значного часу до появи нових членів команди тестування я протистояв сильній команді розробників з 15-16 членів. Навіть після доповнень співвідношення QC: Dev було не дуже здоровим, і я все ще можу з гордістю сказати, що це була вдала подорож, враховуючи все те, що ми протестували, доставили та обробили.

Важливим моментом, який я хочу тут виділити, є- Все це виходило з розуміння Тестування на практиці, а не лише теорії.

Я займаюся тестуванням програмного забезпечення вже майже шість років. Це була дивовижна подорож із такою кількістю різноманітного досвіду та великою кількістю плідного навчання.

В даний час я працюю старшим менеджером з контролю якості, займаючись 5-6 продуктами та модулями. Але те, що дарує мені справжню радість і щастя, - це керівництво командою із 30+ щасливих та пристрасних тестувальників.

Звичайно, багато людей сприяли моєму навчанню, але я все ще можу сказати, що більшість мого досвіду та знань пройшли важкий шлях (і, мабуть, найкращий спосіб), тобто навчитися / вирішити це самостійно.

'Досвід - найкращий учитель'.

Хоча я це кажу, я зовсім не маю на увазі сказати, що вам не виграє вивчення або слідування задокументованим теоріям про тестування програмного забезпечення. Я вважаю, це все, безсумнівно, допоможе, але ніщо не може побороти розуміння концепції в основі і сміливе вирішення проблем.

Я вірю, що документовані матеріали вас не навчать реальне тестування , хоча це може дати вам певний напрямок, і тоді ви самі по собі. Принаймні в моєму випадку були проблеми, які можуть бути не задокументовані для вирішення моїх точних проблем, або я не зміг їх знайти вчасно. Моїм єдиним вибором було зрозуміти проблему / ситуацію в основі і реагувати на неї підходом, який я визнав правильним.

Приклади - Як я підходив у різних ситуаціях

Дозвольте пояснити це за допомогою проблем / ситуацій, з якими я стикався, і того, як я до них підходив.

# 1) Розуміння бізнесу набагато вище, ніж тестування розуміння

Ну, ви всі це знаєте. Тестування - це не просто тестування кількох перевірок та проведення певної перевірки.

Як тестувальник, ми повинні візуалізувати всі можливі сценарії, навіть найрідкісніші з рідкісних сценаріїв безвідмовно. Ми повинні розглянути всі можливі тестові дані, якими може користуватися фактичний користувач.

За все це, ми повинні розібратися в бізнесі в повній мірі.

Це не буде помилкою, якщо я скажу, що ми повинні розуміти бізнес і базу користувачів так само, як і навіть більше, ніж бізнес-аналітик.

Я стикався з подібними шансами.

Я повинен був розуміти складні бізнес-сценарії у сфері закупівель продумайте нові вимоги та зважте їх з точки зору користувача. Я мав не лише опрацьовувати свої справи, а й брати участь у етапах вимог та проектування кожної ітерації. Навіть тут мені не допомогло жодне готове посилання, окрім мого мислення та міркувань.

Щоб краще зрозуміти бізнес та краще розробити свої сценарії / справи, ніщо не працює як ручка та папір.

Також читайте => 5 Потрібно мати інструменти для тестування, які не тестують, щоб полегшити життя

Перед тим, як поїхати Обговорення вимог зустрічі, я заздалегідь записував можливі сумніви / виправлення / незрозумілі моменти. Раніше я писав сценарії, на яких я хочу спробувати або побудувати тестові кейси; іноді навіть малювання сценаріїв працює як шарм.

Коли ви пишете / малюєте, це входить у ваш розум з кращою ясністю, а потім ваш розум працює над цією інформацією, створює більше сценаріїв і дає кращу ясність. Це триває, поки ви не відчуєте ЗВЕРНЕНО !!!

# 2) Виступи проти шансів і під тиском

Я працював над продуктом, який був / є настільки величезним і досить складним, щоб змусити команду з 30 інженерів, які постійно працювали протягом довгих трьох років, щоб вийти на рівень продажу.

Більшу частину початкової фази я або виступав (соло) проти команди з 15-20 розробників, починаючи від молодшого, середнього та старшого рівня, або супроводжував один або кілька інших тестувальників. Усі вони невпинно додавали нові функції до продукту, що вимагало рівної та паралельної уваги з боку тестування.

Будучи частиною зустрічей вимог, написання справ, їх виконання, дослідницьких раундів, обслуговування серверів, розгортання, ніщо не було необов’язковим.

На той час я не знав жодної методології, найкраща практика , курс або книга, яка може показати мені рішення таких проблем. Навіть сьогодні я не впевнений, чи є щось, що може точно допомогти вам боротися з наземними реаліями, коли ви стикаєтесь з ними.

Те, чим я швидше займався, - це агресивний і швидкі раунди пошукових випробувань (Я тоді ще не знав назви) для кожного об’єкта по одному, а потім повторювати. Це рішення працює виключно на тому, як швидко ви можете змінити свої думки та скласти ситуації / сценарії.

Звичайно, це вимагало справжньої швидкої та агресивної роботи, але це спрацювало для мене.

Я маю на увазі під агресивним раундом, Ви націлюєтесь на одну річ за раз (Скажіть по одному елементу форми за раз) і протестуйте його самостійно та у поєднанні з іншими пов'язаними елементами / речами.

Рекомендована література => Як бути наркоманом продуктивності (особливо як тестер)

Наприклад Як протестувати текстове поле.

яке ім’я користувача та пароль мого маршрутизатора

Що ви можете протестувати тут:

  1. Чи приймає та зберігає дані в такому вигляді, як є
  2. Перевірка типу даних
  3. Перевірка максимальної довжини
  4. Поводження з особливим персонажем
  5. Обробка XSS
  6. Багатомовна обробка даних
  7. Обробка порожніх пробілів / відсутні дані
  8. Поведінка клавіш вкладки та введення
  9. Обробка помилок (крос-браузер)
  10. Вирівнювання інтерфейсу користувача (крос-браузер)
  11. Скопіюйте дані вставки / перетягування посилань у текстове поле
  12. Найголовніше - поведінка цього поля w.r.t. інші пов'язані елементи (будь-яке очікування бізнесу, пов'язане з цим полем, наприклад заповнення чогось у якомусь іншому полі на основі даних у цьому полі)

Чи дає вам роздуми про вищезазначене тестування впевненості, що в цій галузі нічого особливо не може піти не так?

Ну, орієнтування на одну річ завжди працювало для мене, і я теж домагався завершення роботи.

# 3) Коли ви стикаєтесь із 'несподіваним'

Як ти думаєш, яка книга раптом допоможе тобі «Як», коли ти маєш робити те, чого раніше ніколи не робив?

Якщо говорити конкретно, тоді - Ні.

Я пам’ятаю той час, коли за відсутності нашого продукту, я разом із кількома іншими членами молодшого та середнього старшого віку мав вперше розгорнути наш додаток на демонстраційному (для нас тоді виробництві). Це було дуже важливо для першої демонстрації нашого продукту.

Ну, ми це зробили, але з великою кількістю випробувань та помилок. Причина в тому, що ніхто з нас не мав досвіду Сценарії Linux та оболонки . Пам’ятаю, наш ІТ-відділ (усі сумлінно) висловив занепокоєння своєму тодішньому менеджеру щодо того, що я запускаю неправильні команди на виробничих серверах. Можливо, це був просто каталізатор і сценарії оболонок / Linux був моїм природним інтересом, але незабаром після цього я в підсумку взяв на себе відповідальність за підтримку та модернізацію п'яти-шести середовищ одночасно.

Shell та Linux настільки добре зацікавили мене, що незабаром саме я почав проводити внутрішні тренінги з цього питання.

# 4) Коли ваші показники вимірюються, ваш досвід - ні

Дуже на початку своєї кар’єри я порівнювався і вимірювався з дуже розвиненими та досвідченими тестерами. Я вважаю, що багато хто з вас, мабуть, переживали подібну ситуацію і знають, що ці додаткові очікування роблять для вас.

Засіб тут повинен був Натисніть і розвивайтесь .

Єдиним шляхом вперед було не думати про те, наскільки я менш досвідчений, не обмежуючись світовими стандартами вимірювання того, наскільки повільно / швидко я повинен рости / вчитися. Не обмежуючись світовими критеріями, як швидко потрібно починати вести та титулом, який потрібно, перш ніж це робити.

Ну, навколо цього пункту, я повинен сказати, незалежно від того, до якої сфери ви належите, я рекомендую вам прочитати «Лідер, який не мав звання» Робіна Шарми. Це допоможе вам розкрити те, що лежить у вас. Це скаже вам, що ніхто, крім вас самих, не може вас стримати.

Якщо мені доведеться перекласти свій досвід кількома реченнями, це виглядає так:

«Ваша допитливість, увага до деталей, дисциплінованість, логічне мислення, пристрасть до роботи та вміння розтинати речі - все, що важливо, щоб бути деструктивним та успішним випробувачем. Це спрацювало для мене, і я впевнений, що буде працювати і для вас. Якщо у вас є ці якості, це має працювати для вас '.

Що ж, читаючи це далеко, якщо ви думаєте, що я просуваю основні людські якості над глибокими теоретичними знаннями, то це не зовсім так. Я вважаю, що починати з чогось і відчувати успіх у цьому, це залежить трохи більше від ваших вбудованих якостей, ніж від інформації, яку ви дізналися. Однак, щоб далеко зайти в будь-якій галузі, вам доведеться засвоїти уроки, принципи та досвід.

У моєму випадку мені також довелося до певної міри вивчати термінології, концепції, теорії, коли я просунувся далі у своїй кар'єрі. Причина в тому, що як тестувальник ви повинні взаємодіяти з кількома людьми, які будуть говорити такими словами, і ви повинні це зрозуміти.

Як керівник або співтестер, у вас буде новий тестер, який приїде з якоїсь частини світу з його власними знаннями про факти, визначення та термінологію. Тут також не можна залишатися пасивним щодо цих речей; ви повинні мати попередні знання про максимум можливих речей, що використовуються / говорять там.

Навчання неминуче.

Мені довелося дізнатись більше про різні типи тестування, як їх виконати та способи пояснити це людям у моїй команді на потрібному етапі. Мені довелося оцінювати нові ідеї, інструменти та реалізовувати їх. Вивчення нових концепцій та методологій стає не менш важливим під час просування по сходах.

Детальніше => Посібник від А до Я з вибору найкращої автоматизації

Висновок

Хоча майже неможливо записати кожну важливу та хвилину, яку я навчився роками, це моя спроба узагальнити це у маркованому списку.

  • Тестування дуже важко визначити. Хтось може провести чудове тестування, і, можливо, не зможе визначити це словами. Це так, як ви бачите.
  • Кожен може мати своє власне визначення тестування. Моя була проста- 'Вам дана річ - знайдіть помилки та покращіть їх'.
  • Вам не обов'язково потрібні великі теорії, складні матриці або ISTQB, щоб бути деструктивним випробувачем. Ти мусиш бути допитливий , зосереджені та пристрасні, мислять логічно та мають здатність до розтинання. Однак знання зайвого не шкодить, але не ціною втрати сутності.
  • Традиційні підходи / концепції теж мають своє значення, і я з рівною повагою ставлюсь до них, враховуючи той факт, що існує значна частина світу, де це просто необхідність. Тільки тестування не може еволюціонувати; оточуючі також повинні розвиватися для цього.
  • Як тестувальник, це стає не менш важливим для дізнаватися нове інструменти, техніки та методології, коли ви рухаєтесь вперед . Планування тестування, кращі підходи до проведення різних видів тестування, ситуаційне тестування - це декілька назв.
  • Оскільки тестування є гнучким, визначення того, як правильно відповідати, також сильно відрізняється від організації до організації. Бути руйнівним або чудовим тестувальником може бути просто достатньо, щоб отримати перевірку зарплати, якщо вам пощастить, або це може вимагати додаткових знань про те, як тестування працює в традиційних компаніях. Обидва знаходяться прямо у себе.напр.Я наймаю людей відповідно до мого визначення тестування (яке дещо змінюється залежно від досвіду кандидата та профілю, звичайно).
  • Як існує стиль кодування, водіння, приготування їжі; також існує стиль тестування. Можливо, вам не сподобається, якщо ви робите це не по-своєму. Я маю на увазі те, що тестування може мати керівні принципи, але воно не повинно бути суворо пов'язане мікропроцесами.
  • Ефективний свинець повинен змусити його команду вибрати роботу, а не доручати. Він може час від часу змінювати його для покращення Продукту.
  • Спробуйте навчити своїх людей у ​​їхній галузі інтересів, а також там, де ви хочете, щоб вони пройшли навчання. Поєднайте думки та зусилля вашої команди з кінцевою метою, яка є 'Найкраща якість'.
  • Не намагайтеся керувати своїми людьми, керуйте ними. Будьте доброзичливими та доступними, це значно полегшує роботу.
  • Кожен член вашої команди повинен любити свою роботу, мати прихильність до продукту і бути прихильним до оточуючих людей. Тоді з них вийдуть лише найкращі.
  • Світ тестування повинен еволюціонувати. Значна частина Світу переходить до більш практичних підходів, таких як дослідницьке тестування, контекстне тестування (яке багато хто робить, не знаючи, що це), яке навіть інші повинні спробувати розробити більше таких методів, як
  • Потрібно створювати більше тестових спільнот, а однодумці повинні збиратися разом у більших масштабах. Тут можна так багато поділитися, навчитися, адаптуватись та впровадити інновації.

Сподіваюся, мій досвід та результати допоможуть вам стати кращим тестувальником або допоможуть краще зрозуміти тестування.

Подальше читання => Від початківця до професіонала: повний посібник з успішної подорожі фахівця з тестування

Про автора: Ця стаття написана членом команди STH Махешем С. На даний момент він працює старшим менеджером із забезпечення якості, маючи досвід керівництва спеціалістами з тестування багатьох складних продуктів та компонентів.

Полюблю почути у відповідь. Коментуйте тут або звертайтесь до нас. Велике спасибі за читання.

Рекомендована література

^