Рейтинг Контента

Если вы думаете, что хотите работать в тестировании - подумайте ещё раз :)

Если вы абсолютно точно уверены в своём желании - следуйте следующим принципам:

1. Старайтесь как можно раньше найти работу. Курсы, книги, статьи - лишь помощь в работе, а не наоборот!

2. Выбирайте первое место работы не по зарплате, а по зрелости процессов. Идите в компанию, в которой тестирование налажено, так вы увидите на практике, как должно осуществляться тестирование. Чаще всего такие условия бывают в крупных известных компаниях, серьёзно относящихся к качеству.

3. Читайте книги, читайте много книг! Так вы очень выгодно выделите себя среди "покликать пришёл".

4. Если вы хотите стать разработчиком, аналитиком или РМом, то работа в тестировании вам никак не поможет. НИКАК! Идити в разработку или аналитику, не тратьте попусту своё время и нервы коллег.

5. Тестирование - обширная область, выберите интересный для вас вектор развития. Специалисты по анализу, автоматизации, безопасности, нагрузке, юзабилити, управлению - это совсем разные тестировщики. Попробуйте всё, выберите интересную область для развития и специализируйтесь.

6. Самое главное при устройстве на работу - опыт. Как его получить, если без него работу найти сложно? Регистрируйтесь на uTest.com и fixber.ru, тренируйтесь, указывайте этот опыт в резюме.

to be continued...

"тестирование подсчета типа треугольника"

Я вот в тестировании 8 лет, на текущей работе уже тест-лид, сам собеседовал не раз. Решил сменить компашку, до этого собеселования нигде не проходил. И что вы думаете - на первом же интервью мне выдают задачу (дословно):

"- Составьте пожалуйста список тестов, для функции, на входе которой три параметра, а на выходе треугольник"

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

 

Это мне предложил технарь из компании "Открытые технологии". ТЕХНАРЬ БЛ& !!! Я вот конкретно эту задачу не встречал, и догадаться что за параметры передаются в функцию не мог. Попробывал было задать наводящие вопросы, что мол за значения в параметрах? (ну там длины это или тройки координат в пространстве) на что был ответ - типа "...вы мне скажИте какие это параметры..." ... что за параметры, что за треугольник на выходе. попробуй догадайся.... Ну я ему совставил кейсы для троек координат в пространстве(отголоски текущей работы) ...

 

... к чему это я .. А да... товарищи собеседующие кандидатов, прежде чем тестить кандидата потрудитесь вникнуть в суть задачь. Оригинальная задача звучит так: "Составьте список тестов для функции, в которую передается три значения длин, а на выходе функция выдает - одно значение BOOLEAN - true, если существует треугольник со сторонами такой длины, и false если не существует".

 

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

 

Опять же к чему это я... а да... на собеседовании постарайтесь не бросаться на составление максимального числа перестановок и конкретных значений. При любой задаче на составление тестов уточните непонятные моменты, составьте микро тест-план, составьте микро-список требований, разделите из на приоритетные и нет, постройте в голове маленькое оглавление для сценария - типа - Смок, функционал, производительность, юзабилити(+эргономика), безопасность, окружение...  и тд, все виды и подвиды, какие вспомните, далее по каждому пункту определите нужен он или нет. Далее наиболее критичные тесты. Не бойтесь записывать.

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

 

Как пример, периодически даем на проверку кандидату форму доступа путем ввода пятизначного цифрового пароля, для сенсорного терминала, и просим "на лету" протестировать и составить отчет.

Форма намеренно заторможена на нажание кнопки "0" - пауза секунд 5.

Правильный пароль известен.

На форме цифры, спецсимволы ,"Отмена", "Вход", "Язык", у тестера есть возможность задать правильный пятизначный пароль обычным апдейтом на рядом стоящем компе.

Все кидаются проверять и перебирать пароли.

Как результат :

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

Половина вводит только пятизначные значения.

Половина вводит только цифры.

95% не проверяют вход при пустом пароле и вход с пустым паролем о комбинациях(0/NULL) я уже не говорю.

