Непрофесійні проблеми тестування в пострадянській державі, Комерція, Різне, статті

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


Запитаєте: «Чому саме в пострадянській державі? Подібні проблеми є майже скрізь ». З однієї простої причини: в пострадянській державі ці проблеми мають своє коріння і специфіку, зважаючи на унікальний менталітету живуть тут людей, як керівників так і тестувальників. Саме з цього я буду використовувати термін «Наші» люди в лапках, що б було зрозуміло, що мова йде про людей виросли і живуть в постоветском державі.


У продовженні всієї своєї кар’єри тестувальника мені доводилося чути дуже багато різних питань на одну наболілу тему «Коли ж наше керівництво почне відноситься до тестування як до одного з основних етапів розробки ПЗ? Невже вони там цього не розуміють? ». Ризикну припустити, що 99% тестувальників на пострадянському просторі, так чи інакше, стикалися з подібною проблемою. А навіть якщо і не 99%, а 75%, то це особливо картину не змінює. І найнеприємніше, що ці проблеми жодним чином не відносяться до професіоналізму тестувальників або його відсутності. Це проблеми, які найчастіше ставляться до некомпетентності керівництва. І ось тут я задумався, а чи завжди це питання некомпетентності керівництва? Може іноді самі ж тестувальники не розуміють таємний сенс їх керівників. Або просто не володіють потрібними знаннями що б зуміти оцінити ситуацію. Ось тепер, коли завдання стала більш зрозумілою, спробуємо її проаналізувати з двох сторін: тестувальника і керівника.


Давайте спершу спробуємо окреслити коло основних проблем, з якими доводилося стикатися:



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


Недостатньо ресурсів для тестування


Спробуємо визначити причини цього, і проаналізуємо кожну з них. Я бачу тут кілька причин:


Немає можливості додати ресурси


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


Керівнику слід не соромлячись сказати про це колективу. Наведу приклад із власної практики. Коли я працював в молодої компанії, в один прекрасний день наш керівник всіх зібрав і оголосив, що в компанії залишилося грошей рівно на півтора місяця. Якщо ми не знайдемо замовника (ів) протягом цього часу то компанія буде закриватися. Ми всі отримали право на пошук роботи і поїздки на співбесіди, проте всі працювали до останнього. Замовника ми знайшли і ця компанія успішно працює вже більше 5-ти років після цього випадку. Така практика, на жаль, більше поширена за кордоном, а не в пострадянському державі у «наших» керівників. З цього не бійтеся говорити людям правду. «Наш» народ не вміє відступати, і не любить здаватися. Тут Ви дізнаєтеся істинний дух компанії, і побачите на кого можна покластися.


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


Нерозуміння керівництва в доцільності додавання ресурсів


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


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


Жадібність можновладців


Тут ми можемо говорити про те, що керівник свідомо робить вигляд, що він не розуміє очевидні докази або намагається «вичавити» людей як лимон, щоб поменше витратитися. Таке можна визначити зсередини компанії, і спробувати поговорити з таким керівником вельми різко і прямо. Швидше за все Вам доведеться поміняти роботу. Такі керівники навряд чи зміняться.


Їх непотрібність


Якщо Ви не розумієте що відбувається – це ще не привід лаяти інших.


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


З іншого боку, це великий недолік керівництва, що воно не донесло свої стратегічні плани, по даному продукту, до підлеглих.


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


Проблеми в процесах розробки, які «звалюють» на непрофесіоналізм тестування


Якщо у Вас всього достатньо, і Ви страждаєте від того, що розробка ведеться «з рук геть» погано, тоді Вам варто поспілкуватися з керівником проекту та директором НЕГАЙНО. Відразу як тільки з’являються проблеми. Чи не накопичуйте їх. Вам необхідно описати Ваші проблеми. Відразу обмовлюся, не варто описувати проблеми в інших відділах. По-перше, Вам треба в цьому розбиратися самому, для того, щоб вказувати що правильно, а що ні. По-друге, Ви, скоріш за все, переведете фокус з Вашої проблеми. Отже, Ви описали Ваше бачення того, що йде не так у Вашому відділі. У загальному випадку, після обговорення цих проблем з керівником і начальником проекту, практично всі проблеми вирішуються. Можна все обговорити записати і працювати по писаному. Можна домовитися усно (краще письмово), якщо Ви довіряєте один одному. У будь-якому випадку вихід є.


