Возможно стоит поставить Junior в пункте желаемая должность.
Этот шилдик поможет другим понять, что вы рассчитываете на начальную позицию, а не на мидл.
12 публикаций создано Flari (учитываются публикации только с 09 мая 2023)
Отправлено автор: Flari 11 ноября 2014 - 07:17 в Личный рост, карьера, развитие
Возможно стоит поставить Junior в пункте желаемая должность.
Этот шилдик поможет другим понять, что вы рассчитываете на начальную позицию, а не на мидл.
Отправлено автор: Flari 17 ноября 2014 - 14:22 в Управление тестированием
у меня был похожий вопрос:)
тут я думаю прежде всего стоит задать вопрос себе.
какую цель вы преследуете когда хотите проводить эти встречи?
как эта цель помогает достичь вашей компании чего-то большего?
окупаются ли затраты на проведение этих встреч? все таки предполагается, что вы будете тратить рабочее время, за которое платит работодатель.
Отправлено автор: Flari 10 ноября 2014 - 15:37 в Круглый стол о работе в тестировании ПО
Я бы так же выразился обо всех, кроме последнего, вопросах. Большинство из них ржачные, потому что нет понимания, что действительно нужно на них отвечать. Но чем больше ты знаешь - тем проще на них ответить "правильными" мыслями.
5, 6, 7 могут показать на сколько хорошо сотрудник проводит самоанализ, знает себя и свои возможности.
Отправлено автор: Flari 06 декабря 2014 - 16:56 в Личный рост, карьера, развитие
первое, что приходит на ум, а Вы свечку держали?
сумма нескольких факторов:
+ результат;
+ заметность;
+ если Вам не всё равно.
Отправлено автор: Flari 09 декабря 2014 - 12:13 в Личный рост, карьера, развитие
IMHO. Повышение - довольно редкая практика в РФ. Обычно самый действенный способ получить повышение - это сменить работу. К сожалению.
Такая уж редкая?
Ваш способ тоже действенный, но неужели никому не повышают в подавляющем большинстве?
никому не повышают в подавляющем большинстве - звучит больше про зп.
никого не повышают в подавляющем большинстве - звучит больше про изменение позиции.
я бы сказал так, повышают позицию в подавляющем меньшинстве компаний.
Опять же это связано не с тем, что компании плохие, а с тем, что для этого должны "сложиться звезды" в компании, чтобы появилась интересная позиция.
Еще как пункт, это зависит от твоей скорости развития. Если ты вкладываешь много энергии в свое развитие - то, обычно, компания не успевает за тобой, потому что это не сильно даст прирост прибыли компании. Ты как бы вырастаешь из компании и приходится искать компанию, которая испытывает потребность в специалисте с твоими новыми навыками.
Отправлено автор: Flari 19 сентября 2014 - 06:49 в Тест-дизайн и ручное тестирование
В соседней теме разгорелся спор, можно ли тестировать фичу, если требований к ней не существует.
Я утверждаю, что не только можно, а иногда иначе никак. Готов объяснить свою позицию аргументированно, послушаю аргументы оппонентов.
протестируйте, пожалуйста, фичу запуска ядерной ракеты без требований.
Отправлено автор: Flari 18 ноября 2014 - 10:33 в Управление тестированием
Спасибо большое от автора вопроса и от меня!
Автор вопроса очень рад вашим ответам, обдумывает их, но сам пока не готов отвечать на ваши вопросы)
Для этого достаточно завести анонимный аккаунт:)
Отправлено автор: Flari 17 ноября 2014 - 13:58 в Управление тестированием
"тестировщики не нашли баги". Если это случилось даже не с одним тестировщиком, то точно нужно все выяснить с тестировщиками один-на-одни.
Вдруг девелоперы решили пофиксить баг, но подумали, что изменение минорное и тесты просто не нужны :)
"вот сижу думаю - наорать на них как обычно или придумать что-то новенькое?"
С другой стороны кажется, что тест менеджер сам не особо адекватен, либо новый, либо не понимает базовые принципы работы с командой.
Отправлено автор: Flari 17 ноября 2014 - 13:30 в QA: обеспечение качества
Ку.
Вот кстати вопрос, всегда им задавался.
Тестирование требований (до написания кода) так же являются обеспечением качества.
Что такое тестирование требований?
Вот скажем пишем мы калькулятор и там должно быть возведение во вторую степень.
Как это требование "протестировать" ДО написания кода?
У меня только одна догадка... Например.
Тест1: возведение положительного числа во вторую степень
Тест2: возведение отрицательного числа во вторую степень
Тест3: возведение нуля во вторую степень
Тест4: возведение какого-то "среднего" числа во вторую степень
Тест5: возведение максимально допустимого числа во вторую степень
Когда мы получаем готовый калькулятор с новой фичей в виде "возведения чисел во вторую степень", то мы проверяем всё это дело по вышеуказанным тест-кейсам?
Это и есть тестирование требований или я что-то путаю? :-)
мне еще эта ссылка нравится http://testingforall.com/blog/?p=588
Требование:
"пишем мы калькулятор и там должно быть возведение во вторую степень"
все пять тестов базируются на информации, которая в требованиях не указана:) То есть на этапе тестирования требований её нужно уточнить.
А вообще возможно ли добавление этого функционала?
Например если в стандартный виндовый калькулятор(Standart) добавить эту фичу, то скорее всего вы нарушите гайдлайны. Так как такой функционал у них возможен только в "Scientific" режиме.
Или еще парочка:
- как этот функционал будет вызываться;
- куда будет записываться результат.
Отправлено автор: Flari 02 декабря 2014 - 15:07 в Автоматизированное тестирование
Возможно стоит уточнить у руководителя, зачем он хочет это добавить, тогда и будет понятно, как реагировать.
может быть ему надо отчитаться на что вы тратите время. а для отчетности нужны красивые отчеты прежде всего.
Отправлено автор: Flari 02 декабря 2014 - 13:09 в Автоматизированное тестирование
Как и на любые изменения, считаешь, сколько нужно будет времени на реализацию каждой хотелки и показываешься менеджеру.
Если ему не нравится время- что то вычеркиваете:)
кстати, а с какой целью они были созданы?
Отправлено автор: Flari 18 ноября 2014 - 10:44 в Начинающему тестировщику
1) проходим курс/читаем книги по python
2) изучаем примеры простых тестов на python
3) находим библиотеку по работе с api.
4) останавливаемся и проверяем, на сколько мы выбрали правильный путь в развитие своей карьеры, если все устраивает - идем дальше(5), если не устраивает - ищем другую позицию.
5) составляем тестовые сценарии, которые хотим проверить
6) подготавливаем тестовые данные.
7) кодим.
8) запускаем/фиксим/рефакторим получившийся фреймворк.
9) отправляем ответ работодателю в виде ссылки на репозиторий.
10) ждем ответа
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru