Требования тестировщик по

Оглавление:

Форум тестировщиков

Требуется младший тестировщик ПО (Junior t.

TexunaTech_job 21 дек 2004

Требуется младший тестировщик ПО (Москва).

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

Ручное и автоматическое тестирование,
документирование результатов тестирования.

Зарплата 300 — 500 $/месяц в зависимости от опыта и квалификации.
Гибкий график (рабочая неделя минимум 30 часов).
Офис в 5 мин. от м. Полежаевская.

Если Вас заинтересовала вакансия, пожалуйста, пришлите Ваше резюме по адресу [email protected]

SergeyP 22 дек 2004

Зарплата 300 — 500 $/месяц в зависимости от опыта и квалификации.
Гибкий график (рабочая неделя минимум 30 часов).
Офис в 5 мин. от м. Полежаевская.

Это з/плата за 30 часов в неделю ?
Какие требования к гражданству, прописке ?

TexunaTech_job 22 дек 2004

Это з/плата за 30 часов в неделю ?
Какие требования к гражданству, прописке ?

Да, это з/плата за неполную неделю с гибким графиком мин. 30 часов в неделю,
гражданство желательно российское.

Тестировщик ПО: как не стать «плохим» специалистом?

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

Представьте себе качество приложения, разработчики которого решили миновать фазу тестирования! Недовольство пользователя нетрудно вообразить, — ведь это чувство вам тоже знакомо, верно? Уже не вызывает сомнений, что тестирование приложений необходимо, и для этого требуются «хорошие специалисты». Но как же выявить плохого тестировщика?

Признаки плохого тестировщика

Слабые коммуникативные способности

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

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

Вот признаки, которые определяют тестировщика, обладающего слабыми коммуникативными способностями:

  • отсутствие энергии для общения;
  • боязнь высказывать свое мнение;
  • чувство уязвимости;
  • недостаток подготовки.

Недостаток технических знаний

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

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

Вот список факторов, оказывающих влияние на уровень технических знаний:

  • отсутствие необходимой для обучения самодисциплины;
  • недостаток практики;
  • недостаток энергии или энтузиазма.

Написание баг-репорта без анализа бага

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

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

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

  • некорректные данные тестирования;
  • нестабильная среда тестирования;
  • неправильная последовательность тестирования;
  • неправильно сформулированные требования.

Отказ от следования процедурам контроля качества

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

Вот примеры подобных отклонений от процедур контроля качества:

  • неиспользование правильных шаблонов тестовых артефактов;
  • не следование процессам обзора;
  • указание более старых версий документов из-за отсутствия контроля версий во время тестирования.

Тестирование, основанное на допущениях

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

Так что никогда не тестируйте ПО, опираясь на предположения! Добейтесь от разработчиков или аналитиков чётких и понятных требований. Если какие-то конкретные требования для вас неясны, задавайте вопросы без всяких сомнений. Баг, пропущенный из-за неправильных предположений, может стоить огромных затрат для проекта.

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

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

Не следование принципу «Протестировать — значит сломать»

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

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

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

Вот факторы, которые мешают следовать принципу «Протестировать — значит сломать»:

  • используются только позитивные подходы к оценке работы системы при полном исключении негативных;
  • не используются исследовательское и Ad Hoc тестирование;
  • недостаток внимания в процессе тестирования;
  • тестирование лишь идеальных сценариев использования ПО.

Застой в развитии навыков тестировщика

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

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

Следующие факторы могут вызвать застой в развитии навыков тестировщика:

  • нежелание повышать свою квалификацию;
  • монотонность рабочего процесса;
  • боязнь выхода из «зоны комфорта».
  • отсутствие четкого представления о собственных карьерных целях.

Отсутствие способности взглянуть на приложение с точки зрения конечного пользователя

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

Смотрите так же:  Налог на тунеядство россии

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

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

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

Примеры халатности во время тестирования:

  • тестировщик забыл добавить скриншот;
  • баг был заведён с неполной или неправильной информацией;
  • вместо точного баг-репорта тестировщик написал чрезмерно растянутый и полный «воды»;
  • был написан некорректный тест-кейс, или же были пропущены шаги в текущем тест-кейсе;
  • тестировщику не хватает способности воспринимать информацию на слух, из-за чего он может пропустить важные моменты.

Тестирование может выполнить любой

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

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

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

Плохой тестировщик, как правило, строит следующие предположения о процессе тестирования:

  • тестирование не требует никаких особых навыков;
  • тестирование — лёгкая работа, которая может быть выполнена каждым;
  • тестировщику нереально добиться карьерного роста — он всегда будет просто пешкой;
  • тестирование — монотонная работа, и ничего нового в ежедневном рабочем процессе ожидать не стоит.

Как не быть плохим тестировщиком

Признаков, по которым вы можете отличить плохого тестировщика от хорошего, множество.

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

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

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

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

Форум тестировщиков

Требования к тестировщику.

GeeZ 03 июл 2015

Скажите, какие наиболее популярные технологиии (и на каком уровне) необходимы для успешного соискателя на должность тестировщика?

Допустим прочёл я Савина, скачал тестовые задания, спецификации, примеры тест-кейсов. Разобрался во всём этом по мере сил. Что дальше? Должен ли я знать HTML, JavaScript, CSS, php и т.д. и на каком уровне?

Да и ещё про возраст: странно ли будет прийти на собеседование на junior tester в 39 лет?

SHINNOK 03 июл 2015

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

Всё зависит от конкретной вакансии — где-то надо знать автоматизацию с помощью Selenium, где-то инструменты нагрузочного тестирования, где-то безопасности и т.д. Определитесь со спецификой и качайтесь в этом направлении 🙂

Molechka 06 июл 2015

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

Вторая колонка добавит веса, но ее сложно прокачать самостоятельно или по книжкам. Но никто не мешает попробовать =)

