2 пример не соответствует условия.
Целое число может быть отрицательным, где пример вида -7+3. Вполне соответствует заявленным условиям
 

целых чисел от одного до десяти

 

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

2 пример не соответствует условия.
Целое число может быть отрицательным, где пример вида -7+3. Вполне соответствует заявленным условиям
 

Блок о обучении кривоват. В заголовке курсы, в теле прочитанные книги. Абзац переименовать бы.
Эммм, а насколько уместен термин "Читаю".  Это не талмуд Эккеля по Яве, читается за выходные.
Детализация трудовой книжки до даты спорно.
Фамилия засвечена в адресе почты.
 

Что вы под выражением "данной задачи" - имеете ввиду. Из контекста не ясно.
Sikuli вам для функционального тестирования (если в контексте оно имелось ввиду) не подойдет?

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

Эммм. Предположим ваша команда разработчиков произвела полный рефакторинг кода? Сколько итераций потребуется для доведения программы до продажного вида?

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

Для новичка в тестировании да, для опытного специалиста нет (если речь конечно идет о пропущенных ошибках, воспроизводимых на сборке 1 итерации).
Если не секрет, на сколько сырой ваш проект? На какой стадии жизненного цикла он находится?
И какой у релиза формат?
В моей компании релизы делятся на исправительный и несущие обновление функционала.
Для первого типа 3 это норма и в принципе вопросы менеджера о общем количестве итераций справедливы, но мы не перетестируем весь функционал, мы верифицируем исправленные ошибки, и ищем баги упаковки.
Для функционального релиза сейчас норма 4-5, хотя начиналось все с 13 итераций на совсем сырой софтине и на заре моей карьеры тест-лида. Как выше сказано с опытом все приходит:)
ЗЫ
Менеджер кстати ждет от вас сходимости тестового покрытия. Как вы формировали план кейсов на вторую итерацию, чем он отличался от плана на первую? 

 

 

 сколько может быть итераций до релиза (вернее сколько нужно ) или сколько надо делать итераций до релиза, ведь их может быть бесконечное число?
Как правильно организовать процесс тестирование, чтоб при релизе можно было выпустить продукт максимально качественный (с минимальным количеством багов, понятно что они могут быть)

Кто-то из великих (ЕМНИП Канер) говорил про 8 итераций. Мне на модуль в 50-100 вариантов использования, как правило, хватало 4-5.

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

 

ну хоть кто-то ещё заметил, что количество итераций тестирования напрямую зависит от качества кода и реализации и зрелости процессов.

 

Ну хоть кто то еще помимо кого это заметил?
Дима, вы о ком?
 

 

пока все зарегистрированные в ходе тестирования ошибки

В целом я с вами согласен, но вот этот пункт неплохо бы развернуть таким дополнением:

проведено достаточное тестирование функционала (покрытие функционала тестами, причём желательно на одной и той же версии).

Иначе вашу формулировку можно довести до абсурда: времени хватило на тестирование только логин диалога, в нём найдён и пофикшен 1 баг, ура, релизим.

А бизнес-логику даже и не посмотрел никто.

 

Дак девушка сказала, что смотрит весь функционал, вот я ей и доверился)


 

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

 

Кажется, я провалил ваш опрос.

failed_survey.png

А я хочу стать гражданином fdh

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

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

Вы слишком строги к данным ребятам. Их наклеечка на разных талмудах (например Философия Java Эккеля) как бы намекает)
Ну взяли они нуба на HR должность. Ну не умеют они классифицировать qa. Ну просят они за бесплатно друга продать)

Переиздание вот этой книги?

Расчлените софтину на ряд областей (категорий рисков). Я решил поступить так как показано на скрине.

В красную выделены области ошибка в которых приведет к отказу программы в продакшене, остановки работы предприятия клиента, падению репутации компании и отзыву релиза с рынка.
В желтую и зеленую группе области которые могут пожить в ожидании исправительного релиза.
В синей мало используемый клиентами или не затрагиваемый разработкой функционал.
Помимо этого в багтрекере, есть данные риски заведены, как отдельный реквизит у бага, поэтому возможно проводить срез и видеть где нужно усиливать покрытие.
Соответственно и тесты с нуля нужно начинать создавать для ключевых зон и дальше вниз по ниспадающей.
Помимо этого эта группировка позволяет определять количество прогонов в разных средах и с разными условиями. (web, gui\ sql, postgresql, oracle\ внутренние опции программы). Соответственно соотношение прогонов 4,2,1, эксплоративное тестирование.
По поводу деления на группы. В принципе это разумно, но почему вы не хотите подтягивать отстающих.
Я бы предложил следующую методику, старшие анализируют документацию и создают Чек-лист с описанием проверок. Вы как руководитель анализируете и проверяете на полноту и если, что дополняете и показываете направления развития, после чего документ летит к младшим и они доводят его до состояния детального тест-кейса. Как верно кто то на форуме выразился, тест-кейс это документ отчетности, дак пусть младшие понимают, что их контролируют. От этого качество тестирования только повысится.


 

 

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

 

