Home

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

Очередной слайдкаст доклада с питерской конференции SQADays-5: выступление Андрея Дмитриева на тему "Опыт налаживания работы новой SQA команды". Нередко у нас на форуме появляются вопросы типа "передо мной поставлена задача создать отдел тестирования, с чего начать?" Обычно этот вопрос задают люди, работающие в относительно небольших компаниях, но которые уже "дозрели" до организации службы тестирования. Всем, кто находится в такой ситуации (а кому-то может быть это ещё предстоит в будущем), посвящается этот доклад.

Слайд-каст выступления Асхата Уразбаева с докладом "Руководство по организации тестирования в Agile" на конференции SQADays-5 в Санкт-Петербурге. В своём докладе Асхат рассматривает типичные заблуждения, а также предлагает конструктивные практики организации тестирования в Agile-окружении.

Начинаем публикацию слайд-кастов докладов с прошедшей весной этого года в Санкт-Петербурге конференции SQADays-5.

И первым мы публикуем слайд-каст выступления Александра Александрова "Количественное управление процессом тестирования". В этом докладе описаны современные подходы к количественному и статистическому контролю процесса тестирования, которые позволяют устанавливать количественные цели по качеству, анализировать процессы и своевременно разрабатывать и предпринять корректирующие и/или предупреждающие действия. На основе изучения метрик по тестированию и их корреляции, предложен метод прогнозирования качества программной системы, переданной Заказчику (а именно, прогнозирования количества дефектов, которые обнаружит Заказчик в поставленной ему программной системе).

Автор: Юлия Нечаева

Ревьюер: Вячеслав Панкратов

Стандартный жизненный цикл программного обеспечения делится на этапы:

1. возникновение и исследование идеи;
2. анализ требований и проектирование;
3. программирование;
4. тестирование и отладка;
5. ввод программы в действие;
6. эксплуатация и сопровождение;
7. завершение эксплуатации.

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

Идея –> требования –> разработка –> тестирование –> релиз.

Итак, требования первичны, до того, как пустить продукт в разработку, разработчики должны четко представлять себе, ЧТО они должны разработать.

Перевод: консультант проекта Ольга Захаренко (Агладзе)

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

Авторский коллектив: Артём Торосян (HR manager VDI), Евгений Грачёв (Project Manager VDI)

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

Автор: Игорь Ашманов: управляющий партнер и генеральный директор компании «Ашманов и Партнеры»

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

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

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

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

Автор: Игорь Ашманов: управляющий партнер и генеральный директор компании «Ашманов и Партнеры»

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

Автор: Игорь Ашманов: управляющий партнер и генеральный директор компании «Ашманов и Партнеры»

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

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