ch_ip

Инженеров, которые делают что-то мотивируя это тем, что так делают все, заменят роботы.

Речь не про "делать, как все", а про выравнивание информационного пространства. Ну и потом в самом начале пути "делать, как все" — вполне рабочая парадигма для обучения.

Тема скорее вредна, чем полезна.

Потому что если книга не подошла лично вам — это не значит, что она бесполезная.

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

 

Про остальные упомянутые книги — они не вредные. Просто надо понимать зачем и про что они были написаны и применять соответствующим образом, включая мозг :)

"Как тестируют в гугл" — это просто еще одна точка зрения на тестирование, которая позволяет вам взглянуть на процесс под другим углом и подумать, а можно ли что-то изменить у себя?

 

Exploratory software testing, James Whittaker — одна из самых полезных книг в моей истории. Считаю ее практически must-read для начинающих и миддлов — очень круто описаны техники тест-дизайна и поиска багов. Если читать не залпом, а по главе в неделю и сразу практиковать прочитанное на тестируемом приложении, то получаются удивительные результаты :)

Я мало чего знаю об автоматизации и нагрузочном тестировании, но, как я понял, в нагрузочном надо неплохо разбираться не только в Java, но и в сетях, БД, статистике, много разнообразных задач.

 

Верно понимаете. А в автоматизации надо разбираться в архитектуре приложения, unit-тестировании, построении фреймворков, continious integration и continious delivery. Везде есть чему поучиться, но в нагрузке действительно, нужно намного больше понимать про внутренности мира IT.
И да, в обоих случаях придется изучить теорию по тестированию.

 

Вакансий по нагрузочному тестированию практически нет.

Плохо ищете или не там. Хорошие специалисты редки, найти очень сложно.

 

Куда можно двигаться дальше из нагрузочного тестирования?

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

 

Какие перспективы роста? Можно ли потом уйти в разработчики?

Перспективы роста — разные. Но если хотите идти в разработку, то надо идти в разработку сразу. Тестирование вам в этом не поможет, в том числе и автоматизированное. Это разные области.

 

Сколько времени понадобиться, чтобы стать более или менее нормальным специалистом в автоматизации и в performance testing?

2 года в автоматизации. 3-4 в performance testing.

Неплохо было бы исправить орфографические ошибки в отчёте + сперва пишется "Ожидаемый результат", а затем "Фактический". И причём это делается для каждого шага :)

Не согласен.

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

И уже только потом — как же должно правильно работать. (Ожидаемый результат)

Версия QTP?
Приведите пример HTML, где расположены те объекты, с которыми у вас на получается работать через QTP. и желательно пример вашего кода, где вы к ним образаетесь

Согласен с топикстартером в плане нулевой информативности заметок типа "А вы team-плеер?"

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

Аргументированный фидбэк от читателей — это ценно. А критика — это всегда повод задуматься.

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

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

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

Контакты наверх.
Убрать слова "Резюме на вакансию", добавить цель или желаемую должность.
В навыки добавить ОС, с которыми умеете работать с указанием вашего уровня владения ими.
Добавить языки.
"По тестированию читал множество различных статей, книгу Савина, тематический раздел на хабре, сейчас читаю Канера и прохожу курс на udacity. На практике с тестированием ПО сталкивался только во время бета-тестов,"
Где все это в резюме?
Организацию и должность можно объединить в одну строку
убрать слово "Период"
Добавить ссылки на место работы, если у них есть сайт.
Телефон пишется в формате +7
Дефисы заменить на тире в периодах
Факультет и университет также можно в одну строку.
Обязанности слабочитаемы в обоих случаях. Висячие слова (одно слово на строке — плохо, компонуйте так, чтобы такого не было)

Выяснять причину пропуска. Без этого невозможно делать дальнейшие выводы.

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

 

Случаи были, но покуда я не менеджер, не знаю, чем оно всё заканчивалось.

Коллеги, у вас осенняя депрессия? Никто ж не заставляет участвовать.
Понятно, что для хорошо устроенных профи призы не особо ценные, а вот для тех, у кого опыта не так много и хочется его набрать и сравнить с другими, самое то!
Да и профи могут решить тряхнуть стариной и попробовать стать лучшими just for fun!

Включаете в профиле настройку "Автонаблюдение", так чтобы Джира автоматически ставила вас в список наблюдающих за тикетом, если вы его автор или оставили комментарий.

Создаете свой фильтр с условием "watcher = currentUser()"

 

Будет ли работать, если просто изменять статус без комментария, не знаю, надо пробовать.

А по мне так лучше указание покера, чем неясно-сто-делание.

Ибо покер - это теорвер+логика, как раз то, что нужно тестировщикам.

 

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

Я утверждаю, что не только можно, а иногда иначе никак. Готов объяснить свою позицию аргументированно, послушаю аргументы оппонентов.

протестируйте, пожалуйста, фичу запуска ядерной ракеты без требований.

 

Элементарно. Сценарий: взять ракету, установить в пусковую установку, задать координаты цели, запустить, подтвердить запуск.

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

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

Ну и кейс на проверку, что можно отказаться от запуска на этапе подтверждения.

Негативные кейсы:
Попытаться запустить без ракеты,
Вставить муляж и попытаться запустить
Вставить торпеду от АПЛ вместо ракеты, запустить

Выставить координаты, куда ракета не долетит

Выставить координаты Луны

Выставить координаты Марса
 

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

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