95% не проверяют кнопку "Отмена".

95% не уточняют может ли пароль содержать спецсимволы с клавиатуры терминала.

Один человек за 3 года проверил смену языка.

Никто не проверяет добавление к правильному паролю других цифр и спецсимволов.

Никто не проверяет обрезанный с конца пароль.

 

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

 

 

Ох скока я понаписал...

Перенумеровал вопросы, чтобы впоследствии было проще их идентифицировать.

1)
Что такое функциональное тестирование, в чем отличие от GUI тестирования?

ФТ - это поиск багов при проверки определенных функций, которые должно выполнять приложение согласно требованиям.

Нет.

Во-первых, ответьте на другой вопрос: "Что надо тестировать в контексте функционального тестирования?"

Ответ на этот вопрос выведет вас на правильный ответ о том, что такое функциональное тестирование.

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

GUI тестирование - это тестирование интерфейса приложения согласно требованию (иногда без требований) и по определенным правилам (для web свои правила, для windows приложений - другие и т.д.)

Да.

После слова "приложения" сделайте смелую точку.

2)
Что такое метод черного ящика?

это метод тестирования без знания (понимания) кода, на котором написано приложение.

Нуууу, почти...

Есть более внятное определение. Хотя оно тоже очень абстрактное, все же оно благоприятнее в целом.

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

Кстати, выражение "метод черного ящика" не очень грамотное. Следует говорить более высоким штилем, вроде "тестирование методом черного ящика".

Можете нагуглить на яндекс.словарях определение слова "метод"?

3)
Что такое исследовательское тестирование?

это тестирование без определенной стратегии.

Нет.

Постарайтесь не упрощать этот термин, бо это вообще некий новый подход, а не что-то очень определенное, что укладывается в несколько слов.

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

Посмотрите описание источника этого подхода - есть целая книга под названием “Secrets of a Buccaneer-Scholar“ от автора этого вида тестирования. Конечно, не обязательно читать всю книгу, чтобы понять суть - достаточно предложенной по линку статьи. Там как раз 5 000 слов :)

Термин, кстати, озвучен (и понят) неправильно, бо в обратном переводе его понимание очень резко меняется. Исследование = research, а не exploration. Надо говорить "Тестирование методом свободного поиска" - много об этом знает Алексей Баранцев и тренинги по этому делу проводит.

4)
Как проверяется спецификация?

не понял вопроса. Подскажите плыз...

Что такое "спецификация"?

Чем "спецификация" отличается от "требований"?

Что от чего зависит и что из чего проистекает?

Яндекс.энциклопедия рулит.

Что такое:
5.1)
стратегия тестирования

Стратегия тестирования - это анализ спецификации (требований) с целью уменьшить кол-во тест-кейсов, не утратив при этом качества теcтирования.

Нет.

Что такое "стратегия" вообще?

5.2)
план тестирования,

План тестирования - определяет объекты тестирования, фокус усилий при тестировании, приоритеты, методы, какие инструменты будут использоваться. Это самый большой из тест-документов, определяющий как будет происходить тестирование.

Вместо того, чтобы ответить "что это" вы ответили на вопрос "что оно определяет".

Перечислять его содержимое - незачем, бо туда много чего может войти, и еще больше может быть оттуда выкинуто в космос. Сперва разберитесь с термином, и заодно ответьте на вопросы
- Зачем тестирование нужно планировать?
- Как это дело можно спланировать?

Не заморачивайтесь чем-то большим и сложным - представим, что речь идет о тестировании функционала 'Save As' из программы "Notepad".

Не факт, что это самый большой документ ;)

5.3)
test script,

догадываюсь, но не могу точно определить, так как нет еще реального опыта.

Опыт не всегда помогает определить термины.

В разных ситуациях под этим термином подразумеваются разные артефакты.

Что такое "скрипт"?

5.4)
check list,

догадываюсь, но не могу точно определить, так как нет еще реального опыта.

Чек-лист - список того, что нужно проверить.

To-do list — список элементарных действий для достижения какой-либо цели