Но для начала расставьте приоритеты - к чему нужно писать тест-кейсы/чек-листы, а к чему нет. Покрыть надо в первую очередь самые важные фичи, если времени не вагон

 

Поддержжу данный тезис.
Рекс Блэк и и его книга "Ключевые процессы тестирования" вам в помощь.
Павел, вы сказали 6 человек. А что эти люди из себя представляют?
Это именно группа тестирования или выделенный ресурс разработчиков? 
Функциональному эксперту достаточно чек-листа, джуниору или ленивому программеру нужен подробный тестовый сценарий.
Как обстоит ситуация с описательной моделью этого вашего огромного проекта? 


 

Недавно получил ответ на резюме, предложили пройти собеседование по скайпу. Собеседование прошел, дали тестовое задание. Так вот суть в чем. Может кто нибудь (из форумчан поопытнее) посмотреть мой отчет, подсказать что добавить-убрать? Отчет я показал своему куратору, на что получил ответ, что он сыроват, на мою просьбу направить-подсказать, предложил разобраться самостоятельно.  Заранее благодарю за помощь и потраченное время

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

Коллега, к сожалению, не смогу ответить на первый, третий, четвертый и пятый вопрос.
Зато, к вашему счастью, могу ответить на второй вопрос.

2) Какова средняя заработная плата тестеру за час в режиме закрытого кода? — Три миллиона долларов. Наличными.

P.S. Так то я понимаю что без английского никуда, и мне самому приходиться писать баги на английском, но чтобы ставить знание языка во главу угла...ИМХО не правильный подход.

В этой фразе, вы на мой взгляд, неверно акценты расставили.
Тестер решает задачи валидации исходя из спецификации, а если она на английском? А если разработчики сидят в Германии или Индии к примеру.
А если софтина нацелена на западный рынок и на QA возложена задача обработки входящих багов от конечных потребителей?
Есть, к примеру, у нас на рынке труда некий локализатор игрулек, Иннова. Дак они ищут в штат спеца с навыками корейского.. Ну хочется им локализовывать корейский контент.

 

 

выше приведенная выдержка

 

Не могу понять, на что имено у Вас такая реакция... Если по отношению к требованию в 2 месяца работодателя, то при чем тут выдержка, если в АйТи сфере я ещё никогда и не на кого не работал... Я только 3 месяца назад только узнал о том, что такая профессия существует. За первый месяц был прочитан и детально законспектирован (впервые я с удовольствием писал конспект!) Каннер, пока был на работе - "проходил" вебинар Портнова... Когда пригласили на собеседование в Глобал Лоджик - с утра и до ночи проводил изучая OSI слои и с нуля пытаясь вникнуть в линукс... Естественно не пройдя собеседования из-за плохого понимания линукса, следующий месяц уменя уходил на ежедневные 5-ти часовые вебинары, посвященные администированию линукса, но в ГЛ мне сообщили, что заказчик не хочет все отклоненные кандидатуры пересматривать заново. Но о том, что паралельно при этом всём я вникал в основы языков питон, джава, си ++... Подводя итоги за самим собой - понял, что сильно распылился и что мне необходим опыт, который как чекпоинт позволит мне развиваться дальше и выбрать уже направление в какую специализацию мне углубляться

 

Стрессовая реакция, коллега ушел в горизонтальный рост, пообщался с теоретическим заменителем, и спроецировал мнение о нем на вас. 
Вы знаете, Дмитрий, честно говоря поражен вашим рвением в изучении профессии. Если бы вы были Москвичом, то после такого спича, я не задумываясь пригласил вас на интервью на должность Джуниора.
Вобщем то, ознакомился с HH.ua. 3 вакансии по запросу Junior QA... Ситуация не вах какая приятная.
Наверное дам не очень уместный, по крайней мере на данном форуме, совет.
Предлагаю рассмотреть вот эту Киевскую вакансию:
http://hh.ua/vacancy...07?query=1c бит
Контора специфичная, берут любого с улицы, заявленный специалист это и чтец и жнец и на трубе игрец, но если вы продали любимую гитару ради внедрения в IT сферу...
Базового представления о бухучете и изучения талмуда Радченко "Практическое пособие разработчика" должно хватить для трудоустройства. Ручками прогрессивный УТ можно здесь в вэбе потрогать http://demo.1c.ru/
К тестированию я шел приблизительно таким путем.




 

