07.08.11
Сегодня мы с Женей в рамках подготовки к Ironman вышли на свой первый старт при поддержке фотографа Тани....
26.07.11
Небольшой граммарнаци пост. Cоображения об использовании слова «функционал» в ИТ.
19.07.11
«Эта книга, рассказывающая о научном подходе к разработке интерфейсов, может быть полезна как для создателей программного обеспечения, так и для руководителей проектов»
Сегодня мы поздравляем с Днем Рождения одну из самых прекрасных девушек нашего коллектива, Юлию Самойлову.
Этого человека в нашем коллективе знают и любят все. И вовсе не потому, что Юля бухгалтер =) Она очень добрая и отзывчивая девушка. К ней всегда можно обратиться с любым вопросом, она всегда проконсультирует, поможет и подскажет, что и как делать!
Мы желаем Юлии всегда оставаться таким же прекрасным человеком, никогда не унывать, крепкого здоровья и хороших друзей.
А с профессиональной стороны желаем: порядка в документах, всегда верных отчетов, чтобы баланс сходился точно!
Многие разработчики не раз задумывались над вопросами: так ли сложно тестировать? Зачем приглашать людей для выполнения работы, которую программист и сам в силах выполнить? И наконец, зачем вообще нужен тестировщик?
Есть два варианта: если проект небольшой и программист может справиться с проверкой всех функций самостоятельно, то конечно тестировщик не нужен. Но если проект представляет собой приложение, в котором функционал включает в себя не только функцию регистрации или авторизации пользователя, то здесь однозначно требуется тестировщик.
Тестировать можно еще до начала процесса разработки. Существует подход, который довольно популярен среди разработчиков — TDD (Test Driven Development). Он представляет собой тестирование приложения еще на моменте проектирования. Чем это может быть полезно? Тестировщик начинает писать тесты по проектным материалам. Благодаря этому очень детально продумывается функционал приложения. Разработчик может сразу прикинуть, какой функционал наиболее важен и удобен для пользователя, а какой можно отложить или сразу «выкинуть» из проекта. То есть получается, что структура и функциональность детально продумываются еще до начала реализации, это является несомненным плюсом. Другое преимущество такого подхода заключается в том, что во время разработки уже есть готовые автоматические тесты. Это помогает разработчикам полностью контролировать все этапы сборки проекта, быстро находить ошибки и исправлять. Основной плюс такого подхода — значительное уменьшение временных затрат на разработку за счет быстрого отлова и исправления багов и хорошо продуманного функционала.
Но если проект уже в процессе разработки, возможно даже есть бета-версии программы, которые отданы в руки пользователям. Что же делать в этом случае? Здесь тестировщик разбивает процесс тестирования на несколько этапов.
Во-первых, smoke-тестирование. Оно представляет собой минимальный набор тестовых случаев с целью нахождения явных ошибок (например, при инсталяции или соединении с базой данных). Негативный результат выполнения таких тестов говорит о том, что дальнейшее более углублённое тестирование не имеет смысла.
Во-вторых, приемочные тесты. Они нужны, чтобы определить минимальные критерии по которым заказчик будет оценивать ваш продукт. Приемочные тесты охватывают основной функционал, без которого приложение можно считать нерабочим (функции входа/выхода пользователя, регистрация, просмотр каталога продуктов, поиск, покупка товаров).
В-третьих, функциональное тестирование. На этом этапе уже более подробно рассматривается функционал самого приложения, продумываются позитивные и негативные тесты, нетривиальные тестовые случаи.
В-четвертых, нагрузочное тестирование. Такое тестирование крайне необходимо для приложений, которые являются многопользовательскими, ведь в них могут работать около 100 пользователей одновременно, а может и больше. Такие тесты дают чёткие результаты по проблемным местам приложения при большой загрузке.
Вопрос по процессу тестирования немного освещён. Но теперь возникает другой: для чего еще может пригодиться тестировщик? Ведь всему этому можно обучить программистов. Не стоит забывать, что тестировщик смотрит на приложения глазами пользователя. Куда сложнее протестировать часть приложения, которая была написана тобой же. Тестировщик не знает внутреннего строения приложения, он не видит кода и действует интуитивно, так как себя повел бы простой пользователь. А еще тестировщик может оценивать приложение со стороны эргономики, функциональности, удобства использования, дать оценку понятности и дружелюбности интерфейса.
Рады сообщить, что мы присоединились к одной из самых популярных в мире социальных сетей Twitter.
Теперь вы можете занести наш микроблог https://twitter.com/fabit_ru в свою ленту и всегда быть в курсе свежих новостей о новых проектах, будничных делах компании, о наших сотрудниках. Мы будем стараться в оперативном режиме рассказывать вам о последних новостях в сфере информационных технологий Белгорода и страны, а также о многом другом. Фоловьте, друзья!
Вы можете посмотреть вакансию в соответствующем разделе.
Вы можете посмотреть вакансию в соответствующем разделе.