Check list — список, содержащий ряд необходимых проверок для какой-либо работы, по резултатам прохождения списка мы сможем узнать состояние/корректной этой самой работы (понятие растяжимое, тут может быть как и дизайн проекта, так и работоспособность чайника)

у каждого действия может быть проверка, иерархию можно строить сколь угодно сложную, но зачастую этого не нужно, вот пример to-do листа:

Выход на работу:
— Одеть пальто
— Обуть туфли
— Надеть шляпу

В тоже время пример check list-a
(check list: проверка внешнего вида)
— чистота пальто
— блеск туфель
— прямота шляпы

Сами проверки так же заключают в себя действия, но список этих проверок это check list.

- Читать.
- Читать.
- Читать.

5.5)
test case,

test case - набор условий и данных, который определяет: совпадает ли реальный результат выполнения определенного требования с ожидаемым. Т.е. есть ли баг или нет.

Нет, у вас слишком упрощенное определение.

Что такое "кейс" (в оригинале - 'case')?

Зачем нужно придумывать кейсы для того, чтобы что-то протестировать?

5.6)
User Story,

догадываюсь, но не могу точно определить, так как нет еще реального опыта.

http://ru.wikipedia.org/wiki/User_story

5.7)
Use Case?

Use Case -это формат требования, который четко определяет конкретную операцию, выполняемую юзером.

Так просто? :)

http://ru.wikipedia....й_использования

6)
Что такое и для чего используется парное тестирование?

буду рад подсказке

Совершенно логичное определение: "Парным бывает молоко. Вот и тестирование бывает таким же" :)

На деле же вот http://citforum.edun...testing/tandem/

7)
Дано поле ввода числовой оценки. Ограничения – значение от 1 до 100, целые и дробные (десятичная до десятых долей). Назвать классы эквивалентности и граничные значения для числовой оценки, привести пример позитивного и негативного тест-кейса.

тут у нас две границы 1 и 100 и три эквивалентных класса: <1 , >=1 но <=100 и >100.
В данном случае нам нужно три позитивных тест-кейса: взять 1, гдето посреди 1 и 100 (например 50) и взять 100.
и два негативных теста: чуть меньше 1 (например 0,9) и чуть больше 100 (например 100,1).

Давайте это пока пропустим.

8)
Каковы классы эквивалентности и граничные значения при записи CD диска объемом 700 МB?
класса два:<700 и >700 , границы две: 0 и 700 Мб

Тоже пропустим.

9)
Что такое тонкий клиент, толстый клиент, JAVA, Sakai (и город, и программа, и строительная компания...), JIRA, LMS.

Это тонкий клиент, толстый клиент, JAVA, Sakai (и город, и программа, и строительная компания...), JIRA, LMS.

Гуглёж - не болезнь :)

10)
Какое ПО для тестирования вам знакомо (test management)?

Если не знаете, то не придумывайте, бо узнать это приходится каждому.

Тем более, что вопрос явно дурацкий: между термином "ПО для тестирования" и "Система управления процессом тестирования" - маленькая марианская впадина...

11)
Что такое “локализовать баг” и как это сделать?

Подразумевается "определить местонахождение дефекта". Можно просто сообщить о том, что есть дефект. А можно сообщить, где именно он находится - или сразу в коде, или только в приложении.

Не путать с "локализация ПО", бо второе подразумевает перевод и адаптацию к определенной культуре.

И внимание: overquoting запрещен :)

Здравствуйте!
Слышал, что многие начинающие тестировщики желали бы ознакомиться с тестовым заданием при устройстве на вакансию QA engineer. Предлагаю Вашему вниманию именно такое тестовое задание - программку: "ListBoxer".
Многие начинающие тестировщики ждут Вашей помощи! Это может быть все, что угодно - от ссылок на литературные источники до выполнения самого задания.
Далее текст задания:

Найдите максимальное количество ошибок, намеренно допущенных в программе "ListBoxer".

Полное описание принципа работы программы доступно через меню "Help", после ее запуска.

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