Извиняюсь, за вчерашний спич. Стресс.насел. Гитара кстати отличная у вас.
Ниже приведена живая тема, которая позволит вам получить необходимый опыт функционального тестирования.
http://software-test...ovshiki/page-10

 

 

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

 

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

 

 

 

 

Вы представляете компанию-разработчика, или за деньги нагоняете разработчику народ на тест? Бывали такие красавцы.

И второй вопрос: вы предоставляете какой-то контроль, обучение, что-либо действительно полезное для новичка? Или просто ищете таким образом бесплатных манки-кликеров?

Здравствуйте, и спасибо за вопрос, Ryjii!

 

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

 

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

 

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

 

Простите, но много "воды" и ничего конкретного. Или мошенник, или Вы сможете ответить на прямой вопрос со второй попытки - ЧТО (чёрт возьми) Вы можете дать новичку, который будет "тестировать" Ваш продукт?!

 

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

 

Итак, Виталий, надеюсь с 3 попытки вы ответите на вопрос - ЧТО,СТО ТЫСЯЧЕЙ ЧЕРТЕЙ, ВЫ МОЖЕТЕ ДАТЬ НОВИЧКУ, помимо рекомендательного письма от конторки, которая пытается обойти федеральный закон от 29.12.2006 N 244-ФЗ (ред. от 23.07.2013) "О государственном регулировании деятельности по организации и проведению азартных игр и о внесении изменений в некоторые законодательные акты Российской Федерации"?

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

 

 

Тестирование не приводит к появлению ошибок, оно их обнаруживает. А что с ними делать - это уже вопрос к ЛПРу.

 

P.S.

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

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

 

Вообщем то вы правильно описали, но в моем случае есть специфика.
Мой проект достался мне в наследство. Тестировался ранее исключительно паком позитивных автотестов, причем сам проект второплановый и писался, что называется... При первом знакомстве в первом же справочнике обнаружил 4 ошибки, которые естественно оказались непривнесенными и существовали несколько лет.
Проверка обновления и интеграционное тестирование занимает трудодень. Регрессия основных элементов - 10.
При этом основной продукт прямой конкурент данного и задачи его тестирования в абсолютном приоритете.
За 2 года выпустил его 6 или 7 раз. Да. один раз словили критическую ошибку, вызванную вышеуказанным пунктом 1. Ее поправили и за день перевыпустились.

 

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

 

Последние два вопроса от ТС наводят на мысль, что это вопрос с собеседования. Поэтому хотелось бы побольше входных данных, соглашусь с kirill_222.

Вам надо просто протестировать этот магазин?

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

Это не вопрос с собеседования, это проект с фриланса. Там люди нашли много багов, стало интересно как они это сделали. Хочу научиться тестировать подобные интернет-магазины.

 

Евгении, вы ознакомились с этой статьей? http://forworktests....3/03/web_3.html
Выдается 2 строкой в гугле на запрос "основы тестирования web приложений".
Пробежал ее по диагонали, базовые ответы на ваши вопросы она даст.

Приветствую. Подскажите, как автоматизировать тестирование интернет-магазина?
К примеру, этого: http://santehopt-per...221);">2</span> 
Какие есть хорошие автокликеры, верификаторы безопасности, программы для нагрузочного тестирования?
Или может вручную это стоит делать? Как вообще происходит тестирование интернет-магазинов?

Евгений, приветствую вас.
Вы таки свою задачу описали в общих чертах.
Наверное легко было бы отписаться фразой Selenium webdriver + JavaScript + SQL запросы, вам в помощь.
Это не есть гуд.
Предлагаю детализировать задачи по пунктам: 1.Кто вы в этом проекте, и насколько с тестированием вы знакомы, 2. Выделение поставленных руководством задач и осмысление ТЗ 3. Выделение критериев качества и их ранжирование, 4. Покрытие критериев качества кейсами, 5. Автоматизация тестирования.
Давайте начнем с первого пункта: кто вы, что вы, зачем, кто с вами в этом проекте, насколько с тестированием знакомы. Ну и резюме ваше было бы здорово видеть:)
ЗЫ
Коллеги, возможно на себя много беру, прошу поправить суждения.