Метка «тестирование» - 3

«Кого хочу, не знаю, кого знаю – не хочу»Читать полностью »

Всем привет! Этот небольшой пост посвящен системе тестирования MeteorJS-приложений Laika от Arunoda Susiripala. Ее особенности довольно интересны:

  • Laika запускает свои тесты так же, как запускается реальное приложение (используется PhantomJS)
  • Каждый тест изолирован, т.е. заново запускается ваше MeteorJS-приложение с чистой базой данных
  • Вы можете использовать для разработки и meteor, и meteorite, laika прекрасно работает с ними обоими
  • Вы можете запускать проверку на сервере и клиенте в одном тесте. Это поможет протестировать такие моменты, как права доступа (permission), подписки (subscriptions) и вызовы методов (method calls)
  • Так как MeteorJS работает в реальном времени, то вам потребуется тестировать приложение при работе нескольких клиентов одновременно. Laika это может.
  • Возможность использования событий для более точного тестирования, т.е., фактически, эмуляция работы пользователя
  • Передача значений в код во время выполнения теста через аргументы
  • Ожидание окончания генерации шаблонов (templates)

Читать полностью »

image

Привет, уважаемые разработчики и тестировщики ПО. Подготовка DevCon 2014 — нашей крупнейшей специально предназначенной для вас конференции идет полным ходом! Сегодня мы готовы поделиться с вами описанием места проведения – природным курортом Яхонты.

Конференция DevCon 2014 – уникальное мероприятие, которое уже четвертый год будет проводиться за городом в живописном природном курорте Яхонты. Давайте познакомимся с особенностями места проведения или, если вы уже были на нашей конференции, вспомним это место заново.

Недавно наша команда организаторов посетила Яхонты и сделала ряд фотографий, которыми мы с вами с удовольствием делимся. Некоторые из фото взяты с официального сайта курорта.
Читать полностью »

image

Несколько раз начинал писать эту статью и бросал. Бросал потому, что тема, как мне кажется, несколько спорная. Изобретенный мною велосипед может кому-то показаться смешным и нелепым и вообще не совсем корректным. Тем не менее…

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

6 февраля, первый раз в этом году, компания Mail.Ru Group откроет двери сообществу Moscow.pm (группа московских Perl-программистов).

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

Приглашаем на Moscow PM 06/02
Читать полностью »

Весь прошлый год мы много писали на Хабр и рассказывали на конференциях о том, как у нас устроен процесс тестирования в Badoo, как мы выкатываем релизы два раза в день и о многом другом.

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

Кроме презентаций, которые вы уже могли слышать на конференциях, мы подготовили для вас несколько совершенно новых докладов.
Мы хотим сделать небольшую уютную конференцию, и позвать примерно 120 человек.
В программе интересные доклады, кофебрейк и обед, экскурсия по офису Badoo.
Будем делать трансляцию и видеозапись докладов. Следите за новостями по хэштегу: #loveqa

LoveQA — Meet New People! Посидим, пообщаемся.

Когда: 15 февраля, суббота

Где: Офис компании Badoo, Цветной бульвар д.2, БЦ «Легенды Цветного», Москва

Читать полностью »

Полтора года назад, когда вышла книга «How Google Tests Software», я загорелась перевести ее на русский язык. Я давно восхищаюсь Уиттакером, я переводила его статьи, слушала мастер-классы и считаю его самым крутым чуваком в тестировании. Тогда я еще работала руководителем отдела тестирования в «Иннове», и компания поддержала мой проект.

С тех пор многое поменялось: я перестала заниматься тестированием, выпускала приложения для iOS, сейчас работаю продакт-менеджером большого веб-проекта. Уиттакер же еще в 2012 году ушел из Google в Microsoft, громко хлопнув дверью.

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

И вот, в январе издательство «Питер» выпустило книгу на русском языке с нашим переводом и дизайном:

Читать полностью »

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

  • На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
  • Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
  • Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
  • За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

Почему такое происходит, вполне понятно: мало кто вживую встречал квалифицированных тестировщиков, тестировщики не делают полезный результат (продукт не пишут), да и вообще у нас принято экономить на всём, на чём только получается. Интересен другой вопрос: что получается благодаря такому подходу? Рассмотрим на примерах.Читать полностью »

Откровенно говоря, ранее я ни разу не занимался в серьезной мере методами тестирования программного обеспечения. Однако, понимаю, что для полной уверенности в том, что программа будет работать, нужно перепробовать всевозможные варианты её использования. Также очевиден для меня и тот факт, что сделать это не всегда возможно. Если имеются конкретные варианты использования, но невозможно проверить их всех в силу их количества, стараются построить набор, который покроет все самые используемые варианты. Но что делать, если использование всех вариантов равновероятно? Как за минимальное число времени обнаружить все ошибки, на которые есть большая вероятность наткнуться? Данная задача действительно известна, и с ней нередко сталкиваются, ну хотя бы, в Яндексе.

Чтобы стало понятно о чем идет речь, представим, что нам необходимо протестировать какую-либо программу или сайт. Очень хорош пример с тестированием веб-формы, скажем для регистрации или для поиска. Возникает вопрос, с какими ошибками в ней скорее всего встретится пользователь? Пускай у нас в форме имеется 6 вопросов, для каждого из которых возможны 10 вариантов ответа. Допустим, на страницу зашел целый миллион пользователей, и каждый из них ответил уникально. Теперь представим, что в форме для заполнения ответами скрывается ошибка. Если ошибка обнаруживается только при определенной комбинации ответов на все 6 вопросов, то на неё наткнется лишь один человек. Если же ошибка вылетает при наборе определенных ответов на какие-то 3 вопроса, то количество людей, обнаруживших ошибку возрастет до тысячи. Очевидно, что чем меньше элементов в комбинации, требуемой для ошибки, тем больше людей с ней встретится. Соответственно, перед нами теперь стоит задача: если мы не можем обнаружить все ошибки, то давайте хотя бы найдем самые критичные, то есть те, на которые наткнется больше всего пользователей.
Таким образом мы должны сформировать тест-кейсы (и чем меньше, тем лучше), при переборе которых мы наткнемся на самые легкодоступные ошибки. Допустим, у нас имеется множество вопросов A, которое мы задаем количеством вариантов ответа на каждый из них: А = {2, 3, 5, 2, ...}. Пусть n — количество вопросов, а 1≤m≤n — степень критичности ошибок, она же степень покрытия или глубина покрывающего набора. Чем меньше значение m, тем критичнее ошибка. Задавая степень покрытия мы строим тестовый набор, который позволит обнаружить все ошибки, степень критичности которых меньше данного m. Если m = n, то поиск ошибок сводится к перебору всех вариантов. Чем меньше задаем степень, тем меньше тест-кейсов будет сформировано и тем меньше ошибок мы найдем.
Читать полностью »

WTF Logo
Статья расскажет о том, как настроить фреймворк автоматизированного тестирования пользовательского интерфейса на языке C#, вместе с Selenium WebDriver и паттерном PageObjects.

Стартовый набор с открытым исходным кодом – SWD.Starter – поможет написать и запустить ваш первый тест в течении 10 минут. Кроме этого, предлагая архитектуру фреймворка, основанную на хороших практиках автоматизации тестирования.
Весь код SWD.Starter может быть полностью настроен под ваши задачи.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js