Знания HTML, JavaScript, CSS, php также добавят вам веса, но, имхо, тестировщик должен сначала побыть ручным, а потом переходить в автоматизацию. То есть знания должны быть на уровне чтения кода, не написания

    Вы здесь:
  1. Главная
  2. Статьи про IT
  3. Собеседования
  4. Подготовка и прохождение собеседования
  5. Требования к тестировщику ПО
  6. Требования к тестировщику ч.2: процессы и этапы разработки ПО

Новые материалы

Требования к тестировщику ч.2: процессы и этапы разработки ПО

В этой части рассмотрим, что необходимо знать про процессы разработки и жизненный цикл программного обеспечения (ПО). В принципе от каждого специалиста (и вакансия тестировщика не исключение), ожидают, что он быстро впишется в общий рабочий процесс. Для этого он конечно же должен представлять как этот процесс выглядит (хотя бы в теории), кто и как в нем участвует. Именно поэтому при приеме на работу большинство интервьюеров оценивают знание процессов промышленной разработки ПО, то, как кандидат видит в нем свое место. Подробно об этапах жизненного цикла ПО и методологиях разработки с точки зрения тестирования я напишу в отдельно, а ниже приведу основные моменты, которые потребуются для подготовки к собеседованию.

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

В целом жизненный цикл каждого ПО, вне зависимости от подходов к его разработке, как правило включает одних и те же этапы:

  • Планирование – формируется бизнес идея и определяются функциональные требования к ПО
  • Проектирование — разрабатывается архитектурное решение системы и выполняется системный анализ, готовится техническое задание для разработки
  • Разработка – непосредственно написание программного продукта
  • Тестирование – выполняется проверка и отладка ПО в соответствии с требованиями. Сюда же относиться UAT — пользовательское тестирование и приемка ПО заказчиком
  • Внедрение – предварительная тестовая установка релиза — DryRun, подготовка всех необходимых инструкций, настройка окружения и установка ПО
  • Поддержка – консультирование пользователей, исправление ошибок, внедрение доработок

