Ответы пользователя по тегу Тестирование ПО
  • Что выбрать джуниору: работать на стабильных проектах или одному ставить процесс тестирования на одном проекте?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Узнаю себя четыре года назад, тогда казалось щас будем двигать горы, ну или как минимум бурить тоннель. А оказалось мы на них будем взбираться. В шлепанцах.

    А горы все выше, а горы все круче, а горы уходят под самые тучи
    — Айболит

    Тест-менеджер, должен понимать специфику приложения, специфику проекта, чтобы принимать обоснованные решения.
    Я по своему опыту могу сказать видение того как нужно поставить процесс тестирования, как распорядиться человеческим ресурсом (и своим ресурсом в том числе) эффективно, приходит только через 3-5 лет. Только тогда избавляешься от крайностей и начинаешь видеть компромиссные решения. Только тогда начинаешь думать о стратегии тестирования. Потому что успел на своем опыте убедиться что работает а что нет. Где рамки возможного. Лучше начинаешь понимать психологию команды.
    И соответственно стратегия тестирования она для каждого проекта своя. А чтобы понять, что для этого проекта важно, нужно в нем повариться.
    И начинать нужно с низов. Вы должны побыть и программистом, и автотестером, и ручным тестировщиком, и девопсом немножко. Изучить продукт, и код достаточно, чтобы когда программист рассказывает, что в коде он сейчас меняет сразу было ясно какие три-четыре проверки на продукте нужно будет провести.

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Регрессии это нормальное явление. Почему такое происходит в принципе - интересный сам по себе вопрос.
    Регресс появляется когда добавление нового кода или изменение старого не учитывает всех задействованных частей программы.
    Отсюда можно сделать вывод, чтобы минимизировать эффект от регрессии, нужно огранизовывать код так, чтобы при его изменении, можно было легко понять, на какие другие части логики это изменение влияет. Именно это является целью создания идеальной архитектуры приложения. Чтобы все было по полочкам. Чтобы доставая из шкафа полотенце, вам на голову не падала матрешка которая стоит на шкафу сверху (кто ее туда поставил, и почему - неясно, записку с комментариями никто не оставил)
    Чтобы бороться с наваливанием кода в кучу - нужно чтобы кто-то следил за тем чтобы его не наваливали в кучу. Архитектор например. Архитектор это такой ландшафтный дизайнер для кода. Но нужен и садовник. Чтобы лужайки были зеленые, а огурцы не расли на грядке в перемешку с морковкой. Фреймворки конечно тоже отчасти справляются с этой задачей. Фреймворк для того в принципе и служит, чтобы для каждой части приложения была своя песочница. Мол, складывай вещи как хочешь но в коробки 40х50х30. Текстиль сюда, кухонную утварь сюда. Коробку подписать, занести в реестр. Как на складе.
    Но ничто не защитит вас от того, что в коробки накидают не того что там должно быть. Надо проверять (тестирование). Выстраивать процесс таким образом чтобы ошибиться по халатности было трудно (архитектура). Чтобы было легко локализовать источник ошибки (логгирование). Систематично избавляться от сложности во всем (здравый смысл).
    Ответ написан
    Комментировать
  • Оптимальный набор тест-кейсов для покрытия клиент-серверной части приложения?

    lxsmkv
    @lxsmkv
    Test automation engineer
    сервер для вас - черный ящик в данном случае. поэтому единственное место где можно проверить реакцию на стимул это клиент. Т.е. вы можете делать только end-to-end тесты. Но без возможности контроллировать сервер, многие сценарии проверить не удастся. Например, если сервер шлет оповещение клиенту за 15 минут до начала события (допустим это напоминалка). Чтобы прокрутить часы вперед и проверить срабатывание и обработку напоминания (напр. если мы заглушили оповещение оно не должно больше приходить) нужен доступ к серверу.
    С другой стороны, чтобы спроектировать тест сервер не нужен, тест проектируется в голове, а вот то, что его нельзя будет выполнить без специальных возможностей это нужно донести до заказчика.
    Ответ написан
    2 комментария
  • Как тестирование систему управления производством компьютерной графики?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Вы хотите проверить, что скрипт по заданным данным на выходе выдает ожидаемый результат? Это можно, посмотрите как сделаны регрессионные тесты для утилиты GraphViz dot https://github.com/ellson/MOTHBALLED-graphviz/tree... они делают прогон на тестовых файлах и сравнивают разницу с эталонными файлами.
    Писать автоматические проверки на работу всего пайплайна я бы не стал. Хотя и такое делается https://github.com/jenkinsci/JenkinsPipelineUnit
    И на докер можно тесты писать https://medium.com/@aelsabbahy/tutorial-how-to-tes...
    Все можно, но чем больше у вас кода тем больше необходимости тестировать тестирующие скрипты. А надо вкладывать силы в продукт, потому что продукт приносит деньги а не тонны тестировочного кода. Какой-то минимум проверок - да. Главное не увлекаться.
    Ответ написан
    Комментировать
  • Правильное тестирование Javascript?

    lxsmkv
    @lxsmkv
    Test automation engineer
    --
    Как перестать беспокоиться и начать писать тесты

    Задача тестов отвечать для Вас на вопросы. Совершенно неважно к какой вымышленной категории Вы эти тесты отнесете.
    Важно чтобы при проектировании теста Вы учитывали, что тест доказывает и чего он не доказывает либо не полностью доказывает. Какую информациою он Вам дает и какую не дает. На что он указывает и на что не указывает. У меня масса таких тестов про которые можно сказать "это не 100% гарантия, но лучше чем ничего".
    Чем меньше Вы будете беспокоиться о том, к какому типу относятся Ваши тесты, тем быстрее Вы начнете думать о том, а что же я хочу проверить и как я могу это проверить. И просто будете это проверять.

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

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Опять же тестирование это отдельная профессия

    Есть профессия - инженер. Инженер это человек кторый в состоянии обдумать все нюансы. Инженер и разработать может и спецификацию написать и протестировать.
    Если вам в мастерской меняют колеса, а на трассе у вас слетают болты - и монтажник скажет, мол "Ну, болты у вас не стандартные. Откуда мне было знать, что для них другой момент нужен. Надо было сразу сказать." (история из жизни)
    Тут сразу возникает возмущение, неправда ли? Мол, как же так, ты же мастер, или что.
    Так же заказчик отностися к исполнителю в IT - он ожидает качественной, профессиональной работы.
    Конечно заказчик хочет все дешево и быстро, но это задача профессионала, обьяснить ему, что входит в стоимость услуг, задать ему необходимые вопросы. Если вы заказываете вязку свитера, он должен быть полосатый, сине-белый, а вам делают полоски вдоль хотя вы рассчитывали на поперек - это чья проблема? Проблема исполнителя. Заказчик рассчитывает, на то, что его обо всех нюансах спросят. Оффициант когда принимает заказ на кофе спрашивает про сливки и сахар. Это профессиональная обязанность. И если принесут не то, что вы хотели, ваш заказ меняют за счет заведения. Без дискуссий.
    Фриланс тем и сложен, что исполнитель должен совмещать в себе несколько ролей.
    Ответ написан
    Комментировать
  • Как правильно составить тесткейсы?

    lxsmkv
    @lxsmkv
    Test automation engineer
    непонятно, как на 100% обеспечивать наличие имени у одного, и отсутствие у второго.
    Обычно для этого делают тестовые аккаунты. Но это не гарантирует проверку динамики. может получиться так что у старых пользователей без имени все норм, а у тех кто удалил имя - нет.

    Вообще подумайте, каким образом это условие может возникнуть, что имя у пользователя отсутсвует. (Я думаю - он его стер, он его не задал при создании аккаунта) Но может есть еще какие-то способы.
    Тогда это будет просто одним из ожиданий тестов в разделе "изменение данных пользователя" и "создание пользовательского аккаунта"
    Ответ написан
    3 комментария
  • Написать тест jsapi для корзины товаров?

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

    Если вы подозреваете торможение на определенном участке то нужно замерять его.
    Можно конечно сделать тест на селениуме, который будет выбирать и добавлять в корзину продукты, и перезагружать страницу и мерять сколько длилась загрузка.
    Но если вы просто хотите определить узкое место, автоматизация тут не нужна, такой эксперимент будет быстрее сделать руками.
    Ответ написан
    1 комментарий
  • На каком языке пишут скрипты в QA?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Для всех основных языков есть драйвера/обертки/библиотеки/API для работы с базами данных и для отправки SQL запросов. Автоматизированные тесты часто пишут на скриптовых языках, они гибче и легче в изучении. (bash и powershell хоть и тоже скриптовые языки, имхо не легки в изучении. Это уже из области системного программирования)
    Если система на фреймворке, то на сайте фреймворка есть как правило документация как проводить юнит-тестирование для этого фреймворка.
    Когда говорят умение писать скрипты, я думаю подразумевают, что разработчик в имеет опыт с одним из ходовых скриптовых языков (php, python, ruby, groovy, js) и за короткое время (недели три-четыре) в состоянии изучить любой другой, на достаточном для выполнения задач уровне. Для человека с опытом программирования это как правило не проблема. Детали синтаксиса всегда можно в документации посмотреть.
    Ответ написан
    Комментировать
  • Можно ли считать профиль в Windows как отдельную среду для работы?

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    (до этого ее тестировать нельзя)

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    Тест - это действие направленное на получение информации о системе.
    Ручной тестировщик получает эту информацию вручную, автоматизатор с помощью компьютерных программ.
    Почитать на первых порах рекомендую "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах" Романа Савина.
    Ответ написан
    1 комментарий
  • Тестирование и поиск багов в на сайтах?

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

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

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

    Однако в случае если при тестировании входа выяснится что дверной замок не работает, то включить дверной замок для теста не получится, и второй тест скажет что мол замок двери открылся, все хорошо, однако на самом деле замок был все время открыт, потому что неработал. (т.н. false positive)
    Ответ написан
    6 комментариев
  • Курсы по QA для нуба?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Наталья Руколь - ищите ее доклады на ютубе и текстовые материалы в интернете.
    Ответ написан
    Комментировать
  • Где найти аудиторию для beta-test?

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    думаю можно попробовать детективы. Дедукция, логическое мышление, эвристика, должно быть близко любому тестировщику.
    ну или подкасты по qa radio-qa.com
    Еще вот могу порекомендовать книжку, независимо от контекста поездки.
    Тайити Оно. Производственная система Тойоты. Уходя от массового производства.
    Считаю, что в дороге важнее чтобы чтец был хороший. А что слушать все равно. Кстати из художественной (может и моветон, но) Лукьяненко Черновик, Чистовик, Спектр - (это приключенческие детективы, хорошо начитаные, о других мирах, и Лукьяненко умеет классно развернуть интригу, и заставить задуматься)
    Ответ написан
    Комментировать
  • Какие есть программы для автоматического тестирования форм?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Ответ написан
    Комментировать
  • Тестирование ПО с использованием OpenGL?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Самое нудное решение часто бывает верным, потому что чудес не бывает :)
    Вы просто когда все системы настроите и проапдейтите, сделайте копию диска, чтобы после настроек-перенастроек можно было тупо откатиться назад на чистую инсталляцию. И одну копию сделайте сейчас, чтобы вернуть все обратно после экспериментов.

    Как вариант, попробуйте Hyper-V.
    Ответ написан
    Комментировать