Ответы пользователя по тегу Тестирование ПО
  • Как правильно использовать Given, when и then в UI тестировании вводимых без данных?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Представьте, что ваш тест это эксперимент (над приложением) и попытайтесь прочитать его так:
    При условии что
    GIVEN и GIVEN а также GIVEN,
    Если я WHEN
    To тогда должно произойти THEN .

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

    При условии, что пользователь уже залогинен.
    При условии, что корзина пуста
    При условии, что поле выбрана опция такая-то.
    При условии, что в поле А введено значение Х а в поле Б значение Y

    А потом вы переходите к самому эксперименту.

    Given: нажми на кнопку А
    Given: и нажми на кнопку Б
    Then: создался объект C

    В данном случае скорее всего условие это нахождение на какой-то странице, или то, что выбрана какая-то секция приложения.
    Вы же не можете "в воздухе" нажать кнопку A и Б, правильно? Given это не действие, это состояние.

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Слишком широкий вопрос, чтобы так вот взять и дать на него развернутый ответ.

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

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Богдан Кирий Конечно в "кустарной" мастерской вряд ли будут процессы по учебнику или какие-нибудть стандарты. Они им попросту не нужны. Поэтому пользы от такого опыта для применения в условиях средней или крупной компании ну не чересчур много. Например, полностью отсутствует процесс отчетности. Он там и не нужен, отчитываться не перед кем, кроме своей совести. Интересно вот, пытались ли вы привнести что-то в тестирование чтобы его улучшить. Ведь, как гвоорится "плох тот солдат который не мечтает стать генералом". Может пытались автоматизировать рутину или что-то в этом роде?

    Кстати, намедни по Хабру пролетало"FunCorp ищет QA-инженеров: пройди интервью и получ..." - срок еще не вышел, до 3 мая. Дерзайте, попытайте силы на тестовом задании.
    Ответ написан
  • Как создать подобную отчетность Jira по багам? Или как ее улучшить?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Это похоже стандартная диаграмма/гаджет Two Dimensional Filter Statistics которую можно просто добавить на дешборд. Обычно, для диаграммы нужно сперва создать фильтр, на основе которого она будет отображать информацию. Вот ссылка на документацию
    Ответ написан
    Комментировать
  • Как правильно подойти к внедрению авто-тестов в проекте?

    lxsmkv
    @lxsmkv
    Test automation engineer
    брали людей из других команд на пару дней дабы быстро-быстро прогнать функционал что бы не сфейлиться на релизе.
    Исходя из этого могу предположить, что тестировали функционал через исследовательское тестирование по методу черной коробки. Значит вам нужно именно end-to-end тестирование.
    Раз проект для веба и без дополнительных трат, то очевидный ответ - Selenium. Про него написано-переписано и на конференциях рассказано тоннами. Selenium поддерживает несколько языков Java, C#, Ruby, Python. Самый низкий порог вхождения у Python. Почитать/посмотреть про page object pattern и вперед.
    Мне тут как-то на глаза попадался вполне достойный и даже бесплатный курс "Автоматизация тестирования с помощью Selenium и Python".
    На будущее, для диагноза затруднений возникающих в процессе внедрения автоматизации и нахождения возможных путей выхода из них на макро и микро уровне могу посоветовать этот ресурс - testautomationpatterns.org - одна из его создателей небезызвестная Dorothy Graham.
    Ответ написан
    Комментировать
  • Как написать скрипт под динамическую страницу в Load Runner?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Вообще не понимаю зачем брать инструмент для нагрузочного тестирования, когда нужно просто автоматизировать взаимодействие с веб страницей. Не приходилось им пользоваться, так что по самому инструменту ничем не помогу.
    Сам принцип довольно простой.
    Скрипт берет html страницы и выявляет в нем ней нужные элементы. A потом производит нужное действие в зависимости от того какие элементы нашлись. Если это input type=text - вводит в него значение "test", если это input type=radio то выбирает тот в котором значение самое длинное. Для парсинга html есть там всякиe библиотеки например beautifulsoup.
    Ответ написан
    Комментировать
  • Как простестировать игру на сайте?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Раз тестирование ручное, все 2 тысячи с плюсом не реально протестировать руками, это понятно. Я думаю предполагается, что вы обснуете выборку браузеров, осей и разрешений. Я бы посмотрел статистику по распространненности браузеров и плаформ и разрешений например тут, и взял бы самые рапространенные. Потом по методу pairwise выбрал бы комбинации. Причем предпочтение я бы отдавал мобильным платформам, потому что mobile first.

    Если делать регрессионное тестирование, то тут нужно уже пилить автоматизацию со сравнением снимков.
    Ответ написан
  • Как написать документацию для приложения?

    lxsmkv
    @lxsmkv
    Test automation engineer
    User story описывает цели которые могут быть достигнуты с помощью приложения. Они определяют пользу. Например, чтобы решить какую задачу выполнить сегодня, пользователь хочет определить самые приоритетные задачи. Польза приложения тут в помощи принятию решений по задачам. Тут нужно думать максимально с т.з конечного пользователя. Зачем он что-то делает и как продукт может помочь ему в этом.

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

    По юзкейсам можно проводить системное тестирование. Т.е. есть заявленный сценарий, работает он или нет.

    Функциональная спецификация определяет детально устройство приложения, с подробным описанием всех технических "если", и "а вдруг".

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    https://github.com/replit однако как это все собрать у себя на машине - понятия не имею.
    Ответ написан
    Комментировать
  • Можно ли где то найти ДатаСет по тестированию ПО?

    lxsmkv
    @lxsmkv
    Test automation engineer
    У вас уже есть сформированый тезис (непонятно откуда взявшийся), теперь вы хотите найти ему подтверждение на основе эмпирических данных? Это халтура, если честно, так научную работу не делают. Но название можно и переделать, а вот сама тема сложная, я бы даже сказал бесперспективная. Давайте разбираться.

    "Повышение экономической эффективности ПО" - эксплуатации или производства? Или того и другого? Что вы понимаете под эффективностью? Денежные затраты на производство? Трудозатраты? Можно сделать никому не нужное ПО которое будет очень качественным, но его польза будет равна нулю. Можно напичкать программу никому не нужными функциями и сделать их очень качественно. А можно сделать уникальный продукт, который будет пользоваться огромным спросом, не особо заморачиваясь о его качестве, и потом допиливать его по ходу распространения. Как тут будут обстоять дела с эффективностью? Сколько ПО выпускается в виде альфы или беты на рынок? Как у них дела с эффективностью? Вроде они на тестирование тратят меньше. Как это все посчитать?

    Да есть исследования (например The Economics of Unit Testing / M.Ellims J.Bridges & D.Ince), на scholar.google.com можно найти еще больше, там приводят кумулятивные данные нескольких фирм, сравнивают количество строк кода, количество дефектов найденное этими тестами. Но на вопрос об экономическом влиянии тестирования они не отвечают. В статье вообще денежными суммами не оперируют.

    Я вам так скажу, невозможно оценить пользу качества, цена качества вариируется от индивидуума к индивидууму. И критерии качества также вариируются. Оценка программного продукта конечным пользователем может оказаться очень разной. А то что продукт выпустили в полном соответствии со спецификацией и это доказано машинными проверками - ну и что? Это никому не интересно если этот продукт оказался невостребованным.

    Единственный подход к этой теме, если хотите связать это как-то с деньгами - это смотреть на издержки в связи с дефектами. А о таких жирных дефектах которые попали в газеты - масса статей. Только и тут по большому счету тупик - доказать безошибочность нетривиальной программы невозможно. Это следствие теоремы Райса. Т.е затраты на тестирование могут стремиться в бесконечность, но не найти ошибку которая погубит весь проект. Ну и как тут считать эффективность? Риски, вероятности, предположения, оценки, домыслы.
    Ответ написан
    Комментировать
  • Куда развиваться ручному тестировщику?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Можно развиваться тем что ты тестируешь более широкий спектр продуктов, (имеется ввиду именно разноплановость) - веб, мобильные, десктоп, игры, операционки, драйвера, железо, продукты.
    Можно развиваться беря на вооружение разные инструменты, для специфических тестировочных задач.
    Можно рассматривать другой пользовательский аспект продукта. Например тестировать на нагрузку, то что Вы сказали. Можно развивать аргументационные и логические навыки.

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

    Вообще, чтобы расширить свой горизонт, и начать более широко смотреть на свои возможности, рекомендую на ютубе записи Джеймсa Бах (James Bach). Все без исключения. Ну вот например ("A Context-Driven Approach to Automation in Testing"), для затравки видео с демками. Или вот ("Open Lecture by James Bach on Software Testing") - обзорная лекция, о том что такое тестирование. Я после нее заинтересовался тестированием и стал тестировщиком и вот уже 5 лет как тестировщик.
    Ответ написан
    Комментировать
  • В чем главные недостатки Test management system?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Я видел одну систему "нового типа", это HipTest, там шаги можно переиспользовать. В классических системах, ты просто пишешь/копипастишь текст. Такие системы не нужны, тогда можно и в ворде все хранить.
    Когда описания формализованы и имеют семантику, открываются новые возможности чтобы действительно управлять тестами, а не просто их складывать. Тогда ты можешь например ответить на вопрос, сколько тестов у нас проходят через этот экран. Сколько тестов у нас нажимают на эту кнопку. Я считаю, что смысл такой системы в этом. Давать новые возможности работы с данными. А не просто сделать хранилище текста, с аккаунтами, чтобы можно было распределять тексты и собирать галочки проставленные пользователями (тестировщиками). Или еще какие-то там красивые репорты из этого кроить. Т.е. понятно, что это тоже нужно, но не это главное в системе управления тестами. Не это отличает систему управления тестированием, от системы управления <чем-то другим>. Я считаю, что цифровые системы должны не просто быть компьютерной заменой бумаге, а расширять возможности человека. Позволять ему делать то, что ему раньше было не доступно. Тогда это оправдано. Например электронная книга дает возможность полного поиска по тексту, в то время как книги, в лучшем случае, ограничены предметным указателем.
    Ответ написан
    Комментировать
  • Как улучшить отдел тестирования?

    lxsmkv
    @lxsmkv
    Test automation engineer
    - На каких технологиях приложение?
    - Какая длина спринта?
    - Как у вас построен процесс написания кода и интеграции?
    - Сколько разработчиков?
    - Какие роли кроме разработчиков и тестировщиков еще есть на проекте?

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

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

    Во время проверки (тестирования) можно написать на этот сценарий приемочный тест. Так у вас потихоньку появятся автоматизированные тесты.

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

    Разработчики тоже должны тестировать. Тот кто пишет фичу Х проверят фичу Y и наоборот. Нельзя давать проверять свою собственную работу. Нужна культура качества и открытой коммуникации - чтобы разработчики не замалчивали замеченые проблемы, а открыто писали на них тикет.

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    это не сразу вскрывается

    Это вскрывается при первом выполнении тестов на старом билде, но с новой библиотекой.
    Ответ написан
    Комментировать
  • Как правильно создавать тест-кейсы для формы регистрации?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Если форма заполнена не полностью, то кнопка отправить должна быть неактивна.
    Если форма заполнена невалидными данными и/или неполностью - кнопка "Отправить" должна быть неактивна и неверно заполненые поля должны показывать подсказку.
    Для каждого поля нужно проверять, что разные ошибочные варианты ввода в это поле распознаются. Переполнение поля тоже.
    Если есть необязательные поля, нужно проверить, что их заполнение, незаполнение или неверное заполнение не влияет на результат. Если есть кнопки переключатели (radio buttons) можно проверить выставляется ли значение по умолчанию если должно или не выставляется если не должно. Бывает что выставляется хотя не должно.

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

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Бизнес-логика это механизм устройства системы, но нее ее графическое оформление.
    Бизнес-логика нацелена на воплощение бизнес процесса определенного спецификацией системы.
    "Бизнес-" она потому, что когда пользователь хочет получить "пользу" от системы и не может этого сделать - страдает бизнес.
    Она определяет внутреннее устройство системы.
    Ошибка в бизнес-логике может произрастать из неверной спецификации или неверной реализации.
    Ошибка в бизнес-логике (негативно) влияет на взаимодействие пользователя с системой.

    Если пользователь нажимает на кнопку, а та не реагирует - это бизнес-логика, потому что по "логике бизнеса" (читай: логика, определенная бизнесом), при ее нажатии должно происходить что-то.

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

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

    А вообще определение немного размытое.

    Технари часто понимают под бизнес-логикой т.н middleware.

    P.S. замените это слово на "функционал" или "функция" - будет лучше для всех.
    Ответ написан
    Комментировать
  • Работа тестировщиком не дает никаких полезных навыков в плане дальнейшего трудоустройства разрабочиком?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Если вы будете заниматься автоматизированным тестированием вам волей-неволей придется понимать устройство приложения. Хотя бы очень поверхностно. Чем лучше автоматизатор тем лучше его понимание устройства приложения. И тут все зависит от вас, станете вы интересоваться устройством приложения глубже или нет. Требовать от вас этого никто не станет. Будете интересоваться - через какое-то время сможете стать разработчиком.

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

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

    У меня сложилось впечатление, что вы хотите через тестирование попасть в разработку. Я бы не стал так делать. Так вы ни хорошим тестировщиком не станете, ни хорошим разработчиком. Я сознательно отказался от работы разработчиком, и остался автоматизатором. Потому что знаю как они работают, и мне иногда грустно. Стать еще одним производителем багов - нет спасибо. А у меня уникальные навыки. Я решаю интересные задачи. Я ковыряюсь в приложении, чтобы понять где к нему прицепиться, чтобы получить нужную информацию. Нормальные интерфейсы, к сожалению, порой не предусмотрены. Я постоянно тусуюсь с разработчиками. Мы обсуждаем баги и я иногда могу подсказать подход к их решению, могу помочь отфутболить баг, или если баг не наш, перенаправить его с нормальным комментарием. Могу зайти в бюро к разработчику и спросить почему баг еще не пофиксили, причем именно техническую причину, и понять ее. Могу прочитать лекцию разработчикам о том, что важно писать внятные коммит-мессаджи. Знаю как пользоваться Джирой. Например трансформировать баг в таск и наоборот. Знаю наши информационные системы. Могу подсказать как с помощью нашего интрумента тестирования продебажить трудно воспроизводимое состояние. Могу читать стектрейс и лог иприложения, и понимая как работает наша программа, обьяснить разработчику, что проблема наша, а не во фреймворке или где-то еще.

    Просто я тянусь к знаниям и не считаю себя умным и "все итак знающим".

    Можно конечно все время сидеть в бюро и добавлять n+1 тест в тестовый набор у уходить в 17 часов домой. От вас зависит.

    И по з/п я получаю больше чем некоторые наши разработчики, потому что навыки уникальные, кроме меня никто не хочет этим заниматься, и не знает как. Другое дело, что если я поменяю место работы то в сухом остатке у меня будет только опыт внедрения автоматизации и язык программирования. Но в разработчики я все равно не пойду. Для автоматизатора всегда открыт весь мир технологий, а для разработчика только те, на которых пишется программа.
    Ответ написан
  • Как с помощью Cypress отследить запрос на сервер ??

    lxsmkv
    @lxsmkv
    Test automation engineer
    В официальной документации вроде описано. Внизу есть и ссылка на пример реализации.

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