Home

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

На конференции Chief ConfeT&QA первое место поделили Анастасия Мусина с докладом “Тестировщики не винтики!” или “Не закручивайте гайки!” и Андрей Мясников с докладом “Что нам стоит дом построить”.

Доклад Анастасии мы уже опубликовали. А сегодня представляем доклад второго победителя Андрея Мясникова “Что нам стоит дом построить”.

Директор: «Ну вот, мы решили расширяться. Теперь ты не тестировщик-одиночка. Теперь ты руководишь отделом! Набирай людей и делай нам хорошее тестирование: не хуже, чем в «Пупкин Inc.»

Тебе дают полномочия, права и ресурсы. Но что с ними делать?

До этого ты тестировал один и писал баги в гугл-док, который показывал программистам. Но с командой так работать не получится! Что делать в такой ситуации? Как не ошибиться?

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

В конечном счёте, всё в ваших руках. Но я помогу вам выжить первое время.

Представляем доклад Сергей Нужненко, который он делал на Летнем Аналитическом Фестивале в 2012 году. По отзывам посетителей это один из лучших докладов ЛАФ-2012.

В этом году на ЛАФ-2013 Сергей прочтет доклад с интригующей темой: “Внедрение системы управления требованиями: (анти?)утопия”.

Программа первого дня фестиваля сформирована: http://conf.uml2.ru/program2013/

А до самого фестиваля осталось совсем немного.

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

Сегодня мы опубликуем в открытом доступе доклад Анастасии Мусиной “Тестировщики не винтики!” или “Не закручивайте гайки!”, который разделил первое место с докладом Андрея Мясникова “Что нам стоит дом построить” на прошедшей онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.

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

1. Тебя (тимлида) разрывают на части менеджеры разных групп разработки, и не все остаются довольны уделенным им вниманием;

2. Тестировщики недовольны распределением задач, а если выбирают их сами — не успевают все в срок;

3. Тестировщики достаточно хорошо знают все продукты, чтобы подхватить тестирование соседней задачи, но на каверзные вопросы «вглубь» ответить не могут;

4. «Море работы, горы работы», и никакого просвета;

5. Вася собрался на футбол, а Маша на свидание? Да бросьте! у нас сегодня релиз, так что на ужин пицца и ночуем на работе!

Знакомо?

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

Автор: Наталья Руколь, ведущая Школы Тест-Менеджеров, очередной запуск которой начнется 20 мая.

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

Как это произошло? Как избежать подобных ситуаций в будущем? Как реабилитировать своё доброе имя перед коллегами?

Я уже рассказывала о пропуске ошибок глазами тестировщика. А в этой статье давайте разберёмся с позиции тест-менеджера: какие возможные проблемы приводят к пропускам, и каковы способы их решения.

Причины пропуска проблем

Представьте себе, что у вас что-то болит, и вы записываетесь к доктору. На приеме он даже не пытается выслушать симптомы, а сразу назначает лекарство. Что вы сделаете? Скорее всего, сбежите от него. И правильно сделаете! Лечение невозможно без диагностики, и, только точно зная источник проблемы, её можно решить.

В тестировании и разработке ПО всё то же самое. Хотите что-то улучшить? Значит, вы хотите вылечить проблему. Найдите её!

Давайте посмотрим на стандартные причины пропуска ошибок, и для удобства восприятия поделим их на 2 категории: проблемы в процессе и человеческий фактор.

Сергей Высоцкий, cпециалист по тестированию высоконагруженных сервисов 2ГИС

Представляем вашему вниманию запись выступления, которое состоялось в рамках DevDay , организованном компанией 2ГИС в Новосибирске.

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

По старой традиции мы публикуем лучший доклад онлайн-конференции Chief ConfeT&QA. По результатам голосования участников конференции, лучшим признан доклад Николая Алименкова "Почему тестирование занимает так много времени".

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

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Testing Problems Are Test Results
Перевод: Сергей Высоцкий и RA

Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:

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

В добавок к этому:

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

Ах да, вот еще:

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

Как мы можем принять во внимание все эти наблюдения?

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

С разрешения Санкт-Петербургского сообщества тестировщиков мы публикуем слайдкаст с выступления Олега Ладыгина «Опыт создания системы управления сборкой и тестированием».

Автор: Сергей Бережной

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

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

«Человек не будет переживать за качество всего проекта. Он не встанет и не скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко».

С моей стороны показалось странным, почему он (опытный руководитель проектов) обращает внимание именно на это, а не на профессиональные знания и опыт. Неужели читал Спольского про «smart and get things done»? Такая тема не могла быть не обсуждена дополнительно! И мы решили обсудить, какие же проблемы кроме этой Заказчик видит в нашем тестировании.

Получился вот такой список главных разочарований в тестировании со стороны Заказчика:

Выступление Алексея Баранцева на AgileDays-2011

Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.

Однако здесь есть два больших подводных камня.

Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

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

Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

Видеозапись доклада можно посмотреть здесь.

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