Если честно, динамика улучшения тестирования и процессов разработки радует, но мобайл - все еще большой бардак...
Искомая статья начинается на 24 странице. Очень хорошо расписаны проблемы методологий разработки и тестирования - после прочтения появится большое количество точек обсуждения обсуждения с лидами разработки и тестирования.
2. Видео по разработке UI для магазина. Отлично показывает, что для мобильного веб-сайта недостаточно уменьшить UI, а необходимо полностью его переработать. Представляю сколько работы уйдет на тестирование :)
Качественно-экономическая подборка ссылок по мобильной тематике
2013-10-07 10:46
Александр Хозя (автор блога Записки мобильного тестировщика, автор и ведущий тренинга Тестирование мобильных приложений) представляет очередную подборку ссылок. <br mce_bogus="1"> Уголок разработки, тестирования и распространения приложений: 1. Статья о тестировании мобильных приложений от World Quality Report. В целом очень интересный выпуск - рекомендую хотя бы пробежаться глазами.
Если честно, динамика улучшения тестирования и процессов разработки радует, но мобайл - все еще большой бардак...
Искомая статья начинается на 24 странице. Очень хорошо расписаны проблемы методологий разработки и тестирования - после прочтения появится большое количество точек обсуждения обсуждения с лидами разработки и тестирования.
Вы наверняка читали о том, что гарантированно найти все ошибки в сколь-нибудь сложной программе средствами тестирования невозможно. Равно как невозможно доказать, что ошибок в программе нет.
Это в теории. А на практике некоторые тестировщики находят дефектов в программе больше, чем другие, в том числе они умеют находить весьма нетривиальные дефекты. Почему? Как им это удаётся? Что за секретные техники они применяют?
Увы, никаких особых приёмов проектирования тестов, о которых не было бы написано в любой книжке, не существует. Эффективные тестировщики применяют те же самые техники, что и все остальные. Разница лишь в том, КАК они их применяют.
На этом тренинге я не буду ничего говорить о том, как и в каком формате записывать тесты, я буду рассказывать только о том, как их придумывать.
Мы постоянно будем держать в уме два противоборствующих фактора:
с одной стороны, тестов надо придумать достаточно много и они должны быть достаточно разнообразными, чтобы выявить как можно больше дефектов;
с другой стороны, тестов надо придумать как можно меньше, чтобы не делать лишней работы.
"Младших тестировщиков производительности" не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.
(с) Скотт Барбер (aka The Perf Guy)
В тестировании компьютерных программ есть "общедоступная" область функционального тестирования, куда доступ открыт всем желающим, и есть целый ряд областей с достаточно высоким "порогом входа", и тестирование производительности находится в их числе.
Для этого вида тестирования требуется хорошее владение оружием, его голыми руками не возьмёшь. Во-первых, нужно само оружие -- тестирование производительности обязательно требует умения пользоваться специальными инструментами. Во-вторых, нужно тщательно изучить соперника -- необходимо хорошее понимание протоколов взаимодействия тестируемой программы с внешним миром и её внутренней физической и логической архитектуры. Ну и конечно же нужно владеть приёмами -- знать какую нагрузку и как подать на тестируемое приложение, и на что смотреть, чтобы выявить проблемы с производительностью.
На тренинге мы будем учиться обращаться с этим оружием:
познакомимся с инструментами, предназначенными для генерации нагрузки и для мониторинга различных характеристик производительности,
освоим способы использования этих инструментов для генерации нагрузки различного вида,
изучим типовые архитектурные шаблоны построения приложений и связанные с этим источники потенциальных проблем с производительностью,
рассмотрим способы выявления проблем с производительностью на основе анализа результатов мониторинга.
Для практических демонстраций и для выполнения домашних заданий будет использоваться инструмент JMeter.
Инженер по тестированию ПО
2013-10-07 14:13 Altarix – быстрорастущая компания, специализирующаяся на разработке программного обеспечения уровня Enterprise ready, мобильных сервисов и приложений. Компания Altarix является партнером крупнейших производителей мобильных устройств и операторов мобильной связи. Мобильные сервисы, в разработке которых принимали участие специалисты Altarix, используют миллионы человек.
Сегодня в компании работает более 120 специалистов из разных областей информационных технологий. Офисы компании находятся в Москве, Санкт-Петербурге и Самаре.
В нашу команду требуется Инженер по тестированию ПО.
Обязанности:
Ручное тестирование мобильных приложений и сервисов: новый функционал, проверка исправлений, регрессионное тестирование
Регистрация выявленных дефектов
Составление отчетов по результатам выполненной работы
Разработка тестовой документации и поддержка ее в актуальном состоянии
В дальнейшем: автоматизация процесса тестирования
Требования в кандидатам: Профессиональные:
Опыт работы в сфере тестирования ПО от 1 года
Опыт написания тестовой документации (желательно)
Опыт работы с системами баг-трекинга
Хорошие знания русского языка (чтобы видеть ошибки в текстах) Личные качества:
Умение четко излагать свои мысли
Ответственность
Внимательность
Стрессоустойчивость
Умение логически мыслить
Условия:
Профессиональный и дружный коллектив
Оформление согласно ТК РФ
Стабильность и конкурентоспособная заработная плата
Возможности профессионального и карьерного роста
Программы развития: обучающие семинары и тренинги
Работа в офисе рядом с м.ВДНХ и Ботанический сад
Уровент заработной платы обсуждается по результатам собеседования (25 000 - 40 000р.)
Адрес для резюме: hr@altarix.ru
Тестировщик программного обеспечения
2013-10-07 14:46
Подразделение норвежской компании, занимающееся разработкой программного обеспечения для судоходных компаний, приглашает на работу тестировщика.
Заработная плата от 40 000 до 50 000 рублей в месяц.
Обязанности:
- Проведение тестирования
- Разработка и поддержка тестовых процедур и сценариев
- Составление отчетов об ошибках
- Участие в разработке методик тестирования
Требования:
- Опыт работы по профилю от 1 года
- Образование: Высшее
- Иностранные языки: Английский — средний, профессиональная терминология
- Знакомство с реляционными СУБД
- Понимание жизненного цикла ПО
- Понимание специфики задач связанных с тестированием
- Знакомство с основными понятиями и методами, используемыми при тестировании
Плюсом будет:
- Разговорный английский язык
- Опыт работы в области тестирования
- Опыт написания документации
- Опыт программирования
Личные качества:
- Желание работать и профессионально расти в сфере тестирования ПО
- Ответственность
- Умение грамотно и четко излагать свои мысли в устной и письменной форме
- Аналитические способности
- Усидчивость
- Готовность к обучению и самообучению
Оформление согласно ТК РФ, официальная заработная плата
Контакты:
Татьяна Федотова
ООО Теомаки
www.teomaki.com
teomaki.job@yandex.ru
+7 (812) 493-41-56
Название ключа Алгоритм Тип Длина (в битах) Экспортируемость
1 RC2 симметричный 40 экспортируемый
513 DES симметричный 64 экспортируемый
17853 ... ... ... ...
Количество строк и значения в них могут изменяться. Представлена табличка как ListView.
Задача: как найти нужную строку, зная, например, Алгоритм и Тип (RC2, 40 или DES, 64)? Найти, убедиться, что она существует или нет, впоследствии м.б. кликнуть на нее.
Методом тыка пробовала писать что-то вроде (подразумевая поиск и клик на первую же строку, где встречается "DES"):
Но получаю ошибку: The list view subitem 'DES' not found.
Не понятно... прошу помощи, уже намучалась.
П.С. Пишу Keyword тест, поэтому для решения этой проблемы хочется дабы кода было поменьше, не делать перебор вручную, если это возможно.
Задание на атоматизацию
2013-10-07 16:51
Помогите с заданием на автоматизацию: (Мыслей в голове куча, а вот как )
Есть система, принимающая на вход два числа. Каждое из этих чисел может быть целым/дробным, положительным/отрицательным и выдает сумму этих чисел. Система имеет особенности: для расчета суммы у дробных чисел используется только целая часть, а любое отрицательное число всегда интерпретируется как положительное. Дан массив входных данных состоящий из 1000 пар значений для этих сумм и условие, что система должна быть протестирована в кратчайшие сроки. Какую практику/практики тест-дизайна выбрать в данной ситуации, чтобы сказать, что система работает должным образом. Обоснуйте свой выбор и опишите применение данной методики.