Але що робити якщо у Вас не загальний випадок. Наведу приклад з особистої практики. Коли я тільки починав роботу тестувальником мені довелося працювати з керівником проекту, основне кредо якого: «Головне прикрити свій зад кілочками ». Чесно кажучи і зараз зустрічаються такі, але на щастя, мене поки доля відводить від таких. (Напевно з першим напрацював на все життя.) Так ось цей керівник проекту, сам по собі був дійсно молодцем: Він підняв проект без документації, знав практично все, що було в цьому проекті. Але от біда, він не хотів це нести в маси. Він вважав, що чим більше він знає, тим більше він не замінимо. Ну не так «наш» людина. Набирав він ці знання на протязі півтора року, поки не з’явився я, і мої колеги тестувальники. Типова проблема більшості «наших» проектів – це немає ніякої документації, а якщо і є, то вона катастрофічно не встигає за розвитком подій в проекті. Ось в такому режимі ми попрацювали пів року. Навіть виставку в Ялті пройшли успішно. Але в термін, на жаль, не вклалися. Занадто багато проблем залишалося в продукті. Здавалося б, ну от і молодці тестувальники, славно потрудилися. А не тут-то було. Наш начальник був перед вибором, сказати керівнику проекту що він і його команда працюють незадовільно і шукати шляхи виходу, при цьому ризикуючи що керівник образиться (сказати по правді, він би точно образився, все-таки «наш» до мозку кісток). Або вказати на недбайливе тестування, що погано шукаємо помилки, продукт до сих пір має багато проблем, і далі по тексту. Начальник вибрав другий варіант. Теж «наш» людина. Не обговоривши з начальником відділу тестування, він його просто просить шукати інше місце роботи. Ось це «наш» підхід. Цілком допускаю, що наш керівник зробив стратегічне рішення, при чому правильне. Але ось втілив він його по «нашому». Мораль прикладу проста: якщо у Вас такий розклад, подумайте про зміну роботи.


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


Принципова відмінність, в даному варіанті, від попереднього в тому, що тут у Вас навіть немає шансу встигнути за розробкою. Спочатку. Через це, дана проблема виглядає, м’яко кажучи, підготовленої, що Чи. Рішення те саме. Йти і говорити з керівництвом. Відразу. Не зволікаючи. І тут шансів набагато менше, ніж у попередньому типі, що у Вас вийде вирішити дану проблему. Саме тому, що вона набагато очевидніше і може бути спрогнозована набагато раніше чим виникла. Якщо люди не розуміють того, що відбувається, то їм просто потрібен крайній для якихось своїх таємних цілей. Це цілком в «нашому» дусі. Мораль все та ж. Шукайте нову роботу.


Проблеми в процедурах самого тестування


Все є. Тестувальників вистачає. І час на тестування є. Що ж може бути не так? Може бути не так сам процес управління тестувальниками. Тут уже все що завгодно. Але в більшості випадків корінь зла в керівнику відділу тестування. Так, якщо Ви бачите сусіда читає новини в інтернеті, в той час як Ви зайняті по вуха, і не маєте часу навіть зрозуміти який розділ він читає, зверніться до Вашого безпосередньому начальнику, начальнику відділу тестування. Якщо Вас не підвищують нарівні з іншими, знову ж таки туди. До нього. Звичайно ж, не все залежить від начальника відділу тестування. Він не може вирішити всі питання. Але якщо відбувається щось ненормальне в розподілі завдань, в просуванні по службі, зрештою, тільки у тестувальників ні РК моніторів, то треба говорити з Вашим керівником. Якщо це не допомагає, ескаліруйте проблему на рівень вище.


