Просмотров: 17862
Дата последнего изменения: 23.09.2021
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
4
5
Откуда и на каких этапах берутся ошибки?
Программист
- Менеджер/аналитик не знает точного сценария использования будущего продукта.
- В техническом задании нет четких задач.
- Клиент сам не знает, чего хочет, или думает, что знает.
- От вопросов программиста на первых этапах вздрагивают, т.к представители клиента не компетентны в данной сфере.
Как снизить число ошибок в данном случае:
- Product Owner/менеджер/аналитик/представитель клиента – должны давать компетентные ответы (здесь можно внедрить KPI и премии) на вопросы программиста о предметной области.
- Представитель заказчика – должен быть также компетентен и доступен для общения.
- Проведен предварительный анализ сценариев использования, объектов и отношений между ними.
- На вопросы программиста должны быть ответы, обсуждения и принятие решений.
- Программист обеспечен современными инструментами разработки - IDE.
- Программист использует систему контроля версий – SVN, git, Mercurial.
- Программист документирует код или пишет «понятно» для себя и других.
- Программист может писать модульные тесты.
- Программист должен сделать функциональные тесты.
Всех ошибок все равно не избежать, но их будет значительно меньше.
При изменении каких-либо требований помогает использование понятного модульного/объектного кода, и опять же на помощь приходят функциональные и модульные тесты, которые позволяют быстро протестировать сделанные изменения в коде.
Верстальщик
- Разные браузеры и их версии.
- Разные разрешения экрана, ОС.
- Разные диалекты Javascript.
- Непонятные сценарии использования – снова некого спросить, прочитать (ну как так???)
- Можно знать одновременно PHP, JS, CSS и HTML
- НЕЛЬЗЯ УМЕТЬ одновременно PHP, JS, CSS и HTML! Нельзя экономить на специалистах.
Как снизить число ошибок в данном случае:
- Создать стенд с разными версиями браузеров.
- Selenium – автоматические тестирование.
Тестировщик
Тестировщику отводится отдельная роль в продукте:
- Тестировщик - это призвание, неподдельная любовь к совершенству в простоте.
- Тестировщик - это свежий взгляд.
- Тестировщик - это умный, злой и въедливый «параноик», знающий требования не хуже:
- Клиента;
- Менеджера проекта;
- Аналитика;
- Программиста.
Системный администратор
Чтобы не создавать ошибок в продукте сисадмин должен знать и уметь:
- Понимать архитектуру веб-проекта - какие сервера, какие порты связаны между собой.
- Где и что настраивается и почему.
- Обновлять программное обеспечение серверов.
- Знать о распределении сервисов по машинам.
- Проводить мониторинг, аналитику.
- Проводить нагрузочные испытания.
- Проводить резервное копирование.
Сисадмин должен обеспечивать контроль качества работы веб-проекта изнутри.
Клиент
Большую ценность в тестировании представляют ранние отзывы от клиента.
- Разработчик - не эксперт в предметной области, только клиент может более точно оценить работу системы перед сдачей проекта.
- Короткие итерации, Product Owner, демонстрации (Scrum) - нужно чаще встречаться с клиентом, показывать промежуточные этапы работы.
- Customer representative (представитель клиента в офисе разработчика) - наличие такого человека сильно упрощает процесс разработки и тестирования.
- Наличие хоть какой-то бюрократии и здравого смысла позволит не затягивать процесс разработки надолго.
- «Секрет» бета-версий: привлечение сотрудников клиента к тестированию позволит еще больше охватить область тестирования и увеличить качество тестирования. Последнее время выгоднее тестировать большие проекты, выпуская их как бета-версии.
Тестирование продукта как на этапе разработки, так и в процессе изменения какого-либо функционала в работающем проекте с помощью функциональных тестов очень важно. Причем, чем больше функциональных тестов покрывают систему, тем больше ошибок будет найдено на этапе тестирования и разработки.