•	Составить план тестирования приложения Listboxer.
•	Расписать тестируемые требования к приложению Listboxer, отдельно указать требования которые нельзя протестировать по каким-либо причинам.
•	Указать функциональность приложения, требования к которой не определены, противоречивы или некорректны.
•	Провести тестирование приложения Listboxer.
•	Предоставить отчеты о найденных дефектах, определить готовность приложения к выпуску.

Скачать программу:  ListBoxer.zip   1,46МБ   5897 Количество загрузок:

Ни один человек на этом формуе задавший конкретный вопрос не уйдет без конкретного ответа.

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

 

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

Почему эта задача должна быть для кого-то важнее чем для вас? Я ее скачал, бегло прочитал по диагонали и ответил вам. Мало? Не меньше чем решению этой задачи посвятили вы.

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

 

Алексей, как опытный ИТ рекрутмент консультант дам Вам ряд советов, основанных на анализе резюме с НН: 

 

1) обновление Вашего резюме на НН было 9 января, Ваше сообщение 20 января - надо обновляться каждые три дня, чтобы было много просмотров. НН сейчас основной инструмент поиска персонала.

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

3) в резюме указан перерыв с июня 2015 г. и опять же он ничем не пояснен - проходили ли курсы, занимались ли фрилансом или самообразованием, ухаживали за больным родственником - неясно. Рекрутер может сделать вывод "в 27 лет мужик не работает полгода, наверно он ленивый". Рекомендую этот момент прояснить сразу, то есть в резюме. Это джависты могут год не работать, а потом на 200000 пойти без объяснений, с Вашим опытом такие штуки опасны.

4) то, что ранее Вы работали кладовщиком и в юности продавцом по 2-3 месяца (опять же с перерывами) в разрезе поиска позиции тестировщика неважно. Рекомендую удалить это полностью, либо отобразить как один опыт, например: "Июнь 2006 - Август 2013 - Разные места работы - Обязанности: работал не в ИТ сфере. Параллельно получал образование в направлениии информационной безопасности и изучал то-то и то-то". 

5) для курсов есть подраздел "Дополнительное образование", не стоит писать их в "Обо мне". Тестировщик должен быстро и интуитивно разбираться в интерфейсе новых приложений, по вашему резюме можно предположить, что Вы это не умеете или не хотите. 

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

7) Советую убрать желаемую зарплату - так будет больше звонков, а уже в процессе диалога договоритесь, выясните, совпадают ли ожидаемые вилки у Вас и у работодателя. 

8) в ИТ сфере очень ценится самообучение, поэтому список прочитанных книг или просмотренных онлайн-курсов (помимо имеющихся сертификатов) будет очень большим плюсом.

 

Это только то, что сразу бросается в глаза. У Вас профильное образование, и не одно, Вы молоды и имеете опыт - Вы 100% сможете трудоустроиться, но надо поработать и над резюме, и скорее всего над самопрезентацией и ответами на основные вопросы на интервью (в интернете много тем об этом). Применив мои рекомендации и направив 10-20 откликов на разные позиции - не только на НН, но также проявив активность на ЛинкедИн (написав ряду рекрутеров, разместив пост о поисках) и сделав адресную рассылку в HR отделы ИТ компаний - Вы обязательно получите результат! Надеюсь, мои советы будут полезны не только Вам. Заранее приношу извинения за прямоту - это то, как видит Ваше резюме потенциальный работодатель в лице рекрутера. 

 

Готова провести очную сессию и дать другие рекомендации (конечно, не задаром). Успешно трудоустраиваю ИТшников, сроки получения оффера - от 2 дней =)

 

И удачи в поисках всем ищущим!

Не представляю для чего может понадобиться тест-кейс на проверку вёрстки.
Согласен с Freiman что хватит чек-листа со списком браузеров.

Вёрстку часто проверяют в Photoshop или Gimp так:
1. Делается снимок экрана в браузере
2. Добавляется к макету как отдельный слой
3. На добавленный слой ставится прозрачность
И смотрим что и как где свёрстано.

