Все записи автора QaEvolution

Типы багов, этимология бага

Перед тем как говорить про типы багов, узнаем откуда взялся сам баг. Слово «баг» в техническом смысле обозначает ошибку или дефект в программном обеспечении или аппаратуре. Этот термин происходит из английского языка и имеет интересную историю происхождения.

Согласно легенде, термин «баг» был введен в 1947 году Грейс Хоппер, программистом компьютера Harvard Mark II. Однажды, когда компьютер начал выдавать ошибки, Грейс и ее коллеги обнаружили, что причиной неисправности стал кусок насекомого, который застрял в одной из электронных ламп. Она извлекла насекомое и записала в журнале причину сбоя как «баг» (англ. «bug»).

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

Читать далее Типы багов, этимология бага

Критичность и приоритет дефектов

Критичность и приоритет дефектов в разработке ПО это базовые аспекты артефактов тестирования. Качество программного обеспечения играет ключевую роль в конкурентоспособности любой компании, поэтому важно уделять должное внимание процессу тестирования. Частью этого процесса является управление дефектами, которые могут возникать в процессе разработки. При этом каждый issue должен быть классифицирован учитывая его критичность и приоритет дефектов.

Критичность дефекта, или Severity, описывает важность воздействия конкретной ошибки на функционирование ПО. Она определяется на основе технических характеристик дефекта и может быть критической, высокой, средней или низкой. Критический дефект имеет наибольшую критичность и приводит к масштабным последствиям, таким как потеря данных или нарушение ключевой функциональности ПО. Высокий дефект также имеет серьезное воздействие на пользователей, но не настолько критичен, как критический. Средний дефект может влиять на работу пользователей, но в большинстве случаев имеет обходные пути. Низкий дефект имеет наименьшую критичность и редко влияет на работу пользователей.

Читать далее Критичность и приоритет дефектов

Тестирование по степени глубины

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

Тест критического пути

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

Расширенное тестирование

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

Читать далее Тестирование по степени глубины

Тестировщик может справиться лучше?

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

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

Большая внимательность к деталям

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

Читать далее Тестировщик может справиться лучше?

УСТАНОВКА НЕОБХОДИМЫХ ИНСТРУМЕНТОВ

Установка JAVA

Установка JAVA
  • Прописываем переменные среды

Открываем: “мой компьютер» -> свойства -> дополнительные параметры -> переменные среды -> системные переменные”

Создаем новую переменную JAVA  и прописываем путь к jdk.

Прописываем переменные среды для Java
Читать далее УСТАНОВКА НЕОБХОДИМЫХ ИНСТРУМЕНТОВ

Использование техник тест-дизайна

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

О некоторых техниках тест-дизайна поговорили тут:

Еще немного предисловия, о том, как к сожалению тестируют в большинстве своем многие, кто ударяя себя пяткой в грудь именуют QA. И не сказать что ребята плохие или знаний мало, но вот не хотят думать, анализировать. Получил задачу и сразу в бой, сразу баги искать, а еще лучше сразу в негативные тесты. И вот ты уже тысячу раз проговорил все, обсудили как надо подходить, договорились о стандартах и правилах. А вместо обдуманного тестирования все равно тестиим дальше…

Читать далее Использование техник тест-дизайна

можешь ли ты тестировать бесконечно ?

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

Мы разрабатывали фичу такого плана. Клиент хотел на основе нашей библиотеки, создать форму для онлайн конфигурации веб формы. Форма наполнялась похожими дроп-даунами, чекбоксами и инпутами и тд. Предполагалось, что к примеру, можно будет создавать тесты для прохождения — учениками или клиентами. Но ), задача была бы слишком тривиальной, если бы не одно, но. В такой конструктор добавлялся конструктор if/else ( а также условия равенства, неравенства, include текста в ответе и наоборот). Условий и равенств было больше 10, который в зависимости от ответа, мог ветвится по форме. Блочить другие части вопросов, показывать новые, изменять ветку по которой пойдет пользователь. И некоторые другие фишки, возможно не столь существенные, а возможность старость, и я не помню. 

Читать далее можешь ли ты тестировать бесконечно ?

Автоматизация тестирования мобильных приложений

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

Немного вводной информации о мобильном тестировании без элементов автоматизации

В этом курсе /цикле представлена автоматизация тестирования мобильных приложений для андроид. Стек технологий следующий: язык программирования JAVA, с использование Maven, естественно Android Studio и Node.js. В будущем планируется добавить автоматизацию тестированя мобильных приложений для Ios в связке с js и Appium, там мы еще познакомимся с Xcode.

  1. Установка и настройка окружений;
  2. Создание первого проекта;
  3. Создание виртуальных девайсов;
  4. Базовые настройки и конфигурация нативных приложений;
  5. Подключение реального девайса и настройка тестов для запуска;
  6. Поиск элементов в нативном приложении;
  7. Автоматизация тач действий и работы физических кнопок;
  8. Автоматизация тестирования мобильных тестов для веба на девайсе;
  9. Автоматизированные мобильные тесты для гибридных устройств;
  10. Настройка подключения Android через Wi-fi.

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

Тестировщица экстрасенс

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

Знакомство с претендентом:

  1. Девушка;
  2. Хочу работать в АйТи — в тестировании, потому что это круто: и развиваться можно, и не скучно, и еще что-то про пользу обществу. (Хоть бы кто-то правду сказал);
  3. Я прочитала целого всего Савина  (headbang).
Тестировщица экстрасенс

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

  1. Произвести впечателение, что человек достаточно способный изучать материал самостоятельно;
  2. Показать свои серьезные намерения.
Читать далее Тестировщица экстрасенс

Use-case и немного юмора. Часть 6

Пишем юз-кейсы для частного чата

Создание публичной группы

Было поручено Адольфу собрать группу художников, которые были слишком заняты и готовились к CG конвенту, но все еще не были собраны в группу, помня поручение начальства «…их задача будет только принять приглашение, остальное все на тебе», Адольф принялся за дело. Он нажал на кнопку ‘+’ в блоке Groups, рядом всплыло окно с название ‘Create group’. Название было исключительно рабочим ‘Enviroment artists conference’. Вспомнив еще одно поручение, Адольф оставил группу в статусе Public, чтобы могли еще придти другие участники, кто только получил приглашение зарегестрироваться. Пораздумав, в About group Адольф добавил краткое описание ‘CG conference 10-16 October, Berlin. You can add new artists, if they are members of future conference’. Кликнув на поле с описание ‘Search user’ Адольф принялся вводить имена, которые ему пришли по почте, найдя нужного человека он кликал на ‘+’, пару раз он случайно добавлял не тех пользователей, но затем также смог легко их удалить, нажав на ‘Х’ около имени случайно попавшего пользователя. Сверив все, что он сделал, Адольф нажал на ‘Create group’. На следующий день, когда статусы участников сменились со статуса pending in yellow color, Адольф понял, что на этом его работа закончена и он кликнул на ‘…’ в правом углу group header и кликнул на ‘exit group’, подтвердив нажатием на кнопку ‘Leave’.

Читать далее Use-case и немного юмора. Часть 6