Sezam

https://vk.com/radio...30618a9f9970f04

А я не знаю прав ли тренер.
Обычно тренер прописывает цель своих упражнений. И возможно, на эту цель работает его комментарий. Цели могут быть разные. Вот от слова А-Б-С-О-Л-Ю-Т-Н-О. :)
Смотря чему он хочет научить или на какие мысли вас натолкнуть своим комментарием.

Если же это сделано не для работы с окончательной целью -- то... ну и такие тренера есть, что ж сказать.

ЗЫ. А у тренера не пробовали спрашивать зачем ОН, а ни кто-то с форума написал такой комментарий? :)

Доброе время суток!

В данный момент работаю Senior QA/Analyst, но хочу уйти в Sales Manager-ы в рамках IT. Столкнулась с проблемой, что в Sales-ы не берут без опыта, несмотря на весомый опыт работы в ИТ и наличие опыта управления. Но вопрос в том, что как же его этот опыт получить, если без опыта и не берут в продажники.

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

1. У меня друг из проектирования ушел в продажи, без каких-либо проблем (около года назад, город СПб) Т.е. можно без опыта в продажах, вопрос времени и того, что именно хочется продавать.
2. Изучайте по книгам, вебинарам подход к продажам. Начинайте применять подход в своей сфере -- продавайте идеи, предлагайте технические решения начальству, заказчикам, маркетингу -- продавайте им эти решения.
Это будет ваш реальный опыт в продажах.

Более дубового ответа не ожидал. Я бы начал с того, что самая главная часть задачи модульного тестирования - это декомпозиция. Как её грамотно сделать - самый интересный стратегический вопрос, от решения которого зависит эффективность тестирования!

что такое эффективность тестирования?

Всем привет!

Из Википедии: Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
То есть, Википедия приравнивает модульное и юнит-тестирование.

Вопрос такой - что можно считать модульным тестированием?
Любой вид тестирования (в том числе функциональное тестирование через UI) отдельно взятого модуля или же обязательно тестирование на уровне кода?

1. Не приравнивает Википедия, а переводит :-) unit == модуль.
2. Ответ такой: что посчитаете необходимым. Обычно (чаще всего что я видел\слышал, о чем говорят стандарты) под модульным тестированием понимается классическая работа с кодом (white box).
Модульное тестирование (unit тестирование) это один из вариантов компонентного тестирования, а компонентное тестирование это тестирование отдельных компонентов. Компонент -- составная часть чего-либо. Это может быть кодом, может быть бизнес-функционалом, может быть архитектурной деталью -- главное, что это можно тестировать изолированно, отдельно от остальных частей.

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

ссылка

за подсказки сразу + к карме же гарантируется!

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

• Что вам необходимо протестировать, какая у вас есть информация, как поставлена задача ? Возможно в вашей формулировке вы нашли 100% ошибок, с другой стороны -- возможно около 10%.
• Что вы знаете об архитектуре приложения ? К чему у вас кроме UI есть доступ?
• Формулировка подразумевает дополнительный анализ с вашей стороны ? Например нет четких тест-кейсов, сказано просто -- протестировать и дана ссылка на страницу (тестовые задания так любят давать).
• Вы выполнили анализ ? Какие области (бизнес\технические) анализировались ? Что из себя представляет результат анализа ?
• Пробовали выявить функциональные и логические блоки в приложении, и анализировать их по отдельности, на возможные ошибки ?
• Как вы запланировали провести свое тестирование ? Какие области и как смотреть собирались ?

Не обязательно на все писать документ. Это можно в голове делать.

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

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

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

Надеюсь этот пост(серия постов) будет полезно или натолкнет на свой подход к написанию баг-репортов.
Здравый смысл и необходимость -- сами по себе никто не отменяет :-)

Хотите честно ?
Если у вас всё работает и без тест-кейсов - забейте на них. Судя по описанию здесь неплохо было-бы наладить процесс создания новых фич. Если старый напрягает... вообще-то говоря :-)

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

Понадобятся для маркетинга или заказчика, скажите - "а нету их".
Понадобится вспомнить через несолько месяцев\лет, что же за фича, и есть только "спека". А тесты... - "а нету их".
Понадобится Вам в отпуск, а проверить, что релиз выкатывать попросят программиста Викториуса. Он спросит, а что проверять? И вроде-бы тесты ему дать хочется... - "а нету их".
Я могу быть уверен "* Чтобы произвести впечатление на руководство - им пофиг, лишь бы багов не было", что багов нет? Посмотрю по тестам, как они прошли, что покрыл-что нет, может в другой стороне копнуть надо... -"а нету их".
...

кроме англоязычных. русские все
можно чуть по-подробнее про test suite? что, зачем, с кем и почему? и сколько раз=)

строится из уже имеющихся тестов, объединяется по какому-то определенному признаку.
Некоторые сюиты, с которыми сталкивался:


