top 10 challenges testers face workplace
Виклики - це нормально. Це коли ви дивитесь на них як на можливості, на золоту шахту і як на перешкоди, на наземну шахту. Протягом багатьох років я мав свою частку 'можливостей' в ІТ-галузі.
Хтось прийшов з роллю, яку я виконував, хтось загальну. Це моя спроба записати їх і звернутися до спільноти, щоб побачити, чи хтось із них резонує з вами, і, можливо, незначною мірою допоможе вам і дасть вам зрозуміти, що ви не самотні.
Ось мій список 10 найкращих:
Що ви дізнаєтесь:
- Топ-10 викликів, з якими стикаються тестувальники на робочому місці
- Тестування / специфічні проблеми контролю якості
- Інші виклики
- Рекомендована література
Топ-10 викликів, з якими стикаються тестувальники на робочому місці
# 1) Культура компанії:
Це почесний перший пункт у списку, тому що, перебуваючи в індустрії ІТ-послуг, я стрибав між кількома клієнтами, командами, місцями та компаніями. Я любив бути частиною деяких команд, а деякі, ну, я б не повторював досвід.
- Команда, в якій я працював, стартувала о 6 ранку. Ще один наполягав працювати до 18 години.
- Один змусив підрядників увійти в будівлю через інші двері, а інший, який навіть не вірив у доступ до картки, що проводить пальцем
- Один з нас змусив залишити всі мобільні пристрої з пам’яттю, Bluetooth чи будь-яким іншим підключенням зовні, тоді як інша компанія цілий день грала чудову музику на робочому місці.
- Деякі компанії дотримуються суворої ієрархії, коли їхній генеральний директор набуває статусу знаменитості, а інші, які не мають кабінок, і всі були рівні.
З часом я зрозумів, що не існує жодного правильного чи неправильного шляху; це просто їхній спосіб. Враховуючи час, ми завжди адаптуємось до обставин, але якщо ви цього не зробите після того, як дасте йому чесний шанс, знайдіть найближчий до вас вихід.
# 2) Різні часові пояси:
Ти залишаєшся в офісі чи вдома перед ноутбуком о 23:00 чи о 5 годині ранку, намагаючись наздогнати свої команди, які розподілені по географії? Це надто звично, чи не так?
Насправді немає протиотрути до цієї проблеми (може бути, кава?) Використовуйте годинники, які показують точний час у різних місцях (світовий годинник на вашому смартфоні теж працює), ідеальні протоколи зв'язку таким чином, що не потрібно проводити зустрічей з питань вирішується через електронну пошту та практикується свідоме планування часових поясів, щоб уникнути цієї проблеми в основному.
Рекомендуємо прочитати => На місці - офшорна модель тестування програмного забезпечення - змусьте це працювати для вас
# 3) Міжкультурні відмінності:
Я працював як в Індії, так і в США. Незважаючи на те, що корпоративна культура досить неетнічна, де ми перебуваємо, це впливає на нашу поведінку та розуміння.
як подати звіт про помилку
Наприклад: 'Привіт, як ти?' є звичним привітанням у США. Це не обов'язково означає, що вони хочуть точно знати, що ви відчуваєте в даний момент. Однак, коли я був новим у США, я думав: «Я щойно був на зустрічі з цією людиною. Що зміниться за такий невеликий час? ' :) Мені добре, я швидко навчився.
Крім того, в одних культурах розмова менше означає тихе споглядання, тоді як в інших це просто означає, що це нудно або вам нема чого сказати.
Коли ви намагаєтеся зрозуміти ці дрібні нюанси, ви краще розумієте людей і можете краще функціонувати.
Тестування / специфічні проблеми контролю якості
# 4) Немає документації:
Класичний. Багато команд досі вірять у словесне спілкування і зберігають мало довідкового матеріалу про те, як програмне забезпечення стало таким, яким воно є сьогодні. Швидкі цикли розвитку лише зробили це більш інтенсивним.
Однак це насправді один із випадків, коли проблеми стають можливостями.
Беріть участь у розмовах зі своїми розробниками, аналізом бізнесу або технічними командами. Дослідити застосування; створити посилання на аналогічні програми та їх стандарти. Зрозумійте перспективу кінцевого користувача. Отримайте авантюру завдяки пошуковому тестуванню.
Щоб дізнатися більше, перевірте => Як протестувати заявку без вимог?
# 5) Нестабільне середовище:
Зазвичай команди з контролю якості страждають від погіршеного середовища, в якому ми повинні бути справді готовими максимально використати те, що маємо.
Наприклад: Сервер, який перевантажується і потребує перезапуску кілька разів під час тестування, журнали, які часто потрібно очищати, щоб переконатися, що немає переповнення тощо.
Виведіть ці проблеми на перший план і переконайтеся, що ви отримуєте підтримку навколишнього середовища під час тестування. Для випадків, що часто трапляються, отримайте доступ до серверів із кроками, щоб виконати просте обслуговування, таке як перезапуск, очищення черг тощо.
Рекомендуємо прочитати => Як мінімізувати дефекти тестового середовища
# 6) Інструменти, що подаються з силою:
Іноді ми знаємо, що інструмент не підходить для роботи. Нам не залишається іншого вибору, як продовжувати користуватися ним, оскільки клієнти / команди вже мають ліцензії і не хочуть йти на нову, поки не закінчиться поточна ліцензія.
Мені довелося протестувати додаток Mainframes на HP QTP без надбудови Terminal Emulator. У цьому випадку я мав інструмент, але не правильну конфігурацію. Я мало що міг з цим зробити, тому мені довелося переходити між нормальним та низькорівневим режимами запису як обхідне рішення.
Це не весело, але ви вивчаєте альтернативи. Або, принаймні, ви дійдете до певного висновку щодо того, працюють альтернативи насправді чи ні.
Також читайте => Посібник від A до Z щодо вибору інструменту автоматизації
# 7) Деякі програми просто не вирізають:
Ви коли-небудь тестували додаток і починали задаватися питанням: 'Як це взагалі можна назвати програмним забезпеченням, коли це машина, що виробляє помилки?'
У мене був цей особливий привілей, де більшість мого дня стосувалось просто повідомлення про помилки та ще деяких повідомлень про них. Деякі області програми вирізані внаслідок цих помилок. Весь спектр суворості відкидає вас від гри, і стає непереборним, коли ви починаєте думати: 'Чи є сенс у тому, що я тут роблю?'
Понаднормово, я навчився твердо вирішувати, що програмне забезпечення не готове до тестування та відхилити збірку. Я більше не шукаю срібну підкладку, коли її немає.
Інші виклики
# 8) Люди-примхи:
Ви коли-небудь стикалися з розробником, що стукав столом у конференц-залі, як тільки ви пояснили дефект? Так, це сталося зі мною. :) Пізніше я дізнався, що це його форма висловлювання, а не загострення.
У мене також був член команди, який спочатку виявився незгідним і грубим, але насправді був просто сором'язливим. Ця людина навряд чи скаже кілька слів або зустріне погляд, коли її попросять оновити статус. Я був дуже близький до того, щоб скласти негативний огляд ефективності та ескалації, якби я не розумів, що ті самі деталі можна легко та детально отримати від нього по електронній пошті. Йому не сподобалась ця розмова один на один.
Кожен різний і заслуговує на користь сумнівів. Не поспішайте судити і поважати межі.
Також прочитайте це => Як ефективно керувати тестовою командою
# 9) Відсутність циклу зворотного зв'язку:
Іноді ви їдете днями в кінці, працюючи над і зациклюючись на результаті, лише щоб дізнатися, що це не повинно було бути таким чином.
Або ви працюєте з віддаленого місця разом зі своєю командою, яка знаходиться в іншому місці, і ви відчуваєте себе ізольованою і не має від кого відбити ваші ідеї.
Або ви отримуєте відгук, який не зовсім корисний. Скажімо, ви створили технологічний документ, і вони сказали, що це добре. Ви не бачите документ процесу, опублікований або введений у користування, і вам залишається цікаво, що з ним сталося. Отже, „хороший” зворотний зв’язок тут нічого доброго не дав і є майже невідгуком.
Шукайте чесних відгуків та створюйте спільноту для обговорення ваших ідей. Не часто це найпростіше зробити, але без позитивного підкріплення, яке дає цей крок, ви залишаєтесь демотивованими.
# 10) Попередньо вироблені уявлення:
Ну, ми знаємо, що на робочому місці є багато забобонів навколо статі, національності тощо. Я не буду тут вдаватися до конкретних особливостей, але якщо ми не почнемо дивитись на світ як на глобальне село, а всі рівні, світ і робоче місце стануть токсичний.
Про автора: Дякуємо члену команди STH Сваті за те, що він поділився цими 10 найвищими викликами, з якими стикаються тестери.
Тепер твоя черга.
Якого з пунктів у списку ви здивували чи кивнули головою, щоб зрозуміти? З якими викликами стикалися і як їх долали?
Будь ласка, поділіться та коментуйте!
Рекомендована література
- Незабаром глобальний бізнес з тестування програмного забезпечення досягне 28,8 мільярда доларів
- Поради щодо тестування програмного забезпечення для початківців тестувальників
- Як зберегти мотивацію живою в тестерах програмного забезпечення?
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
- Дзен і мистецтво тестування програмного забезпечення
- Тестування програмного забезпечення QA Assistant Job
- Кращі статті про тестування програмного забезпечення 2008 року
- Проблеми, пов'язані з ручним та автоматичним тестуванням