Отправляет email-рассылки с помощью сервиса Sendsay

Новые обсуждения форума тестировщиков Software-Testing.Ru

Подписаться Бесплатная «Серебряная» новостная рассылка Подписчиков 581 RSS
←   Сентябрь 2019   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней 20 выпусков (2-3 раза в неделю)


Сайт рассылки: http://https://software-testing.ru/forum/
Открыта: 04-06-2004

Автор
barancev@gmail.com

Статистика

581 подписчиков
0 за неделю
←   Все выпуски   →

У нас проблема с автотестами - не начать ли все с нуля?


Software-Testing.Ru - портал тестировщиков  

Новые темы форума тестировщиков


У нас проблема с автотестами – не начать ли все с нуля?
2019-09-12 09:48

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

 

Автоматизация тестирования – это краеугольный камень непрерывного процесса поставки программного обеспечения. Автоматизация постоянно держит новые фичи под огнем тестов, которые никогда не будут вовремя завершены, если мы начнем выполнять их вручную. Однако по моему опыту код тест-автоматизации – это иногда худший код в мире разработки. Команды зачастую не придают значения его важности, объему требуемой работы и его уникальным техническим трудностям. В результате выходит не код, а громоздкая куча мусора! Его даже можно назвать "банкротом".

 

Что делать в этой ситуации? Полностью забить на существующее решение по автоматизации и начать заново? Может, и так, а может, и нет. Не торопитесь взорвать все, что можно, и начать сначала! Нет такого понятия, как идеальный проект, и, возможно, еще можно что-то сделать. Перезапуск автоматизации с нуля – не самое простое решение.

 

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

 



Варианты обхода ЭЦП (таблетка) в api-автотестах
2019-09-12 11:44

Добрый день.

 

Для прохождения кейса необходимо подписывать документ (ЭЦП), физически прикладывать таблетку к считывателю, который втыкается в USB. Автотесты API.

 

Варианты, которые мне не очень нравятся:

1. собрать из лего\ардуино робота

2. проставить напрямую в базе признак, где возможно

3. попросить разработку собрать сборку без эцп

4. не автоматизировать такие кейсы

 

Какие ещё варианты обойти действие? Может быть, кто-то сталкивался с подобной проблемой?

 

Спасибо.

 

 



Тестировщик, Москва
2019-09-12 13:59

АО «Технологическая компания «ЦЕНТР» — диверсифицированный IT-холдинг, объединяющий активы в таких секторах экономики как: ритейл, сфера развлечений, СМИ, решения для финансового сектора, автолизинг, страховой бизнес, телеком и множество других стремительно развивающихся проектов.


В свою дружную команду на проект https://sim-sim.com/ ищем Тестировщика.

ОБЯЗАННОСТИ:

  • Разработка тест-планов, документации по тестированию и ПМИ;
  • Анализ требований и разработка чек-листов/тест-кейсов;
  • Контроль устранения аварий;
  • Развёртывание и настройка тестовых конфигураций;
  • Проведение функционального, регрессионного и нагрузочного тестирования;
  • Проведение ручного тестирования с фиксированием результатов, регистрацией и контролем исправления выявленных недостатков;
  • Разработка скриптов для автоматизации тестирования;
  • Разбор инцидентов и взаимодействие по их решению с первой линией.

ТРЕБОВАНИЯ:

  • Опыт работы в области тестирования от 1 года;
  • Понимание специфики связанных с тестированием задач, опыт тестирования многокомпонентных приложений и комплексных проектов;
  • Понимание принципов работы реляционных СУБД (Oracle), знание языка SQL на уровне написания стандартных запросов;
  • Знание скриптовых языков и умение автоматизировать рутинные задачи тестирования;
  • Уверенная работа в среде Linux, администрирование и настройка пакетов (желательно);
  • Опыт работы с системами автоматизации тестирования (желательно);
  • Опыт тестирования сетевых приложений, распределенных систем (желательно).

УСЛОВИЯ:

  • График работы с 09.00-18.00;
  • Полностью официальные выплаты;
  • Комфортный, современный офис около метро Автозаводская.

