Привет, блогхаус.
Перечитываю свои записи здесь, очень необычно читать их из будущего.
Когда у меня уже всё прекрасно, гребу бабло лопатой
Не, по сути я завела себе лог в инсте, веду там в видео-формате, записываю мысли туда.
Если тебе интересен формат, велком https://instagram.com/testing_training/
За время моей 30-летней карьеры я понял, что лидерство — это больше, чем силовые действия сверху. Определяющие характеристики лидерства изменяются в соответствии с потребностями и капризами личности, организации, отрасли и мира в целом. Другими словами, лидерство — это не состояние, это путешествие. Между одним стилем лидерства и другим не всегда есть четкие разделительные линии — иногда автократичный лидер вынужден быть партисипативным, а реформатор должен действовать как автократ. Когда я задумывался над тем, какую роль мне надо выполнять в разное время, у меня лучше получалось выбрать подходящий стиль принятия решений, общения с людьми и управления временем для того, чтобы я мог удовлетворить самые насущные потребности организации на тот момент.
Автократ
Партисипативный лидер
Реформатор
Всем привет.
Сегодня я хочу поделиться с вами информацией о том, что меня хорошо так дрессируют и учат новым фокусам)))
Теперь я знаю, что нужно делать, если разработка что-то делает на куа сервере. Что делать, если не знаешь что делать :D
Так же знаю, что нужно следовать довольно странным требованиям, чтобы закрыть проект.
А так же хочу поделиться мыслью о том, что вчера я защищала свой первый тест-план и жутко нервничала. По итогам могу сказать, что я почти защитила, мне дали советы, я их внесла, теперь жду еще правок.
Тест план — это что-то из разряда «— У вас была с самого начала тактика и вы её придерживались? — С самого начала у меня была какая-то тактика и я её придерживался.» (видео)
Мне надо было думать как мы будем тестировать. Но так как у меня не хватает времени, чтобы проверить это самостоятельно, у меня есть инженер, которому я это всё де-ле-ги-ру-ю. Очень красивое слово, которое по факту не такое красивое)) Но щито поделать, не мы такие, жизнь такая.
Постигать все тонкости общения довольно сложно было. У меня каждый день была мысль, что я сдохну от такого напряжения, и всегда думала о том, что после нового года можно уволиться. Только это меня и держало. Сейчас можно сказать, что всё нормализовалось в моём душевном состоянии. Это случилось тогда, когда я не вошла в скайп с телефона в понедельник. Жизнь заиграла новыми красками. Надо будет, подождут. Вот так вот.
Всем привет.
Пишет уже не совсем юный тестировщик.
Я сейчас обучаюсь на лида. Да-да, я вообще не ожидала такого. Но лето было достаточно бурным.
Постепенно накопились короткие заметки, пробую их донести доступным языком. Часть может быть не понятна из-за специфики комании. Это будет зацензурено.
Поехали.
1. Тест план. Документ, в котором куа лид составляет всё то, что должно быть простестировано, кем и в какие сроки.
2. Организация работы куа команды:
2.1. Проверка ИН (Installation Notes — установочные заметки) — если просят внести настройки на сервер, то надо просить это вносить в ИН.
2.2. Таска с описанием дев задачи, если статус ресолвед, то указывать в какой сборке.
2.3. Понять как заводить куа иши: под ворк айтемы или создавать новые? Что указывать в тикетах?
2.4. Какие требования к системе? Должна быть трасибилити матрица..
3. После установки выдачи, всегда высылать логи разработчикам, даже если всё ок.
Если приходится делегировать, то как минимум один раз — за 3 недели до ЮАТа надо поставить выдачу самостоятельно на чистый сервер, чтобы убедиться что ничего не подкладывалось на сервер по пути.
4. Не важно долго это будет или нет — нам нужна корректная выдача, которую мы сможем поставить без какого либо геморроя, а если такой нет, но значит поднимаем ТМу или ПМу флаг, что все плохо, выдачи нет.
За выдачу отвечает разработка, а мы отвечаем за то, что полученная выдача валидна.
5. Отчётность перед ТМ (техническим менеджером). Нужно понять, какая информация нужна ТМу.
6. Старатья делать так чтобы на куа ничего не весело. То есть если ты коммитишься на что-то, то это делаешь — сама сидишь и овертаймишь если нужно.
+ когда мы в отчете говорим что вот разработчкики иши не фиксят, нужно смотреть чтобы вот таких ишей не было: адишнл инфо рекваед, а то есть иша-то есть, но камушек на стороне куа.
7. Изменение модели системы должно быть задокументировано, например, добавление новых параметров.
8. Рисование "колбасок" в тест-плане: в день не больше трёх кейсов.
9. Бага — правится только код. Док таска — правится только документация. Дев таска — редактируется дока и код.
10. Выдачи собирает — RE (Release Engeneer), а заказывает сборку — ТМ или dev lead
Поставить звездочку (символ) важности сообщения и пришли ссылку на сервер (актульно для скайпа).
Пример: (*) DevLead, закажи плиз выдачу под этот сервер http://ххх.com/
11. Не «я», а «мы», куа лид отвечает за команду.
12. За 15 минут до митинга с командой смотреть репорт. «Обновить дью даты». «Каковы причины не соблюдения дью даты?»
13. Звонок в 6 своему подопечному: «мне нужен Статус».
14. «Я не уверена, есть ли эксперт, к которому мы можем обратиться для прояснения ситуации?»
15. Fail Rate до 10% терпимо.
16. RE (те, кто собирает сборки) работает до 6 часов по МСК.
17. Первый прогон санити у SVT команды (почему-то это важно).
18. Не нужно вступать в дискуссии. Ты просто пишешь, что отныне да будет так.
Если кто-то после этого будет возмущаться, попроси привести аргументы. И все.
Не нужно, а вы... а мы..., правы, не правы.
Твоя задача добиться своего не испортив отношения с командой.
Username вообще девелопер.
Все вопросы ты решаешь в тмом или дев лидом.
Я тебе уже это говорила — это DevLead.
А кто там снизу вякает — тебя не интересует, и вступать с дискуссию не нужно
19. «Я хочу помочь всем нам». «Я хочу понять причины». «И хочу понять, как можно ускорить».
20. Динамика! Должна быть сходимость заводимых багов и их фиксов. Т.е. должно быть с каждым днём заведенных багов меньше.
21. Дью даты!!!
22. Флаги в отчёте для ТМа — риски, оговорённые наперёд.
Знаете, что самое обидное в работе в большой компании? То, что ты прикреплён к проекту. Это, конечно, всё очень здорово. Но.
Ты работаешь, точнее, приходишь работать на новый проект, всё вокруг страшное и непонятное. Ну еще бы оно было понятным, ведь в сфере сотовой связи очень много непонятных слов для железок и устройств. Ты сидишь, изучаешь всю эту мутату, по другому никак не скажешь, потихонечку въезжаешь в то, что, собственно, ты делаешь, и что тебе надо тестировать. И всё, жизнь прекрасна, когда ты знаешь, что ты знаешь то, с чем тебе работать. Все новые сложные слова уже уложились к тебе в голову, ты знаешь, что и как называется, ну просто рыба в воде, хе-хе.
А потом, внезапно, ты понимаешь, что проект имеет свои сроки. И чаще всего они небольшие. И после того, как ты пристроишься к новым людям, к их тараканам, к терминологии, к технологии, тебя переводят на другой проект.
Я чаще всего воспринимаю это как ведро холодной воды. И сразу становится грустно. Сразу думаю, что всё не вечно, и пути чаще расходятся, чем сходятся...
Лучшее
Материалы сайта предназначены для лиц старше 16 лет (16+)