В LI сейчас активно встречаю цикл советов по тестированию от Артема Русова. Возникла шальная идея переложить некоторые советы на работу аналитика — огонь же ведь, когда мы работаем с требованиями упреждающе, ага? Буду делиться по кусочкам и со ссылками на оригинальные посты — они сами по себе интересно читаются, хоть и коротенькие.
📌 3. Не берите на себя чужие активности.
Хех, а я уже давно писал похожую заметку тут: https://t.me/itmineba/47, https://t.me/itmineba/48. Рекомендую почитать, если вы тот самый БА, который проектирует бэдешки и чует, что что-то в жизни пошло не так.
📌 6. Согласуйте формат отчетов о дефектах с разработчиками. Для нас тут посыл еще критичнее, ибо наша документация в идеале должна быть на вес золота. Снова отправлю в архинужную заметку своего авторства о том, как не писать доки для сферической ЦА в вакууме: https://t.me/itmineba/46.
📌 11. Самый лучший способ разобраться в технологии – разработать свой сервис для автоматизации или упрощения быта для помощи себе любимому.
Я периодически советую для прокачки техбазы стать на время джун-девелопером. План нехитрый: если не знаем, с чего начать, берем веб-приложения как наиболее частый тип решений и пробуем запилить нечто базовое по любому учебнику для чайников (например, сайтец с CRUDL-менеджментом товаров). Нынче это в разы проще: дорогой чатик, проведи меня как ментор с заданиями по циклу разработки с нуля: фронтенд на простейших вещах (HTML, JS), бэкенд для обработки данных (например, на PHP), БД для хранения этих данных, хостинг и развертывание. Что мы поймем: алгоритмизацию, что такое код и как он работает, принципы работы веб-систем и их архитектуру, всякие фишки а-ля https, сертификаты, куки, домены и пр. Сириусли, с таким опытом наша коммуникация с командой может стать на порядок приятнее.
📌 15. Исчерпывающее тестирование невозможно — фундаментальный принцип тестирования.
У аналитика аналогично: невозможно проработать требования на 100%. Всегда есть как де-факто упущенные вещи (как система должна вести себя в високосный год с Сатурном в суперпозиции), так и собственная паранойя (перманентное ощущение, что мы где-то не доработали). Но: если наш арсенал — это “Глагольте, что нужно сделать”, то объем неполноты будет критичным. Если же владеем полезными техниками (”Построю-ка я модель/словарь данных”, “Пропишу сценарии юз кейсов с анализом всех негативных сценариев”, “А тут уместно ляжет диаграмма состояний, чтобы понять путь объекта данных”), мы самим инструментарием резко сокращаем неполноту и закрываем большинство гэпов.
📌 3. Не берите на себя чужие активности.
Хех, а я уже давно писал похожую заметку тут: https://t.me/itmineba/47, https://t.me/itmineba/48. Рекомендую почитать, если вы тот самый БА, который проектирует бэдешки и чует, что что-то в жизни пошло не так.
📌 6. Согласуйте формат отчетов о дефектах с разработчиками. Для нас тут посыл еще критичнее, ибо наша документация в идеале должна быть на вес золота. Снова отправлю в архинужную заметку своего авторства о том, как не писать доки для сферической ЦА в вакууме: https://t.me/itmineba/46.
📌 11. Самый лучший способ разобраться в технологии – разработать свой сервис для автоматизации или упрощения быта для помощи себе любимому.
Я периодически советую для прокачки техбазы стать на время джун-девелопером. План нехитрый: если не знаем, с чего начать, берем веб-приложения как наиболее частый тип решений и пробуем запилить нечто базовое по любому учебнику для чайников (например, сайтец с CRUDL-менеджментом товаров). Нынче это в разы проще: дорогой чатик, проведи меня как ментор с заданиями по циклу разработки с нуля: фронтенд на простейших вещах (HTML, JS), бэкенд для обработки данных (например, на PHP), БД для хранения этих данных, хостинг и развертывание. Что мы поймем: алгоритмизацию, что такое код и как он работает, принципы работы веб-систем и их архитектуру, всякие фишки а-ля https, сертификаты, куки, домены и пр. Сириусли, с таким опытом наша коммуникация с командой может стать на порядок приятнее.
📌 15. Исчерпывающее тестирование невозможно — фундаментальный принцип тестирования.
У аналитика аналогично: невозможно проработать требования на 100%. Всегда есть как де-факто упущенные вещи (как система должна вести себя в високосный год с Сатурном в суперпозиции), так и собственная паранойя (перманентное ощущение, что мы где-то не доработали). Но: если наш арсенал — это “Глагольте, что нужно сделать”, то объем неполноты будет критичным. Если же владеем полезными техниками (”Построю-ка я модель/словарь данных”, “Пропишу сценарии юз кейсов с анализом всех негативных сценариев”, “А тут уместно ляжет диаграмма состояний, чтобы понять путь объекта данных”), мы самим инструментарием резко сокращаем неполноту и закрываем большинство гэпов.