Ответы пользователя по тегу Тестирование ПО
  • Дают ли тестировщики/инженеры по автоматизации оценку трудозатрат?

    @azShoo
    Все участники процесса разработки в том или ином виде дают оценки трудозатрат.
    Форма подачи этих оценок не зависит от должности, а скорее зависит от компании и принятых в ней процессов на этот счет.
    Так или иначе, любая рабочая активность должна приносить определенный результат, и вопрос "когда этот результат будет получен" - необходим.
    Ответ написан
  • Где можно попрактиковаться новичку по тестить и желательно с фитбэком?

    @azShoo
    Нормальных способов получения такого опыта нет, но, как человек который собеседует (в том числе и джуниоров), могу сказать что этот опыт не особенно и нужен.
    И всё таки, варианты примерно следующие:
    1) Биржи тестирования (utest и иже с ними).
    По факту, больше времени вы потратите на то, что бы выбить себе задачи среди конкурентов, но какой-никакой опыт там можно получить.
    2) Стажировки в крупных компаниях. Тоже не самый крутой способ, т.к. скорее всего особого опыта вы не получите, просто будете пару месяцев решать рутинные задачи, от которых тщательно увиливают люди в штате компании.
    3) Проектная\почасовая работа на удаленке (напр. предложенные в комментах вакансии ассессоров в яндексе). Примерно то же самое, что п.2, но за символические деньги.

    По факту, всё это не особо нужно.
    Люди, которые готовы брать на работу начинающего специалиста не ждут в его резюме какого-то полезного опыта.
    Им нужно, в первую очередь, видеть общую адекватность, интерес и способность учиться и развиваться без пинков.
    Всему остальному они готовы вас учить. Иначе бы они не смотрели в сторону джуниор специалистов.
    - Пройдите курсы по тестированию и минимальные курсы по программированию (codeacademy + пайтон, например).
    - Почитайте пару книжек про тестирование, процесс разработки ПО, общий computer science.
    - Почитайте статьи по особенностям тестирования на разных платформах (напр. мобильных)
    - Напишите несколько пробных автотестов на UI и API, выложите их на github.
    - Возьмите несколько типичных бизнес-кейсов в любом известном приложении, напишите для них тестовую документацию. Можно так же выложить это всё на гитхаб.
    - Попрактикуйтесь в стандартных SQL запросах и работе с командной строкой.

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

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

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

    Третье: получить необходимые знания по тестированию, computer science и смежным областям.
    Что вам понадобится:
    - Основы computer science, работы клиент-серверных приложений, HTTP + знания по устройству и принципам работы целевой платформы (мобильные\дектоп\т.д. в зависимости от вакансии).
    - Знания по теории тестирования. Здесь достаточно прочитать одну-две книжки по тестированию и\или два десятка статей в интернете. Важно не заучивать определения, а понимать что это и зачем.
    Стандартный набор: что такое тестирование и его цель, виды и типы тестирования, методики тестирования, практики тест-дизайна, виды артефактов тестирования и тестовой документации (какие зачем нужны, когда применять, как писать).
    - SDLC, методологии разработки, жизненный и релизный цикл приложений.
    - Основы работы с базами данных: какие бывают, что такое, базовые запросы SQL.
    - Основы программирования: базовый курс в интернете\книжечка\ютуб по Python\Java\что-нибудь ещё.

    Четвертое: поизучать вакансии и походить по собеседованиям, понять где чего не хватает - выучить.

    Пятое: Profit - вы тестировщик.
    Ответ написан
  • Как написать тесты для бота ВК?

    @azShoo
    Ваши тесты должны проверять ваш код. Для этого и нужны ассерты (то самое сравнение, про которое вы говорите).
    То, что вы описали в "Я хочу" - не тесты и, вероятно, применять для этого JUnit нет смысла.
    Ответ написан
  • Как осуществить переход с Web тестирования в Mobile?

    @azShoo
    Почитать про архитектуру платформ.
    Почитать про специфику тестирования в мобайле (работа в фоне, энергоэффективность, ресурсоемкость, нестабильный коннект, например).
    Устроиться на новую работку.

    В целом, различия с точки зрения процесса тестирования косметические.
    Есть специфика платформ, на которую необходимо обращать внимание (часть описал выше), но это все проистекает из common sense.
    Есть специфика инструментов (снятие логов, дебаггинг, распространение тестовых сборок и пр.), но это уже на практике проще освоить, никакого рокетсаенса.
    Ответ написан
  • Нужны ли тестировщику мобильных приложений иметь при себе смартфоны различных версий Android и iOS?

    @azShoo
    Нужны. Работодатель вполне в состоянии обеспечивать необходимыми девайсами команду (это не так дорого, как кажется)
    Есть проблемы с удаленщиками, тут спасает только SauceLab и аналоги, но они хреново работают, не всегда пригодны к использованию и не всегда повторяют поведение живых девайсов.
    Ответ написан
  • Почему открывается 2 браузера при выполнении тест?

    @azShoo
    Вероятнее всего дело в том, что вы два раза инициализируете вебдрайвер
    Тут
    > FirefoxBinary firefoxBinary = new FirefoxBinary();
    и тут
    > driver = new FirefoxDriver(firefoxOptions);
    Ответ написан
  • Как правильно тормозить проверку условия при переходе на другую страницу?

    @azShoo
    Выносите wait в отдельную функцию, которая принимает на вход драйвер и целевой элемент.
    Функция в цикле с минимальным таймаутом проверяет целевой элемент на наличие\видимость\кликабельность, как только его находит - возвращает true.
    Сверху навернуть максимальный таймаут, что бы не впадала в бесконечный цикл и вуаля.
    У вас wait который ждет ровно столько, сколько нужно что бы появился целевой элемент.
    Ответ написан
  • Организация документация в автоматическом тестировании. Как организовать?

    @azShoo
    Я бы на вашем месте в первую очередь ответил себе на вопрос "Какую проблему должна решить нужная вам документация".
    Для чего вы хотите её написать?
    Что бы структура проекта автотестов, его запуска и пр. были более прозрачными для нового человека?
    Что бы было очевидно, какие кейсы покрыты автотестами, а какие нет?
    Что бы было понятно, какие именно действия и проверки выполняются в том или ином автотесте?
    Что бы просто была документация и всем было хорошо?

    Как только появится список конкретных проблем, которые желаемая вами документация должна решить - выбор того, как должен выглядеть нужный вам документ будет более очевиден.
    Ответ написан
  • Позитивный тест кейс, как?

    @azShoo
    Всё смешано в кашу.
    Думаю вам надо основательно почитать по теории тестирования и разобраться, где и что.
    Граничные значения и классы эквивалентности, а так же примеры их применения, гуглятся по запросу "Практики тест дизайна". Ну, или в любой книге по тестированию ПО.
    Если коротко: это про то, что разнообразные значения параметров, приводящие к одному и тому же результату нет смысла перебирать и можно схлопнуть их до минимума проверок.
    Напр. если у вас валидной датой рождения является 1910 - 2000 год -> вам нет смысла перебирать все значения от -MAX_INT до + MAX_INT, вам достаточно проверить >1910, 1910, 1911 - 1999, 2000 и > 2000.
    Т.к. по сути у вас есть 3 класса эквивалентных кейсов: пользователь указывает слишком раннюю дату рождения, пользователь указывает дату рождения в допустимом промежутке и пользователь указывает слишком позднюю дату рождения.
    Плюс к этому добавляется проверка границ этих интервалов - т.е. конкретных кейсов на границе каждого класса.
    Это позволяет определить, что границы классов проходят именно по нужным вам значениям (1910 - 2000), а не раньше\позже.



    По поводу классификации тесты на позитивные и негативные.
    Здесь всё просто. Позитивные кейсы проверяют работоспособность сценариев при ожидаемом поведении пользователя.
    Напр. вбил валидный емейл и пароль, они совпадают с теми, что есть у зареганного ранее пользователя -> авторизация прошла успешно.
    Нажал кнопку "Восстановить пароль" -> на почту ушло письмо с восстановлением пароля.
    И т.д.

    Негативные сценарии покрывают ситуации, когда пользователь сознательно или случайно делает что-то не так - начиная от валидации значений, до дублирования запросов, всяческих инъекций и прочего.
    Напр. кейс "Перевести деньги с карты -> Нажать назад в браузере -> Перевести ещё раз" будет негативным -> необходимо проверить, что предыдущий стейт страницы (в котором деньги ещё не выведены с карты) не даст пользователю вывести больше, чем у него есть.
    Ответ написан
  • Что должен знать Junior Automation Tester в 2018?

    @azShoo
    Понятие джуниоров везде разное.
    Если максимально усреднить:
    - Теоретическая база по Computer Science: понимание работы целевой платформы, общие принципы построения приложений, версионность, SDLC и прочее.
    - Теоретическая база по тестированию: тест-дизайн, практики и подходы тестирования, артефакты тестирования и принципы и подходы к построению и проведению тестирования.
    - Теоретическая база по автоматизации: какие инструменты есть, как автоматизируются те или иные сценарии, что стоит автоматизировать, а что нет и с какой стороны ко всему этому подходить. Пресловутый page object и html\page elements.
    - Теоретическая база по программированию: ООП, структуры данных, способность решать минимальные типовые задачи, знание Java\Python.
    - Какой-никакой опыт работы с инструментами автоматизации (Селениум для веба, Appium для мобил и т.д.)
    Ответ написан
  • Делаем что то одно — все остальное ломаем?

    @azShoo
    Давайте будем честными, продукты имеющие реальную продуктовую ценность имеют такое число состояний, что какие-то из них будут всегда сломаны.
    Независимо от фреймворков, тестирования и прочего. Баги будут, и чем больше изменений вы вносите - тем больше шансов привнести и баги.

    Тем не менее, есть вполне стандартные методы минимизировать эту боль.
    Это и практики тестирования (не только силами тестировщиков) и повышение code culture, код ревью, мониторинг состояния продукта, нормальные практики релизов и прочее-прочее-прочее.
    Никакого единого способа "всё и сразу починить" нету.
    Ответ написан
  • Как лучше всего выполнить задание на должность Junior QA?

    @azShoo
    1) Почитать про теорию тестирования. Вам нужно понять, как происходит процесс тестирования, какая у него цель и пр.
    2) Прочитать про основные практики тест-дизайна: Вы должны примерно представлять, какие проверки нужны и в каких случаях.
    3) Применить полученные знания в выданному вам продукту и составить условный набор тест-кейсов.

    Я бы ожидал от джуниора, что он понимает:
    а) Какие проверки необходимо провести для оценки общей работоспособности игры, и что стоит проверять после того, как общая работоспособность проверена.
    б) Понимает, какими способами можно свести к минимуму эти самые проверки (применение тест-дизайна на практике).
    в) Понимает, что такое приоритеты в тестировании - какие проверки стоит проводить раньше, какие позже.
    Ответ написан
  • Где тестировать API приложение?

    @azShoo
    Есть разные уровни тестирования, задействующие API.
    Если вы тестируете непосредственно контракт (посылаем такой запрос -> получаем такой ответ), то делать это через UI кажется бессмысленным. Подойдет любой инструмент, позволяющий посылать запросы.
    Вариантов много: Postman, RestAssured, а так же любой язык + библиотека для отправки HTTP запросов (напр. Python + Requests \ Java + ApacheHttpClient).
    Если вы проверяете интеграцию сервисов (интеграционный тест), то логично проверять что сервис А посылает валидные запросы, а сервис Б их валидно обрабатывает. Т.е. запрос будет происходить от лица сервиса А (изнутри или со стороны его UI - не важно).
    Если ваш тест представляет собой end-to-end проверку (т.е. максимально приближенную к продакшену последовательность действий), то тест будет проходить в UI (т.к. это точка взаимодействия пользователя).

    Первый вариант проще и быстрее, начинать стоит с него. End-to-end тестами стоит покрывать только основный пользовательские сценарии, т.к. такие проверки обычно долгие и дорогие в разработке и поддержке.
    Ответ написан
  • Существует книга или цикл статей по подготовке синтетических тестовых данных, профилированию данных?

    @azShoo
    Если мы говорим о подготовке данных для тестирования - то это всё напрямую вытекает из вполне емких принципов тест-дизайна.
    Граничные значение, классы эквивалентности, pairwise testing - все это позволяет довольно быстро определить нужные наборы данных для каждого сценария и схлопнуть их до необходимого минимума вариаций.
    Дальше уже вопрос выявления сценариев, по которым нужно готовить данные. Тут нужно анализировать систему, составлять тестовую документацию и пр.
    В целом, я бы сказал, что пары фундаментальных книг по тест дизайну и тест-анализу поможет понимать, что и на каких данных проверять.
    Дальше уже только долгий и кропотливый труд по формированию и синтезу тестовых данных.
    Ответ написан
  • Стоит ли тестировщику сдавать на ISTQB?

    @azShoo
    Давайте по порядку.
    Да, ISTQB стоит денег, причем даже за "неудачную" попытку его пройти.
    Так работает сертификация везде и всегда.
    Дискуссиями о том, какую смысловую нагрузку несет получение сертификата идет не один год, единого мнения нет.
    Если коротко: хуже от этого никому не будет, хотя рассчитывать, что это даст ощутимый результат - смысла нет.
    Что касается работодателей: нужно понимать, что при собеседовании у работодателя стоит цель закрыть определенные задачи за N денег. Если вы смогли его убедить, что можете это сделать - ему будет пофиг на все бумажки. Если не смогли - сертификат тоже вряд ли поможет.
    Есть работодатели и ситуации, когда сертификат играет "в плюс" (напр. при подаче документов на релокацию в другую страну любые сертификаты будут дополнительным плюсом в глазах бюрократов из иммиграционной службы).

    Ну и последний вопрос: ситуация, когда текущий работодатель оплачивает сертификацию сотруднику - довольно стандартная. В большинстве случаев это делается с условием, что если вы уволитесь раньше, чем через N - вы вернете стоимость сертификации.
    Хотя я бы, с точки зрения работодателя, скорее бы отправил человека на курсы, повышающие его скиллы, нежели на сертификацию позволяющую проверить насколько человек ориентируется в профессиональной терминологии (а весь ISTQB это по сути заучивание терминов).
    Ответ написан
  • Тестируются ли внутренние разработки компаний отдельно от проектов, где используются?

    @azShoo
    Короткий ответ: Да, тестируется.

    Длинный ответ:
    Команды, занимающиеся разработкой подобных инструментов - это всегда относительно независимая команда, существующая в своих циклах разработки, релизах и своем окружении.
    Тестирование такого продукта может быть завязано на тех "клиентов", которые интегрировали у себя этот продукт (т.е. во время "внутреннего тестирования") учитываются юзкейсы внешних клиентов. Так работает тестирование любого продукта - тебе, прежде всего, необходимо гарантировать работу тех сценариев, которые задействованы твоими пользователями.
    Тем не менее, продукт, вероятнее всего, будет тестироваться изолировано от внешних интеграций.
    Ответ написан
  • Как можно смоделировать работу 10000 пользователей в приложении?

    @azShoo
    Тут нужно понимать, что конкретно вы хотите проверить.
    Если речь о том, как сайт выдерживает параллельную работу 10 тысяч юзеров - вам нужны инструменты нагрузочного тестирования (гуглите Load & Performance testing tools и вперед).
    Если речь о том, как сайт работает на бОльших объемах данных (условно - вывести список из 10к заказов вместо 10 штук) -> нужно копать в сторону сидирования данных и вообще их генерации, т.к. по сути вам не нужны "действия пользователей", а нужны только данные в базе (т.е. артефакты этих действий).
    Если речь о лайфтайме данных, то тут сложнее. Вы можете сгенерировать данные, якобы созданные 2 месяца назад (условно подменив все необходимые таймстэмпы нужными), но это никак не покажет проблемы. Основная причина багов в "старых" данных - то, что со временем приложение, модель и структура данных меняется, что делает созданные 2 месяца назад данные не полностью корректными с точки зрения текущей системы (если в процессе изменений была нарушена обратная совместимость).
    Тут может помочь только:
    а) раскатывать кусок старого дампа и проверять на нём.
    б) генерировать тестовые данные в старой версии приложения и инъектить их в базу новой версии.
    в) использовать дамп с прода, где эти старые данные уже сгенерены пользователями.
    Ответ написан
  • Заниматься инструментами тестирования - это плохая идея?

    @azShoo
    Тестирование - это сложно, мучительно и тратит время.
    Проблема в том, что других способов гарантировать корректную работу приложения у вас нет.
    Хотя если у вас есть идеи - поделитесь, с радостью послушаю.

    По поводу остального: это как и с любыми новыми инструментами и технологиями, пока вы разбираетесь - тратите много времени и генерируете много WTF/min, когда осознали и собрали все грабли - выходите на "плато" производительности и начинаете генерировать полезный результат.
    Ответ написан