Функциональные\не функциональные наборы.
1. Признак может носить функциональный характер: тестирование какого-либо бизнес-определенного поведения программы (проверка пользовательского сценария)
2. Признак может носить не функциональный характер: тестирование производительности.

Может быть разделение по областям покрытия:
1. Покрытие веток программного кода
2. Покрытие функциональных элементов (страницы\Экраны\консоли)


Может быть разделение по времени затрачиваемому на выполнение (обычно совмещалось с функциональным\не функциональным разделением):
1. Сюит должен выполняться за час.
2. Сюиты должны выполняться одинаковое время.

Может быть разделение по этапу тестирования:
1. Сюиты тестирования требований
2. Приемочное тестирование
3. BVT
4....

Создаются для упрощения трассировки. Для ускорения коммуникации. Для более высокоуровнего управления тестированием.

Хорошее резюме :)


На вскидку:

• Название файла - не уникально, может затеряться в папке HR-ов.
• Objective

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

• Образование я перенес бы вниз, у вас есть опыт, который интереснее может оказаться для работодателя (если отсылаем резюме в компанию которая по предметной области похожа).
• Навыки - перенес бы под опыт.
• MS Office

• опечатка в уровне знаний.
• Мне не кажется необходимым писать о навыках работы с офисным ПО в вакансии для технаря, когда IT-related умения и навыки - более технически сложные.

• градация basic knowledge и т.п. - не очень понятна, т.е. я как интервьюер буду в затруднении подготовить однозначные вопросы для проверки именно этого уровня, можно расписать подробнее - области, которые известны и не "градировать" базовые знания: strong не strong.
• Где на практике применялись технические знания?
• Перс. хар-ки - не уверен что их до сих пор читают HR-ы, менеджеры, там вроде никто не пишет что он "урюк, разгильдяй и лодырь" :)
• Если есть возможность, в опыте стоит отразить техническую сторону в том случае, если резюме отправляется в компанию из другой предметной области (не продажи\медицина).

Небольшой оффтопик.
Сейчас наткнулся на ошибку SQL Server'a c датами меньше, чем 1753/01/01. С этой датой работает, а 1752/12/31 и меньше уже отваливается.
Может кто знает в чем там дело?

говорят: "Тестирование скучная, монотонная работ" :)


ограничение типа datetime
1 января 1753 года — 31 декабря 9999 года

ИМХО почему:
Т.к. до 1752 года Англия и её колонии не принимали григорианского календаря для синхронизации календаря с лунным циклом (Calendar (New Style) выкинули 10 дней: 9/3/1752 - 9/13/1752.
Т.е. год получился "укороченным", что повод ограничить тип переменной, дабы не разбираться с внезапными граблями на программном уровне, куда делись 10 дней. Как месяцы друг в друга перегонять и т.п.

Ещё интересные даты:
10/5/1582 - 10/14/1582 - эти даты были исключены из григорианского календаря папской буллой о переходе от юлианского к григорианскому календарю. Т.е. как-раз, переход на "новый стиль", если угодно. Следующим днём после 4 октября стало 15 октября.
Т.е. логическая граница, для требований\ПО... а то мало-ли, решит кто архивы старые хранить.
И да, разработчики тоже историю могут знать... :)

Никакой загадки :)
Unix время: с 01.01.1970 - начинается отсчет.в 19.01.2038 (03:14:08) значение переменной для времени привысит 2^31.
что может привести к ошибке.
Это довольно-таки стандартные даты для проверки программ работающих со временем.


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

Александр Калугин про эту тему давно говорит:
http://pmarcor.com/2...uality-manager/
http://www.slideshar...ORP/ss-10493069

Вот резюме

1. Citizenship - Гражданство.
2. Зачем красный цвет?
3. Опять же - русский текст с английским вместе. Сделайте два резюме, на вакансии на английском и русском.
4. где Ваши достижения? О чем были сделаны курсовые? Дипломные работы?
5. Окончание обучения через 4 года, и готовность работать по 40 и более часов в неделю. Потянете?
6. senior AT engineer - senior IT engineer возможно? Непонятно что в обязанности этого инженера будет входить.
7. ПО для работы с графикой - оно необходимо на вакансии куда Вы посылаете резюме?
8. Название файла. Как это название может быть ассоциировано с Вами?


Повторю рекомендацию изучить линчевание резюме на dou.ua :)

Если думаете работать на западных заказчиков - то сертификация уровня Advanced очень им приятна. Восторга от Foundational уровня - видел мало, практически совсем не видел :).
Просто сдать на "шару" можно, вероятность не 0%.
Однако, будьте готовы ответить на вопросы уровня соответствующего вашему сертификату на собеседовании.

Для опытного тестировщика не сидящего на пятой точке ровно, и развивающегося - Foundational - ночь подготовки словарь посмотреть, и можно идти сдавать :)