Home

Автор: Карен Н. Джонсон (Karen N. Johnson)

Перевод: Дмитрий Дудников по заказу Software-Testing.RU

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

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

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

И, кстати, раскрою небольшой секрет, не дожидаясь официальной публикации -- во второй день конференции SQA Days 7, которая пройдёт в Харькове 14-15 мая, Саша будет проводить мастер-класс "Конструктивное решение проблем и конфликтов", акцентируя внимание именно на конфликтах между тестировщиками и другими участниками проектов разработки, так что этот кейс можно считать небольшой подготовкой к мастер-классу.

Кейс “Опять двадцать пять”

Максим (руководитель проекта) и Алексей (руководитель группы тестирования) работают в небольшой продуктовой компании.
Однажды вечером между ними состоялся такой диалог.

М: Привет! Слушай, похоже тебе и твоим ребятам придется поработать в субботу. Извини, что сообщаю об этом всего лишь за два дня.
А: Опять? Надо же…
М: Да. Разработчики буквально пару минут назад сообщили мне, что завтра к обеду будет готов билд, в котором будут исправлены все пять оставшихся критичных багов, восемь второго приоритета и еще куча мелких. Всего 27 штук! И это они за 4 дня успели сделать, такого у нас уже давно не было. Они действительно классно поработали. Давай и вы тоже продолжите в том же духе.
А: Мда… они молодцы, конечно. Они сами что-нибудь потестили? Билд хотя бы собирается нормально?
М: Конечно собирается, даром что ли неделю на настройку билдера убили. И юнит-тесты прошли все, хоть их и немного.
А: … да еще и старых.
М: Ну да, старых, но это же все время, ты же в курсе. Каждый из них, конечно же, проверил все пофикшенные баги у себя локально, куда ж без этого. И все было нормально. Но чтоб узнать, как оно все вместе работает, вы нам и нужны. Так ведь? У них на это просто никогда не будет времени, да и не их это задача. Вы же должны обеспечить качество продукта.
А: Хорошо, я могу протестировать продукт, но как обеспечить его качество и качество их чудо-кода… я не знаю.
М: Конечно знаешь. По крайней мере, лучше тебя этого никто тут не знает. Ты же эксперт в таких вещах.

Продолжение кейса и обсуждение в блоге Happy-PM

Портал Software-Testing.ru представляет серию интервью с участниками прошедшего мероприятия.

Приглашаем всех на SQA Days 7 в Харькове, 14-15 мая 2010.

Александр Александров: "Надо считать собственные недоработки, а не свои успехи"

Александр Александров (Luxoft, Москва), эксперт по управлению качеством программного обеспечения, управлению тестированием, анализу и совершенствованию инженерных процессов, кандидат физико-математических наук, доцент, старший научный сотрудник, внедренец практик CMM/CMMI.

Дедушка русского тестирования (пруфлинк).

Чем и как «дышит» нынешний тестировщик? Возьмем, для примера, Москву. Вот Алексей Баранцев говорит, что ощущаются какие-то изменения, но какие конкретно — еще никто не знает.

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

Не думаю, что в Москве происходит что-то такое, чего не происходит в других местах. Например, есть общие тенденции, связанные с интересом и популярностью гибких методологий. Докладов про тестирование в Agile я слушал уже штук семь, причем география докладчиков абсолютно разная. И после каждого такого доклада я снова убеждался в том, что никакой специфики тестирования в Agile нет. Я разговаривал с коллегами, работающих в разных местах, с разными программистами из Минска, Питера, Киева — абсолютно разные места, не так ли? — а точка зрения по этому вопросу одна и та же.

Впрочем... Есть резкий рост количества инструментов автоматизированного тестирования. Их становится много. Десять лет назад их было всего два — от Rational и от Mercury, а сейчас у нас в УЦ Luxoft только учебных курсов по этим инструментам штук десять; а есть еще большое количество инструментов, которые нашими курсами не охвачены.

В трансляцию блогов добавлен блог Натальи Руколь -- http://nrukol.blogspot.com   

Автор блога о себе: Много чего, где и как тестировала. Люблю развиваться сама и помогать развиваться окружающим людям.

И о блоге: Мой блог – это двусторонний интерфейс взаимодействия с QC-сообществом. В планах блога:

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

На сайте Харьковского клуба тестировщиков опубликованы видеозаписи зимних встреч клуба:

• 29/11/2009: Тимур Хайруллин - Нагрузочное тестирование
• 29/01/2010: Александр Орлов - Из тестировщиков в менеджеры
• 19/02/2010: Сергей Поволяшко - Трудозатраты и планирование тестирования

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

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

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

Оригинальная публикация: Dawn Haynes http://www.sqetraining.com/file/DawnHaynesArticle.pdf

Перевод: Лаборатория Качества.

Как сделать тестирование эффективнее и полезнее, почти не меняя действующую стратегию? За 10 лет я составила 10 эвристических правил «увеличения отдачи» от тестов с помощью разумных изменений в условиях, последовательности, данных или перспективе тестов во время их выполнения.

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

Две недели тому назад прошёл тренинг Rapid Software Testing, свежие впечатления улеглись, появилась некоторая отстранённость, и теперь я готов написать о том, как это выглядело с моей точки зрения, а также поделюсь отзывами других участников.

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

А вот я являюсь поклонником Майкла Болтона с тех самых пор, как познакомился с идеями контекстно-ориентированного тестирования и проникся к ним симпатией. Причина этого в том, что Джеймс является своего рода духовным лидером этого движения, символом, а Майкл выполняет роль проводника и толкователя идей школы. Джеймс в последнее время почти ничего не пишет, изредка появляющиеся в его блоге заметки либо носят полемический характер, либо являются рассказами «за жизнь». По слухам он трудится над новой книгой, и это, возможно, отнимает значительную часть писательского потенциала. Но нам, читателям, хотелось бы чего-нибудь прямо сейчас. И эту нишу заполняет Майкл – он много и интересно пишет в блог, ведёт (точнее, вёл до недавнего времени) колонку в журнале Better Magazine, активно участвует в обсуждениях SoftwareTestingClub и в различных блогах, выступая в роли евангелиста и апологета школы контекстно-ориентированного тестирования. И поэтому я, как человек, очень любящий читать, все эти идеи воспринимаю именно в интерпретации Майкла.