У деяких випадках проблема може бути не в вашому начальнику. Наведу приклад з моєї практики: у нас в компанії не було окремо виділеного відділу тестування. Кожен проект мав набір своїх тестувальників на чолі з їх керівниками. І ось, в черговий робочий день, мене викликав великий начальник і каже: «Ось я плачу тестувальникам зарплату. Регулярно її підвищую. А хто мені може сказати відповідає Чи вона насправді? Чи справді я піднімаю її заслужено? Хто мені розповість дійсно чи один тестувальник краще ніж інший? »Тут є проблема довіри до керівників тестірощіков. Але нам важливіша інша проблема – в організації не було єдиної системи. Не було єдиної культури тестування. Такий метод добре працює коли тестувальників небагато, всі сидять поруч і діляться один з одним інформацією. Хто як працює, що і чим тестує. Як рапортує і т.д. В такому випадку є людина яка може охарактеризувати всіх тестувальників, нехай навіть він і працює не в його проекті. Однак коли в організації стає багато тестувальників, виходить, що ви можете просто не знати один про одного. Ви можете сидіти за стінкою, робити одне і те ж. Вирішувати ті ж проблеми і навіть не підозрювати, що поруч є людина, яка може допомогти. Не було системи обміну знаннями. Це вже проблеми більш високого рівня компетенції. В такому випадку необхідно організувати окремий тестовий відділ. Вибирайте самого шановного керівника тестувальників і робіть його головним. Що б він знав, де скільки людей. У кого який рівень знань. Хто в чому сильний. Кому які ресурси потрібні, і т.д.


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


Керівництво втручається в роботу тестувальників не володіючи достатньою компетентністю в області тестування


Якщо попередня проблема була, здебільшого, з вини тестувальників, то дана проблема існує тільки лише з вини «наших» всезнаючих керівників. Що тут порадиш. Якщо Ви добре знаєте своє справу, то швидше за все Ви будете часто сваритися з начальством і Вас або попросять, або Вам це самому набридне. Якщо ж Вас це влаштовує, то і проблеми немає. З досвіду скажу, був у мене такий начальник, під час перебування мою розробником. Він навіть у дизайни ліз і, дивлячись на запущену програму, міняв графічний користувальницький інтерфейс «на льоту». Компанія, мабуть, існувала не для того, щоб зробити продукт. Та ще «наша» компанія. Закінчила вона, як і годиться, плачевно. Кращі уми пішли досить швидко. Була ще спроба щось продовжити зі студентами. Останнє що я чув про цю компанію, що її співробітники судилися з директором. А компанію закрили. Робіть висновки самі.


Терміни на тестування свідомо недостатні (потворне керівництво)


Як переконати керівництво, що треба більше часу? Брак часу – це завжди велика проблема для тестувальників в непродуманих проектах. Серед нас дуже багато тих, хто відданий справі якості ПЗ до мозку кісток, і не бажає пропустити навіть косметичну помилку. Буде грудьми стояти за виправлення шрифта в «глубоковложенной» формі, яку може і відкриють лише п’ять разів за весь час експлуатації ПЗ. Більшість тестувальників можуть відчувати мало не фізичний біль від усвідомлення того, що в продукті є помилки, але часу на їх пошук немає. Адже і часу немає не тому що необхідно випускати продукт раніше конкурентів або з якоїсь іншої зрозумілої причини. А тому що відразу не продумали, чи ще гірше, не захотіли витрачати часу і коштів. Підливає масло у вогонь ще й той факт, що люди встають перед дилемою, «… а навіщо тоді потрібно це саме тестування, якщо свідомо результат буде, в сенсі продукт буде з помилками … ». Якщо Ви зіткнулися з такою проблемою, відразу опишіть її і відправте керівнику проекту і його начальнику. Не бійтеся. Опишіть що за такий період Ви встигнете протестувати тільки от таку-то частина продукту. Якщо вони Вас не захочуть слухати, значить їх не цікавить якість ПЗ. З іншого боку, Ваша справа довести до відома керівництва, що тестування буде проведено в такому-то обсязі, і якщо в нетестіруемих частинах продукту будуть виявлені помилки на стадії експлуатації продукту, то це цілком не Ваші проблеми.


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


