Перейти к содержимому

Публикации chuk

5 публикаций создано chuk (учитываются публикации только с 29 марта 2023)


#35569 Негативный опыт работы по удаленке

Отправлено автор: chuk 15 ноября 2006 - 16:56 в Круглый стол о работе в тестировании ПО

chuk

Спасибо за развернутый и очень интересный ответ.

Я в удаленной работе не спец, сам работаю в фирме, но вот подработать тоже захотелось, плюс еще опыта поднабраться в тестировании веб приложений (в основной своей работе с вебом дела не имел). Проект и правда шел как-то странно, много разработчиков и один удаленный тестер, т.е. Заказчика в глаза не видел, по знакомым нашли друг друга. Т.е. это как бы халтурка, как у нас это называют,

Просмотр сообщения


тут такое дело - начинать надо вообще по принципу - ничего хорошего не ожидать от таких халтурок. :) Т.е. я когда начинал - я вообще исходил из того, что в крайнем случае, даже если денег не заплатят - то хоть опыт получу. Оно так и получилось - опыт на таких проектах огромный - никто за тобой не стоит - все проблемы разруливаешь сам. И финансовые вопросы решать, и контакты, и общение с разными людьми (хорошими и плохими) и планы и методы работы и за свои промахи сам отвечаешь - все сам. Поэтому если получил такой результат - то ничего страшного - зато опыт дороже. На других проектах уже все другим будет.

у меня было 8 проектов такого типа, когда сам за себя (только я их халтуркой не называю :)) ), какая там халтурка, когда пахать надо конкретно :)
Их этих 8 - ми проектов - только один я считаю провальным - когда вообще все завалилось - и проект и деньги за работу и контакты с потенциальным кастомером.

на остальных семи - я их считаю относительно удачными - были почти все проблемы из того списка, что я приводил, но для меня они оказались удачными в том плане, что кроме оплаты я получил ну просто огромный опыт :)



#35541 Негативный опыт работы по удаленке

Отправлено автор: chuk 15 ноября 2006 - 10:24 в Круглый стол о работе в тестировании ПО

Да, есть негативный опыт.
И не платит деньги, и не платит премии, и рассказывает, какие неимоверные баги были найдены после нас.

+ еще набор некоторых негативов:

- отсутствие нормального суппорта
- отсутствие нормальных требований
- полное закрытие проекта по разным причинам
- изменение оговоренных условий работы
- банкротство заказчика
- необоснованное сваливание вины на QA за проблемы менеджмента и девелоперов.
- неоговоренное изменение планов и "втуливание" новых функциональностей при сокращении сроков проекта.

в общем - такой вот набор негатива попадался.

тут такой вот вопрос - что значит "удаленка" ?
удаленка, когда Ваша фирма удаленно работает на кого-то или когда лично Вы по своей инициативе (или просьбе, или рекомендациям, или самостоятельно) находите заказчика и работаете только Вы (не имея за спиной никакой формальной опоры) ?

Если Вы работаете в пределах своей фирмы удаленно, то тут немного полегче:
В любом случае должен быть формальный договор, руководство должно оговорить сроки, условия и формат приемки/передачи работы и оценки качества Ваших работ. И все вышеперчисленные негативы возможны только в том случае, если очень сильно ошибся руководитель или менеджмент по работе с кастомерами - когда явно пропустили что-то в контракте.

если же Вы работаете один, то тут Вы можете получить полный набор "удовольствий". Поэтому желательно как можно сильнее формализовать Ваши отношения с потеницальным заказчиком. Чем больше формальных документов на работу, тем лучше. Хорошо бы еще иметь какого-то поручителя в любой форме, который может поручиться как за Вас как специалиста, так и за Заказчика, как за серьезное лицо.

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

Но в любом случае - если Вы в первый раз начинаете работу с вообще незнакомым заказчиком и информации по нему нет, то это в большей степени лотерея, так как отследить, что он может сделать - практически невозможно.

Основная проблема в том, что у нас тот кто платит деньги, тот и прав.
И если ему что-то не понравиться (не важно, по каким причинам), то может и не заплатить. Поэтому выбор надежного заказчика для удаленки - это наверное самое сложное в такого типа работе.

Если выбор правильный - то даже если и будут какие-либо проблемы на проекте - люди адекватные и во всем можно разобраться, если выбор неправильный - то может быть вообще все что угодно. И я сомневаюсь, что даже если у Вас как у отдельного человека (не конторы) будет формальный договор - Вам удасться добиться положительного для себя результата. Это очень трудно - бегать по судам и что-то доказывать, а если у вас и договора нет, или же идет удаленка "за бугор", а там чтобы судиться - это можно вообще крест поставить - то шансов практически нет. Поэтому самостоятельная удаленка - очень большой риск, но с другой стороны - достаточно соблазнительные уровни зп, на чем многие и ловятся. :)



