Сегодня День Знаний, и по всей стране школьники отправляются грызть гранит науки.
Наверное они верят, что вот ещё немного осталось до окончания школы -- и не надо будет больше учиться! Как бы не так. В школе вы учились учиться, а после её окончания вам предстоит учиться работать. А потом осваивать новые профессии, изучать новые технологии, повышать квалификацию. Но не стоит печалиться, ведь учиться так интересно!
Поэтому мы хотим поздравить с этим праздником всех тестировщиков, стремящихся к знаниям, но в первую очередь -- тестировщиков-джуниоров. А также их наставников, менторов, кураторов и прочих причастных.
С Днём Знаний, коллеги!
А для тех, кто постоянно развивается, мы предлагаем наше расписание тренингов на сентябрь-октябрь. Мы представляем тренинги разного уровня по разным областям тестирования.
Скоро 2016 год - яркий, наполненный бурными событиями, легкий и веселый — таким обещает быть год обезьяны.
Уже сегодня нужно задумываться о том, что подарить коллегам айтишникам на Новый год…
Мы сделали недорогой, но при этом красивый настольный календарь, сочетающий символику нового года и айтишную тематику. Мы надеемся, что он станет отличным подарком и порадует всех кто работает в it-сфере: программистов, тестировщиков, аналитиков, менеджеров.
В своей работе мы сталкиваемся с багами каждый день. Какие-то баги мы легко узнаем и ловим их, а на какие-то не обращаем внимания. Наш календарь напомнит о том, что баги бывают разные, а обезьяна, символ нового года, продемонстрирует их так, что даже ребенок это запомнит.
Доклад Ирины Ивановой на на встрече Tallinn DevClub.
Все люди время от времени склонны к когнитивным искажениям – так называемым, ловушкам мышления. Каждый род деятельности, в свою очередь, склоняет к тем или иным ловушкам в разной степени. При тестировании, например, можно легко найти зависимость или, наоборот, случайность там, где их нет. Или найти сложный критический баг, но пропустить простой.
Многим знаком инструмент Selenium. Это стандарт de facto (а вскоре и de juro) в области автоматизации веб-приложений и мобильных приложений. Невероятно популярный инструмент. Но удивительно то, что Selenium развивается без чёткого плана. С одной стороны, это вполне объяснимо – команда разработки представляет собой группу энтузиастов, работающих над проектом в свободное время. С другой стороны, непонятно, почему коммерческие вендоры не могут повторить этот успех. Вот вы верите в то, что такое возможно?
Концепцию предвзятости я понимал смутно, пока не прошел курс Джеймса Баха "RST". Смысл понятия в том, что зачастую мы видим то, что наш мозг, наша психика хотят видеть, а не то, что существует на самом деле.
В целом, такая профессия, как тестировщик, существует именно благодаря предвзятому отношению.
Представим разработчика, создающего страницу регистрации для нового приложения. Он регистрирует нового пользователя, вводя свое имя, почту, дату рождения, и получает сообщение "Добро пожаловать, Стюарт Кук!"."Все работает", заключает разработчик, и переходит к следующей интригующей задаче.
Можем ли мы сказать, что регистрация была протестирована? Разработчик ввел данные, увидел то, что и хотел увидеть - приветствие системы - и убедился, что все работает как надо.
Все мы попадались на эту удочку не раз (я, по крайней мере, попадался) - один тест ничего не доказывает. Осознание, что мы склонны делать вывод "все работает", исходя из одного-единственного подтверждения - ключевой момент курса "Быстрое тестирование".
Ввести данные и получить сообщение "Привет, Стюарт" - неплохой старт. Но до финиша еще далеко.
Вдруг это просто сообщение? Что, если учетная запись не была создана? Мы можем проверить базу данных, или попробовать войти в систему, чтобы убедиться, что учетную запись можно использовать. Если разработчик еще не создал страницу авторизации, придется ограничиться базой данных. Вы же собирались ее проверить, правда?
А если мы зарегистрируемся как Вася - мы тоже получим сообщение "Привет, Стюарт"? Мелочь, а неприятно. Что, если поля регистрации будут принимать значения любой длины? А если мы введем туда полную ерунду - удастся ли создать учетку?
27-28 ноября в Москве пройдет уже Восемнадцатая Международная конференция в области обеспечения качества ПО «Software Quality Assurance Days».
В этом году тестировщики СНГ выбрали своей столицей столицу России, где пройдёт уже 18-ая Международная конференция. Москва удобный логистический, культурно-исторический и технологический центр, который объединяет в себе лучших ИТ-компаний, с интересными докладчиками и широкими возможностями для культурного отдыха после конференции.
Конференция пройдёт в известном ивент-центре ИнфоПространство.
На данный момент активно формируется программа конференции. Всех желающих выступить с докладом просим регистрироваться по адресу. Напоминаем, что докладчики участвуют в конференции бесплатно.
Также открыта регистрация на конференцию по минимальной цене!
Как прошла прошлая конференция в Минске можно увидеть:
Вначале я рассматривал тестирование, разработку и людей, вовлеченных в эти процессы, примерно так:
Затем я решил, что эти две области перекрывают друг друга. Тестировщики иногда занимаются разработкой, а разработчики могут привлекаться к тестированию.
Но позже я понял важную вещь. Тестировщики это тоже разработчики - они же участвуют в процессе разработки программного обеспечения! И, надеюсь, приносят пользу.
Автоматизация в тестировании применяется гораздо шире, чем может показаться на первый взгляд. Этим занимаются не только специально назначенные люди, у которых на бейджике (или на лице) написано "автоматизатор". В традиционно "ручном" тестировании автоматизация тоже встречается, пусть и в меньшем количестве.
Посмотрите небольшой видеоролик "Автоматизация в тестировании", записанный Алексеем Баранцевым, а потом посмотрите вокруг -- есть вероятность, что вы активно используете автоматизацию, даже не задумываясь об этом!
А если задуматься и подойти к этому осознанно, не окажется ли внезапно, что сфера применения автоматизации в вашей повседневной работе может быть расширена, иногда даже без приложения сколь-нибудь значительных усилий?
Сообщение об ошибке, если его вывод вообще необходим, должно содержать полезную информацию как для пользователя, так и для техподдержки и разработчиков. Ниже предлагаются несколько пунктов, о которых стоит помнить при обработке ошибок и составлении сообщения об ошибках.
Начальные знания о сообщениях об ошибке
Программа выводит сообщение об ошибке в ответ на необычную или исключительную ситуацию, которую не может разрешить самостоятельно. Если программа написана корректно, сообщения об ошибке у нее выводятся нечасто: везде, где это возможно, программа сама справляется с возникающими проблемами и не обращается за помощью к пользователю.
С этой точки зрения можно выделить два класса плохо написанных программ. Во-первых, это программы, которые не могут самостоятельно исправить ошибку, либо требуют слишком много действий от пользователя. Во-вторых, программы, – и о них мы поговорим подробно, – которые при возникновении реальной проблемы выдают пользователю неадекватные сообщения об ошибке.
Конечно, самое лучшее сообщение об ошибке – это его отсутствие. Если что-то пошло не так, программа должна использовать все доступные средства, чтобы как можно быстрее исправить ошибку. Например, она не должна выводить сообщение о том, что файл не найден, если поиск не был произведен достаточно тщательно. Как минимум, разработчик должен предусмотреть возможность поиска файла на всех жестких дисках. Если файл был найден не в ожидаемом месте, программа должна либо обновить путь к файлу, либо создать копию файла в требуемом месте. В любом случае пользователя беспокоить не стоит.
Если вывести сообщение об ошибке все же необходимо, не тратьте время пользователя впустую, если можно заранее предсказать возникновение проблем. Например, программа установки не должна начинать копирование файлов, пока не произведена проверка на наличие свободного места на диске. Путём несложных вычислений можно определить, достаточно ли свободного места на диске, но большинство программ не делает такую проверку. Если программа установки прерывает процесс, когда ей требуется перезаписать какой-нибудь файл – это тоже плохо, так как вынуждает пользователя постоянно следить за процессом установки.
При этом не стоит полагаться и на операционную систему. Удивительно, но команды DOS COPY и XCOPY до сих пор не проводят проверку на наличие свободного места на диске перед началом копирования файлов; вместо этого копирование начинается “вслепую” с надеждой на то, что места будет достаточно. Windows ничуть не лучше, эта система тоже не проверяет диск на наличие свободного места перед копированием файлов. Хуже того, если вы одновременно копируете несколько файлов, Windows прерывает процесс копирования после обнаружения первой ошибки и “забывает”, какие файлы были выделены для копирования.
При написании программы старайтесь предугадать условия возникновения ошибки и реакцию системы на эти ошибки. Постарайтесь выполнить задачу пользователя максимально точно, и не относитесь к ошибке как катастрофе (если, конечно, это не является реальной катастрофой). Запомните состояние программы до возникновения проблемы и дайте пользователю возможность легко вернуться в это состояние. Всегда пишите функции, которые возвращают статус выполнения и используйте уникальный код ответа для каждой проблемной ситуации. Если возвращается код ответа, который свидетельствует о возникновении проблемы, обычно удаётся собрать достаточно информации, которую можно передать ответственным за исправление ошибки специалистам. С другой стороны, помните, что внутренние сбои в работе программы, с которыми она может справиться самостоятельно, не должны беспокоить пользователя, поэтому сообщения о таких ошибках не должны выводиться без крайней необходимости. Также в сообщении нужно четко разграничить информацию, предназначенную для пользователя, и необходимую для сотрудников техподдержки.
Мы решили в очередной раз перезапустить проект Панбагон. На этот раз в формате группы в фейсбуке.
Для тех, кто не в курсе, расшифруем значение названия этого проекта. Пантеон -- так в Древнем Риме назывался храм, посвящённый всем богам. А наш проект посвящён не бОгам, а бАгам, поэтому он так и называется. Здесь мы выставляем на всеобщее обозрение баги, найденные случайно или специально в тех программах, которые мы использовали, или на тех веб-сайтах, которые мы посещали.
Целью является не простая фиксация чужих ошибок, не желание посмеяться над нерадивыми разработчиками и тестировщиками, которые пропустили дефект. Нам бы хотелось, чтобы не просто публиковались описания багов, но и были попытки понять и описать, чем вызван этот дефект, почему он остался необнаруженным, какие приёмы, техники, инструменты тестирования могли бы помочь в его поимке, как можно профилактическими мерами добиться того, чтобы такие баги вообще не возникали.
Скоро 2016 год - яркий, наполненный бурными событиями, легкий и веселый — таким обещает быть год обезьяны.
Автор: 