Testing is a skill

С момента написания первой части отчета, появились некоторые дополнительные материалы. Я решила не редактировать предыдущий пост, а вынести в отдельный. На первой части встречи, в процессе обсуждения методик тайм-менеджмента, Антон Столяр рассказал про один интересный алгоритм. На его рисунке это выглядело забавно, но на форуме он мне дал ссылку на более упорядоченный вариант. Итак, диаграмма рабочего процесса: Следуя этой схеме, мы можем рассортировать ежедневные задачи, которые поступают к нам для решения и оптимизировать свое рабочее время. Кстати, в комментах к предыдущему посту   Сергей Атрощенков дал ссылку на такую же диаграмму, только в более подробном и оформленном варианте - тыц . Спасибо ему за это. Далее, я упоминала в первой части отчета про составление характеристики идеального тестировщика в вакууме. Нам остались на память такие фото: На данный момент я их только примерила на себя (особенно интересны были личные качества, некоторых мне явно не хватает) :), а вот до

Вчера состоялась третья официальная встреча минского сообщества тестировщиков ПО. На обсуждение были заявлены 2 темы - "Тайм-менеджмент" с презентацией от Виктории Бутич (за что ей большое спасибо :)) и "Методы оценки работы QA", проведенная в формате круглого стола. Встреча проходила в конференц-руме, любезно предоставленном нам компанией EPAM Systems.

Чем больше работаю в тестировании, тем требовательнее становлюсь к качеству интернет-сайтов. Последние пару недель я периодически мониторю сайт белжд (www.rw.by), чтобы контролировать наличие свободных билетов на поезд на определенную дату. Каково же было сегодня мое удивление, когда, зайдя на сайт, я не увидела привычный интерфейс! Раньше информация о расписании находилась в разделе "Пассажирские перевозки". Поэтому я, естесственно, зашла туда. Открылся дропдаун со значениями, но ни один из них не подразумевал наличие необходимой мне информации. Но я зашла в каждый раздел, мало ли :) не нашла. Потом я просмотрела все менюшки сайта. Нет информации. Потом я заметила поиск и собралась им воспользоваться, но ВНЕЗАПНО глаз наткнулся на то, что мне было нужно. Это был баннер слева вверху. Зачем важную информацию размещать на баннере - непонятно. Тем более, что многие ставят плагины к браузерам, чтобы не смотреть рекламу. P.S. а поиск я все-таки проверила. Чтобы уменьшить колич

На работе готовимся к предстоящему релизу и изучаем те Change Requests, которые будут внедрены. В связи с этим читаю много всяких переписок. И вот покажу на примере, что сегодня улыбнуло (цвет имеет значение, так было в письме, суть разговора не сильно важна): Пишет Damian, в своем письме приводит кусок разговора: SP: уточняет какой-то момент, правильно ли понимает DR:   подтверждает, говорит то же самое своими словами Следующее письмо от Sotha:  Дэмиан, уточни, пожалуйста, написанное красным  Ответ Damiana: Читай то, что написано синим  Письмо Sotha: ок, спасибо за помощь. Ну и дальше скучная переписка ))) P.S. в последнем сообщении нет иронии, там видно было из дальнейшей переписки

В рабочие часы все мы составляем тест кейсы, выполняем их, заносим баги и т.п. Но вот work-day закончен. А останавливается ли на этом наше поведение, как тестировщиков, до следующего рабочего дня? Когда приобретаем новую вещь, что мы делаем? лезем в инструкцию или тыкаем в кнопочки посмотреть, что будет? По дороге домой не высматриваем ли какие-то мелкие детали? А самое интересное, когда вы дома смотрите какие-то свои сайты в интернете и вдруг находите баг - ваши действия? Лично я - честно отправляла несколько раз баг-репорты :)  А если собеседник опечатывается - говорим об ошибке или терпеливо закрываем глаза? Наверное, нельзя быть тестировщиком на работе и не-тестировщиком в свободное время. Работа влияет на нас и наше поведение. Я стала внимательнее, стала задавать более правильные и корректные вопросы в разговорах. Стала объяснять гораздо лучше какую-то информацию другим. И терпеливее относитьсяк тому, когда кто-то исправляет мои ошибки :)

Еще на тренингах, когда я только пришла в компанию и совсем мало знала о тестировании, мне в голову заложили одну хорошую вещь: писать в описании проблемы "ничего не работает" - недопустимо. Сегодня одна девушка, под начальством которой я долгое время работала, попросила помочь ей проретестить один дефект. И она мне переслала письмо, в котором описывалась проблема. Там было несколько строчек и скриншоты. Я прочитала один раз, второй, третий - и все равно не поняла, что же не так! Проблема в том, что есть система и в ней генерится отчет, откуда подтягиваются данные из системы. И ошибка в том, что цифры в отчете и системе - разные. Но это на словах из письма, на деле - одинаковые (под делом я подразумеваю скриншот и приаттаченный отчет из письма). Я сделала те же шаги в тестовом энвайроменте - одинаковые цифры. Отписалась девушке, что непонятно же совсем, что не так. После чего узнала, что они уже провели консилиум из 3х тестировщиков, пришли к тому же выводу "непонятноч

Если мы работаем не в компании одного проекта, то вполне возможное явление - переход/перевод с одного проекта на другой. Так же некоторые проекты имеют свойство заканчиваться, и переход становится неизбежен. Но в данном посте речь будет не об этом. В последние пару недель я столкнулась с ситуацией, когда человека, с которым я вот уже 8 месяцев отработала бок о бок на одном стриме, переводят на другой проект. А я остаюсь. Я никогда не была на другом проекте, только на разных стримах внутри одного. Для меня разные стримы - это гуд, потому что я "пощупала" продукт с разных сторон. А разные проекты? Есть несколько мыслей, я решила их разбить на плюсы и минусы, ведь у каждой медали - 2 стороны. Итак, "за" переход: развитие новых навыков. Ведь на других проектах могут быть новые тулы, по-другому построены процессы, да даже репорты пишутся по-другому :) если на первом проекте вы достигли "потолка", то новый проект как нельзя кстати смена команды (тут можно и

Можно было сразу броситься в бой и начать описывать проблемы, уже полученные знания и просто размышления, но я решила для начала представиться. Меня зовут Лена. Чуть больше года я работаю в компании Allied Testing. Это мое первое место работы в качестве тестировщика. Пока я попробовала себя только в ручном функциональном тестировании, но в планах хочется гораздо большего. Однажды я прочитала статью Натальи Руколь -  Как развиваться начинающему тестировщику . Некоторые пункты уже были в статусе Passed, некоторые я тут же осуществила. И только по одному меня одолевали сомнения - создать свой блог. Казалось бы, ну чем я могу поделиться, когда у самой опыта совсем чуть-чуть? Но время шло, обсуждения на форумах и статьи в рассылках давали пищу для размышлений. Потом я стала одним из членов сообщества минских тестировщиков -  BelQA . Побывала на двух встречах, вопросы снова стали накапливаться, и как-то пришла к тому, что уже недостаточно это обсуждать с коллегами в кабинете. Захотелось ст