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

Подписаться

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

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

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

Лучшие вакансии

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


Проблемы тестирования – это результаты тестирования
26.06.2017 09:18

Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/

Автор: Майкл Болтон (Michael Bolton)

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

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:

  • Я единственный тестировщик, и работаю с несколькими разработчиками (или один из тестировщиков, и в нашей команде много разработчиков).
  • Я очень сильно ограничен по времени. Постоянно приходят новые билды, и мы релизимся каждую неделю-две.
  • Продукт(ы), который я тестирую, очень сложен сам по себе.
  • Между модулями продукта (или между разными продуктами) множество взаимозависимостей.
  • Я вижу, что ряд проблем возникает именно из-за этих взаимозависимостей – небольшое изменение в одном модуле может повлечь за собой катастрофу в другом.
  • Я считаю, что для отлова подобных багов нужно прогонять полный регресс для каждого нового билда.
  • Я стараюсь справиться с задачей, используя автотесты, но сложность продукта затрудняет автоматизацию тестирования – "якоря" для автотестов минимальны или отсутствуют, а частые изменения продукта усложняют поддержку автоматизации.
  • На поддержку автотестов уходит приличное время, и я не успеваю заняться тестами, которые хотел бы прогнать.
  • Все это сильно выматывает, но я пытаюсь справляться.
Подробнее...
 
Как писать хороший баг-репорт
22.06.2017 08:23

Оригинальная публикацияhttp://bytextest.ru/2017/02/15/bug-report-kak-pisat/#more-4457

Вы когда-нибудь видели под вашим багом комментарий “it is not reproducible”? Чувствовали, как екает сердце от статуса “waive requested”? Иногда команда разработчиков «разворачивает» баг, который вы так трепетно лелеяли и выхаживали. Ну, может не так уж и трепетно, раз его все таки не смогли воспроизвести.

Нажмите на картинку, чтобы увеличить изображение

Представьте ситуацию, когда, например, баг был заведен в Mozilla Firefox. Допустим, на сайте не работает кнопка «login». Так и запишем, попутно забыв указать в STR (шагах воспроизведения) — какой именно браузер и какую его версию мы использовали. А вот разработчик использует, допустим, Edge. И в их среде кнопка работает нормально. Соответственно, баг отклоняют за невозможностью воспроизведения и комментарием: «Может быть, проблема в вас?» Вы, как порядочный тестировщик, перепроверяете ошибку, находите ее и переоткрываете баг. Чем все закончится — непонятно.

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

Подробнее...
 
Чему тестировщики могут научиться в "Голодных играх"
19.06.2017 09:55

Автор: Барт Ванхерк (Bart Vanherck).

Оригинал статьи: http://www.bartvanherck.be/2017/01/12/testers-can-learn-from-the-hunger-games/

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


Недавно я прочитал первую часть трилогии "Голодных игр" Сьюзан Коллинз. Книга, если задуматься, крайне интересная. Что можем мы, как тестировщики, вынести из Голодных игр?

1. Исследуй свое окружение

Когда Китнисс, главная героиня книги, входит в виртуальный мир, она понятия не имеет, что он из себя представляет. Каждый год игры проводятся в новом виртуальном пространстве. Что это значит для нее? Ей нужно познакомиться с этим пространством. Где находится вода, где можно найти еду, и так далее. Как она это делает? Исследуя мир вокруг себя.

В мире тестировщиков все аналогично. Каждый новый продукт или даже новый билд содержит какие-то нововведения. Тестировщику нужно исследовать этот новый билд. Как это работает? Какие ошибки тут можно допустить? Если я сделаю вот так, что случится дальше?

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

Подробнее...
 
Освоение тестирования SOAP API
23.06.2017 08:29


Оригинальная публикация: http://quality-lab.ru/soap-api-testing/

АвторЮлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества" 

Не так давно в нашем блоге рассказывалось об освоении тестирования через REST API. Я же хочу поделиться опытом тестирования SOAP, «старшего брата» REST.

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).

Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.

Подробнее...
 
Плохие требования – кошмар тестировщика
13.06.2017 09:59

Оригинал статьи: http://www.testingexcellence.com/bad-requirements-software-testers-nightmare/

Автор: Намита Коли Арора (Namita Kohli Arora)

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


Реальный мир никогда не бывает переполнен розовыми пони, и то же самое справедливо для наших рабочих задач. Я множество раз сталкивалась с тест-проектами, которые были крайне далеки от идеала: в них отсутствовала даже самая базовая документация, и не было никакого намека на централизованное управление тестированием. Худшее, с чем я встречалась – это проекты, в которых или вообще не было требований, или эти требования были записаны абы как. Работа над такими проектами сводит меня с ума и стоит мне многих бессонных ночей (я не преувеличиваю – попытки разобраться в разрозненных информационных потоках заставляют мозг работать 24/7). Но нравится мне это или нет, такие проекты – наша реальность, и у нас нет выбора: с ними приходится иметь дело.

"Плохие требования" – довольно широкое понятие. К примеру, это могут быть:

Подробнее...
 
Психология тестирования (конечно же, не исчерпывающая). Личный перевод из книги «Искусство тестирования» Г. Майерса
05.06.2017 08:08

Оригинальная публикацияhttps://habrahabr.ru/post/329966/

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

— тестирование – это процесс для демонстрации того, что в программе нет ошибок;
— цель тестирования в том, чтобы показать, что программа выполняет ожидаемые от нее действия корректным образом;
— тестирование – это процесс, направленный на создание уверенности, что программа делает то, что должна.

Эти определения неверны.

Вот вам дедуктивное умозаключение:

Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта – 
Добавление надежности продукта происходит путем поиска и удаления ошибок.

