Автор: Карен Н. Джонсон (Karen N. Johnson)
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинальная публикация
Регрессионное тестирование порой может быть весьма трудоёмкой задачей. Регрессионное тестирование – это тестирование, предназначенное для повторной проверки свойств приложения или продукта с целью убедиться в том, что после внесения изменений или добавления новых возможностей приложение по-прежнему работает. Уже из определения видно, что регрессионное тестирование может быть очень обширным, поскольку может потребоваться повторная проверка практически каждого свойства продукта. Как правило, регрессионные тесты – это тесты, разработанные ранее, следовательно, основная работа при регрессионном тестировании заключается не столько в создании тестов, сколько в их выполнении. Таким образом, самая первая проблема – это планирование того, что мы будем перепроверять. Итак, как же выбрать, что подвергнуть регрессионному тестированию?
В преддверии конференции SQA Days 10, которая будет проходить 2-3 декабря в Москве, мы решили (с разрешения докладчиков) опубликовать статьи-анонсы некоторых выступлений. Открывает эту серию публикаций статья Максима Цепкова, технического директора и главного архитектора компании CUSTIS, в которой вновь обсуждается больная для тестировщиков тема совмещения ролей тестировщика и аналитика. Во благо это или во зло?
Agile-методологии появились и развивались в ответ на проблемы традиционных методологий. Чтобы снижать риски, связанные с постановками, в них предусмотрено два механизма. Во-первых, быстрая обратная связь через демонстрации и общение с заказчиком. Во-вторых, стремление к кросс-функциональности внутри команды. Однако в реальности полная кросс-функциональность достигается редко из-за широкого спектра разнородных деятельностей, входящих в процесс создания ПО.
Поэтому на практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей, что изображено на Рис.4. Аналитика-тестировщика традиционно называют аналитиком, хотя столь же успешно его можно было бы назвать и тестировщиком. Более того, если существенная часть аналитической работы находится на стороне заказчика, то последнее точнее отражает его функции.
На первой встрече Московского клуба тестировщиков Алексей Баранцев выступил с докладом на тему «Как понять, действительно ли ваша работа для кого-то важна и нужна».
Ниже слайдкаст этого выступления (из которого, правда, по техническим причинам пришлось вырезать большую часть обсуждений -- они были слишком бурные и диктофон, увы, записал их совершенно неразборчиво).
17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.
Наш сайт уже публиковал переводы заметок Майкла, а к приезду Майкла мы решили сделать целую серию переводов.
Оригинал: Testers: Get Out of the Quality Assurance Business
Переводчик: Михаил Павлов
Недавно Кори Фой (Cory Foy) опубликовал в своем твиттере такой призыв: «Наличие отдела обеспечения качества – признак некомпетентности в отделе разработки. Обсудим?»
Вот что я думаю по этому поводу. Я тестировщик, и настало время расти и развиваться нашему ремеслу. Какой бы ни была организационная структура компании, нам, тестировщикам, пора прекратить заниматься обеспечением качества.
Осенью 2008 года на конференции AYE я помогал Фионе Чарльз (Fiona Charles) и Джерри Вайнбергу (Jerry Weinberg) проводить сессию под названием «Тестирование лжет». Джерри сидел у входа в аудиторию и, пока участники заходили и занимали места, я прислушался к тому, что он говорит людям, сидевшим рядом с ним.
- Вы занимаетесь обеспечением качества? - спросил он.
- Да, последовал ответ.
- Значит, вам позволено изменять исходный код программ, которые вы тестирует
- Нет, конечно, нет.
- Очень интересно. А как же тогда вы можете «обеспечить» качество?
Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире. Когда мне было лет двадцать с небольшим, я решил, что если я хочу быть всесторонне образованным молодым человеком (и привлекательным для девушек), неплохо было бы научиться вкусно готовить. Как и большинство молодых людей, я не собирался тратить много времени и усилий на кухне, но при этом хотел производить впечатление. Кроме того, я хотел уметь готовить как из скромного набора продуктов своего холостяцкого холодильника, так и находясь на неисследованной территории чужой кухни. Один из моих стандартных приемов изучения нового – прийти в книжный магазин и порыться в книгах. Так я и сделал, и после недолгих поисков наткнулся на книгу «Гурман за 60 минут» Пьера Фрейни. «Отлично!», — подумал я.
Подробнее...
Автор: Алексей Лянгузов (budabum@gmail.com)
Слайдкаст: http://www.slideshare.net/LeshaL/ss-4686660
Какое-то время назад, несколько наших проектов вышли в мир ПО с открытым исходным кодом. За эти годы было выпущено и протестировано несколько версий и накоплен вполне солидный опыт.
Данная статья рассказывает о том, какие особенности встречаются при тестировании программ с открытым исходным кодом. Что нужно для этого знать и уметь. К чему надо готовиться, чего ожидать, а чего опасаться и избегать. Ещё статья затрагивает тему того, как минимизировать затраты на тестирование.
Готовя статью, я практически не нашёл материалов по тестирование программ с открытым кодом в интернете. В частности, не нашёл ничего про то, что же отличает тестирование открытых программ от обычных.
Возможно считается, что тут нет никакой разницы? Или люди думают, что проекты с открытым кодом не нуждаются в тестировании, в традиционном его понимании?
Прочитайте статью, если вы так думаете или если вы собираетесь тестировать ПО с открытым кодом, и вероятно какие-то вопросы перестанут быть для вас вопросами.
Один из самых увлекательных докладов на прошедшей конференции SQA Days 7 -- рассказ Юли Нечаевой о тестировании игр. Чем занимаются тестировщики в компаниях, производящих компьютерные игры? Действительно ли они играют на работе? Да, играют, конечно. Но каково это, проходить по сотне раз одни и те же предписанные сценарии? Чем ещё они занимаются? Что лучше -- нанимать тестировщика и учить играть, или нанимать игрока и учить тестировать? Что можно автоматизировать, а что приходится тестировать вручную? Конечно, за сорок минут невозможно раскрыть все секреты тестирования игр, но Юля постаралась выделить самые главные особенности.
Несмотря на то, что прошедшая недавно конференция SoftwarePeople была ориентирована преимущественно на менеджерскую аудиторию, Юля Нечаева не побоялась выступить там с докладом о тестировании. Она рассказала менеджерам о том, чего они могут ожидать от тестировщиков -- с одной стороны, не совсем то, чего они обычно привыкли требовать, а с другой стороны -- гораздо больше, чем они обычно себе представляют.
«Я интересуюсь наукой просто для того, чтобы узнать больше об окружающем мире, и чем больше я узнаю, тем интереснее. Мне нравится познавать».
Ричард Фейнман
Автор: Майкл Болтон
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru
Оригинал: http://www.developsense.com/articles/2005-04-ThePleasureOfFindingThingsOut.pdf
Время от времени кто-нибудь спрашивает меня, чем я занимаюсь. И я отвечаю, что я - тестировщик программного обеспечения, обучаю тестированию, пишу о тестировании, и люблю тестировать. В этот момент некоторые смотрят на меня так, словно у меня вдруг выросли ослиные уши. И в этот момент мне кажется, что самое время дать некоторые пояснения, и я рассказываю им о Ричарде Фейнмане.
|