На тестувальників покладають роботи незв’язані з тестуванням


Тестувальника «змушують» писати вимоги, підтримувати їх в актуальному стані. Просять збирати різноманітну інформацію, яку не встигають або не бажають збирати ті, хто повинен це робити. Але в Здебільшого, як це не сумно, це «чорнові» роботи, які, нібито, нікому більше робити. Дана проблема з’являється з кількох причин: 1. простого нерозуміння керівництвом обов’язків тестувальника; 2. Неправильним процесом розробки, див. п. 2 а, 3. Бажання «спихнути» нудну роботу на когось; 4. Брак ресурсів см. п 1. Ми не будемо тут зупинятися на причини неправильного процесу або нестачі ресурсів. Це окрема проблема яка описана вище. Просто відзначимо, що дані проблеми перегукуються і, як одним з результатів неправильного процесу або нестачі кадрів, ми отримуємо роботи не пов’язані з тестуванням. Зосередимося тут на причини нерозуміння керівництвом цілей, які стоять перед тестуванням в цілому і перед конкретним тестувальником зокрема, а так ж торкнемося питання про статус тестувальника в деяких компаніях.


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


Ще одна дуже важка тема – це статус тестувальника в компанії. Нерідко доводилося читати, що на тестувальників ніхто не звертає уваги, ніхто ними не займається, тестуємо що скажуть без підготовлених документах, так би мовити «на колінах», і т.п. Якщо у Вас в компанії таке ж відношення, то не дивуйтеся чому ви роздруковуєте документи для керівника проекту або міняєте картридж у принтері. В такої компанії хороші тестувальники не потрібні. Там потрібні різноробочі які, до всього іншого, ще трохи і тестувальники. Якщо Ви хочете стати хорошим фахівцем в області якості ПЗ, тоді йдіть (Швидше за все це Вам і запропонують коли Ви почнете виконувати Ваші безпосередні обов’язки.).


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


А «наші» тестувальники повинні частіше дивитися на себе, і спілкуватися за своїми питань з керівництвом, перш ніж скаржитися й лаятися на весь світ. Не всі проблеми, які на них звалюються, породжуються керівництвом або іншими співробітниками. Не варто боятися розмов з керівництвом і треба бути більш допитливими. Ще приклад з особистої практики. Буваючи в різних країнах у замовників і слухаючи своїх колег, які були там де мені не пощастило бути, я побачив закономірність, що чим більше країна була, або до цих пір є, під жорстким управлінням партії або громадських організацій, кланів, спільнот та ін тим менш вільні і самолюбні ці люди. Це дуже яскраво виражено в таких країнах як Індія, Корея, Китай. Там взагалі складно уявити що б тестировщик, порушуючи жорстоку субординацію, почав розмовляти з «високим» начальством. І навпаки, з якою легкістю тестировщик розмовляє про свою роботу з керівником в Європі чи Америці. Навряд-чи я «відкрив Америку» даними спостереженням, однак те, що це накладає відбиток на «наших» людей, ми можемо переконатися в нашій пострадянській країні і дана стаття це зайвий раз підтверджує.


Не стану завершувати статтю таким ось невеселим висновком. Справедливості заради скажу, що за останні 3 роки, я зіткнувся тільки з однієї з вище перерахованих проблем, яка була досить швидко вирішена. І таких як я з кожним днем ​​все більше і більше. Тому що «наші» люди, по мимо всього іншого, дуже швидко вчаться. Це стосується і тестувальників, і керівників.


Рада тестувальникам. Запам’ятайте колеги: чим більше непрофесійних тестувальників, тим більше компаній, в яких є всі перераховані вище проблеми. Вчіться, прагнете і відкриються перед Вами «правильні» двері.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*