Несколько месяцев назад мой коллега Макс прислал мне заинтересовавшую его ссылку со списком когнитивных искажений человека. Читая описания разнообразных ловушек мышления, я понимала, что вижу проявления многих из них как в повседневной жизни, так и на работе. Изучив вопрос, решила поделиться с коллегами: впервые статья вышла на английском языке в журнале компании Logeek Magazine, сейчас же я хочу поделиться с более широкой аудиторией, разместив на DOU.
«You should work to reduce your biases, but to say you have none is a sign that you have many» — Nate Silver
Существует прямая связь восприятия человека с образом его мыслей, мнением относительно различных ситуаций. Не всегда мышление и мнения человека объективны — в них могут наблюдаться систематические ошибки и отклонения. При возникновении подобных отклонений видимого от реального, говорят о ловушках мышления или же, научным языком, о когнитивных искажениях.
Ловушками мышления называют стандартные, шаблонные отклонения в мышлении человека, основывающиеся на деформированных убеждениях.
Люди живут в собственной реальности, основанной на их восприятии окружающей действительности. Именно на этой реальности базируется их поведение и взаимоотношения с окружающими. Часто причиной нелогичного поведения, неверных выводов и нелогичных интерпретаций являются именно присущие людям ловушки мышления.
Программное обеспечение неизменно создается людьми, тестируется людьми и, в большинстве случаев, используется людьми. И каждый человек в этой цепочке подвержен собственным когнитивным искажениям.
Запись доклада Николая Юденко на онлайн-конференции Chief ConfeT&QA.
«Ты не можешь контролировать то, что ты не можешь измерить». Том ДеМарко
Надеюсь, что слушатели знакомы с понятием метрик в разработке ПО. Я хочу рассказать об их использовании конкретно в тестировании, делая упор на практическое применение.
Как оценить выполненный объем? Или как оценить планируемый объем? Что сказать прожект менеджеру о состоянии проекта, его качестве? Как формализовать такие понятия в тестировании как «хорошо», «плохо», «нормально», «еще немного», «никогда»? Как и главное на основании чего прогнозировать и планировать работу отдела тестирования? Когда мы закончим тестирование? Зачем нам столько тестировщиков? Как нам поможет автоматизация? Как мы можем влиять на разработку проудкта?
С подобными вопросы периодически сталкивается практически каждый тест менеджер (Test Manager) или ведущий тестировщик (Test Lead). Я хочу рассказать и показать как мы можем «измерять тестирование» на разных этапах жизненного цикла ПО: от изучения требований до написания автотестов, от тест дизайна до регрессии, от функционального тестирования до внедрения.
Как при помощи «линейки и калькулятора» улучшать процесс тестирования и как следствие весь процесс разработки.
Год назад произошло интересное – придумали необычный способ тестировать наш продукт. Подход повлиял на все процессы в компании и сказался на росте клиентской базы. Сейчас проведено уже более 50 тестов, и есть чем поделиться.
Метод скорее относится к инструментам Customer Development и затягивает в анализ всю команду разработки. Каждый тест с интересом смотрят и программисты, и дизайнеры. Мгновенно разгораются споры и обсуждения, как пофиксить баг или UX-проблему. График роста числа активных пользователей системы в день
Пробовал рассказать про подход другим продуктовым командам, но без примеров тема остается не раскрытой. Одна команда из четырех попробовала – и тоже получила отличный результат. Под катом – попробую рассказать подробно о том, как не совсем обычно мы тестируем YouGile, с примерами и деталями.
Все программы, которые мы тестируем, работают с информацией. Когда одна и та же информация хранится в разных местах, то это вызывает проблемы при работе — неясно, где самая актуальная информация; при изменении надо найти все копии и синхронно их изменить; сложно разделять права доступа. Это является источником потенциальных проблем.
Во вводной лекции курса "SQL для тестировщиков" мы рассказываем, как реляционные базы данных помогли решить эти проблемы и заняли лидирующее положение в области хранения данных. Банки, страховые компании, интернет магазины используют реляционные базы данных в своих приложениях.
Чтобы не пропустить ошибок при тестировании программ, работающих с базами данных, нужно учитывать их особенности. Лекция знакомит вас с основами реляционных баз данных — объясняет структуру хранения информации, принципы связей между данными и существующие ограничения.
В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.
Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.
Автор: Алёна Соколова