#35521 Непрофессиональные проблемы тестирования

Отправлено автор: chuk 14 ноября 2006 - 17:05 в Портал Software-Testing.Ru

Слава,
спасибо за комменты,

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

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


Небольшой коммент по фразе:

"... Я же описал ситуацию, когда "А потому что сразу не продумали, или еще хуже, не захотели тратить времени и средств" - это типичная проблема везде, когда берешься не за свое дело, а если, при этом, нет желания его делать, то результаты прогнозируемы и очевидны."

Насчет типичности - возможно это типично для очень неопытного менеджера, для руководителя, который "случайно" оказался в этой системе, но почему-то мне кажется (опять же - личное мнение и его можно не учитывать), что если фирма сумела протянуть хотя бы пару лет на ниве разработки ПО, то такая ситуация уже нетипична в принципе.

Если Вы говорили о таких фирмах-скороспелках, то вопрососв нет. Но выделять этот раздел публикации как отдельный класс проблем только для фирм-однодневок не очень корректно, так как может быть их и очень много, но серьезного влияния на рынок разработки ПО они не оказывают.

Это можно предложить только в пределах учебного курса (по принципу "как закалялась сталь" -- чтобы другие "однодневки" не попались на этом). Возможно, что публикация как раз для этого и предназначена.

Я со своей стороны пытаюсь подойти к более практической части - что я должен делать, когда на руках у меня такой проект. И не важно - почему, важно то, что я принял решение его сделать. Т.е что я должен сделать, чтобы максимально полно обеспечить качество.

И когда Вы говорите, что такие проекты - это типичная проблема в условиях, когда "... сразу не продумали, или еще хуже, не захотели тратить времени и средств" - я не могу с Вами согласиться, так как и у более серьезных фирм, которые живут уже не первый десяток лет случаются такие проекты и все наши (и не наши) "монстры" IT (VDI в том числе) отнюдь не отказываются сходу от таких проектов и пытаются решать такие проблемы. И решают их вполне успешно.

Может быть я и ошибаюсь, но вот действительно - фирме 11 лет и таких проектов было очень мало и все они брались в критические моменты, все понимали - что это проблемные проекты, что нормального результата не будет, но тем не менее добивались результата.

Может быть к своему счастью, но я еще ни разу не успел столкнуться с такой ситуацией, когда руководство по каким-либо причинам так "протупило" или "зажало" деньги, время или ресурсы на такие проекты.

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

Наверянка, у многих на этом форуме в копилке опыта были такие проекты - интересно узнать - все ли последовали Вашим советам "уволиться" ? (тут я немного "подкалываю" конечно с постоянным упором на "увольняться", но мне кажется, что вариант с "уволиться" вообще нетипичен для нашего рынка. Я очень мало (почти никогда) не видел людей, которые по принципиальным расхождениям с руководством в сроках и ресурсах на проект были вынуждены увольняться.

Если не трудно - поделитесь опытом (я больше чем уверен, что у Вас тоже были такие проекты) - как Вы выходили из таких ситуаций ? Это не "вопрос-подколка". Мне действительно интересно знать - как в условиях кризиса ресурсов (не важно, по каким причинам) можно выйти из подобных ситуаций ?

Есть достаточно много публикаций по менеджменту в кризисных ситуациях, но они какие-то абстрактные - общие фразы только. Если есть возможность, не могли бы Вы или может еще кто-то, кто читает эту ветку просто кратко расписать - что же я буду делать как QA Manager на таком проекте.

Я свой вариант представил - возможно он и не очень, но в свое время он помог. Может есть еще какие варианты кризис-менеджмента (но только с точки зрения работы QA). Если можно - то без общий линок на общеизвестные ресурсы по кризис - менеджменту. Просто своими словами - что надо делать.

Сорри, что вот так напрягаю в пределах этой ветки.

и еще хотел откомментировать следующее "... И еще вы предлагаете переложить проблему на плечи тестера?". --- тут небольшое пояснение - что я понял под проблемой из Вашего комментария. Я рассматриваю не проблему того, как и почему появился такой проект, а проблему того, как можно успешно решиьт такой проект.

Если рассматривать только причины - то Вы абсолютно правы в своей публикации, а если рассматривать способы реакции на такой проект - вот тут я и пытаюсь расписать.

насчет плечей тестера - проекты разные бывают, бывает, что QA работает на внешнего разработчика, тогда кроме QA на проекте со стороны фирмы больше никого и нет - т.е. все QA однозначно ложиться на наши плечи и успех проекта только на этом и стоит (успех - это имеется ввиду удовлетворение подрядчика/заказчика в результатах работы QA). И ведь достаточно часто просто ставят перед фактом - есть сроки, есть объемы а дальше - как хотите.
Т.е. тут вы однозначно правы - все ложиться на поечи QA. Но я не хочу, чтобы сложилось такое мнение, что имея такой проект нас отдавали на растерзание. Наоборот - у нас была "зеленая улица" по любым хотениям и желаниям вплоть до кофе в постель :), т.к. все прекрасно понимали, что от нашей работы очень многое зависит. Это опять же - к вопросу о том, что руководство чаще всего отлично понимает - что это за проект и "откуда ноги растут". Поэтому я и не рассматриваю вариант с Идиотом-руководителем

