Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Тест-менеджмент
Как посчитать время на тестирование
18.12.2015 10:54

Оригинальная публикация

Автор: Евгений Ефимов, QA Manager, DataArt

Посмотреть запись выступления Евгения на эту тему

…Или, другими словами, как посчитать время на тестирование так, чтобы все поверили? Ведь на самом деле у нас обычно — две цели. Первая — посчитать время так, чтобы не ошибиться и правильно распределить ресурсы — скорее всего, поначалу сделать это хорошо все равно не получится. Вторая цель более реальна: посчитать время на тестирование так, чтобы доказать кому-то, что вам нужны еще люди в команде, объяснить, почему вы не успеваете и т. д. Как ни странно, после того, как раз 50 сделаете второе, то и первое будет получаться!

Давайте теперь посмотрим, как считать время на тестирование, на конкретных примерах.

Подробнее...
 
QA Fest: тест-менеджмент
14.12.2015 11:07

Мы публикуем подборку докладов с QA Fest – 2015, посвященных организации процессов тестирования в команде.

Мотивация в IT: теория и правда – доклад Сергея Новика

Первые шаги самоорганизованной команды: доклад Богдана Мисюры

Как успешные зарубежные команды нанимают лучших из лучших: доклад Станислава Трубина

Секреты успешного проекта глазами тест-менеджера: доклад АленыЧерненко-Дыба и Алексея Лупана

Организация тестирования встроенных систем "с нуля": доклад Владимира Скляра

QA dream team: как создать и вырастить свою команду – доклад Дмитрия Горина

 

 
Как посчитать время на тестирование так, чтобы все поверили
04.12.2015 13:59

Выступление Евгения Ефимова на онлайн-конференции для тестировщиков Fun ConfeT&QA

«А сколько времени тебе надо что бы протестировать билд?» и «А почему так много?» одни из наиболее часто задаваемых вопросов QA-инженерам независимо от проектов и места работы.

Я расскажу, как ответить на эти вопросы себе и другим и быть уверенным в своем ответе.

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

Статья Евгения Ефимова на эту тему

Обсудить в форуме

 
Оценка тестового покрытия на проекте
09.11.2015 11:07

Автор: Наталья Руколь

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.
Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.

Зачем оценивать?

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

  1. Поиск своих слабых зон. Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
  2. Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу, а ответы на них даёт оценка покрытия.
  3. Фокус внимания. Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.
Подробнее...
 
Грабли тестировщика
03.07.2015 13:36

Доклад одного из наших тренеров Натальи Руколь (автор и ведущий тренингов Школа тест-менеджеров и Школа тест-аналитиков) на конференции SQA Days 17.

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

На конференциях принято рассказывать: мы сделали такую крутую штуку! Мы внедрили опупенный инструмент! Посмотрите, как мы справились с этими техниками… Такие рассказы слушать приятно, и есть, чему поучиться. Но наши рабочие дни обычно состоят не из геройских подвигов! Мы сталкиваемся с проблемами и трудностями:

  • пропустили критичный дефект
  • не успели провести тестирование вовремя
  • автотесты не окупаются и требуют слишком много времени
  • нет сил актуализировать тесты и планы

Что делать при возникновении таких проблем? Я знаю отличное решение:

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

На этом докладе вас ждут:

  • мои самые позорные грабли в карьере тестировщика
  • извлечённый опыт и найденные решения
  • самоуспокоительные мантры тестировщиков.
Подробнее...
 
Мир без тестировщиков. Миф или реальность?
28.05.2015 12:07

Обсуждение, организованной Татьяной Писчасовой, о Мире без тестировщиков на конференции CodeFest 2015.

В черном-черном городе.. на черной-черной горе.. в черном-черном офисе.. черные-черные разработчики.. писали черные-черные программы...
И САМИ ИХ ТЕСТИРОВАЛИ!!!!

Каждый тестировщик будучи junior-ом слышал такую страшилку от старших товарищей.

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

Приглашаю коллег обсудить этот тренд. Чем грозит (и грозит ли) тестирование продукта без выделенного специалиста.
В чем плюсы, в чем минусы такого подхода.
На каких проектах он применим, на каких - нет.
Как обеспечить качество продукта без специалистов по качеству.

И как жить тестировщикам, которых "оставили без работы".

Подробнее...
 
ЗАЧЕМ МЫ ТЕСТИРУЕМ?
25.05.2015 15:24

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

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

В результате нас ждут проблемы с договорённостями, в команде царит недопонимание. Зато, мы соответствуем своему абстрактному "хорошо" и "правильно"!

Для просветлённых тест-менеджеров, готовых отказаться от таких абстрактных правил, предлагаем вниманию 1-й вводный вебинар нового онлайн-тренинга Натальи Руколь Школа Тест-Менеджеров v 2.0.

На нём мы рассмотрим:

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

Вебинар будет полезен тест-менеджерам и тестировщикам-оркестрам, самостоятельно определяющим "как будет проводиться тестирование на проекте".

 
Технический долг: взгляд и действия со стороны QA / QC&AT
25.05.2015 10:27

Доклад Дмитрия Химиона, Performance Lab на конференции CodeFest 2015.

Вы — участник проекта, где релиз дополняется 20-ю патчами?
Вы — QA-менеджер и чувствуете, что разработчики «лукавят», говоря что «у них всё работает»?
Вы — тестировщик и думаете, куда бы развиваться и как еще можно повлиять на качество проекта?
Тогда этот доклад будет вам интересен и, возможно, полезен в работе. Я расскажу о работе с проблемой технического долга со стороны команды тестирования, что qa-team может в этой области, и как оно может выглядеть. Рассмотрим связь между ISO, зрелостью процессов, командой тестирования и проявлением технического долга.

Подробнее...
 
Экономически эффективный процесс тестирования
18.05.2015 11:17

Доклад Андрея Солнцева, разработчика в таллинской компании Codeborne, на конференции CodeFest 2015.

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

А мы разрабатываем интернет-банк всего лишь вчетвером. Вместе с автотестами. Никаких аналитиков. Никаких тестировщиков. Никаких тест-менеджеров. И тесты наши пробегают всего лишь за 5 минут. Как нам это удаётся?

Смотрите запись доклада

Подробнее...
 
Развитие управления проектами и критериев качества в ИТ
10.04.2015 14:12

Выступление Максима Цепкова на AgileDays-2015.

Страница данного доклада с кратким текстовым содержанием и презентацией

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

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

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.

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

Подробнее...
 



Страница 3 из 10