Показаны сообщения с ярлыком здравый смысл. Показать все сообщения
Показаны сообщения с ярлыком здравый смысл. Показать все сообщения

понедельник, 16 апреля 2012 г.

Привет, Аноним в поисках вопросов

Внезапно мне пришёл комментарий:

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

вторник, 21 декабря 2010 г.

Правильный багрепорт 2: точность описания и исследование проблем

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

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

четверг, 16 декабря 2010 г.

Авралы как производная от качества планирования

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

Подробнее о каждом из типов.

вторник, 16 ноября 2010 г.

Рунглиш. Новояз. Жаргон.

Когда я впервые после учебы пришел работать в серьезную IT-компанию, мне, безусловно, пришлось учиться быстро и многому. И прежде всего мне пришлось учится понимать речь своих новых коллег. В первую неделю, натурально, я понимал от силы треть, когда ребята обсуждали между собой какие-то рабочие моменты. Общаясь со мной, они старались говорить попроще, но и тогда половина слов и их сочетаний оставались непонятными.

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

Профессиональный жаргон - дело не новое, и думаю большинство с ним сталкивалось в своей работе, а уж в сфере IT - просто все. Жаргон свойственен любой профессии; где-то его больше, где-то меньше. В IT обилие жаргона связано, на мой взгляд, прежде всего с тремя аспектами: