Перейти к содержимому

Тестирование безопасности
онлайн, начало 10 июля
Тестирование мобильных приложений
онлайн, начало 10 июня
Программирование на Java для тестировщиков
онлайн, начало 12 июня
Школа для начинающих тестировщиков
онлайн, начало 11 июня

SALar

Регистрация: 25 сен 2003
Offline Активность: 22 мая 2020 14:04
*****

Мои темы

Точная оценка времени тестирования при помощи кубиков

22 мая 2020 - 11:37

Посиделки: "Эстимация при помощи дайсов".
 
Пока мало, кто верит, что бросание кубиков и выбор значений с выпавших граней позволяет очень точно оценить трудоемкость проекта. Но многие так уже делают. Успешно.
 
Поговорим об этом в воскресенье 31 мая. С 11:00 до 12:30. 
 
Как обычно: без записи, бесплатно, с огоньком. В zoom. 
 
Следите за изменением информации в канале https://t.me/News_FrancisBaconClub

Джедайские техники управления задачами в Agile

07 ноября 2019 - 12:00

  • Моделей управления задачами много. Более двух дюжин.
  • Рассмотрим часто применяемые и неплохо реализованные в Jira.
  • На практике вы будете одновременно использовать несколько моделей одновременно. Т.к. разные задачи требуют разных методов.
  • И еще. Хорошее управление вполне способно снизить time2market раза 4 и поднять производительность команды в 1.5-2 раза.
 
Don’t Worry, Be Happy
———————————————————-
Вебпосиделки КиФБ пройдут 12 ноября (вторник) 11:00 - 12:30.
 
Записи, скорее всего не будет.
 
Оперативная информация в чате https://t.me/FrancisBaconClub

Исследование некоторых аспектов пиксельхантинга

01 ноября 2019 - 10:16

Уважаемый коллега.

 

Клуб имени Фрэнсиса Бэкона приглашает тебя принять участие в исследовании некоторых аспектов пикселхантинга (один из аспектов кросбраузерного тестирования верстки).

Еще лучше, если вы привлечете своих коллег. Если хотите - участвуйте в опросе анонимно.

 

С твоей стороны понадобится до получаса. Если больше - бросай с чистым сердцем. Просто отпишись, что это заняло больше времени, чем ожидалось.

 

Что нужно сделать? Нужно сыграть в игру “Найди 10 отличий”. Эта игра очень близка к пикселхантингу и на сайте http://rebzi.ru/ есть много вариантов с четко определенным DoD (условия окончания).

 

Порядок действий:

  • Зайти в папкку: https://drive.google.com/drive/folders/1fscY8PgxpR5hOIEXrIDZQwFYq35E1haZ

  • Скачать бланк.

  • Заполнить анкету.

  • “Сохранить как”, добавив к названию свой ник.

  • Зайти на сайт http://rebzi.ru/, раздел “10 отличий” (при необходимости запустить Adobe Flash).

  • Пройти “разгонные” упражнения (хотя бы одно). На этих упражнениях никаких замеров делать не надо, они нужны просто, чтобы войти в ритм. Если на решение уходит более 5 минут, то может это просто не твое?

 

Далее нужен будет хронометраж. Прибегни к помощи коллеги с секундомером. Если же хочешь сделать все сам - запусти программу делающую запись с экрана (мне проще использовать zoom, но на самом деле таких программ масса). Потом просмотри запись и вычисли время. Использование программы позволит полностью сосредоточиться на эксперименте. 

  • Найди тихое место, где тебя не побеспокоят хотя бы 5 минут. Отключи инстант мессенджеры и телефон.

  • Выполни 8 упражнений. 10 - лучше, но хватит и 8. Обязательно те, что в таблице, чтобы у всей группы были одинаковые упражнения. Не нужно щелкать “по площадям”, нужен чистый результат.

  • Пришли результат в https://t.me/Sergey_A_Martynenko или на почту sergey.a.martynenko@gmail.com. Не нужно кидать в общий чат. 

 

Клуб иФБ будет благодарен, если тебе дополнительно удастся провести тестирование среди детей или пенсионеров. 

 

Данные собираем до воскресенья 10 ноября 21:00.

 

Удачи.

 

Семинар «Использование стандартной отчетности Jira для повышения прибы

30 сентября 2019 - 06:31

2 октября пройдут вебпосиделки на тему: «Использование стандартной отчетности Jira для повышения прибыли фирмы».
 
Тезисы:
• Задач в трекере должно быть больше, чем мы сможем сделать. Как правило.
• Часть из этих задач – шлак. Это нормально. Просто его надо периодически чистить.
• Протухающие задачи нужно срочно делать. Или переводить в разряд шлака.
• Можно легко увеличить прибыль, если регулярно читать отчеты. И использовать их.
• Но никакие самые распрекрасные отчеты не помогут, если их не читать.
 
План:
• Обсуждаем тезисы.
• Рассматриваем, как можно использовать стандартные отчеты Jira для увеличения прибыли.
 
 
среда., 2 октября 
Время начала в 11:00 
Продолжительность 1.5 часа.
вебинар в zoom

У нас проблема с автотестами? Что делать?

13 сентября 2019 - 06:14

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • У вас есть CI

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

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

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

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

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

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

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

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

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

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

 

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

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

 

Еще нет. 

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

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

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

 

И т.д. и т.п.: https://docs.google....pwTLh73_M/edit#
 


Яндекс.Метрика
Реклама на портале