Ответы пользователя по тегу Тестирование ПО
  • Можно ли где то найти ДатаСет по тестированию ПО?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    lxsmkv
    @lxsmkv
    Test automation developer
    Негативные тесты это проверка на то, что приложение справляется с непредусмотренными ситуациями ожидаемым образом.

    Позитивный тест
    Дано: первое слагаемое равно 1
    и дано: второе слагаемое равно 3
    если мы производим операцию сложения данных чисел
    тогдарезультат будет равен 4

    Вот несколько примеров негативных тестов

    Дано: первое слагаемое равно 1.0
    и дано: второе слагаемое равно 3
    если: мы производим операцию сложения данных чисел
    тогда: будет выведена ошибка несоответствия числовых типов

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

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

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

    lxsmkv
    @lxsmkv
    Test automation developer
    В принципе все правильно. Берете и делаете. Серебрянной пули нет.

    Особенно порадовало, что "все занимаются тестированием"- это правильно. Лишь бы это не было "все - значит никто". И следите за тем, чтобы тестирование давало результат - либо тикет в системе либо фикс. Если баги находят, но просто говорят о них на кухне - это не тестирование. Если баг фиксится сразу, это не значит что коммит-сообщение можно ляпнуть "fixed some strange bug" - он должен содержать описание сценария в котором он происходит и как он влияет на пользователя.

    Улучшайте коммит-сообщения. Так чтобы из них можно было собрать патчноут и красиво показать пользователю. А не куча невнятного "внутряка". Формулируйте с позиции пользы, это заставит разработчиков немного больше гордиться проделанной работой, а следовательно добавит им мотивации. Для примера посмотрите как пишут патчноуты передовые представители игровой индустрии.

    По автоматизации .. подводные камни такие:
    - если автотестов много - их долго выполнять. Начните с небольшого количества 20-50. На них вы обкатаете внедрение и процесс. Не считайте никакие ROI - это бред. Чем считать ROI лучше написать еще один полезный тест.
    - архитектуру тестов старайтесь организовать так, чтобы работу по их написанию можно было распараллелить. Например если у Вас Page Object - один может писать компоненты из которых другой может строить сценарии.
    - ваш сервис сильно зависит от доступности источников данных - проверяйте доступность источников регулярно, особенно если эти данные вы получаете не по API, а выковыриваете парсером.
    - сделать тестовую базу данных - правильно. Автоматизируйте ее свертывание-развертывание через контейнеры.
    - по приоритетам автоматизации - точно так же - по "абстрактной" значимости. Хороший источник для идей - багтрекер. Кластеризуйте ошибки по типам и делайте выводы.
    - не делайте автоматизацию ради автоматизации - в первую очередь чините продукт, потом тесты.
    - не усложняйте тесты ради того чтобы они справлялись с более сложными условиями, упрощайте условия.
    - автотесты будут сыпаться по непонятным причинам. Делайте как можно более полезное логгирование. Если тесты выполняются в произвольном порядке - это тоже может быть одной из причин. Любой рандом в тестировании - зло. Учитывайте это при наполнении тестовой базы данных. Желательно, чтобы тестовая база всегда содержала одинаковые данные. Смотря что у Вас за база. Если это только пользователи это одно, а если у вас там хранятся аггрегированные данные, то нужно время от времени пересобирать тестовую базу из свежих источников и проверять работу тестировочных скриптов с ней.
    - автоматизацию тестирования можно применять не только для тестирования конечного продукта, можно тестировать миграции схемы базы данных, восстановление базы из бекапа и прочее.

    Можете почитать мои ответы по этому хабу, может найдете там еще ответы на какие-то близкие Вам вопросы.
    Вот некоторые из моих советов-ответов более-менее общей направленности:

    Как добиться независимости в тестах (phpunit)?
    Правильное тестирование Javascript?
    Как систематически подойти к тестированию в малой компании разработчиков?
    С чего начать изучение на должность QA автоматизатора?
    Как создать отдел тестирования?
    Какие шаги тестирования сайта?

    Читайте:
    "Lessons Learned in Software Testing" (Kaner, Bach, Pettichord)
    "Experiences of Test Automation: Case Studies of Software Test Automation" (Graham, Fewster)
    и вот эту вики: TestAutomationPatterns (Кстати, ее инициатор и редактор та же Dorothy Graham. Есть даже пару записей ее лекций на ютубе - советую глянуть)
    В ней прям шаблоны. Проблема - решение. Бесценная вещь. Мне в свое время очень помогло, чтобы понять "что не так" и как это лечить.
    Ответ написан
  • Как найти тест, не подчищающий за собой?

    lxsmkv
    @lxsmkv
    Test automation developer
    Можно в процедуру удаления фикстуры вставить специальное лог сообщение и искать в логе. Если сообщение должно выводиться перед окончанием теста, то фильтровать на окончание теста плюс сколько-то строк сверху. LogЕxpert такое умеет делать. Или просканировать весь лог скриптом, и определить для каждого теста, было ли выведено специальное сообщение.
    Ответ написан
  • Дают ли тестировщики/инженеры по автоматизации оценку трудозатрат?

    lxsmkv
    @lxsmkv
    Test automation developer
    У нас заказчик спрашивал сколько мы можем писать автоматизированных тестов в неделю. Я делал прикидку по методу Guesstimation. Сам составил формулу расчета, с временными затратами на поддержку, проверку резулътата, заведение багов, проверку фиксов. Временные оценки, на каждую такую деятельность из которой строится автоматизация, брал на глаз, по опыту. Потом получается какая-то цифра. Если цифра не нравится, то можно крутить параметрами временной оценки. Но формула важна. Из чего состоит ваша работа. А она как правило комплексная.
    На выходе получился нижний "физический" лимит процесса. Т.е. столько - свободно можем выдавать, но может и больше. На практике получилось в среднем в два раза больше. Но зато мы выполняем и перевыполняем свои обещания.
    Ответ написан
  • Реально в 36-40 лет стать тестировщиком или программистом если есть свободное время?

    lxsmkv
    @lxsmkv
    Test automation developer
    У меня диплом экономиста. Поступал в свое время на информатику, но не потянул. С экономическим после универа никуда без блата не устроишься. Друг посоветовал попробуй тестировщиком. А я по жизни люблю возиться с компьютером и пробовать всякие штуки. Почему бы не делать это за деньги? Взяли автоматизатором. Нужно было человека на проекте заменить, который этим на полставки занимался, чтобы его вернуть в другой проект. Стечение обстоятельств. Прошло четыре года, и я из "никого" стал мидлом с перспективой до сениора. Начинал с зарплаты в два раза ниже среднего. Целенаправленным, качественным, трудом добился зарплаты средней, даже выше чем у некоторых наших девелоперов, и уважения коллектива и клиента. Хотя, надо сказать что с программированием я познакомился уже в пять лет, на бейсике и ZX Spectrum.

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

    В любом случае вы ничего не потеряете если попробуете. Новые знания никогда не лишние. Я в свое время интересовался фотографией, а еще до того дизайном - все пригодилось.
    Ответ написан
  • Как в CMS/Битрикс 24 автоматизировать проверку работоспособности доработок после обновления?

    lxsmkv
    @lxsmkv
    Test automation developer
    Короткий ответ - писать UI тесты.
    Для этого чаще всего пользуются Selenium. Но нужно будет программировать, на яве, питоне или руби.
    Есть решения где программировать надо по минимуму. Но такие инструменты могут быть не бесплатными.
    Вот небольшая выборка таких. Ничего конкретно из них порекомендовать не могу - не пользуюсь. Пробуйте.
    https://www.katalon.com/katalon-studio/
    https://www.testcraft.io/
    https://www.froglogic.com/squish/
    https://www.leapwork.com/technology/web-automation
    https://testcafe.devexpress.com/
    https://www.cypress.io/
    https://endtest.io/
    https://experitest.com/cross-browser-testing/visua...
    https://screener.io/
    Ответ написан
  • Как натренировать тестировщика?

    lxsmkv
    @lxsmkv
    Test automation developer
    Я вам расскажу про среднестатистических тестировщиков. Не про талантливых, а про обыкновенных.

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

    Если тестировщик никак не проявляет инициативы - тоже плохо.

    Спрашиваешь тестировщика:
    - Чем ты сегодня занимался?
    - Тестировал.
    - Что тестировал?
    - Все тестировал.

    яркий пример того, что тестировщик не понимает, что его продукт - информация. Или ему вообще не обьяснили чего от него хотят. Проблема скорее руководителя.

    Если тестировщик не производит информации - он бесполезен.

    Еще нельзя тестировщиков сажать в отдельное помещение. В изоляции они будут неэффективно работать.

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

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

    Чем чаще вы будете оставлять тестировщика "за бортом" тем менее эффективно он будет работать.

    Нужно чтобы тестировщик чувствовал свою отвественность за продукт. Для этого он должен быть частью команды. Чем больше отвестственности вы возложите на тестировщика тем быстрее он вырастет. Будете относиться к нему как к чуваку для мебели - он таким и станет.
    Если вы не знаете, что хотите от тестировщика - то он не знает тем более. Разработчик без задания тоже не знает что делать. Нужно поставить тестировщикам задачи. И желательно с письменной отчетностью. Скажу вам сразу это все не так просто, и дополнительная работа для руководителя. Но можно взять тест-менеджера. Он знает как использовать тестировщиков эффективно. Как поставить отчетность и пр.

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

    Если вы не знаете какие задачи поручить тестировщику - решите этот вопрос в первую очередь.

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

    Подведем итог: чем конкретнее задача поставленная тестировщику - тем (внезапно) больше пользы от его работы.
    Ответ написан
  • Почему восстановливаются покупки в приложении iOS?

    lxsmkv
    @lxsmkv
    Test automation developer
    скорее всего все действия с корзиной сохраняются в аккаунте пользователя. клиент(приложение) обычно только отображает состояние в базе данных. если вы каждый раз создаете нового пользователя, то может быть что в режиме песочницы у тестового пользователя одна таблица. одна для всех. это так, гипотезы как такое может быть. а в чем дело узнатъ можно только у разработчиков
    Ответ написан
  • Как прокачивать навык управления процессами?

    lxsmkv
    @lxsmkv
    Test automation developer
    Элияху Голдрат: "Цель".
    Тайити Оно: "Производственная система Тойоты. Уходя от массового производства"
    Ответ написан