• Как решить задачу о рюкзаке 0-1 (ее разновидность)?

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

    Перефразирую задачу:

    Допустим, у вас всего в наличии N предметов, a рюкзак должен быть укомплектован К предметами, причем К<=N. Нужно выбрать такую комплектацию, чтобы общий вес не превышал максимально допустимый и общая ценность предметов была наиболее высокой.


    Предлагаю Вам решение "в лоб":

    Создайте список всех сочетаний K над N (для комбинаторных рассчетов есть специальные библиотеки для большинства языков программирования). Для каждого сочетания рассчитайте его вес и уберите те сочетания которые превышают ограничение по весу. Оставшиееся сочетания отосортируйте по убыванию ценности и возьмите самые верхние.
    Ответ написан
  • А почему все блоки питания с разным значение вольт не делают с максимальным значением ампер?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Я вот совсем физику плохо в школе учил, но мне кажется чем выше сила тока тем больше нагревается проводник и тем больше потери энергии.
    Ответ написан
  • Код с комментариями - избыточность?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Это просто кровавый энтерпрайз. У нас тоже так. У нас разрабы сразу говорят: "Не пытайся понять все это сразу, тебе понадобится минимум полгода чтобы понять и освоить устройство приложения и его частей [на таком уровне, чтобы работать автономно]."
    Вам нужно больше задавать вопосов коллегам. Вы не успеете умереть от стыда - вопросы кончатся быстрее:)
    Как молвит японская поговорка: "Спросить - позор на один раз. Не знать - позор на всю жизнь".
    У нас например один из архитекторов добровольно сделал курс обзорных презентаций (3 раза по часу) по архитектуре приложения и это здорово помогло. Спросите тимлида, может он подговорит какого-нибудь опытного программиста или архитектора на такое доброе дело. Все понимают что новичкам надо помогать. Но сами по себе они не бросят все, чтобы заполнять ваши пробелы. Но все без проблем поделятся опытом. Это же для любого человека приятно - показать свои знания. Так что вы не бойтесь, они только на вид такие неприступные. Сядьте рядом с каким нибудь особенно разговорчивым и веселым коллегой. Он вам будет потихоньку все обьяснять. Посмотрите как он анализирует баги, и задавайте вопросы, это много дает. Никто не ожидает что от вас на первых порах будет много пользы. Так что не переживайте. Но все оценят если вы будете быстро впитывать полученные знания. У нас некоторые новички за 3 месяца освоились а некоторые и за год не в зуб коленом.
    Ответ написан
  • Регрессионное тестирование: как проводить?

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    у вас "#answer1" ".error1" "#q1" все - строки, создавайте их конкатенацией с индексом, как-то так "#answer"+i.toString(); и.т.д а потом вставляйте в скобки.
    Ответ написан
  • Как развиваться в программировании не привязываясь к языку?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Как писать бестселлеры не привязываясь к языку. Нет, не получится. У каждого языка своя парадигма, свой менталитет. Читать много. То что понравится брать на заметку. Читать про сами языки, как они возникли, какие проблемы они хотели решить когда были созданы. Какие возможности эти языки предлагают, читать сравнительные статьи, холивары даже. Читать код всяких библиотек и sdk. Он обычно написан опытными программистами.
    Изучатъ историю становления компьютерных вычислений как дисциплины. Пробовать разные языки, хотя бы на уровне базовых туториалов. Про паттерны почитайте. Например www.gameprogrammingpatterns.com - там рассматриваются некоторые в контексте разработки игр. В контексте игростроя вообще концепции легче воспринимаются, это область применения которая понятна и знакома практически любому человеку. Так же, например если хочешь получить практические навыки в автоматизации, нет ничего лучше чем начать с написания игровых ботов. Игры такой контекст который задействует практически все технологии и области компьютерных знаний.
    Ответ написан
  • Как автоматизировать общение с клиентами?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Возможно чат-бот не решит вашу проблему.
    Почитайте обязательно это:
    Эпик-фейлы в онлайн-чатах, или почему продажи не растут
    Если бездумно впилить чат-бота то у вас станет одной проблемой больше. Клиенты станут уходит еще и потому что нет личного контакта, а от бота кроме стандартных чаще всего бесполезных ответов ничего не добьешься.

    Вполне вероятно, что вы пытаетесь решить не ту проблему. Проблема в том. что количество запросов возрасло - нужно понять почему. Может недостаточные описания на сайте? Может часто отправляют не то что заказывали. Оптимизировать нужно иммено в узком месте.
    Почитайте про теорию ограничений. Хотя бы эту одну статью:

    Как теория ограничений помогает зарабатывать больш...

    В любом случае, сначала займитесь анализом - сгруппируйте темы запросов в кластеры.
    Ответ написан
  • Позитивный тест кейс, как?

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

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

    Грамматические ошибки это негативное качество. Репортить конечно. Тут у вас хоть будет на что сослаться, есть Правила Русского Языка ;-).

    Вот это видео посмотрите, доходчиво обьяснено про классы эквивалентноси и граничные значения.
    Разработка тест кейсов по методике Pair wise. Ники...

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

    По плану тестирования (навскидку, подробности додумаете сами):
    Общее:
    • Нужно проверить все статичные ссылки. Можно написать для этого автоматизацию.
    • Проверить грамматику и содержание (что в тексты не закопипастили по ошибке ерунду)
    Функциoнальные области я бы разделил на категории, например:
    1. Управление учетной записью
      1. Регистрация
      2. Вход
      3. Смена пароля
      4. Восстановление пароля.
      5. Удаление

    2. Управление списками дел
      1. Добавление (списка или задачи)
      2. Просмотр
      3. Удаление
      4. Изменение


    и т.д. каждый подпункт будет иметь множество тесткейсов .т.е то что нужно проверить при .. смене пароля, удалении элемента списка и.т.д.

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    библиотека для работы с rest api yandex disk https://pypi.python.org/pypi/yadisk она и поновее будет. наверное ее сами разрабы саппортят.
    Ответ написан
  • Полезно ли при обучении изобретать велосипеды?

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

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

    Автоматизация актуальна всегда. Автоматизация тестирования будет актуальна пока актуально тестирование. А оно становится актуальнее с каждым днем. Сложность приложений растет, качество приложений падает. Без автоматизации проверок человек просто будет не в состоянии проверить приложение в достаточном обьеме.
    Вот у нас около 800 UI тестов которые катают на 20 разных вариантах сборки. Человек не может за день сделать 16 тысяч проверок. Я проверяю результаты автоматизации, и завожу баги, в 5-10 раз чаще/больше чем ручные тестировщики. И это несмотря на то, что для автоматизации были выбраны самые незамысловатые сценарии.
    А в свободное время я могу вручную тестировать интересные сценарии. И находить неочевидные ошибки. A желающих заниматься автоматизацией не так уж и много. Так что вы будете всегда уникальным специалистом.
    Ответ написан
  • Что выбрать джуниору: работать на стабильных проектах или одному ставить процесс тестирования на одном проекте?

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

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

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

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

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

    lxsmkv
    @lxsmkv
    Test automation engineer
    https://www.artlebedev.ru/everything/process/
    тут студия Лебедева рассказывает как создаются их продукты, от задачи к решению, с картинками.
    А еще на главной странице можно выбрать любой представленный продукт и там прочитать секцию "процесс".
    Ответ написан
  • Болезнь творца или как создать свой виртуальный мир?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Вот инструмент для разработки игр и десктопных программ на PHP develnext.org/ru
    Начните с написания диздока. В нем кроме всего прочего описана механика игры в мельчайших подробностях. Без него вы закопаетесь в коде по уши и никогда не закончите свой проект.
    Насчет клона игры Жизнь для разминки, тоже согласен. Чтобы понять как работает подобная симуляция.
    Сложность на мой взгляд в императивном описании поведения каждого агента и мира.
    Хотите поэкспериментировать с агентным моделированием, попробуйте NetLogo.
    Ответ написан
  • Как перейти от стадии знания тегов к успешной верстке?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Смотреть как сверстаны чужие страницы, например. Ну и постоянно спрашивать Яндекс "как верстать сайты", там весь интернет этим завален.
    Знание тегов это как знание назначения карандаша, красок и кисточки. Рисовать все равно надо учиться. Это процесс. И как в любом обучении быстрых путей нет. Можно быстро что-то сделать но научиться быстро чему-то нельзя. Я могу сделать яичницу, но чтобы научиться ее делать нужно посвятить этому куда больше времени чем я этому посвящаю. Так вот нужно ответить себе на вопрос, вам хочется быстрых результатов или вы хотите этому научиться, то есть посвятить этому часть своей жизни.

    Когда я увлекался веб программированием, я мастерил маленькие финтифлюшки в онлайн редакторах типа jsfiddle и jsbin. Нужно постоянно решать какие-то задачи, только так нарабатываются навыки. Тренировка называется. И нужно доводить до конца. Что значит не выходит? Просто оно еще не готово. Делайте, продолжайте трудиться над этой конкретной задачей, и получится. Только когда вы одолеете свою задачу вы чему-то научитесь. Я повторюсь: быстрых путей нет.
    Ну и важно, чтобы это вам было действительно интересно. Если предмет интересен, ты готов читать о нем и исследовать его весь день. А это положительно сказывается на результате. Вот такой секрет.
    Ответ написан
  • Какие тесты на каких этапах развития проекта наиболее важны?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Да там все в кучу свалено: тормоз, фара, водитель, права, дорожный знак. Все понятия относящиеся к вождению индивидуального транспортного средства. Бррр..

    Есть подходы к тестированию (парадигмы, напр. TDD), есть методики для систематического подхода к покрытию тестами (pairwise, boundary). Есть разделение по стадиям разработки (alpha, beta). Категоризировать и писать определения можно сколько угодно.
    Вам нужно проверять работоспособность приложения на регулярной основе. Это, как правило, юнит тесты на сам код, и функциональные тесты на приложение (эмуляция пользователя). Функциональный от слова проверка функции фичи.
    Это обеспечивает какую-то степень распознавания регрессий. Ревью кода - тоже тестирование. И когда Вы запускаете программу чтобы убедиться, что то, что Вы написали работает - тоже тестирование. Только вы знаете какие проверки Вам нужнее всего.
    Ответье себе на вопрос: "В чем вы хотите каждый день, после каждой сборки, после каждого коммита, быть уверены?" Не надо писать тесты только потому, что все так делают. Надо понять какая Вам от них польза. И все встанет на свои места.
    Ведь проблема в чем, приложение растет, и со временем разработчик тестирует только ту часть приложения которую только что написал. А все старое перепроверяется гораздо реже. Так вот автоматизация при систематичном ее применении может Вам в этом помочь.
    Ответ написан