При всём этом, тестировщик должен владеть минимальными понятиями о вёрстке (и более хорошими, если макет составлял не квалифицированный человек (очень сложный для реализации макет)).

Лучше использовать PixelPerfect для Firefox или PerfectPixel для Chrome :)

Добрый день!
Будут ли варианты, если макета нет?

Для тестирования верстки использую этот чеклист: http://habrahabr.ru/post/114256/

Исходно к созданию данного FAQ послужил пост Sana в этой ветке форума:

помогите, пожалуйста, найти/составить приближенный к идеалу отчет про ошибки (такой себе шаблон)

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

что еще добавить/изменить? было бы не плохо посмотреть на пример

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

Итак, подборка ссылок из интернета (дополнения приветствуются):
Статьи

• "Работа над ошибками малой кровью" — статья Джоэла Спольски с примером оформления дефекта и рассказом о его жизненном цикле.
• Серия постов "Мысли о баг-репортах" Сергея Атрощенкова в его блоге. Очень подробно и с примерами как составлять заголовк бага, его описание и какую дополнительную информацию стоит прикреплять в виде аттачментов. На основе 4-х постов собрано краткое руководство в формате гуглодока.
• Серия постов о баг-репортах в блоге "Про Тестинг" про стуктуру и жизненный цикл баг-репортов в таблицах и схемах. Разобраны основные поля, которые есть у отчета, кто их заполняет, распространенные ошибки при создании баг-репортов.
• Статья "6. Написание запросов в системе отслеживания ошибок" из цикла "TOP 13 ошибок тестировщиков. Часть II. Управление ошибками " — в библиотеке software-testing.ru. Приведен шаблон баг-репорта с подробным описанием каждой части шаблона и градаций типа отчета и степени важности
• Статья в блоге Алексея Лупана (не только про отчеты об ошибке, но и про тестовые задания и поиск работы. Must read для начинающих, тем более, что слог Алексея прекрасен и читается на одном дыхании)
• Памятка составляющему отчет об ошибке — краткое пошаговое руководство к дейтсвия от момента нахождения ошибки до полного занесения в БТС (баг-трекинговая система)
• Распространенные ошибки при составлении баг-репортов — разбор 7 ошибок на хабре (взгляд со стороны разработки)
• И ответ Андрея Адеркина на статью о распостраненных ошибках с хабра — статья "Как правильно составлять баг-репорты" (ответ тестировщиков - достаточно кратко, есть примеры плохих/хороших заголовков, разница между severity и priority)
• Почему не нужны эмоции в отчетах об ошибках - заметка по совету из книжки "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord) от Оли Киселевой.
• Отчет об ошибке - небольшая статья с основами в блоге QA & ST — очень кратко, но все по делу. Как шпаргалка для экзамена собеседования
• "Правильный багрепорт для всех и каждого"— статья Павла Буленко из блога "Not so critical" о том, почему нужны шаблоны отчетов с историей о том, как автор пришел к этому пониманию и какие выгоды получил.
• Как эффективно сообщать об ошибках — прекрасное эссе Саймона Тэтхема — программиста: "В этом эссе я попытаюсь ясно сформулировать, что делает сообщение об ошибке хорошим. В идеале я хотел бы, чтобы все в мире прочитали этот очерк перед тем, как сообщать кому-либо об ошибках."

Доклады
50. Прекрасный доклад Алексея Лянгузова на SQA Days "Грамотная работа с дефект-трекером — путь к успеху". Очень подробно о том, как именно писать ошибки (а вы знаете 4 способа написания заголовков?) и о том, что еще можно делать с БТС

51. "Как заводить баги понятно всем" — доклад Казначеевой Анастасии на SQA Days-11
52. Доклад Сергея Атрощенкова Отчеты об ошибках, или как просто встать на путь постоянного совершенствования с конференции confetQA

