Kanban VS Scrum
В чём же различие между подходами?
Kanban уделяет меньше внимания срокам, работа происходит в непрерывном потоке. Здесь основной принцип — бережное управление, при котором исключается переработка.
Так же существенное отличие Kanban от Scrum — это то, что задачи могут появляться на доске ежедневно, а в Scrum итерации — 2–4 недели и только потом сверяешь результат.
Можно представить подходы в виде очного (Kanban) и заочного (Scrum) обучений.
В очном ты ходишь в институт регулярно на пары и получаешь задачи. На заочке — прослушиваешь курс лекций в короткий промежуток времени, получаешь задания и приходишь, условно, через пару месяцев для подведения итогов в учёбе.
Каждый подход имеет место.
Многое зависит от проекта. Если разрабатывается новый продукт, то на старте подойдёт Scrum. Он больше фиксирует рамки по срокам. Также здесь коллективная работа, что сильно сплочает.
Когда релиз уже вышел, приходит новый этап. Нужно вносить новые правки, проверять гипотезы. Появляется много маленьких задач. Сюда логично вписываются канбан-доски.
Поделитесь, вы уже работали по какой-то из систем? Какие ваши впечатления? 🤔
В чём же различие между подходами?
Kanban уделяет меньше внимания срокам, работа происходит в непрерывном потоке. Здесь основной принцип — бережное управление, при котором исключается переработка.
Так же существенное отличие Kanban от Scrum — это то, что задачи могут появляться на доске ежедневно, а в Scrum итерации — 2–4 недели и только потом сверяешь результат.
Можно представить подходы в виде очного (Kanban) и заочного (Scrum) обучений.
В очном ты ходишь в институт регулярно на пары и получаешь задачи. На заочке — прослушиваешь курс лекций в короткий промежуток времени, получаешь задания и приходишь, условно, через пару месяцев для подведения итогов в учёбе.
Каждый подход имеет место.
Многое зависит от проекта. Если разрабатывается новый продукт, то на старте подойдёт Scrum. Он больше фиксирует рамки по срокам. Также здесь коллективная работа, что сильно сплочает.
Когда релиз уже вышел, приходит новый этап. Нужно вносить новые правки, проверять гипотезы. Появляется много маленьких задач. Сюда логично вписываются канбан-доски.
Поделитесь, вы уже работали по какой-то из систем? Какие ваши впечатления? 🤔
🔥9
Мы по скрамбану 👌
Комментарий от подписчицы Валентины, на который стоит обратить внимание: ссылка
Именно так и работает Agile на практике - берем лучшее и используем.
Например:
1. Канбан доска
2. 1-2-недельные спринты
3. Достижимые цели, чтобы после спринта бежать с демо к заказчику
4. Ежедневные митинги на 15 минут
5. Мероприятия по планированию и оценке задач каждый спринт
6. В середине спринта прилетают новые задачи - криты и блокеры (ошибки от пользователей, мешающие рабоать) и мы их чиним. Есть зарезервированное время под них.
7. Если приоритеты заказчика поменялись, мы убираем из спринта неприоритетную задачу и заменяем на более востребованную
Ни разу не видела использование в чистом виде только канбана, или только скрама. Всегда комбинация правил, выбранная компанией на основе опыта.
Также есть более сложные фреймворки типа SAFe. И это уже другая история.
На собеседованиях, при переходе в новую компанию, рекомендую всегда уточнять по какому фреймворку они работают, частота релизов и другие нюансы, которые могут влиять на ваши рабочие будни ✔️
Комментарий от подписчицы Валентины, на который стоит обратить внимание: ссылка
Именно так и работает Agile на практике - берем лучшее и используем.
Например:
1. Канбан доска
2. 1-2-недельные спринты
3. Достижимые цели, чтобы после спринта бежать с демо к заказчику
4. Ежедневные митинги на 15 минут
5. Мероприятия по планированию и оценке задач каждый спринт
6. В середине спринта прилетают новые задачи - криты и блокеры (ошибки от пользователей, мешающие рабоать) и мы их чиним. Есть зарезервированное время под них.
7. Если приоритеты заказчика поменялись, мы убираем из спринта неприоритетную задачу и заменяем на более востребованную
Ни разу не видела использование в чистом виде только канбана, или только скрама. Всегда комбинация правил, выбранная компанией на основе опыта.
Также есть более сложные фреймворки типа SAFe. И это уже другая история.
На собеседованиях, при переходе в новую компанию, рекомендую всегда уточнять по какому фреймворку они работают, частота релизов и другие нюансы, которые могут влиять на ваши рабочие будни ✔️
Telegram
Валентина Ульянова in GetAnalyst - Чат | Сообщество IT-аналитиков (СА, БА, PM)
По опыту работы как в проектной, так и в продуктовой разработке по скраму и канбану - в большинстве команд и компаний работают по скрамбану, то есть комбинируют эти подходы, беря от них самое лучшее и то, что работает в конкретной компании/команде. Если компания…
👍6
"Большое спасибо за вебинар! Очень много полезной информации и круто, что можно из полученных знаний самостоятельно сформировать индивидуальную карту развития. Отдельное спасибо за дополнительные материалы!" (Татьяна)
"Отлично раскрыта тема обязанностей системного аналитика и помимо этого получил интересную информацию о правильном резюме" (Ерхан)
"Спасибо! Было очень много ценной информации и по составлению резюме и по профессии системного аналитика" (Анна)
Сегодня повторим практический вебинар:
📹 5 лайфхаков для создания цепляющего резюме
⏰ 15:00 - 18:00 Мск
Регистрация здесь!
"Отлично раскрыта тема обязанностей системного аналитика и помимо этого получил интересную информацию о правильном резюме" (Ерхан)
"Спасибо! Было очень много ценной информации и по составлению резюме и по профессии системного аналитика" (Анна)
Сегодня повторим практический вебинар:
📹 5 лайфхаков для создания цепляющего резюме
⏰ 15:00 - 18:00 Мск
Регистрация здесь!
getanalyst.ru
GETANALYST | 5 лайфхаков для создания цепляющего резюме
Создайте ваше резюме в прямом эфире!
🔥3
В канале для начинающих системных аналитиков рассказываю про инструменты аналитиков. Один из них - Trello, который можно использовать для планирования личных задач и небольших проектов 👇
Telegram
GetAnalyst - Системый анализ
Trello - инструмент для управления задачами
Программа удобна для планирования и в работе с командой. Задачам можно присвоить метки, срок выполнения, добавлять файлы, чек-листы, комментарии, смайлы.
💥 понятный сервис
💥 удобно ставить цели и задачи для себя…
Программа удобна для планирования и в работе с командой. Задачам можно присвоить метки, срок выполнения, добавлять файлы, чек-листы, комментарии, смайлы.
💥 понятный сервис
💥 удобно ставить цели и задачи для себя…
Добрый вечер!
Хочу извиниться перед подписчиками и другими участниками, которые зайдут в канал, за ушедший сегодня СПАМ с приглашениями на вебинар. Кому-то ушедший по 2-3 раза.
Материалы и концепция школы жили и должны продолжить жить в параллельных мирах с темой вебинара и способом информирования о нем.
Подобное больше не повторится в будущем. Мне жаль, что вам пришлось столкнуться с этим всем из-за моей ошибки.
Вебинар ОТМЕНЕН.
Спасибо всем, кто сообщил в каналах коллег и в ЛС, о полученной рассылке.
Хочу извиниться перед подписчиками и другими участниками, которые зайдут в канал, за ушедший сегодня СПАМ с приглашениями на вебинар. Кому-то ушедший по 2-3 раза.
Материалы и концепция школы жили и должны продолжить жить в параллельных мирах с темой вебинара и способом информирования о нем.
Подобное больше не повторится в будущем. Мне жаль, что вам пришлось столкнуться с этим всем из-за моей ошибки.
Вебинар ОТМЕНЕН.
Спасибо всем, кто сообщил в каналах коллег и в ЛС, о полученной рассылке.
👍1👎1
В информационных системах мы работаем с данными. Добавляя или меняя очередную функциональность, я всегда прокручиваю в голове комбинацию из четырех букв — CRUD.
Что такое CRUD-модель, чем она полезна, как ее применять при анализе требований и проектировании систем? Ответы на эти вопросы я разбираю и показываю на примере ✍️
Читать
Что такое CRUD-модель, чем она полезна, как ее применять при анализе требований и проектировании систем? Ответы на эти вопросы я разбираю и показываю на примере ✍️
Читать
getanalyst.ru
CRUD-модель и ее использование
В информационных системах мы работаем с данными. Добавляя или меняя очередную функциональность, я всегда прокручиваю в голове комбинацию из четырех букв — CRUD.
❤6
Хочу познакомить Вас с роботом-помощником GetAnalyst 🤖🦭
Он только-только запустился 🚀 Его цель - знакомить вас с миром алитики и развивать профессиональные навыки.
Он уже знает о разработке требований, проектировании БД, историю профессии аналитиков и готов с вами поделиться 😉
Это начало, он еще пополнит базу знаний!
Давайте дружить 🤖
Он только-только запустился 🚀 Его цель - знакомить вас с миром алитики и развивать профессиональные навыки.
Он уже знает о разработке требований, проектировании БД, историю профессии аналитиков и готов с вами поделиться 😉
Это начало, он еще пополнит базу знаний!
Давайте дружить 🤖
Confluence - база знаний
Инструмент для ведения базы знаний команды разработки:
+ проектная документация,
+ требования,
+ ПМИ,
+ сценарии тестирования,
+ отчеты.
Все знания коллекционаинруем в нем. Документы версионируются. Всегда можно узнать когда были внесены изменения в документацию и, соответственно, в функциональность системы.
Сюда можно загрузить разные документы, полезные ссылки, подключить инструменты для рисования диаграмм и картинок. Классно, что можно создавать красивые планы разработки и отслеживать движение по ним.
Интегрируется с кучей сервисов. Есть классный опыт автоматического создания Confluence-страниц на основе PostgreSQL базы данных.
Обычно используется внутри компании, документация не выставляется в открытый доступ.
✔️информация оптимизируется в одном месте (отчёты, задачи и т. д.)
✔️помогает вести протоколы встреч, решений и задач; ✔️позволяет создавать задачи в Jira и отслеживать их исполнение
✔️можно создавать справочную информацию для бизнес-заказчиков
✔️позволяет контролировать изменения в версиях документов
😬сложно следить за изменением форматирования документов (гигансткие отчеты при сравнении версий документов)
😬 приходит много отчётов на почту, но можно настроить фильтры
😬 кто-то ругается на неудобную навигацию, но тоже решаемо за счет крутой оргнизации структуры
😬 подвисает при входе и выходе в режим редактирования, в отличии от notion
Разработчик ПО Confluence, как и у Jira - Attlassian. Условия использования такие же. Регистрация под VPN, есть бесплатная версия, можно платно.
Инструмент для ведения базы знаний команды разработки:
+ проектная документация,
+ требования,
+ ПМИ,
+ сценарии тестирования,
+ отчеты.
Все знания коллекционаинруем в нем. Документы версионируются. Всегда можно узнать когда были внесены изменения в документацию и, соответственно, в функциональность системы.
Сюда можно загрузить разные документы, полезные ссылки, подключить инструменты для рисования диаграмм и картинок. Классно, что можно создавать красивые планы разработки и отслеживать движение по ним.
Интегрируется с кучей сервисов. Есть классный опыт автоматического создания Confluence-страниц на основе PostgreSQL базы данных.
Обычно используется внутри компании, документация не выставляется в открытый доступ.
✔️информация оптимизируется в одном месте (отчёты, задачи и т. д.)
✔️помогает вести протоколы встреч, решений и задач; ✔️позволяет создавать задачи в Jira и отслеживать их исполнение
✔️можно создавать справочную информацию для бизнес-заказчиков
✔️позволяет контролировать изменения в версиях документов
😬сложно следить за изменением форматирования документов (гигансткие отчеты при сравнении версий документов)
😬 приходит много отчётов на почту, но можно настроить фильтры
😬 кто-то ругается на неудобную навигацию, но тоже решаемо за счет крутой оргнизации структуры
😬 подвисает при входе и выходе в режим редактирования, в отличии от notion
Разработчик ПО Confluence, как и у Jira - Attlassian. Условия использования такие же. Регистрация под VPN, есть бесплатная версия, можно платно.
❤3👍3
Notion - хранение требований и документации, управления задачами
Сервис помогает управлять задачами и проектами, собирать в одном месте все нужные ссылки, файлы и документы, делиться ими с другими.
Если приходится работать с разными форматами файлов и документов, то можно объединить в один проект.
В какой-то степени может даже заменить любой таск-трекер, такой как Trello, т.к. тоже позволяет ставить задачи и контролировать их выполнение.
✔️ нет ничего лишнего: всё просто и понятно
✔️ всё файлы в одном месте, не нужно скачивать дополнительные приложения
✔️ интегрируется другими сервисами: Google Docs, GitHub, Figma, Miro, Invision
❌ нельзя одновременно работать над одним документом в реальном времени
❌ нет русскоязычной версии
Есть бесплатная и платная версии.
Ссылка: notion.so/
Я использую Notion для небольших проектов. Он очень популярен в образовательных бизнесах. Удобно пистаь в нем регламенты, инструкции, планы. В больших проектах разработки больше доверяю Confluence - он удобнее.
Сервис помогает управлять задачами и проектами, собирать в одном месте все нужные ссылки, файлы и документы, делиться ими с другими.
Если приходится работать с разными форматами файлов и документов, то можно объединить в один проект.
В какой-то степени может даже заменить любой таск-трекер, такой как Trello, т.к. тоже позволяет ставить задачи и контролировать их выполнение.
✔️ нет ничего лишнего: всё просто и понятно
✔️ всё файлы в одном месте, не нужно скачивать дополнительные приложения
✔️ интегрируется другими сервисами: Google Docs, GitHub, Figma, Miro, Invision
❌ нельзя одновременно работать над одним документом в реальном времени
❌ нет русскоязычной версии
Есть бесплатная и платная версии.
Ссылка: notion.so/
Я использую Notion для небольших проектов. Он очень популярен в образовательных бизнесах. Удобно пистаь в нем регламенты, инструкции, планы. В больших проектах разработки больше доверяю Confluence - он удобнее.
❤6👍3🔥2
Разработка требований – это важный процесс, который позволяет сформировать ясное представление о том, что должно быть реализовано в приложении. Необходимо учесть потребности пользователей, а также технические особенности платформы, на которой будет работать приложение.
В результате разработки требований должен получиться документ - требования к приложению , в котором будут указаны все необходимые функциональные возможности приложения, его интерфейс и сроки разработки.
Важно помнить, что разработка требований – это постоянный процесс, который может претерпевать изменения в течение всего проекта
Требования – это целевое видение того, что должна получить команда разработки в результате их работы.
При разработке требований к приложениям выделяют следующий список характеристик, которые необходимо описать:
• Функциональность
• Производительность
• Внешний вид (UI)
• Компоненты
• Безопасность
• API-интерфейсы для интеграций
• Удобство (UX)
Для каждой характеристики требуется понять, что именно должно быть реализовано.
Например, у UI-дизайна могут быть:
• Сведения о цветовой схеме, названиях элементов и прочих свойствах
• Примеры для того, чтобы удостовериться, что все они должны быть удовлетворяющими
• Инструменты, которые разработчику помогут сделать дизайн
• Дополнительные связанные с UI-дизайном функции, например, ответственность за адаптивность приложения к различным гаджетам.
Это только несколько примеров, что должно быть учтено при разработке требований.
В результате разработки требований должен получиться документ - требования к приложению , в котором будут указаны все необходимые функциональные возможности приложения, его интерфейс и сроки разработки.
Важно помнить, что разработка требований – это постоянный процесс, который может претерпевать изменения в течение всего проекта
Требования – это целевое видение того, что должна получить команда разработки в результате их работы.
При разработке требований к приложениям выделяют следующий список характеристик, которые необходимо описать:
• Функциональность
• Производительность
• Внешний вид (UI)
• Компоненты
• Безопасность
• API-интерфейсы для интеграций
• Удобство (UX)
Для каждой характеристики требуется понять, что именно должно быть реализовано.
Например, у UI-дизайна могут быть:
• Сведения о цветовой схеме, названиях элементов и прочих свойствах
• Примеры для того, чтобы удостовериться, что все они должны быть удовлетворяющими
• Инструменты, которые разработчику помогут сделать дизайн
• Дополнительные связанные с UI-дизайном функции, например, ответственность за адаптивность приложения к различным гаджетам.
Это только несколько примеров, что должно быть учтено при разработке требований.
👍9🔥1
Разработки требований – это важный этап разработки программного обеспечения. За него на проекте отвечает Системный аналитик.
Системный аналитик выступает как посредник между командой разработки и заказчиком, помогая сформулировать требования и учесть все нюансы проекта.
На практике роль системного аналитика может выглядеть так:
▫️Заказчик желает разработать приложение для учета финансов.
▫️Системный аналитик проводит интервью с заказчиком, чтобы уточнить его потребности и ожидания.
▫️Затем, он формулирует требования к приложению, учитывая все пожелания заказчика и технические возможности.
▫️После этого, он предоставляет требования команде разработки, которая использует их для создания приложения.
Если вы заинтересованы в разработке требований к программному обеспечению и хотите улучшить свои навыки в этой области, то курс "Системный аналитик: с нуля до опыта работы на проекте" идеально подойдет для вас!
Я создала комплексный курс, который включает в себя лекции, практические занятия и практику на воркшопах, где я даю индивидуальную обратную связь!
Весь курс мы будем работать над созданием одного проекта! Вы научитесь аналитике, участвуя в стартап-проекте:
✔️ соберете требования, сформулируете требования к программному обеспечению,
✔️ освоите методики, как учитывать все пожелания заказчиков и технические возможности приложений,
✔️ как работать с командой разработчиков,
✔️ определять и анализировать технические риски 💻
Не пропустите шанс улучшить свои навыки и стать экспертом в области системного анализа!
Записывайтесь на курс уже сегодня и начинайте свой путь к успеху 🚀 А если вам нужна помощь с выбором обучения, то вы всегда можете записаться к нам на бесплатную диагностическую консультацию 🙂
Системный аналитик выступает как посредник между командой разработки и заказчиком, помогая сформулировать требования и учесть все нюансы проекта.
На практике роль системного аналитика может выглядеть так:
▫️Заказчик желает разработать приложение для учета финансов.
▫️Системный аналитик проводит интервью с заказчиком, чтобы уточнить его потребности и ожидания.
▫️Затем, он формулирует требования к приложению, учитывая все пожелания заказчика и технические возможности.
▫️После этого, он предоставляет требования команде разработки, которая использует их для создания приложения.
Если вы заинтересованы в разработке требований к программному обеспечению и хотите улучшить свои навыки в этой области, то курс "Системный аналитик: с нуля до опыта работы на проекте" идеально подойдет для вас!
Я создала комплексный курс, который включает в себя лекции, практические занятия и практику на воркшопах, где я даю индивидуальную обратную связь!
Весь курс мы будем работать над созданием одного проекта! Вы научитесь аналитике, участвуя в стартап-проекте:
✔️ соберете требования, сформулируете требования к программному обеспечению,
✔️ освоите методики, как учитывать все пожелания заказчиков и технические возможности приложений,
✔️ как работать с командой разработчиков,
✔️ определять и анализировать технические риски 💻
Не пропустите шанс улучшить свои навыки и стать экспертом в области системного анализа!
Записывайтесь на курс уже сегодня и начинайте свой путь к успеху 🚀 А если вам нужна помощь с выбором обучения, то вы всегда можете записаться к нам на бесплатную диагностическую консультацию 🙂
👍1
Я нередко остаюсь на связи с учениками прошлых поток и интересуюсь как у них дела после обучения.
Какими достижениями делятся ребята:
✔️ Появилась возможность работать в новой, интересной и развивающейся сфере
✔️ Есть те, кому удаленная профессия помогла переехать в другой город/страну
✔️ Получили повышение на работе или перешли на другую должность
✔️ Повысили доход
✔️ Получили должность в крупной компании
В такие моменты нередко вспоминаю ролик, который сейчас часто встречаю в соцсетях. Там главная фраза:
«Кто вообще придумал поговорку «Не умеешь — не берись?». «Не умеешь — научись!»
Невозможно не согласиться. Всегда придерживаюсь того же принципа 😉
Какими достижениями делятся ребята:
✔️ Появилась возможность работать в новой, интересной и развивающейся сфере
✔️ Есть те, кому удаленная профессия помогла переехать в другой город/страну
✔️ Получили повышение на работе или перешли на другую должность
✔️ Повысили доход
✔️ Получили должность в крупной компании
В такие моменты нередко вспоминаю ролик, который сейчас часто встречаю в соцсетях. Там главная фраза:
«Кто вообще придумал поговорку «Не умеешь — не берись?». «Не умеешь — научись!»
Невозможно не согласиться. Всегда придерживаюсь того же принципа 😉
❤4🔥4
Продолжая говорить о требованиях к приложениям, важно понимать, что их производительность может быть затронута различными факторами с точки зрения системного анализа.
💻 Производительность — это мера того, насколько эффективно приложение использует ресурсы системы для выполнения действий, которые вы создали для этого.
Аналитик, понимая бизнес-метрики и бизнес-процессы, может влиять на требования к:
▫️мощности оборудования,
▫️структуре кода,
▫️эффективности использования памяти,
▫️скорости получения данных из базы
и т.д.
Сначала кажется, что это сложно. Но на самом деле влияние на эти требования оказывают совершенно простые характеристики, собираемые в ходе общения с бизнесом и пользователями.
Например: количество пользователей, требования к времени ожидания обработки запроса, алгоритмы обработки данных...
Это одна из составляющих нефункциональных требований к приложениям.
💻 Производительность — это мера того, насколько эффективно приложение использует ресурсы системы для выполнения действий, которые вы создали для этого.
Аналитик, понимая бизнес-метрики и бизнес-процессы, может влиять на требования к:
▫️мощности оборудования,
▫️структуре кода,
▫️эффективности использования памяти,
▫️скорости получения данных из базы
и т.д.
Сначала кажется, что это сложно. Но на самом деле влияние на эти требования оказывают совершенно простые характеристики, собираемые в ходе общения с бизнесом и пользователями.
Например: количество пользователей, требования к времени ожидания обработки запроса, алгоритмы обработки данных...
Это одна из составляющих нефункциональных требований к приложениям.
👍8❤1
Нефункциональные требования - это требования, которые не касаются непосредственно функциональности приложения, но влияют на его удобство использования.
Пример, когда тестирование нефункциональных требований провалено - мобильное приложение для покупки билета на электричку 🚃:
- имеет маленькие кнопки для выбора времени отправления поезда, на который надо купить билет (удобство использования),
- начинает долго грузиться по утрам, в час пик (производительность),
- и мой купленный билет можно при желании использовать многократно в течение дня (безопасность).
- чтобы добавить возможность покупки билетов "туда-обратно", программисты говорят, что дешевле с нуля все переписать (масштабируемость).
Поэтому, работая над требованиями к приложениям, думаем про:
💥 Надежность - способность приложения работать бесперебойно на протяжении определенного времени, без ошибок
💥 Безопасность - способность защищать данные и систему от внешних угроз, доступность персональных данных пользователей, авторизация
💥 Удобство использования - эргономика, интуитивно понятный интерфейс
💥 Производительность - скорость и эффективность работы приложения
💥 Масштабируемость - способность приложения адаптироваться к росту нагрузки и изменению требований
💥 Совместимость - способность приложения работать с разными системами и устройствами
Сохраняйте в заметки, чтобы не потерять, и использовать при постановке очередной задачи или написании ТЗ!
Пример, когда тестирование нефункциональных требований провалено - мобильное приложение для покупки билета на электричку 🚃:
- имеет маленькие кнопки для выбора времени отправления поезда, на который надо купить билет (удобство использования),
- начинает долго грузиться по утрам, в час пик (производительность),
- и мой купленный билет можно при желании использовать многократно в течение дня (безопасность).
- чтобы добавить возможность покупки билетов "туда-обратно", программисты говорят, что дешевле с нуля все переписать (масштабируемость).
Поэтому, работая над требованиями к приложениям, думаем про:
💥 Надежность - способность приложения работать бесперебойно на протяжении определенного времени, без ошибок
💥 Безопасность - способность защищать данные и систему от внешних угроз, доступность персональных данных пользователей, авторизация
💥 Удобство использования - эргономика, интуитивно понятный интерфейс
💥 Производительность - скорость и эффективность работы приложения
💥 Масштабируемость - способность приложения адаптироваться к росту нагрузки и изменению требований
💥 Совместимость - способность приложения работать с разными системами и устройствами
Сохраняйте в заметки, чтобы не потерять, и использовать при постановке очередной задачи или написании ТЗ!
👍9🔥6
А еще есть такое понятие у тестировщиков, как нефункциональное тестирование. Это проверка соответствия НФТ (нефункциональным требованиям) для приложений.
Примеры тестовых сценариев для НФТ:
▫️Производительность: Время загрузки приложения не должно превышать 3 секунд при одновременном доступе к нему до 1000 пользователей.
▫️Совместимость: Программное обеспечение должно быть установлено на всех версиях Windows и Mac.
▫️Доступность: Все веб-изображения должны иметь теги alt.
А это наиболее распространенные типы нефункционального тестирования:
✔️ Тестирование производительности
✔️ Нагрузочное тестирование
✔️ Тестирование отказоустойчивости
✔️ Тестирование совместимости
✔️ Юзабилити-тестирование
✔️ Стресс-тестирование
✔️ Тестирование ремонтопригодности
✔️ Тестирование масштабируемости
✔️ Объемное тестирование
✔️ Тестирование безопасности
✔️ Тестирование аварийного восстановления
✔️ Тестирование переносимости
✔️ Тестирование эффективности
✔️ Проверка надежности
✔️ Тест на выносливость
✔️ Тестирование документации
✔️ Тестирование восстановления
✔️ Тестирование интернационализации
✔️ Тестирование локализации
Пишете требования? Давайте подумаем заранее, что тестировщики или пользователи могут нам подкинуть 😉
Примеры тестовых сценариев для НФТ:
▫️Производительность: Время загрузки приложения не должно превышать 3 секунд при одновременном доступе к нему до 1000 пользователей.
▫️Совместимость: Программное обеспечение должно быть установлено на всех версиях Windows и Mac.
▫️Доступность: Все веб-изображения должны иметь теги alt.
А это наиболее распространенные типы нефункционального тестирования:
✔️ Тестирование производительности
✔️ Нагрузочное тестирование
✔️ Тестирование отказоустойчивости
✔️ Тестирование совместимости
✔️ Юзабилити-тестирование
✔️ Стресс-тестирование
✔️ Тестирование ремонтопригодности
✔️ Тестирование масштабируемости
✔️ Объемное тестирование
✔️ Тестирование безопасности
✔️ Тестирование аварийного восстановления
✔️ Тестирование переносимости
✔️ Тестирование эффективности
✔️ Проверка надежности
✔️ Тест на выносливость
✔️ Тестирование документации
✔️ Тестирование восстановления
✔️ Тестирование интернационализации
✔️ Тестирование локализации
Пишете требования? Давайте подумаем заранее, что тестировщики или пользователи могут нам подкинуть 😉
👍5