2. Помимо знания самих этапов разработки важно понимать кто выполняет работу на этих этапах, какие роли и задачи у участников процесса. В процессе разработки ПО все роли (по крайней мере в идеальном мире) тесно взаимодействуют между собой, поэтому важно знать кто за что отвечает как в рамках команды IT, так и за ее пределами. Отмечу основных участников процесса:

  • Заказчики – формируют требования к продукту, верхнеуровнево описывают задачу на языке бизнес целей и выгоды
  • Архитекторы – разрабатывают архитектурное решение продукта, схему интеграций с другими системами
  • Аналитики – бизнес аналитики и системные аналитики. Бизнес аналитики отвечают за проработку бизнес задач и формирование основных функциональных и нефункциональных (если они критичны для заказчика) требований к ПО. Системные аналитики детализируют и переводят в техническую плоскость (на уровень таблиц, функций, классов, интерфейсов и т.п.) бизнес требования, формируют техническое задание для команды разработки
  • Разработчики – разрабатывают и документируют код ПО, занимаются отладкой и исправлением ошибок, проверяют код при помощи Unit-тестирования, собирают билды и поставки, готовят инструкции по установке
  • Тестировщики (QA специалисты) – отвечают за качество ПО, выполняя для этого анализ требований, разработку планов и сценариев тестирования, выполняя тестирование ПО и т.д.
  • Команда поддержки – занимаются выводом ПО в эксплуатацию, установками и настройкой среды для пользователей
  • Пользователи – являются конечными потребителями ПО, в рамках процесса разработки могут привлекаться к приемочному тестированию

3. Следующий вопрос, с кем из перечисленных выше ролей и как взаимодействует группа тестирования. Правильный ответ – со всеми. В идеале QA специалист включается в работу на всех этапах, взаимодействуя со всеми участниками процесса разработки ПО:

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

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

  • Модели разработки ПО, это виды процесса разработки, порядок выполнения работ. Есть три основных модели:
    • Каскадная – модель водопада, все этапы разработки ПО выполняются последовательно от планирования до внедрения и сопровождения, выстраиваясь в одну длинную цепочку
    • Итеративная – весь процесс разбивается на множество коротких циклов разработки – итераций. Цель каждой итерации – создание фрагмента или версии ПО. Разработка ведется с непрерывным анализом результатов каждой итерации и корректировкой последующих.
    • Спиральная – вариант итеративной модели, при котором в разработке выделяются уровни развития ПО – витки спирали, для получения контрольных точек и оценки рисков проекта
  • Методологии разработки ПО, это подходы и практики, которые применяются для разработки. Существует множество методологий знать их все невозможно и это не нужно для прохождения собеседования. Но лучше всего иметь представление хотя бы о некоторых из них, например: Agile, RUP, MSF, TDD.

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

Профессия — тестировщик ПО

Профессия — тестировщик ПО

Профессия — тестировщик ПО

Есть такая профессия — качество защищать!

Артем Ваулин, инженер по тестированию, ведущий тестировщик, руководитель группы тестирования компании «КОРУС Консалтинг»

В НАСТОЯЩЕЕ время в России быстрыми темпами набирает популярность такая специальность в сфере ИТ, как тестировщик программного обеспечения (ПО). Еще несколько лет назад о данной специальности, профессии и даже науке в нашей стране знали лишь немногие. Даже если тестированием и занимались, то точно не выделяли его в отдельную дисциплину или специализированный вид деятельности. Сегодня же тестирование становится равноправным спутником программирования и разработки: количество профессиональных тестировщи-ков постоянно растет, спрос на тестировщиков пре-восходит предложение, все крупнейшие ИТ-компании «охотятся» за «поборниками качетва», существует множество специализированных тренингов, курсов повышения квалификации, несколько крупнейших вузов страны включили в свои программы обучения курс по тестированию ПО.

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

«Универсальные» требования, которым должен удовлетворять каждый тестировщик (перечень позиций требуемой и желаемой квалификаций могут варьироваться в зависимости от того, ищет ли компания молодого специалиста или опытного тестировщика), представлены в таблице.

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

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

Карьера с тестированием

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

Несколько важных знаний и навыков кратко описаны ниже.

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

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

Представление технической информации. Способность объективно презентовать информацию. Навыки в написании статей на соответствующие темы. Умение ясно и доступно излагать свои мысли.

Управление временем. Умение в единицу времени делать значительно больше, чем другие.

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

  • знание методологии и методик тестирования;
  • знание типов и видов тестирования, различных их классификаций;
  • технические знания приложений, с которыми приходится работать (Веб-приложения, банковское ПО и т.п.);
  • знание стандартов и методологий, применяемых к приложениям, с которыми приходится работать;
  • умение создавать тестовую документацию;
  • знание стандартов в области тестирования;
  • умение разрабатывать системную документацию, системную архитектуру;
  • начальные навыки разработки ПО;
  • понимание жизненного цикла разработки ПО, различных методологий его разработки и места тестирования в данном процессе;
  • знание автоматизированных средств разработки и тестирования;
  • знание основ баз данных и SQL.

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

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

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