Поэтому не занимайтесь тестированием. Не занимайтесь тестированием для того, чтобы показать, что все работает; начните с аксиомы – программа содержит ошибки (кстати, это верно для большинства программ), и далее тестируйте так, чтобы найти их столько, сколько это вообще возможно, будто это Ваш последний день (в тестировании).

Подробнее...
 
Особенности тестирования веб-приложений
26.05.2017 08:25

Автор: Олег Грабко, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикацияhttp://quality-lab.ru/key-principles-of-web-testing/

Доводилось ли вам тестировать веб-приложения? Практически любой специалист по тестированию программного обеспечения с опытом более года даст утвердительный ответ на этот вопрос, ведь существуют вполне объективные причины такого положения дел:

- на данный момент в сети Интернет действует более миллиарда сайтов, и пользуются ими более 3,5 млрд. людей по всему миру (по данным Международного союза электросвязи на июль 2016 года);
- в России более 70% взрослого населения являются интернет-пользователями, а общий оборот средств на российском рынке интернет-торговли за первое полугодие 2016 года вырос на 26% в сравнении с аналогичным периодом 2015 года и достиг 405 млрд. рублей.

При взгляде на эти баснословные цифры становится понятным, почему в мире разрабатывается так много новых веб-приложений. Этот процесс приводит к необходимости привлечения большого количества специалистов. То, что веб (в широком смысле) будет продолжать наращивать темпы своего развития, подтверждается и набирающим силу «мейнстримом»: всё «переезжает» в облака. Облачные технологии становятся новой реальностью современного Интернета: даже некогда привычные нам десктопные Word и Excel сегодня представлены в виде веб-альтернатив от Microsoft. Исходя из сказанного, можно утверждать, что потребность в хороших инженерах по обеспечению качества, специализирующихся на веб-продуктах, будет только расти.

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

Подробнее...
 
Не был ли Сун Цзы тестировщиком?
17.05.2017 08:34

Оригинал статьи: https://testzius.wordpress.com/2017/02/13/sun-tzu-was-a-tester/

Автор: Майкл Фритциус (Michael Fritzius)

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

О книге

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

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

Давайте посмотрим, как мудрость Сун Цзы применима к "Искусству тестирования".

Далее следуют цитаты из книги и их возможное приложение к тестированию. Расширенный набор цитат можно посмотреть здесь.

Применение в тестировании

"Превосходство над вражескими нациями без вступления в военные действия есть наивысшее из искусств".

Работая с другими людьми, мы должны помнить о том, что люди – существа эмоциональные. Каждый приносит на рабочее место свой личный "багаж" эмоций. Часть нашего багажа отвечает за наше отношение к другим людям. Если вы хотите напасть в ответ на чей-то укол, остановитесь и подумайте, почему люди говорят именно это? Действительно ли они хотят "достать" вас, или преследуют личные цели? Обычно это скорее второе, а не первое. Хорошая коммуникация – залог успеха: обезвредьте ситуацию, поговорив с коллегой и попытавшись понять, какие цели он преследует.

Подробнее...
 
Ваш API – ваше лицо
05.05.2017 08:10

Автор: Юлия Багрий

Оригинальная публикацияhttp://quality-lab.ru/your-api-is-your-public-face/

Для начала нам нужно понять, что же такое API?
API (Application Programming Interface) – это интерфейс, который позволяет осуществлять взаимодействие между программами. Если человек общается с приложением через кнопки и диалоги (пользовательский интерфейс, UI), то программы обмениваются информацией друг с другом через API.

Категории взаимодействия API

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

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

Основные риски, связанные с внутренним API, – это функциональные дефекты и проблемы производительности. Здесь пользователи могут лишь предполагать, из-за чего конкретно приложение работает «как-то не так».

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

Подробно остановимся на втором варианте. Предоставление API является для некоторых главным бизнесом (те же социальные сети и платежи), для других же – приятным дополнением к основному сервису. Но в любом случае форма реализации и представления API, образно говоря, «приоткрывает дверь во внутреннюю кухню» разработки. И вот тут уже «спрятаться» за красивым дизайном и саппортом не получится.



Подробнее...
 
Освоение тестирования REST API
28.04.2017 08:36

Автор: Андрей Шальнев

Оригинал публикации: http://quality-lab.ru/rest-api-testing/

В этой статье я хочу поделиться опытом освоения тестирования (в т. ч. автоматизации) на уровне API (Application Programming Interface – интерфейс программирования приложений, интерфейс прикладного программирования). Надеюсь, что предлагаемый материал будет представлять интерес для всех, кто ранее проводил тестирование через графический интерфейс и еще не имеет опыта работы с http-запросами.

Немного о REST API и SOAP API

Стоит отметить, что на сегодняшний день есть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:

  • REST (от англ. Representational State Transfer – «передача состояния представления») обеспечивает общение между клиентом (как правило, это браузер) и сервером с помощью обычных HTTP-запросов (GET, POST, PUT, DELETE и т. д), передавая информацию от клиента в параметрах самих запросов, информацию от сервера – в теле ответа (который может быть, например, JSON-объектом или XML-документом). REST является архитектурным стилем, а не стандартом.
  • SOAP (от англ. Simple Object Access Protocol – простой протокол доступа к объектам, вплоть до спецификации 1.2) характеризуется использованием HTTP(S)-протокола лишь как транспорта (чаще всего, методом POST). Все детали сообщений (в обе стороны – от клиента к серверу и обратно) передаются в стандартизованном XML-документе. SOAP может работать и с другими протоколами прикладного уровня (SMTP, FTP), но чаще всего он применяется поверх HTTP(S). SOAP является протоколом и имеет спецификацию.
Подробнее...
 



Страница 1 из 14