Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Санджит Хохар (Sunjeet Khokhar)
Оригинал статьи
Перевод: Ольга Алифанова

Выдающиеся тестировщики, с которыми я имел счастье сотрудничать, не просто "сообщали, что там пожар" – они очень хорошо умели расследовать и сообщать –

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

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

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

Материал подготовлен компанией SimbirSoft

Успех IT-проекта во многом зависит от того, насколько грамотно организована система тестирования и обеспечения качества (Quality Assurance, QA) на всех этапах его жизненного цикла. 

Для специалиста по QA один из самых надежных способов подтвердить свои профессиональные качества ─ наличие международного сертификата ISTQB. Сегодня поговорим о том, что дает такая сертификация сотруднику, работодателю и бизнесу, а также о том, как мы в SimbirSoft поддерживаем квалификацию QA инженеров.

Автор оригинала: Hillel Wayne

Оригинальная публикация
Перевод статьи

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Автор: Джеймс Бах (James Bach)
Оригинал статьи: https://www.satisfice.com/blog/archives/5290
Перевод: Ольга Алифанова

Рим был построен не за один день, но хватило всего шести дней, чтобы он по случайности сгорел дотла в 64 году нашей эры. Он был заново отстроен с учетом пожарной безопасности. А когда в 1903 году при пожаре в театре "Ирокез" в Чикаго погибло 502 человека, уже в 1904 году нормы пожарной безопасности повысились. Пожар на фабрике "Трайангл" в Нью-Йорке (146 погибших) привел к основанию Нью-Йоркского Бюро пожарной безопасности, а Национальная Ассоциация Пожарной Безопасности сейчас поддерживает несколько сотен различных норм и требований – и многие из них появились вследствие особо трагичных пожаров. Люди учатся на трагедиях.

Наша компания разрабатывает систему КОМПАС-3D для построения трехмерных моделей и чертежей. Проект зрелый – в этом году ему исполнилось 30 лет. Над продуктом работают 9 команд в двух городах – Коломне и Рязани.

В системе автоматизированного тестирования мы используем Telegram для уведомлений, управления тестами и администрирования. Технически боты реализованы очень просто. Главная ценность заключается в их интеграции с системой автотестирования. Итак, что у нас делают Telegram-боты.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова.

В прошлый раз я начал давать подробный ответ на вопрос, "Выполняете ли вы исследовательское тестирование, тестируя API? Как вы это делаете?"

Я начал с того, что перефразировал первый вопрос вот так:

Если у продукта есть API, тестируете ли вы его?

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/07/exploratory-testing-on-an-api-part-1/
Перевод: Ольга Алифанова

Меня недавно спросили, занимаюсь ли я исследовательским тестированием API, и как именно я это делаю. Вот мой ответ.

Прикладной программный интерфейс (API) – это средство, при помощи которого мы можем использовать ПО для отправки команд продукту, чтобы он сделал нечто требуемое. Мы тестируем и API как таковое. Интерфейсы – это одно из измерений/факторов/элементов продукта. В широком смысле мы не просто тестируем API – мы используем их для контроля и наблюдения за продуктом, чтобы узнать о нем много интересного и нового.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/01/testing-buttons.html
http://thethinkingtester.blogspot.com/2018/02/testing-back-buttons.html
Перевод: Ольга Алифанова

Про кнопки, как правило, легко забыть. Кнопка "Сохранить" настолько универсальна, что кажется, что она просто не может не сработать. Однако игнорирование тестирования кнопок на странице может привести к игнорированию багов. Недавно мне рассказали о тестировании функциональности существующей веб-страницы. Новая фича отлично работала, но команда забыла проверить кнопку "Удалить". Оказалось, что разработчики забыли добавить действие удаления, и кнопка делала ничего!

Автор: Дейв Вестервельд (Dave Westerweld)
Оригинал статьи: https://offbeattesting.com/2018/07/30/api-testing-is-exploratory-testing/
Перевод: Ольга Алифанова

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

Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую API и работаю над курсами, обучающими API-тестированию. Это тестирование тоже требует исследовательского подхода!

Множество инструментов может помочь вам с тестированием API, и я пользуюсь многими из них. позвольте внести ясность: использование инструментов не отменяет исследования. Я находил в API множество багов, но сделал я это совсем не способом "заставить инструмент прочитать спецификацию в Swagger, а потом нажать на запуск". Я сделал это, изучая API. Большая часть инструментов для тестирования API направлена на то, чтобы помочь вам настроить автоматизированный регресс. У регрессионного тестирования есть свои задачи и своя польза, но не забывайте, что те же самые инструменты могут помочь вам при исследовании вашего API.

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