Перспективы роста и дальнейшего развития тестировщиков

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

  1. Профессиональный путь развития: младший тестировщик — старший тестировщик — ведущий тестировщик — эксперт.
  2. Административный путь развития: ведущий тестировщик — руководитель.

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

Но рано или поздно каждый тестировщик (да и любой человек, в принципе) задумывается над тем, что он полностью исчерпал себя на этом поприще, «выжал» все из текущей деятельности, достиг максимальных высот профессионализма. Что же делать тестировщику, когда он попал на профессиональное «распутье»?

Тестирование находится на стыке различных прикладных ИТ-дисциплин, и по роду своей деятельности тестировщику постоянно приходится в них «окунаться». Таким образом, тестировщик с минимальными трудозатратами может перейти в одну из следующих областей:

  • консалтинг в сфере тестирования (постановка/аудит процессов тестирования, обучение специалистов вопросам, связанным с тестированием, и т.п.);
  • управление качеством (внедрение/аудит систем менеджмента качества);
  • бизнес-анализ (выявление, описание существующих бизнес-процессов, проектирование новых, разработка требований);
  • ИТ-консалтинг (постановка и автоматизация бизнес-процессов);
  • разработка ПО (программирование);
  • управление проектами по созданию или внедрению информационных систем.

И это далеко не полный перечень направлений, по которым может развиваться высококлассный тестировщик.

Форум тестировщиков

Что нужно знать от джуна до лида?

Dananas 28 авг 2015

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

В общем, сразу в прорубь:

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

Или говоря другими словами, вот будешь знать от сель до сель, можешь считаться джуном, а если будешь знать от сель до сель, то лидом.

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

Например, выделю 3 уровня:

Что бы быть полноценным джуном нужно знать что?

1. Терминалогию тестирования (опять какая же?)

2. Виды тестирования

3. Нафиг оно вообще все это нужно (а нужно ли реально это джуну знать или это уровень лида уже?)

4. Для чего нужны сценарии.

5. Как заводить ошибки (общая культура).

user12 28 авг 2015

Можно посмотреть, тут

Но вообще очень многое зависит от вашего проета

Molechka 28 авг 2015

В нашей компании junior = middle/senior какой-то другой.

Это слишком условное разделение.

Нельзя выделить среднюю температуру по больнице, но можно ориентироваться на навыки с http://testbase.ru/, согласна с Виктором

Первые 2 колонки — надо иметь представление и делать «хоть кое-как». То есть что-то в голове должно быть. Для начинающего.

Смотрите так же:  Волго-вятский округ арбитражный суд

На работу джиниуров берут и только за горящие глаза, внимательность, умение гуглить — тут хватит первой колонки, «с чего начать».

Но на работе придется вникать в навыки из «как прокачаться».

Соответственно, middle — тот, кто хорошо владеет навыками средней колонки.

А сеньор — это уже из области третьей колонки, «во что углубится», который досконально знает какую-то одну область.

Как делить внутри своей компании, своей команды — решайте сами.

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

Там как раз разделение, что-то типа:

Джуниор — умеет проходить по чужим.

Миддл — умеет проходить по чужим, включая мозг, исправлять, дополнять их.

Сеньорн — сам составляет.

А так все качества в виде таблички.

Хотите такую же? Сядьте, подумайте, какие навыки в компании вашей нужны, выпишите их. А потом распишите по уровням, что вы считаете нужным вначале, на нормально и крутом левеле

Dananas 28 авг 2015

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

Допустим наш джун вкурился во все это. И условно может считать себя мидлом. А дальше каков вектр будет? =)

На мой взгляд нужно:

1. Знать как разворачивать тестовые стенды и уметь их администрировать.

2. Уметь планировать.

3. Уметь грамотно коммуницировать с любым участником всей цепочки разработки.

4. Понимать чем отличается мягкое от пушистого, например, приорити и севирити.

4,5. Купаться в различных видах тестирования.

5. Знать что такое пост и гет и 5 типов ответов.

6. Уметь приоритезировать.

7. Быть самостоятельной единицей в ТМС.

Что еще может быть?