Обсуждения на форумах:
71. Обсуждение на этом форуме, как писать баг-репорты, для начинающего тестировщика с примерами шаблонов
72. Ссылка на тему-рекламу семинара Сергея Мартыненко "Как описать дефект". Уже из программы семинара можно получить ряд вопросов, над которыми стоит задуматься
73. Пример, почему не всегда надо заносить все дефекты в баг-трекер (хорошее обсуждение темы, все ли баги надо заносить в баг-трекер)
74. Пример испльзования стандартных терминов при описании бага, чтобы его было легче найти (и не заводить дубликаты)
75. Обсуждение добавления скриншотов к описанию ошибки на этом форуме
76. Классификация полей в отчетах об ошибке (рекомендую прочитать все обсуждение. Полезно, несмотря на давность лет)
77. Как правильно ловить баги — инструкция для бета-тестировщиков игр с описанием того, как заводить баг-репорт.
78. Как правильно писать отчет об ошибке - объяснение на пальцах для блондинок
79. Обсуждение описания ошибки про сообщение об ошибке. Очень интересное обсуждение с разными вариантами описания одного и того же бага, а также споров на тему, что надо включать в отчет об ошибке, а что нет.

Другое

• Пример баг-темплейта на сервисе по формированию шаблонов для баг-репортов для разных трекеров (Jira, Trac, Redmine, github)
• Как правильно обращаться с багом в картинках. Спасибо Andy Glover (http://cartoontester.blogspot.com) —
• Как правильно описывать баг — в картинках. Спасибо Andy Glover (http://cartoontester.blogspot.com)

P.S. ключевые слова для поиска: Issue Document, bug report, defect report, issue report, отчет об ошибке, работа с багтрекером, описание бага, описание ошибки, шаблон бага, шаблон ошибки, bug template, issue template

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

Более половины "проблем" джунов, если не 90% - это, на самом деле, проблема ментора и отсутствия нормального онбординга.
"Вот тебе чек-лист, тестируй!" - и на этом всё..

Все что угодно.
Собирайте фидбек. Да не всегда дают. Да фильтровать надо. Но даже 1 адекватный фидбек на 10 запросов даст направление для работы.
Изучайте вопросы которые задают и в которых плаваете.

 

Возможно это ваши личные качества.

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

А резюме вы не покажете, с ним "все в порядке".

 

Я вас уже по совокупности 3-х постов не найму.

Я не гуру, но свою позицию выскажу. Для статистики, так сказать.

Возможно, требования повышают, потому что немало людей, чувствуя нехватку скила в программировании, пытаются войти в разработку через тестирование. Мол, в компании проще проявить себя, чем пытаться заскочить в поезд на ходу. А так, посижу де в тестерах, попишу автотесты, покажу свой код, найду подход к людям... Ну и т.д. Отсюда предложение с начальными навыками (иногда даже очень неплохими) программирования. А компаниям что? Разработчик по цене тестировщика. Почему нет? Я когда пришел, то ничего вообще не представлял о разработке и тестировании. Всему научился на месте. А когда уходил из компании, на мое место претендовал парень из техподдержки. Ему сказали, что ищут человека с навыками программирования. Вот так то.

Что посоветовать? Искать. Опять же статистика. Откажут в одной компании, другой, третьей. В следующей возьмут. Отнеситесь к этому как "Да? Нет? Следующий!". Почему так мало откликов и приглашений? Не знаю. Пример из жизни: кум претендовал на позицию разработчика в одной компании, не имея при этом опыта работы именно разработчиком. Сам там что-то пописывал на С++ дома. Дал мне почитать свое резюме. Я почитал, поисправлял некоторые фразы, убрал синтаксические и орфографические ошибки. Отправили. Его взяли. Это я к чему? Может что не так с резюме? Лично я подстраивал резюме под каждую вакансию индивидуально. Возможно, у вас там написано то, что не нужно на данной позиции, и HR отметает вас как человеа, неспособного выделить главное... Не знаю. Ведите статистику. 20-30 собеседований - это не информативно. Сказали бы так: я разослал резюме 47 компаниям, 23 пригласили на собеседование, в 16 отказали сразу, в 7 - после тестового задания - вот тогда было бы о чем думать. А пока всё размыто.

Желаю удачи в поисках. Иногда удача - очень важный фактор 

Рано вам в тест-менеджеры :)
Идите в крупную компанию, где много тестировщиков и этих самых тест-менеджеров, и посмотрите, какие у них задачи, методы, сложности.
Со временем разберетесь и начнете брать на себя некоторые обязанности менеджера/лида. И втянетесь. Или нет.

Вообще у вас была отличная возможность стать менеджером/лидом, набраться опыта и набить шишек - http://software-test...botu-pomoshnik/ - но вы ее профакапили.

Это норма. Как говорится, "новичок в первые полгода может даже немножечко вредить".
Пока он не разберется с системой как следует, вам придется на него отвлекаться, и в результате действительно все пойдет медленнее.

Что делать?
1. Выделить на новичка определенное количество времени и в строго определенные часы. Например, 9-9.30, 13-13.30, 18-18.30
Это может снизить его производительность, но повысит вашу. В данном случае, как я понимаю, ваше время сильно важнее, ибо релиз.

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

3. Попросить поизучать систему методом свободного тыка. Ужасно неэффективно, но иногда других вариантов нет.
Дайте ему список вопросов для изучения - какие пользовательские задачи решает продукт, как работает контроль доступа, с какими внешними системами может взаимодействовать продукт (платежи и пр.), итд итп.

В одной известной игре была замечательная фраза "Ничто не истинно и всё возможно". Мне 30 лет, первый раз я подумал о смене профессии и переходе в ИТ в 27. Что - то читал, что - то слушал, начинал с РНР и HTML. Потом родился ребёнок и стало слегка не до смены работы. Чуть позже я начал учить С# и читать книги по тестированию. В итоге я сходил на два собеседования в обоих случаях меня взяли, с одной разницей - на первом мне предложили просто смешную ЗП, а на втором дали ту на которую я минимально рассчитывал (т.к. меньше не мог, ибо семья) и через три месяца накинули еще 300 у.е. Сейчас я уже начал писать тесты C# + Selenium с помощью нового друга из моего дев тима. Резюме всего этого, никогда не сдавайтесь, будьте уверены в себе и вас возьмут, рано или поздно.

Конструктивно, как исправить -- теперь метод должен выглядеть примерно так:

  private String closeAlertAndGetItsText() {
    try {
      Alert alert = driver.switchTo().alert();
      String alertText = alert.getText();
      if (acceptNextAlert) {
        alert.accept();
      } else {
        alert.dismiss();
      }
      return alertText;
    } finally {
      acceptNextAlert = true;
    }
  }

К сожалению, новые релизы Selenium IDE выходят реже, чем релизы WebDriver, поэтому пока код генерируется ошибочный. В следующей версии Selenium IDE это уже будет исправлено.

Коллеги, узнала о себе кое-что новое: я могла бы работать за комплименты ))

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