Если мы рассматриваем вариант, когда девелоперы и QA сидят вместе в одной лодке, то конечно QA - это не мальчики для битья и не ответчики за весь проект, но именно на таких проблемных проектах очень хорошо видно, что без QA вообще никак, т.е. у тех, у кого еще хоть немного оставались крупинки сомнения о "дармоедах" из QA Team - после таких проектов обычно все сомнения уходят. И кооперация c QA на таких проектах очень интересная -вплоть до парной работы и совместного просмотра кода. В некоторых местах почти по XP. Иногда я ловлю себя на мысли, что может быть XP как раз и подходит оптимально для таких проектов, но все равно - в чистом виде я даже и не пытался его использовать там. Даже мыслей не было о каких-то особых процессах на таком проекте - просто в чистом виде креатив по тестированию :).

сорри за длинные пояснения.

То, что я пишу - можо смело выкинуть :) Единственное, что я хочу тут увидеть (может много хочу конечно) - это что-то типа краткого мануала - получил такой проект - делай раз, делай два, делай три... --- и может быть, у тебя все получится.

Я пока не смог определиться в области (как я себе ее сам называю) экстремального тестинга.

По процессам работать легко, особенно если они настроены, а даже если они и не настроены - то столько док-ции, что и идиот сможет создать любой процесс.

Намного сложнее заставить всех понять - что по ним надо работать (в основном - кастомера), и самый высший пилотаж - это суметь работать по любым процессам независимо от всех приколов с ресурсами, руководством, кастомером и т.д., т.е. по принципу "QA must go on" (только не надо мне говорить про "уволиться" :)) на таких проектах.



#35456 Тестирование постановки задачи

Отправлено автор: chuk 13 ноября 2006 - 15:22 в Управление тестированием

Занимаемся этим на каждом проекте.
Но проблем много - кастомеры разные, форма док-тов разная, степень детализации разная.

Идеальный случай - наличие диаграмм, хорошие Use Cases, хорошие снепшоты.
Но такое редко. Чаще всего - просто описание.

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

формулы ручками.
Чаще всего - таблицы в экселике, которые потом можно подгружать как тестовые данные через TestComplete (это для формул)

или же логика - те же таблички в экселике.
Дерево охвата всех веток логики.

очень хочется подобрать хороший тул для менеджмента требований, но пока все никак не нашел то, что нужно.

хочется, чтобы тул был открытым, чтобы не требовал отдельной должности Requirement Manager, чтобы кастомер туда тоже "иногда" заглядывал, а не ждал, когда его дернут или когда ему что-то новое приспичит.

Caliber понравился, но не сложилось.
Вот может свое что-то наваяем для себя.

Но что интересно - трудность не в тестировании как таковом постановки задачи - тут просто внимательность и логика - отследить связи и возможные противоречия. Основная трудность у нас - это увязать все до кучи - так как само по себе тестирование постановки задачи без тесной связи кастомера, девелоперов, райтеров и QA приводит к огромным временным затратам. Пока все "очухаются" на запросы - то много времени проходит.

а вообще стараюсь все проверки по требованиям в виде схем и таблиц оформлять - так нагляднее и ошибок меньше пропускается.
С одной стороны дольше, а с другой стороны - такие проверки легко править и анализировать.

что касается анализатора логики - то пытались RUP-ом по моделям и UML-диаграмам ходить, но для этого сначала надо их иметь или сделать самому - а это время и переработка требований в виде кастомера (а он их дает в чем угодно, хоть в звонках телефонных). Поэтому отказались от такой работы - дешевле пока ручками практиковаться.



#35443 Непрофессиональные проблемы тестирования

Отправлено автор: chuk 13 ноября 2006 - 14:05 в Портал Software-Testing.Ru

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

Единственный коммент по части:

"Сроки на тестирование заведомо недостаточные (безобразное руководство)
Как убедить руководство, что надо больше времени?"