П.С. Вот представьте себя в первом классе. По математике проходите сложение и вычитание. И ведь никто не дает вам в младших классах разбор интегралов и пр. Потому что сначало нужно усвоить азы.

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

aid 28 авг 2015

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

lurk 28 авг 2015

3. Прочитайте главу 8 Ключевые процессов тестирования

[ссылка сейчас не работает — ищете в кеше гугла данную статью]

Дисклеймер, что должен уметь джун — если он хочет хорошо зарабатывать:

1-3 Подвешенный язык

1-4 Знание английского языка

1-3 Автоматизация тестирования

3-4 Уметь тестировать

Причем уметь тестировать, если он хочет хорошо зарабатывать — имеет самый низкий приоритет. Ниже может быть только знание английского (если фирма ориентировано на русскоязычный рынок). Везение вынесу за пределы умений =)

SHINNOK 28 авг 2015

Dananas 31 авг 2015

Значит нарисуется два вектора развития: техническая и управленческая =)
LURK, спасибо за ссылки, увлекся чтением =)

lurk 31 авг 2015

Перед тем, как погрузиться в обучения нового сотрудника: Продумайте, что Вам от него нужно — какая цель его обучения? Что он должен уметь, чтобы наносить наибольшую пользу фирме при справедливых (но умещающихся в бюджет) затратах на него? Чему его выгоднее обучать? Кто будет его обучать? Может эффективнее и дешевле послать его на курсы?

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

Если решите квест и копнете глубже — узнаете много полезного.

Dananas 03 сен 2015

Как таковой, у меня нет задачи обучить какого-то конкретного человека под какой-то конкретный проект. Я просто хочу обобщить нормально знания по навыкам и умениям. Почти все прочитал, что написал, сегодня попробую начать объединять 😉

Dananas 03 сен 2015

Начал шаманить и сразу ступор: какая бывает документация в тестировании?

Если верить этой статье (http://habrahabr.ru/post/254209/), то документация бывает внешней и внутренней. И с этим вроде понятно. Но не понятно куда тогда относить такие документы как Стратегия тестирования, различные регламенты (работы отдела, работы с ошибками, написания сценариев и пр), различные учебные материалы?

Может ли кто покидаться умными вещами в меня относительно видов документации? Способов их деления и т.д.?

Tishka 03 сен 2015

1. Стратегию тестирования описываю в тест-плане.

2. Работа отдела, Работы с ошибками, Написания сценариев и пр — это больше относится к внутренней документации отдела.

P.S. Это личные выводы.

lurk 03 сен 2015

Начал шаманить и сразу ступор: какая бывает документация в тестировании?

Если верить этой статье (http://habrahabr.ru/post/254209/), то документация бывает внешней и внутренней. И с этим вроде понятно. Но не понятно куда тогда относить такие документы как Стратегия тестирования, различные регламенты (работы отдела, работы с ошибками, написания сценариев и пр), различные учебные материалы?

Может ли кто покидаться умными вещами в меня относительно видов документации? Способов их деления и т.д.?

Вариант 1. Гугл или Яндекс на ваш выбор.

Вариант 2. Устроится на работу/обучение к опытному наставнику и узнать у него.

Вариант 3. Разобраться самому — сделать выводы — и выводы уже уточнить в этой теме.

Vasiliy 03 сен 2015

Вы смешиваете понятия, имхо. Или виды..

Стратегия тестирования описывает что и как делаем в этом проекте. Пишет ее тест-менеджер, имхо. И это артефакт тестирования.

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

Учебные материалы я бы отнес к отделу, если они общие или к проекту, если они описывают специфику данного проекта.

Dananas 04 сен 2015

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

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

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

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

lurk 05 сен 2015

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

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

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

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

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

Если человеку сказать, что пока он делает А (свою работу) — он получает X денег, а если он хочет получать 2Х — то ему нужно будет делать Б. То часто он будет стараться учить-делать Б, забивая на А.

lurk 05 сен 2015

А вы этой статье верите?

После того как автор написал, что

Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным. И это единственный правильный ответ.

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям. Всё. Не больше и не меньше.

я отрицаю существование негативных проверок, поскольку:

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

Dananas 07 сен 2015

Не особо кнешно верю =)
Но вектр в свое время для размышления автор задал мне.

Author: admin