Home

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

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

Традиционно мы публикуем выступления уже достаточно опытных и «умудренных годами» тестировщиков. Но сегодня решили немного отойти от стандартов и опубликовать выступление начинающего тестировщика – Софии Костюченко «Исследовательское тестирование. Как это было».

Чем может быть интересно это выступление?

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

Во-вторых, подготовлено оно совсем начинающим тестировщиком – поверите ли вы после просмотра, что на момент этого выступления опыта в тестировании у Софьи было … всего 2 месяца, а опыта выступлений не было вовсе? Правда, это были 2 месяца обучения на Курсе практического тестирования и Софья стала там одним из лучших выпускников. Сейчас Соня работает джуниор тестировщиком, продолжает учиться на 4 курсе физического факультета и (уверены) обязательно выступит где-нибудь еще.

Считаете ли вы себя квалифицированным тестировщиком?

Знаете ли вы, куда вам развиваться дальше и как это делать?

Если ответ «да», то мы за вас очень рады!

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

Есть что добавить? Поделитесь, и мы улучшим эту презентацию!

Автор: Андрей Мясников

Вместо предисловия.

В этом тексте нет ничего нового и интересного. Абсолютно ничего. Это обычный набор заржавевших парадигм, которые у всех уже стоят поперек горла и набили оскомину одним своим звучанием и фальшивой слащавостью. Когда-то их вбили и мне, дав «правильные» книги и пропуск на «нужные» тренинги. И я вовсе не собираюсь их опровергать, а повторю ещё раз для тех, для кого не дошло с двадцатого раза. Может быть, дойдёт с двадцать первого. Итак, вперед!

“Whysoseriously?”
Joker.

Джокер.

Когда-то давно из колоды я вытянул джокер.

Нет, я не увлекаюсь азартными играми и вообще отвратительно играю в карты.

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

«А что?» - думал я, - «Работенка непыльная, знаний много не надо. Того, что у меня есть, вполне хватит». Хахаха. Три раза. Три месяца испытательного срока я въезжал в то, что я «знаю», учился привязывать это к реальности и применять на практике.

Потом работал и получал удовольствие. Был доволен собой и думал, что вот теперь-то меня похвалят за хорошую работу. Но почему-то не хвалили.

Я думал, что я просто ещё мало работаю, чтобы меня заметили. Впахивал, нередко задерживаясь допоздна, и похохатывал надо коллегами, которые ездили на какие-то тренинги и изучали новые инструменты и методики. Нафига? Ведь я и так справляюсь и могу выполнять свою работу пусть не на 5+, но на твердую четверку точно.

Компания платит деньги, я работаю – все довольны.

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

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

Бориз Бейзер описал "парадокс пестицида" в своей книге "Software Testing Techniques", вышедшей ещё в далёком 1983 году. Он попытался провести аналогию между повторным выполнением тестов и повторной обработкой полей тем же пестицидом, который уже применялся недавно. После первой обработки часть вредителей погибла, но не все -- некоторые выжили, потому что их организм оказался устойчив к яду. Так вот эти "счастливчики" с большой вероятностью переживут и повторную обработку. Точно так же, утверждал доктор Бейзер, повторное применение одних тех же тестов, и даже повторное применение одних и тех же методов тестирования, приводит к тому, что в программе остаются дефекты, против которых эти методы неэффективны.

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

- У нас много регрессионных тестов, нам не хватает времени на то, чтобы их все выполнить, может быть их автоматизировать?
- Может быть. Но сначала скажите, эти тесты часто обнаруживают дефекты?
- Да практически никогда! Поэтому и хотим автоматизировать.
- А новые тесты в этот набор часто добавляются?
- Только по дефектам, которые пользователи нашли.
- То есть пользователи в этих модулях обнаруживают дефекты, а тесты их не обнаруживают?
- Ну-у-у, да...
- А почему?
- ??? (молчание) ... (понимание) Так это же парадокс пестицида!!!!

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

Коллеги, оставьте ненужный хлам в старом году, а в новом году добавьте разнообразия в свою жизнь! Скачать плакат для печати в pdf формате.

Давно хотели поделиться с нашими читателями ссылкой на запись специального вводного семинара "Тестирование программного обеспечения: основные понятия".

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

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

Посмотреть отзывы о прошедших онлайн-семинарах

Автор: Вячеслав Панкратов

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

Вопрос задаётся не только в русскоязычном сообществе, но и нашими коллегами по всему миру и звучит примерно так:

• В чём разница между Тестированием и QA?
• What's the difference between QA and testing?
• What Is The Difference Between Quality Assurance, Quality Control, And Testing?

Автор: Алексей Лемешко

Статья была переработана с учётом полученной в форуме критики и рекомендаций.

Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения — процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.

Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные — пишут правильно. Но

Автор: Алексей Курских

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