Если бы все решал руководитель фирмы, которая берет заказ - то все, что написано в статье - абсолютно верно. Идиотов становится все меньше и разумный человек всегда понимает, что некоторые вещи просто нереально сделать в указанные сроки (если конечно обоснованно доказать ему это).

Но есть такой интересный тип проектов - когда у кастомера есть фиксированный бюджет и все попытки объяснить кастомеру что в пределах этого бюджета и выделенных на проект ресурсов просто невозможно обеспечить требуемое качество приводят к полному непониманию. И тут уже не важно, что говорит QA и какие доводы приводит - все равно бюджет увеличен не будет и на нужды QA (а значит и для всего проекта в целом) доп. ресурсы не дадут.

Вот в этой ситуации и приходится выбирать: самый простой вариант (и самый 1-й в списке) пойти и обоснованно доложить руководству - что есть вот такие проблемы и приемлемое качество обеспечно не будет.

Если бы все дело было только в руководителе - то вопрос решался бы однозначно - дополнительнйы анализ + пересмотр планов + сроков.

Но чаще всего бывает, что руководитель и сам не в состоянии решить эти вопросы с заказчиком.

Вот тут начинается интересная история - можно отказаться от заведомо проблемного проекта, можно заранее объяснить кастомеру - что будет плохо (но на такого рода заявления, особенно в начале проекта - кастомер обычно не реагирует и витает в облаках). Можно искать доп ресурсы себе в убыток - лишь бы удовлетворить кастомера (но все время себе в убыток работать не будешь). Можно просто плюнуть на все - коль эти проблемы решить нельзя (с кастомером) или обидеться на руководителя (что он по каким-то причинам не в состоянии их решить) и продолжать работу по принципу "делать все, что могу, а дальше - как получиться".

один из предложенных автором статьи вариантов - "поиск нового места работы" не всегда адекватен, так как такие проекты иногда (а бывает, что и не иногда, а чаще) появляются на любых фирмах.

в моей ситуации за последние 6 лет работы "удалось" поработать на нескольких подобных проектах. И каждый из них в случае успеха вел к новым заказам и потенциальным клиентам - т.е. все равно имея даже такой проект надо сделать так, чтобы кастомер получил "максимум" удовольствия за свои деньги.

По моему мнению в такой ситуации надо принудительно самому поломать все настроенные процессы тестирования.

Вот допустим есть у меня процесс QA для "стандартного" и "благополучного" процесса, когда и сроки в пределах разумного и ресурсы более-менее обеспечены. И тут приходит такой проект. В этой ситуации все, пришел полный конец, надо быстренько забыть в принципе о таком понятии, как процесс обеспечения качества разрабатываемого продукта. Так как качество на таком проекте в принципе не зависит от процесса QA, он вообще не работает на таких проектах.

В этой ситуации единственное, что может спасти проект в части QA (если не считать случая, когда вообще от него отказаться или уволиться) - это перераспределение ресурсов QA между проектами так, чтобы на таком проблемной проекте оказались "сливки" QA команды, которые обладают огромным опытом и некоторыми "ведическими" знаниями в области тестинга - это может хоть частично компенсировать нехватку времени, отбросить некоторые несущественные формальные процедуры процесса обеспечения качества, максимально минимизировать время на менеджмент тест кейсов, баг трэкинг и максимально сосредоточиться на анализе требований и очень тесной кооперации с девелоперами. Уже один грамотный анализ требований может на во время 1-й недели проекта отсечь порядка 30 % проблемных и бажных мест (проценты взяты из собственного опыта).

конечно - с моей стороны - это все - общие фразы. И риск такой постановки работы огромен, но с другой стороны - или так, или вообще никак. По собственному опыту - такой подход может хоть частично компенсировать нехватку времени, отказаться от сплошного тестирования тест кейсов, уменьшить количество тестовых итераций. Но в этой ситуации, так как стандартные процессы не работают - почти вся ответственность и нагрузка ложится на личные качества и индивидуальный профессионализм тестера. Т.е. если тестер не оплошает со своим опытом и знаниями - может кое-как и вытянем, если же нет - то почти однозначно - что проект завалим.

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

в своей работе я всеми силами стараюсь избегать такие проекты, но как бы то ни было - это очень хороший опыт работы. И это не есть исключение, такое происходит достаточно часто и со всеми разработчиками. Это уже потом, когда фирма стала "большой и толстой" и может себе позволиь по году не находить ни одного нового проекта и жить на старых хвостах - такое можно себе позволить и отказываться от них, но чаще всего не до жиру.

а вообще было бы интересно - может кто-то еще поделится опытом - как решать задачи QA в условиях явного недостатка ресурсов (как временных так и людских).

спасибо,
Александр