AltUnity Tester - это инструмент автоматизации тестирования на основе пользовательского интерфейса с открытым исходным кодом, который помогает находить объекты в вашей игре Unity и взаимодействовать с ними с помощью тестов, написанных на C #, Python или Java.
Почему не стоит говорить об "аудитории MOBA", "основных геймерах", "женщинах-геймерах", а лучше мыслить менее масштабно.
Одним из распространенных заблуждений, порожденных общедоступными исследованиями, является предполагаемая популярность определенных игровых жанров.
Совсем недавно передо мной встала очень на вид простая задача - выбрать для небольшой компании (28 человек) систему управления тест кейсами. Поручили мне эту задачу в силу того, что в компании я пока один единственный тестировщик, а если правильнее и точнее сказать, то QA-engineer.
Итак, приступим, первое с чего стоит начать - это скорее всего Ютуб, посмотрим как работают большие компании, кто и что говорит о той или иной системе, почитаем статьи на Хабре, что и вам советую сделать, несмотря на подобные статьи, как эта.
Рост и развитие IT-сферы происходит очень быстро — нагрузка растет, команды становятся многочисленнее, задачи усложняются. Для обеспечения темпа работы при высоких требованиях к качеству необходимо формировать особую IT-инфраструктуру и привлекать современные удобные инструменты, способные при этом подстроиться под запросы конкретной QA-команды.
Мы снова провели срез-анализ рынка старых и новых TMS-решений, выбрали основные функции, которые хотели бы видеть в системах управления тестированием, сравнили их возможности и цены. Не было цели составить рейтинг, так как у каждого инструмента есть свои плюсы и минусы. Делимся свежим списком тулзов для тест-менеджмента, один из которых точно вам подойдёт.
Привет, Хабр! Меня зовут Сергей Радченко, и мы с командой профессионально занимаемся тестированием уже несколько лет. Сегодня я посчитал количество автотестов, которые мы подготовили для веб-интерфейсов, десктопных приложений, API, систем двухфакторной авторизации и так далее (их оказалось более 5000). И мне захотелось рассказать о нашем опыте создания экосистемы для автоматизированного тестирования. В этом посте вы найдете описание полезных для комплексного тестирования фреймворков, а также исходный код некоторых дополнительных методов, которые мы дописали самостоятельно, чтобы написание тестов происходило быстрее, и тестирование приносило больше пользы.
Конференция по тестированию Heisenbug грядет: до старта осталось меньше месяца. В программу вносят последние штрихи, поэтому уже можем рассказать Хабру, какие доклады в неё попали.
Будут полюбившиеся зрителям спикеры, работающие над популярными инструментами: Артем Ерошенко (автор Allure Framework), Андрей Лушников (занимается Playwright), Олег Ненашев (из команды Jenkins).
Будут и совершенно новые темы. Например, впервые на Heisenbug поговорят о тестировании Flutter-приложений и умных девайсов. Более того, речь зайдёт даже о беспилотных автомобилях и экзоскелетах!
А помимо обычных докладов, пройдёт ряд воркшопов, где на экране вместо теоретических слайдов будет происходить сплошная практика.
Для хабрапоста мы разбили полный список докладов на тематические блоки — так что можете выбрать интересное вам и перейти к нему.
Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.
Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.
Для тех, кто хочет войти в профессию
В 1947-м 9 сентября зарегистрировали первый баг в истории IT. Это было забавно: Гарвард, учёные тестируют вычислительную машину Mark II Aiken Relay Calculator и вдруг видят застрявшего между контактами электромеханического реле мотылька. «Bug» (англ. «жук»)! — сказала Грейс Хоппер, одна из первых писавшая программы для предыдущей версии гарвардской ЭВМ Mark I. Уснувшее навеки насекомое извлекли из реле и вклеили в технический дневник, сопроводив надписью: «First actual case of bug being found (первый случай в практике, когда был обнаружен жучок)». Так багами стали называть ошибки в программах, а процесс их исправления — debugging (отладка). И так 9 сентября стало Днём тестировщика.
Ошибки допускают все, это нормально. Но их нужно разбирать и принимать решения по их недопущению. Это и называется учится на ошибках. А обеспечение качества - это учиться на чужих ошибках.
В этом посте узнаешь про распространённые ошибки, какие повстречал, как их увидеть, как с ними бороться и к чему приводит их допущение.
Меня зовут Дмитрий, я специалист по тестированию в студии IT Territory. За 17 лет мы выпустили более 15 успешных игровых проектов с общей аудиторией около 100 млн игроков по всему миру. Вы можете быть знакомы с нами по таким проектам, как Аллоды Онлайн, Hawk, Space Justice, World Above, Rush Royale. И в этом посте я расскажу о том, как мы проводим нагрузочное тестирование игровых серверов.
Локализация видеоигр (как и любой другой аспект разработки) хорошо описывается волшебным треугольником тройственной ограниченности: цена — время — качество.
Чтобы локализация была дешевой, нужно пожертвовать скоростью (понадобится много времени) или качеством (хороший перевод стоит дороже).
А если хотите получить высокое качество, то это будет либо дорого, либо очень долго.
Чтобы локализация была выполнена быстро, придется жертвовать качеством либо платить больше. (В зависимости от того, насколько сжатые сроки и сколько людей задействовано, может получиться, что вы и заплатите намного больше, и потеряете в качестве!)
В общем, смысл понятен.
Мне слишком часто приходится видеть, как разработчики привлекают к работе над локализацией игры волонтеров из «сообщества»: они хотят, чтобы локализация была дешевой и быстрой и думают, что если исходный английский текст написан хорошо, то и качество перевода будет высоким. Так же?
Ну… вообще-то нет.
Привет, меня зовут Евгений. Я младший разработчик компании Aigrind. Сейчас я работаю в команде новой мобильной MMORPG Skylore.
Разработка игры в жанре MMORPG — сложный и трудоемкий процесс. В таких играх много механик, которые зачастую наслаиваются друг на друга. Изменения в одной части игры могут выстрелить в совершенно другой.
Так, в нашей игре сотни квестов, и каждый из них нужно тестировать. Например, удалили моба с локации, а после теста оказалось, что он был нужен в середине сюжетной цепочки квестов. Для таких случаев можно нанять армию QA, которые будут каждый день вдоль и поперек проверять все квесты в игре. А можно переложить тестирование квестов на ботов!
Каждый тестировщик в моем окружении хоть раз попадал в ситуацию, когда на проекте требуется построить процесс с нуля. Многие наверняка задавались вопросом «С чего начать?». За последние 5 лет у меня было несколько проектов с таким опытом в разных студиях.
Что же делать? Нужно найти точку опоры, исходя из которой можно понять какой процесс подойдет. Для меня этой точкой опоры стали проблемы мобильных игровых проектов на ранней стадии разработки. В этом материале разберем самые основные и постараемся найти для них решение.
За что мы любим обучение в онлайне? За удобство и свободу учиться где угодно и когда угодно. За воплощение концепции life-long learning. А еще за технологичность. Сегодня мой рассказ о том, как используются технологии ИИ в работе крупнейшей в Европе онлайн-платформы обучения детей английскому языку Novakid.
Оцениваем
Начав изучать что-то новое, рано или поздно человек спрашивает себя: «Какого прогресса я добился?». В нашем случае этим вопросом задаются родители учеников: в Novakid учатся дети и подростки. Их интерес закономерен вдвойне. Для родителей результаты ребенка – главная метрика оправданности инвестиций в обучение.
На платформе Novakid прогресс каждого ученика измеряет ML-система и оценка строится на основе 1 500 микронавыков. Параметрический анализ учитывает даже мельчайшие детали. Например, насколько свободно ребенок овладел той или иной грамматической конструкцией.
Здесь может возникнуть вопрос о роли преподавателей. Они, конечно ставят оценки - после прохождения блока занятий или курса. В зависимости от того, как педагог оценил ту или иную компетенцию (Speaking, Reading, Grammar и тд.) ребенку назначают дополнительные упражнения и занятия. То есть вместо школьной 5-балльной шкалы оценка, наоборот, происходит незаметно для ученика (stress free) и показывает, "освоил" он материал, или "нужно еще поработать".
Почему это важно? Во-первых, учитель – тоже человек и может ошибиться. Во-вторых, на объективность оценки может повлиять плохое настроение ребенка. Наконец, на уроках иногда меняются учителя. Кто-то из детей моментально адаптируется к новому преподавателю, а кому-то нужно больше времени для налаживания доверительного контакта.
Привет! Меня зовут Ольга Ермолаева. Я работаю в тестировании с 2008 года. Сейчас руковожу департаментом качества в компании «Инттерра» и помогаю студентам на курсе для тестировщиков в Яндекс.Практикуме в качестве наставника.
Все, кто работает в IT-сфере, когда-то задавались вопросом, как найти первую работу. Ведь все работодатели требуют опыт, но никто не говорит, где его взять.
Начинающие программисты пишут свои pet-проекты, выкладывают на Github и добавляют ссылку в портфолио. Дизайнеры могут показать свою страницу на Behance или Dribble. Но что делать начинающим тестировщикам?
Можно пойти на платные курсы и приобрести учебный опыт, но его не всегда бывает достаточно для получения желаемой работы. Можно самому писать тестовую документацию, проводить тестирования, оформлять баги, но не факт, что итог будет приемлемого качества, потому что нет обратной связи.
В статье я поделюсь с вами одним из вариантов решения этой проблемы.
Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.
Важно выстроить процесс работы с автотестами, требующими поддержки и особенно с нестабильными(flacky) тестами. Если сразу не уделять должного внимание к автотестам доверие к ним упадет и в конечном итоге упавшие тесты будут полностью игнорироваться
Обычно мы делаем это так:
С ростом проекта и функциональности ПО неизбежно увеличивается объем регрессионного тестирования, хотя сроки зачастую остаются прежними. Как при этом грамотно преодолеть сложности на Scrum-проектах? Читайте в нашей статье.
