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

Подписаться

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

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

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

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

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


Ловушки мышления в тестировании
31.08.2015 12:28

Доклад Ирины Ивановой на на встрече Tallinn DevClub.

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

 
Чем тестировщик отличается от разработчика?
10.08.2015 12:32

Перевод статьи Chris S

Оригинальная публикация: http://secondsignofmadness.blogspot.ru/2015/07/testers-developers-and-coders.html

Вначале я рассматривал тестирование, разработку и людей, вовлеченных в эти процессы, примерно так:

 

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

 tvd128129

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

Подробнее...
 
SQA Days-17: лучшие доклады
06.07.2015 11:13

Публикуем подборку докладов, выбранных лучшими на SQA Days-17 (без учета профессиональных спикеров).

Подробнее...
 
SQA Days-17: ручное тестирование
30.06.2015 18:12

Публикуем подборку докладов с SQA Days-17, посвященных ручному тестированию.

Подробнее...
 
Эвристики ХРОНИЧеского регрессионного тестирования
21.04.2010 00:02

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

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

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

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

Подробнее...
 
У семи программистов адрес без дома
25.06.2015 13:38

Все примеры по тестированию ориентируются на форму регистрации или числовое значение. А когда тестировщик приходит на работу и видит там строковое поле, начинается ступор — как тестировать? Какие там баги могут быть?

Компания HumanFactorLabs опубликовала статью про примеры тестовых данных для тестирования... Адресов! 

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

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

Недавно нас попросили привести примеры необычных адресов, в связи с чем и написана эта статья.

Подробнее...
 
Самые ужасные баги в истории
08.06.2015 13:29

Подборку подготовила Ольга Алифанова

Все мы знаем, что баги могут ужасно досаждать. Но помимо мелких неприятностей, они также могут повлечь за собой колоссальные убытки, ущерб и даже смерть. Портал Software-Testing.ru подготовил подборку самых катастрофических багов в истории.

Подробнее...
 
Исследовательское тестирование 3.0
03.06.2015 13:40

Авторы: Джеймс Бах, Майкл Болтон

Оригинал: http://www.satisfice.com/blog/archives/1509

Перевод: Ольга Алифанова

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

Джерри хорошо понимал, чем отличается человеческий труд от машинного. Однако за ним пришли формализаторы и всех запутали. Официально формализация тестирования началась в 1972 году, когда была опубликована книга "Методы тестирования приложений". Книга концентрировалась не на сути, а на форме тестирования – то есть на словах, изображениях, строках кода, файлах, таблицах, диаграммах и прочих точно определенных формах и моделях. Эти формы и модели можно увидеть, прочитать, указать на них, переместить их, сосчитать, хранить, воспроизводить,  и поэтому так прельщает возможность определить их как "тестирование". Но тестирование – это не модели и артефакты. Тестирование - это использование артефактов человеком. Артефакты тестирования без участия людей похожи на суперсовременные клиники без докторов или медицинских сестер: как минимум – практически бесполезны, как максимум – опасны для несведущих, пытающихся их использовать.

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

Джеймс Бах ввязался в этот бой в 1987 году и попытался разложить ситуацию по полочкам. Наблюдая процесс тестирования, он обнаружил, что ad hoc тестирование хорошо работает для поиска багов, а сценарное – нет (Примечание: Мы не пытаемся показать, что обнаружить это было легко и просто. Мы хотим сказать, что неочевидные истины тестирования присутствуют вокруг нас, и их можно осознать, если отложить фольклор о моделях и сценариях и присмотреться к тому, как на самом деле работают люди). Джеймс начал рассказывать о своем опыте и писать о нем. Когда он проработал тест-менеджером несколько лет (в основном тестируя компиляторы и другие инструменты разработки), до него дошла информация, что Кем Кэнер придумал термин "исследовательское тестирование" как антоним сценарного. В своей небольшой статье Кем не дал точного определения и только кратко наметил суть понятия, но он был первым, кто заговорил о создании тестов во время их исполнения.

Так появилось то, что мы называем "Исследовательским тестированием 1.0".

Подробнее...
 
Embracing The Imposter
20.05.2015 11:44

Доклад Сергея Высоцкого (Spotify) на конференции CodeFest 2015.

Тестирование и отладка распределенных систем это ужасно. В первую очередь потому что они сложные. Но во многом еще и потому, что в мире, где существует больше одного компьютера очень часто происходят вещи о которых многие даже не задумываются. Я в свое время был немало удивлен увидев как ряд популярных FOSS (Free and OpenSource software) продуктов реагирует на Network Split. К счастью это все можно сильно упростить немного развив концепции применяемые в других областях тестирования.

Подробнее...
 
Alien bugs или пришельцы из мира дефектов
13.11.2014 12:22

Павел Новик, ЗАО «Технологии качества», бренд A1QA

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

Однако, все не так просто, как может показаться на первый взгляд.

I. Непроста и неказиста жизнь рядового программиста тестировщика.

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

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

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



Страница 21 из 27