ПРЕИМУЩЕСТВА РАБОТЫ В КОМПАНИИ:

  • Работа в высокотехнологичной сфере с уникальным продуктом;
  • Участие в масштабных проектах, не имеющих аналогов в РФ;
  • Поощрение инициативы и внедрение улучшений;
  • Реализация инновационных решений;
  • Обучение и профессиональное развитие;
  • Карьерный рост и поощрение талантов;
  • Четкие прозрачные задачи;
  • Поддержка любителей спорта;
  • Команда единомышленников.

    Александра Югас
    IT Recruiter Технологической компании "Центр"
    alexandera.yugas@tccenter.ru


У нас проблема с автотестами? Что делать?
2019-09-13 09:14

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

 

  • В компании отрисован основной бизнес процесс доставки и есть понимание где вы конкретно находитесь

  • В компании отрисован процесс доставки ценности заказчику или нескольким заказчика не принципиально. 

  • Поставлено управление задачами, это означает что все причастные переводят задачи в нужный статус. И задачи типизированы

  • В компании сформулированы цели тестирования.

  • Заголовки задач в трекере “причесаны”, иными словами, по заголовку можно понять что это за задача, да не умная девочка служанка должна понимать такой заголовок. Почитать тут.

  • Реестр задач управляем, в любой момент времени он отражает текущий статус и политику проекта/продукта

  • Реестр требований есть и он то же управляем

  • Существует трассируемость требований на задачи. 

  • Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

  • Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

  • Существуют матрица влияния компонент друг на друга

  • Задачи трассируются на компоненты, да мы всегда знаем почему мы пишем или удаляем код

  • Все стоит на версионном контроле.

  • Хорошо, вы особый случай, да текстуру весом 25 гб не надо класть в систему контроля версий. Кстати а сколько раз вы их уже того…. ?

  • Существует версионная политика, кто, как и зачем.
    Да есть понимание почему git flow плохая модель.

  • Существую стандраты: кодирования и прочего

  • У вас есть CI

  • Да! У вас конечно должна быть релизная политика, где в частности прописаны способы версионирования, всего чего надо.

  • У вас есть репозиторий для артефактов, откуда вы можете однозначно вынуть готовый к установке продукт. Рука сама стала писать yum…

  • У вас есть политика по маркировке артефактов. По разным критериям, статический анализ кода, кстати не забыт

  • Среда для развертки продукта поднимается по щелчку пальца. Да она то же на версионном контроле. Все как код!

  • Среда полностью автоматизировано проверяются на правильность. Да порты, да версия джавы, да этот ….

  • Продукт разворачивается по щелчку. Разумеется  с проверкой :) Поставить все могут а вот, что бы работало!

  • Продукт конфигурируется полностью автоматически под необходимую задачу. Кстати это относится и бизнес конфигурации! И это тоже проверятся в автоматически! Кто сказал про стык с платежными системами????

  •  У вас есть способ повторяемо и автоматически генерить все необходимые тестовые данные. Да это то же на версионном контроле. Да оно связано с артефактами продукта.

  • Я упомянул, что все выше указанное работает для любой версии продукта?

  • У вас прописан конвейер поставки, он обычно внутри релизной политики, но я вытащил наружу.

 

Поздравляем!

Вы готовы к написанию автотестов!

 

Еще нет. 

  • Интерфейсы, будь то GUI или API проектируются ДО того, как программист сядет писать код. Да, в соответствии со стандартом проектирования интерфейсов. Да, там прописана политика именования идентификаторов элементов управления ( для GUI).

  • Задачу на написание тестов тестировщик получает, как правило, раньше, чем программист получит задачу на написание кода.

И не надо начинать автоматизацию тестирования, с написания регрессионных тестов. Вот совсем не надо.

 

И т.д. и т.п.: https://docs.google.com/document/d/1hKVE464sKVTDCz3rd7Jra2Of5xX_vXOUO2pwTLh73_M/edit#
 


© 2010 | Software-Testing.Ru
В избранное