Нечего так быстро кликать!

По мотивам статьи Алексея Лупана «Слишком быстро кликаю мышкой?» вспомнился довольно часто возникающий баг на сильно загруженных JavaScript'ом страницах.
Если на открытой странице несколько раз достаточно быстро кликнуть на элементе, с которым работает JavaScript, то проявляют себя JavaScript'овые ошибки.
Т.е. если после нажатия на данный элемент должен проработать массивный скрипт, то нетерпеливые пользователи могут и не дождаться завершения его работы, нажав на другие элементы страницы. Эти действия в итоге вызывают конфликты и ошибки неопределения объектов. Один скрипт удаляет объект, на который сркипт второго элемнта ссылается.
Такая ошибка часто проявляет себя, когда не учитываешь время подгрузки элементов при автоматизации. Мой QTP при обращении к таким элементам научен ждать хотя бы секунду...
В ответ на такие ошибки программисты обычно говорят/кричат/ругаются/советуют (подчеркнуть необходимое) «Не.... так быстро кликать мышкой!!!»

Текст сообщения и комментарии...

Из-под пера Maksim Grinevich

Тэги: , , | 0 ответов, оставьте свой...

Когда приоритеты теряют силы...



Почему в жизни проекта наступают моменты, когда появляется большое количество issues с максимальными приоритетами? Для этого есть несколько причин, и они на первый взгляд вполне уважительны, чтобы так поступать...
Но бывают моменты, когда стоит задуматься, а так ли это сейчас важно. Конечно, влиять на начальство не так и легко. Зачастую даже team leads не могут изменить то, что так красноречиво описал в письме ПМ или project owner.
«Предупрежден, значит защищен» — гласит народная мудрость. Мы ей поверим, и попытаемся разобраться, чем это грозит нам — team lead’ам и обычным тестировщикам.
1. Задачи, которые находят тестировщики не имеют наивысшего приоритета, за редким исключением showstopper’ов. В итоге может получится ситуация, когда важные задачи не будут реализованы из-за реализации задач с неправильно выставленным приоритетом.

2. Неверная приоретизация заразительна — пройдет время, и вот уже все ставят более высокие приоритеты исходя не из сдравой логики и важности для проекта, а исходя из важности и «удобности» для этого лица — не важно ПМ он или junior тестировщик.

3. Неверные приоритеты демотивируют сотрудников: создается впечатление, что плохо работает, раз столько ошибок найдено уже после релиза приложения.

Этот список можно продолжать, но стоит лучше обратить свой взгляд на решение проблемы.

Решение, хоть и не идеально, но оно есть — таблица критериев приоритета.
Сия таблица не есть что-то новое, это скорее хорошо забытое старое.
Суть заключается в том, что в начале проекта (или по необходимости) ключевые фигуры проекта договариваются об единых правилах для назначения того или иного приоритета.

Безусловно, бывают исключения, но только как исключения, а не как правило.

А у вас как обстоят дела с приоритетами. Все их правильно устанавливают?

Текст сообщения и комментарии...


Ускорение работы QTP: функции в отдельном файле


Заметил такую особенность: если функции в Quick Test Pro выделять в отдельный *.vbs файл, то скорость выполнения операций возрастает значительно.


Поэтому теперь у себя в коде стараюсь как можно больше всего выносить в Associated Function Libraries.

Текст сообщения и комментарии...


А так ли нужны test cases ?


А так ли нужны test cases, когда нет времени на регрессионное тестирование вообще?

В небольшой фирме, где я сейчас работаю, времени на тестирование выделяется ровно столько, сколько необходимо на верификацию bugs, проверку новых features и прогонку smoke теста при выпуске нового патча.

Я привык относится к тестированию более систематически — прочитал книги Канера и иже с ним, в подборке куча регулярно читаемых «светил» отрасли и т.д. (здесь умышленно не касаюсь практического опыта) — и считаю, что хорошо построенный процесс тестирования (читай всей разработки) приводит к хорошему результату.

Но совсем недавно, на очередном team meeting, мне подумалось: А зачем писать test cases, если их никто не использует? (Честно говоря, они нужны только нашему заказчику, да и то раз в год...)

Подумал... и сам испугался: неужели я ставлю себя умнее, чем все эти умудренные опытом люди? Но потом мне вспомнилось цитата какого-то умного человека «документ пишется не для документа, а что бы документ использовался» (вольная интерпритация)

И в итоге вывод, который я сделал для себя, гонка за «процессом», «как нужно», «как написано» и т.д. не приводит к результату, если в этом нет необходимости.
Вода течет только туда, где есть место — «правильный» процесс тестирования нужно внедрять там, где без него невозможно жить, а «сопокойные» места (где нет проблем) лучше не трогать.

Текст сообщения и комментарии...


Тестировщик? Тестировщик!

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

Я считаю, что по отношению к своей профессии можно определить, на сколько профессионален данный специалист. Если для него работа тестировщика что-то низкое и в планах перейти в программисты, аналитики и т.д., то не состоится данный "специалист" как инженер по качеству... "Ну, не судьба..."

Если же человек при оглашении своей специальности говорит с гордостью "Тестировщик!" или "Инженер по качеству" (что звучит солиднее), то уже один этот факт показывает, как человек может работать.

Конечно, крикунов-лузеров-непрофессионалов достаточно. Но ведь и я не отменяю важность знаний и умений. Я лишь подчеркиваю, что, ко всему прочему, важно присутствие удовлетворения своей работой и профессиональной гордости...

Текст сообщения и комментарии...