От меня требовали методы тестирования, идеи,направления. Но хотели услышать только те которые записаны у них в тест плане. Потому что по началу у меня просто была лавина идей, но меня заворачивали.

- изначально неправильный подход того, кто проводил собеседование. Увы, такое встречается. Кто проводил собеседование? Руководитель компании или отдела тестирования?
Не взяли в такую контору - не велика беда )



На свое решение я потратила 40 минут.
Удалила вот почему: за обедом вдруг подумала, что, может быть, FreeMan1 очень тонко играет - хочет получить решение на свою тестовую задачку. Хотя, после первого прочтения условий такой мысли не возникло). FreeMan1, пожалуйста, простите мне мое недоверие!

Решение именно в том виде, как было, ниже,
но у меня появились новые мысли:
1) в тест-дизайне уделить внимание безопасности. Проверить, возможен ли тут аналог sql-инъекции. И как шифруются данные ; )
2) я указала, что не стала бы проверять для всех 59 потоков. Сейчас думаю, что я была не права. На практике сколько угодно случаев нелепых копи-пастов ; )

Очень жду конструктивной критики.
Моя реальная работа делается так: разработчик (их шесть, тестировщик один) делает фичу, я пишу для неё чеклист на бумаге, прохожу. Никому не сообщаю своих оценок, на вики сохраняю только то, что нельзя забывать. Поэтому оценить оценку в 50-90 часов мне трудно ))

