Сообщений в теме: 67

[elfische]

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

Раскаиваться ему не в чем. Тут нет вины никого из нас в данной ситуации. Я никак не могу найти термины, в которых ему можно доступно объяснить про тестирование. Пока с него не стали требовать ставить качественные сборки, он не задумывался о приёмочном тестировании. Пока не встал вопрос о ДЕЙСТВИТЕЛЬНО важных функциях модуля, говорил, что все важные.
Я уже много всего перечитала, но пока не могу правильно сформулировать запрос, по которой найду точную информацию, как разговаривать с разработчиками.

P.S. Тимлид коллеги создал пациента с именем "Альбина" (это коллега) и фамилией "останься". Какая прелесть!

[elfische]

или людей с программерским опытом.

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

Заранее наверняка невозможно сказать, понравится ли человеку в тестировании, если он им до этого не занимался. У нас есть девушка, которая ушла в разработчики. И парень. Тот ушёл в автотесты, потом разработку, затем в вёрстку. И только в вёрстке он почувствовал себя "в своей тарелке".
А в целом согласна, что человек должен быть заинтересован.

[Xenia Berkut]

P.S. Тимлид коллеги создал пациента с именем "Альбина" (это коллега) и фамилией "останься". Какая прелесть!

Да, действительно, прелесть)
Мне очень интересно, что примерно вы хотите ему объяснить?

[ksena]

Тот ушёл в автотесты,

Так у вас и автоматизация есть, не все так плохо оказывается. А чего вы зашиваетесь, автоматизация вас не разгружает?

[ksena]

Я уже много всего перечитала, но пока не могу правильно сформулировать запрос, по которой найду точную информацию, как разговаривать с разработчиками.

Есть замечательные книги в которых рассказывают как правильно обьяснить проблемы тестирования начальнику/заказчику: Рекс Блэк "Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование" и Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд (Agile Testing). Сама читала, многое черпнула из этих книг, рекомендую.

[elfische]

Мне очень интересно, что примерно вы хотите ему объяснить?

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

[ksena]

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

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

[elfische]

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

Есть замечательные книги в которых рассказывают как правильно обьяснить проблемы тестирования начальнику/заказчику: Рекс Блэк "Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование" и Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд (Agile Testing). Сама читала, многое черпнула из этих книг, рекомендую.

Вот! Стоило только правильно высказать проблему, как тут же получила книжку в лоб! Как долго я к этому шла... (тут должен быть смайлик, отображающий раслабление и удовольствие).

[Xenia Berkut]

Мне очень интересно, что примерно вы хотите ему объяснить?

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

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

[ksena]

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

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

[elfische]

Стоп! Я сейчас отвечу!

[Xenia Berkut]

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

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

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

[ksena]

Да, он не должен сию секунду что-то делать, но и забивать на замечания или негативно на них реагировать тоже не должен, согласны?

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

[Xenia Berkut]

Да, он не должен сию секунду что-то делать, но и забивать на замечания или негативно на них реагировать тоже не должен, согласны?

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

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

[ksena]

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

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

[Xenia Berkut]

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

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

Ну, в общем-то , разными словами практически об одном и том же.

[elfische]

Я снова тут. Отвечу сразу в целом, раз без меня уже получилась дискуссия.

Почему баг может лежать в бтс, но я о нём отдельно сообщаю. Есть два поля: severity и priority. Различие таково, что первое обозначает серьёзность техническую, а второе -- менеджерскую. Техническая интуитивно понятна, а менеджерская вот в чём заключается. Пусть у нас есть куча простеньких багов по вёрстке. Они легко чинится за пять минут. И пусть есть ну очень серьёзный баг, но его невозможно починить, пока не выйдет с больничного специалист по этой функциональности. В данном случае priority для багов по верстке будет выставлена critical, а этот тяжёлый баг полежит с majority до прихода специалиста. Соответственно, в нормальном процессе, тестировщик должен указывать severity, а пм (человек, занимающийся разбором полётов в скраме, у нас его нет, потому забыла, как называется; потому пусть будет пм) должен принять решение и выставить priority.
У нас поплыли процессы. Сейчас живём в хаосе: самый востребованный ресурс -- программист. Кто лучше и быстрее до него достучится, тот и "выиграл". Тимлид не смотрит на техническую severity, только на менеджерскую. Поэтому, когда банальный баг по вёрстке, но невозможно добраться до кнопки "Найти", приходится ставить critical, чтобы это немедленно починили.
Кроме того. Если буду сидеть и ждать, пока там найдут баги в джире, у меня просто не будет работы. Я обязана обеспечивать качество модуля, и никого не интересует, как. Приходится подстраиваться под меняющиеся процессы разработки. А они реально меняются каждую неделю, пусть и по мелочи.

[ksena]

У нас поплыли процессы. Сейчас живём в хаосе: самый востребованный ресурс -- программист. Кто лучше и быстрее до него достучится, тот и "выиграл". Тимлид не смотрит на техническую severity, только на менеджерскую. Поэтому, когда банальный баг по вёрстке, но невозможно добраться до кнопки "Найти", приходится ставить critical, чтобы это немедленно починили.

Кто-то из вас что-то не правильно понимает, ваша "техническая severity" и "менеджерская" не должны уходить друг от друга далеко, если баг критичный технически, он критичный и менеджерчки, поскольку такой баг сильно влияет на "качество продукта". Разнобой может быть тогда, когда например была какая-то доработка для какого-то конкретного заказчика, и этот заказчик у вас в vip статусе, и поэтому все баги которые есть в "его" функциональности, имеют критический менеджерский статус, хоть он там и совсем далеко не критичный. Или наоборот когда технически критичный баг может быть не критичный менеджерски: например, функциональность решено убить, но делают это постепенно, и в этой старой функциональности есть серьезная поломка, но поскольку есть некий модуль, заменяющий данную функциональность - этот баг менеджерски не критичный. А так чтобы в текущих модулях технически критичные баги рассматривалиь как не критичные менеждерски... ну я не знаю, кто такое придумал?

[elfische]

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

Как мне хочется согласиться! Но в реальности оно, блин, не так. Вот и пытаешься объяснить, как оно должно бы быть и как есть.

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

[ksena]

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

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