очень маленькое (0,00000000000000000000000000001);
...
Тестировщики кивают головами и говорят — «Все понятно!». А потом им предлагают строковое поле и все, ступор о_О
Что вводить в строку? Символы русские, английские, спецсимволы, циферки, перемешал — готово! Но так и робот может проверить, тестировщик то зачем?)) И как вы отловите баги, когда имя “Иван” считается некорректным, потому что распространенное? (А такое бывает — пруфлинк, поиск по «Иванов Иван Иванович»)
Тренер Ольга Назина подготовила пример тестирования поля «Имя» для своих студентов — смотрите и вдохновляйтесь! :) Столько уникальных для поля тестов, а ведь казалось бы, простая строка...
Это выдержка из лекции про классы эквивалентности курса «Техники и инструменты поиска и оформления дефектов». Без знания о классах эквивалентности и граничных значениях никуда, особенно при поиске багов. Поэтому мы сделали отдельную тему для отработки навыка. Приходите, будет интересно :)
После каждого тренинга мы просим участников написать отзыв -- что понравилось, что не понравилось. Это помогает нам в следующих тренингах не повторять ошибок и делать их лучше.
С отзывами учеников первой группы курса можно познакомиться по ссылке.
Кроме того, по уже сложившейся традиции после создания нового тренинга и завершения работы первой учебной группы Алексей Баранцев пишет “отзыв” со стороны тренера. И это тоже позволяет проанализировать возникшие проблемы, чтобы в следующий раз их избегать и делать тренинги ещё качественнее.
По нашим планам должно было получиться 12 занятий по 45 минут. Но на самом деле объём записанного материала получился в полтора раза больше. Информации действительно так много.
Но цену мы решили пока не поднимать :)
2. В начале курса мы даём участникам анкету, в которой среди прочего предлагается оценить свои навыки программирования по пятибалльной шкале. Результат оказался неожиданным -- средняя оценка примерно 3 балла.
При этом та же самая анкета показала, что почти 70% участников имеют практический опыт использования Selenium. Это вызвало некоторые опасения при подготовке заданий для самостоятельной работы. С одной стороны, они должны были быть достаточно сложными, потому что большинство участников уже работало с инструментом и простые задания будут скучны. С другой стороны, они не должны были требовать хороших навыков программирования. Насколько можно судить по результатам выполнения заданий и обсуждению в чате учебной группы -- это сделать удалось. Задания достаточно сложные, для их выполнения нужно хорошо знать Selenium (то есть внимательно смотреть и слушать лекции), но с точки зрения программирования они весьма просты.
На конференции CAST 2015 Иоана Сербан читала доклад про "Взять под контроль ваше тестовое окружение". Это захватывающая и интересная история ее личного опыта с тест-окружениями. Посмотрите запись доклада, если еще ее не видели.
Я выбрала презентацию Иоаны как основу для недавней сессии по обмену знаниями о тестировании в своей организации. Так как мы все еще работаем как распределенная команда, не очень-то практично собирать всех тестировщиков в одном месте физически, чтобы делиться идеями. Взамен я попросила их посмотреть доклад Иоаны в свободное время, а потом обсудить его во время дискуссионной сессии через онлайн-групповой чат.
За нашими обсуждениями иногда трудно уследить – множество людей печатает одновременно, однако мы подняли ряд любопытных вопросов. Мы покрыли четыре темы: стабильность нашего билда, техники для автоматизации тестов, ключевые особенности наших окружений, и люди, с которыми мы работаем над тестовыми окружениями.
Для тех, кто еще новичок в написании тестовой документации, будет интересно посмотреть выступления, в которых докладчики рассказывают об особенностях роли тест-дизайнера.
Вы можете узнать о методиках, которые используют в работе более опытные коллеги, посмотрев видеозаписи докладов с конференции QA Fest 2016.
Неплохая идея – определить и отслеживать метрики, чтобы держать автоматизационные усилия под контролем и принять меры, если метрики скажут вам, что ваши действия не приносят нужных результатов. Еще важнее возможность купаться в славе, если они-таки их приносят! Но что такое хорошие метрики тест-автоматизации? В этой статье я рассмотрю некоторые метрики, которые считаю полезными, и некоторые, без которых мир автоматизаторов вполне может обойтись. Отмечу, что я не собираюсь перечислять ВСЕ метрики, которые используются в автоматизации, но надеюсь, что упомянутые мной укажут вам верное направление.
Итак, что, с моей точки зрения, может быть полезной метрикой для отслеживания эффективности и/или результатов усилий по автоматизации?
Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?
В рамках курса мы создали специальный «бажный» сайт для тестирования. Внедрили туда 20 разных по типу ошибок. Чтобы их найти, придется применять разные техники и инструменты:
— Собрать логи.
— Проверить консоль JS.
— Найти граничные значения.
— Пройтись по туру, отмененному из-за дождя.
— Проверить разные браузеры.
— Убрать ограничение, установленное на клиенте.
— …
Сервер поднят на linux-е, куда у студентов есть доступ на чтение логов. Это позволяет применить полезные в будущем инструменты:
Putty — снять статистику, последить за логом
WinSCP — забрать лог с сервера
Grep — найти нужный стек в логе (linux)
Cygwin — найти нужный стек в логе (windows)
Еще на курсе будут использоваться:
Postman — послать POST-запрос на сервер
Perlclip — сгенерить большую строку текста
Курс запускался в два этапа — год назад вышла первая версия на 4 занятия. Мы рассказывали только то, что не зависит от “веб — не веб, линукс — не линукс” итд. Как искать, локализовывать и оформлять задачи. Материала было много! По отзывам студентов:
Ого, сколько материалов и заданий! Скучать не придется. А текст задания: "Меня обманули и обесчестили, я разворачиваюсь и ухожу." развеселил))
Но курс должен не только веселить, но и учить. Общаясь с ребятами, мы поняли просто “найти и локализовать” неинтересно. Это ведь все умеют, мы занимаемся этим каждый день.
Интересно другое:
— Как понять, кто именно сломался, если системы интегрированы?
— Как доказать подрядчику, что проблема именно на его стороне?
— Что делать, если ошибку уже пропустил?
Или технические штуки, которые пригодятся в дальнейшем:
— Залезть на сервер linux, найти нужный лог, изучить стек-трейс. — Перехватить сообщение в консоли разработчика. — Прочитать ответ, пришедший с сервера. — Найти баг кеширования на сервере.
Все это теперь есть! Мы расширили курс, теперь там девять уроков вместо четырех. И 27 домашних задания — чтобы как следует закрепить материал. Приходите к нам, если хотите взглянуть на “обычный” процесс поиска и локализации багов по новому.
Друзья, поздравляем вас с чудесным и даже немного волшебным праздником - с Новым годом!
Желаем вам всего самого лучшего в следующем году. Пусть все хорошее, что не успело произойти в 2016-м, обязательно случится в 2017-м. Желаем вам здоровья, удачи, любви и пусть самые близкие всегда будут рядом!
Новый год - это всегда планы, мечты и надежды. Мы желаем, чтобы в 2017-м вы могли воплотить в жизнь даже самые дерзкие начинания. Пусть для этого всегда найдутся силы и желание! А мы со своей стороны надеемся еще больше помогать вам в реализации профессиональных планов.
С наилучшими пожеланиями, команда Software-Testing.Ru
Время идет, появляются новые инструменты автоматизации тестирования. Влияет ли это на рабочий процесс? Конечно!
Что делать в таком случае: переписывать тесты с нуля или достаточно только немного подправить их? А как это сделать, ничего не сломав? Сколько времени придется потратить на доработку? Вопросов немало.
Коллеги на конференции QA Fest 2016 рассказали об эволюции автоматизации и поделились своим опытом актуализации автотестов:
Дмитрий Химион - Векторы развития систем автоматизации тестирования
Яков Крамаренко - Укрощаем фреймворки-динозавры используя NSelene
Иван Пашко - Теория Дарвина в тестах. Эволюция Wait-ов
Этот вопрос звучит частенько: что же делать, вот приходишь ты на работу, или на проект, и должен тестировать, а ТРЕБОВАНИЙ НЕТ!
Для некоторых из нас крайне трудно представить себя в подобной ситуации.
Если вы работали только в местах, где тест-кейсы были документированы, а спецификации присутствовали, то сама мысль об этом выглядит для вас дикой.
Но есть места, где все слишком заняты, чтобы писать требования, или им это просто не нужно.
На то есть множество причин – и очень хороших причин, хотя плохие среди них тоже присутствуют.
Но несмотря на причины, возможно, в какой-то момент вы обнаружите себя в этой ситуации и вас попросят протестировать то, для чего нет требований и, возможно, НИКТО не знает, как оно на самом деле должно работать.
Сейчас я объясню, что это вполне посильная задача – и вы не просто справитесь с ней, но справитесь блестяще, и улучшите свой навык тестировщика.
Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?
Утром 10 декабря в холле «Radisson-Славянской» можно было увидеть не только тестировщиков, но и разработчиков, которые не хотят просто «перекидывать код через стену», а ощущают значимость тестирования. В том же холле, помимо прочего, можно было поиграть в робохоккей — и поскольку в этой игре надо управлять жуками, она смотрелась на «Гейзенбаге» довольно символично.
Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?