Именно таким никогда не занималась на работе, но интересно стало быстренько попробовать.

Первым делом, я бы спросила, есть ли подробная документация (говорят, это надо первым делом спрашивать на собеседовании : )). Видимо ответ будет: "это всё, что есть"

Я поняла условие так: есть функция f(бинарные данные; номер потока) - читает, перерабатывает, сохраняет данные - функция запускается при каком-то условии - по таймеру, или по размеру файлов на диске. Тут ещё хочется задать вопрос, с какими параметрами приложения может быть связь - вопрос к спецификации, аналитикам, разработчикам.

То есть, проверяем f(bin,i) и scheduler(?). Плюс, считаю, нужно и нагрузочное тестирование.

Что делать:

1. Разворачиваем окружение.
Сервер, на котором работает приложение: установка OS, ftp server, database, тестируемого приложения, конфигурация. Машина, с которой будут идти тестовые данные. Сетевой интерфейс между ними.

[часов 16 надо - учитывая риски, что админов не окажется на месте и всё такое. Возможно, в живом проекте всё это уже есть, и этот шаг пропустится]

2. Тест-дизайн.
Чтение с диска: размеры файлов, блокировки...
f(bin,i) - чтобы написать идеи, надо знать, каким образом перерабатываются данные перед сохранением в таблицу. Наверно, я бы сказала, что для каждого i специально проверять не буду )
сохранение данных в таблицу
scheduler

При составлении тест-дизайна формируются и требования к эмулятору входных данных - след. пункт.

[Зависит от процессов компании. Написание тест-кейсав - часов 20, подробный план тестирования - часов 10]

3. Создание эмулятора потоков входных данных - например, java, генерация данных в нужном формате и сохранение, возможно, запуск эмулятора по таймеру. Написание, отладка, тестирование.

[написание: 6 часа, доделка, отладка, проверка, со всякими рисками - 10 часов. Итого - 16]

4. Выполнение тестов

[функциональные тесты - 8 часов, нагрузочные - вообще не знаю )) , рассуждать буду так: отладка + калибровка + отработка - часов 8 человеческого присутствия, плюс выполнение - часов 20, в том числе ночью.]

5. Оформление, анализ результатов

[функциональные тесты - 2 часа, нагрузочные - опять не знаю )) , кажется миллион, но отвечу 6]

По времени получилось 50-90 часов

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

Подробнее всего по теме мне понравилась блестящая статья Майкла Болтона. Очень рекомендую, там хорошо рассказано о самом методе, его целях и преимуществах, и о том, что иногда лучше не долго составлять комбинации, а "прыгать в воду и плыть".
http://www.developse...iseTesting.html

На сайте, посвященном этой методике, есть ссылки и на и другие статьи по теме:
"Articles and Other Resources on topic"
http://www.pairwise.org/articles.asp

А здесь ссылки на инструменты. Есть устаревшие, есть рабочие:
"Pairwise Testing - Available Tools"
http://www.pairwise.org/tools.asp

Jenny - один из рабочих.
http://burtleburtle....math/jenny.html
(список комбинаций от Jenny можно легко превращать в текстовый какой-нибудь программой для множественной замены)


Ранее подымавшиеся по вопросу темы на форуме, из тех, что мне помогли и для тех, кто предпочитает почитать о теме по-русски:

http://software-test...rum/topic/2113/
Сайты посвящённые Pairwise Testing

http://software-test...rum/topic/1599/
Зависимые тесты как сократить число тестов

http://software-test...forum/topic/90/
Ортогональные матрицы для тестирования

http://software-test...forum/topic/91/
Пример ортогональной матрицы


Дополнения в тему, естественно, приветствуются :)

Это самый адекватный ответ на заданные вопросы. Нефиг садится за штурвал если тангаж от крена не отличаете.

https://www.codecade...om/learn/python