Комментарии 7
Пойти на стажировку и поработать в другой команде. Например, на месяц. Мы долго боролись с границами между командами и в умах людей и теперь у нас так можно.
Или можно пойти в компанию, создающую различные продукты с большим количеством интеграций. Мир, как известно, не совершенен и частенько придется работать за себя и вон того дядю, иначе релиза твоего продукта может и не случиться :)
Опыта тестирования различных технологических стеков набирается столько, что даже проект менять не требуется.
+2
Хорошие книжки.
Кто то Кнута брал читать, осилил? )
В нише «Исследования» книга стоит, как называется?
Кто то Кнута брал читать, осилил? )
В нише «Исследования» книга стоит, как называется?
0
Очень верно подмечено:
Насчет челленджа: это ведь противоречит этому выводу. Неэффективно читать книги не имея реальной проблемы с которой можно связать написаное в ней.
Я тоже читал Lessons learned in Software Testing и выдержки оттуда слал моему тимлиду, мол «Вот оно обьяснение наших проблем, вот… мы не одни во вселенной...» Но в нем это никак не отозвалось кроме замечания, что не нужно тратить время на научные исследования они никому не нужны, нужны зеленые ui тесты, и чем больше, тем лучше. Да понятно, что это бред, но этого хочет заказчик. А успех проекта это деньги заказчика. Не будем выполнять волю заказчика не будет проекта не будет денег. Все просто.
А книги читаю, да, для себя, молча. И никому больше об этом не рассказываю. Выдаю знания за свои :) На самом деле я еще ни разу не изобрел велосипеда, университет отбил у меня такой навык. Я пользуюсь исключительно чужими знаниями и опытом. Синтезируя его по необходимости в общее решение.
Алгоритм простой:
Пока у тебя нет опыта работы — книги тебе не помогут. Знания из них будет попросту не с чем связать — своего опыта ещё нет. И рецепты из книг почему-то не будут работать. [...] ты разочаруешься в книгах, ведь в них сплошная «голая теория», «неприменимая на практике».
Насчет челленджа: это ведь противоречит этому выводу. Неэффективно читать книги не имея реальной проблемы с которой можно связать написаное в ней.
Я тоже читал Lessons learned in Software Testing и выдержки оттуда слал моему тимлиду, мол «Вот оно обьяснение наших проблем, вот… мы не одни во вселенной...» Но в нем это никак не отозвалось кроме замечания, что не нужно тратить время на научные исследования они никому не нужны, нужны зеленые ui тесты, и чем больше, тем лучше. Да понятно, что это бред, но этого хочет заказчик. А успех проекта это деньги заказчика. Не будем выполнять волю заказчика не будет проекта не будет денег. Все просто.
А книги читаю, да, для себя, молча. И никому больше об этом не рассказываю. Выдаю знания за свои :) На самом деле я еще ни разу не изобрел велосипеда, университет отбил у меня такой навык. Я пользуюсь исключительно чужими знаниями и опытом. Синтезируя его по необходимости в общее решение.
Алгоритм простой:
- Классифицировать новую проблему
- Найти как ее решают другие
- Применить и опробовать решение
- Если нет желаемого результата то у нас новая проблема. goto 1
- End.
+2
Иногда просто можно себя пинать, самому себе дедлайны делать, чтобы развиваться.
0
Спасибо за список, но блин, почему его нельзя экспортнуть?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
«Календарь тестировщика» за август. Прочти книгу