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

Подписаться

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

Конференции

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

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

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

.
Тест-менеджмент
Анатомия ошибки
29.11.2012 12:36

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

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

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

Подробнее...
 
Почему тестирование занимает так много времени
02.10.2012 14:01

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

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

Подробнее...
 
Проблемы тестирования это результаты тестирования
24.10.2011 10:06

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

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

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

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

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

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

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

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

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

 

Подробнее...
 
Опыт создания системы управления сборкой и тестированием
02.08.2011 11:04

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

Подробнее...
 
Проблемы тестирования в аутсорсинге
30.06.2011 12:28

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

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

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

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

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

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

Подробнее...
 
Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD
20.04.2011 11:50

Выступление Алексея Баранцева на 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 приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

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

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

 
Критическое мышление и очеловечивание стратегии тестирования
04.04.2011 15:13

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Mission Critical: Visualize, Personalize, Humanize

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

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

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

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

Мне не раз приходилось сталкиваться с этим в реальных проектах, и меня беспокоило то, что мы рассматривали «пользователей» всех скопом, не вдаваясь в детали и не проводя различий.

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

Подробнее...
 
Отказ от плана не значит отказ от цели
20.12.2010 15:49

Автор текста: Баранцев Алексей

В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: "тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом" (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).

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

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

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

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

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

Не теряйте из виду своих целей!

 
Расшифровка доклада Алексея Баранцева "Как понять, действительно ли ваша работа для кого-то важна и нужна"
06.11.2010 15:59

На первой встрече Московского клуба тестировщиков Алексей Баранцев выступил с докладом на тему "Как понять, действительно ли ваша работа для кого-то важна и нужна".

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

А сегодня Алексей Лупан опубликовал в своем блоге расшифровку данного доклада, за что ему огромное спасибо.

 
Рефакторинг фирмы, специализирующейся на тестировании
06.10.2010 17:51

Автор: Илья Комендантов

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

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

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?

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



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