Перейти к содержимому

Публикации LeshaL

81 публикаций создано LeshaL (учитываются публикации только с 29 марта 2023)



#102402 Какая з/п у тестировщика ?

Отправлено автор: LeshaL 16 марта 2012 - 12:12 в Свободное общение

Да и кроме главного направления тестирования в каких еще направлениях смотреть - HTML, sql, Java? Я просматривал чужие резюме и заметил, что много чего мелькает, но что подучить, не сильно отвлекаясь от основной темы ТЕСТИРОВАНИЕ?

Одним из возможных преимуществ для работодателя может быть знание предметной области.



#93466 С чего начинать изучать тестирование с нуля! Помогите ПЛИЗ!

Отправлено автор: LeshaL 30 августа 2011 - 21:19 в Личный рост, карьера, развитие

Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?

з.ы. вроде осознал, Тестировщик должен найти проблему и передать в вышестоящие инстанции(н-р прогерам), а они уже будут решать проблему...

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

И ошибки обычно складывают в специальное место, которое называется дефект-трекером - там их все видят и когда они там - о них все знают.



#95951 SQA Days - 10

Отправлено автор: LeshaL 21 октября 2011 - 21:15 в SQA Days

Тоже хочу кружку! так и запишите +1

И еще покажите мне, плиз, кнопочку "Напечатать программу конференции", чтобы она так красиво сразу и на принтер ушла.

Программу в данный момент печатать еще рано. Для печати будет сделана специальная версия, скорее всего в PDF формате. По крайней мере сейчас планируется сделать именно так.



#104872 Процесс найма сотрудника со стороны работодателя

Отправлено автор: LeshaL 25 апреля 2012 - 21:22 в Про тестирование обо всём подряд

Добрый день!
Во-первых, хочу поддержать ребят, которые говорят о том, что тестовое задание надо давать хотя бы после интервью, а не до него. Причин несколько, думаю они будут понятны из написанного ниже. Я бы предложил такую схему:
Изучение резюме и телефонный скрининг (для определения того, что человек хочет выполнять предлагаемую работу в принципе) -> техническое собеседование (лучше когда несколько человек, всей командой не обязательно, не все любят) -> тестовое задание (опционально, в них есть несомненные плюсы) -> второе интервью для определения условий итд (желательно с руководством) -> офер (для победителя).

Во-вторых, можете посмотреть видео моего недавнего выступления о том как я работу менял. Взгляд соискателя:

В-третьих. 2-3 дня на такое тестовое задание абсолютно нормальный срок (это для тех, кто что-то подозрительное тут увидел). Не забывайте, что кандидат может иметь работу, на которой у него есть задачи, другие интервью и тестовые задания, семью итд. А лучше всего спросить самого кандидата за сколько он сможет сделать задание. Это тоже показатель.



#103692 На правильном ли я пути?

Отправлено автор: LeshaL 07 апреля 2012 - 04:52 в Начинающему тестировщику

А какие конкретно у вас затруднения с баг-трекером?
На последней конференции я кое-что рассказывал по этой теме.
http://www.slideshar...haL/ss-10392275

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



#103691 На правильном ли я пути?

Отправлено автор: LeshaL 07 апреля 2012 - 04:45 в Начинающему тестировщику

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

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



#95538 Создание вебинара

Отправлено автор: LeshaL 14 октября 2011 - 21:31 в Свободное общение

1. Если вам нравится визио или в нем хорошо выходит рисуйте в Visio! Но нужен инструмент для создания презентаций. Т.к. PowerPoint стоит денег (правда кого это в России волнует) я советую бесплатный libre office impress (http://www.libreoffice.org/download). Копируете картинку из визио, вставляете в слайд.
Учтите, на слайдах все должно быть крупным. Мелкие, детализированные диаграммы из визио могут стать абсолютно неразборчивыми и скучными.

2. Если вы выступаете первый раз - не надо никакого интерактива. Просто расскажите и ответьте на вопросы.

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

4. Если хотите сделать слайдкаст, то slideshare.net вам поможет. Регистрируетесь, загружаете слайды, загружаете звуковую дорожку доклада и синхронизируете слайды со звуком. Все очень просто. Потом можно поделиться с кем угодно.
Можно выложить отдельно звук и слайды, но это хуже. А еще хуже делают люди, неуважающие слушателей - они выкладывают на slideshare слайды и звук и не синхронизируют. Не делайте никогда так.

5. Если хотите провести вебинар, то подумайте ... и не делайте. Судя по всему опыта в этом деле у вас нет. Шансы на то, что получится сделать "живой" вебинар малы. Люди злые и если у вас будут накладки, то сделаете себе антирекламу. Запишите лучше для начала "оффлайн" презентацию со звуком. Разошлите знакомым. Анонсируйте тут на форуме.

И еще, а из какого вы города? Уже много где есть сообщества тестировщиков, можно договориться с организаторами и выступить на одной из встреч (если у вас в городе оно есть, а если нет - то кто мешает создать? Опытом создания готовы делиться). Лучше начинать с "живых" презентаций, когда видны глаза слушателей и есть обратная связь.



#100548 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 12:43 в Автоматизированное тестирование

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

Интересная идея, надо обдумать. Хотя она не отменяет прохождение по специфицированным (читай acceptance) сценариям. А тестирование сценариев, конечно же, не отменяет функционального тестирования.



#100549 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 12:53 в Автоматизированное тестирование

Походу можно новую тему открывать :) про уровни автоматизации тестирования :)

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.
2) ReqTests - набор тестов написанных по спеке, покрывающий как отдельные функциональные требования, так и описанные сценарии. Второе в будущем может трансформироваться в отдельный Acceptance Tests
3) OtherTests - тесты с разными наборами данных, негативные тесты (неописанные в спеке) и прочие тесты (например необходимые для воспроизведения дефекта и его верификации).

Если решим запускать в CI после каждого комита какие-то тесты, то вероятно появится еще поднабор, состоящий из 1 и части 2.
Понятно, что один тест может входить в несколько тестовых наборов.



#100600 Уровень абстракции тестов

Отправлено автор: LeshaL 07 февраля 2012 - 05:41 в Автоматизированное тестирование


Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.


Жутко интересно, как вы ограничили размер набора. Выбрали самое важное что укладывается в n минут? GUI тесты имеют свойство идти долго. Если не секрет, сколько идет этот зеленый набор?

Да никак пока не ограничили. Сейчас тесты идут порядка 3х минут ибо их не много еще. Добрая половина из них уедет в другие наборы, когда я наконец засетаплю все через хадсон. Программисты обычно не делают много комитов за день (имеется ввиду в интеграционное пространство) и пару раз запустить такой набор - не проблема, тем более, что это их инициатива изначально.



#100502 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 06:14 в Автоматизированное тестирование

№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.

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

В моих тестах будет столько проверок, сколько требуется. Я буду проверять прекондишены перед запуском основного действия, например для уменьшении времени при неуспешном выполнении подготовительного действия. Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
Или вот например:
.doLogout()
      .checkLoggedIn(false)
      .checkLoggedOut(true);
имеет две проверки после действия. Можно сделать одну, так чтобы второй метод вызывал первый и в данном случае это прокатит, но в другом случае будет сложнее не запутаться, чем вызвать несколько проверок.

Честно говоря я большой непоклонник слепого следования сомнительным "бест практисам".



#100491 Уровень абстракции тестов

Отправлено автор: LeshaL 05 февраля 2012 - 18:06 в Автоматизированное тестирование

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №2.
Объясню почему.
1) Он дает возможность более просто писать тесты, оперирующие с разными наборами данных, но с примерно одинаковым алгоритмом действий.
2) Оперирует объектами бизнес логики приложения отдаляясь от конкретной реализации страниц. Страницы же отвечают за предоставление информации об элементах и их содержимом.
3) При реализации этого подхода, вариант №1 остается доступным.
4) Более просто проследить сценарии, описанные в спецификациях.
5) Позволяет более "чисто" писать именно сценарные тесты с несколькими проверками по ходу дела и оперирующими несколькими объектами (а не только пользователем, как в примере).
6) Даёт простую возможность переиспользовать методы объектов как предварительные акции и без всяких изменений. Надо только убрать методы "checkXXX".
7) Очень важно то, что он даёт возможность следить за тем, чтобы в методах был бы вызван хоть раз хоть один check, в отличие от стандартного unit теста, который будет пройден, даже если в нём нет ни одной проверки.
8) Позволяет использовать проверки неоднократно (не в рамках одного теста, а "шарить" их между разными тестовыми классами).
9) Позволяет проверить результат всех проверок (asserts) в тесте, в отличие от junit, где падение происходит на первой же проверке. Очень удобно при отладке тестов.
10) Позволяет делать негативные проверки без перехвата AssertError (или что там используется) в каждом тесте, где есть такая необходимость.

Что касается возможности вешать дополнительные asserts, то она ровно такая же как и в первом варианте.
Что касается сложности отладки или поиска неисправности во втором варианте - зависит от того как выдаётся информация при ошибке.
Что касается того, что все перевести на вариант №2 не получится, ну и ладно. Вариант №1 меня тоже устраивает, а вариант №3 при появлении будет переводиться в вариант №1 или №2. Вообще оптимальным при написании нового теста кажется такая последовательность: пишется тест в варианте №3 (можно опустить) и потом переделывается в №1, при появлении большего количества тестов на данную функциональность всё рефакторится к виду №2.



#100162 Уровень абстракции тестов

Отправлено автор: LeshaL 29 января 2012 - 18:47 в Автоматизированное тестирование

Всем привет!
Продублирую вопрос, заданный мной в фейсбуке (и твитере), т.к. здесь наверное более удобно обсудить различные точки зрения.

Пишу селениумные тесты. Скажите плз, какой из вариантов на ваш взгляд выглядит лучше и будет более удобен на практике (и для написания тестов и для их поддержки). Учтите, что тесты пишутся в среде, где все умеют так или иначе программировать.
=============
http://pastebin.com/Wc6K4z4K
=============
1) 1й вариант - то что есть сейчас. Требует компромисса между скоростью написания и читабельностью. Неплохо приспособлен к изменениям, но требует определенных затрат на это.
2) 2й вариант требует затрат на фреймворк, без выигрыша по скорости написания, но с превосходной читабельностью и замечательной реакцией на изменения.
3) 3й вариант - почти "сырой" - т.е. почти никакой не нужен фреймворк и достаточно быстрое написание тестов. Но никакая читабельность и солидные затраты на изменения.

----
На данный момент все подходы применимы, некоторые в экспериментальном варианте. Нужно выбрать. Прошу мнений.
Есть еще подвариант второго варианта
http://pastebin.com/kDf6e9xh

Вообще второй вариант задуман для отвязки проверок от используемого фрейворка (junit, testng etc) и ради возможности следить за тем, чтобы не было тестов без проверок и еще ради возможности найти все ошибки сразу, а не падать на первом же ассерте. Хотя при написание тестов и проверок требует больших затрат.



#100165 Уровень абстракции тестов

Отправлено автор: LeshaL 29 января 2012 - 20:30 в Автоматизированное тестирование

Скорость написания в третьем случае иллюзорна - быстро будет написан первый тест(пока вилларибо пишет фреймворк, виллабаджо наклепала 3 теста), потом копипаст утянет в пучину.
Первый вариант кстати лично меня отталкивает лишь наличием приведения - из-за снижения читабельности и рассеивания внимания +)
Второй вариант конечно заманчив - но решительность при выборе в его пользу зависит от сложности системы в целом.
Я бы начал со второго варианта, но не слишком бы убивался пытаясь придерживаться его - написал бы некоторое кол-во разноплановых тестов, а потом бы уж точно определился со стилем. Да и вообще бы на первых порах написания фреймворка не советовал наращивать "критическую массу" тестов.

В первом варианте приведения вроде можно избежать, как сделать я придумал только вот сейчас отвечая на вопрос. Завтра попробую. Да и возникают они только после метода open общего для всех страниц. А метод используется редко сам по себе.
Ну и конечно его можно избежать, разбив на две строки. Такова уж неповоротливая джава.
И так и есть, пока есть представители всех 3х вариантов тестов. 3й я стараюсь переводить в первый. Второй экспериментальный, сделал на выходных и пока не советовался с программистами, насколько он им будет удобен. В том-то и дело, что он заманчивый (с точки зрения тестировщика), но есть некоторые моменты, которые меня смущают.



#100489 Уровень абстракции тестов

Отправлено автор: LeshaL 05 февраля 2012 - 17:15 в Автоматизированное тестирование

...

Спасибо за столь детальный анализ. На мой взгляд не хватает обобщенного вывода в конце, по которому можно было бы принять решение.
И конечно, данный анализ чрезмерно сложен для такой задачи. В качестве пояснения скажу, что весь код модифицируем так как этого хочется (в том числе и код приложения); а данные (например имена пользователей) заточены на специальное тестовое наполнение базы. В отличие от абстрактного ПО, рассчитанного на массового пользователя у этих тестов и фреймворка ограниченное и однозначное использование во вполне однозначных начальных условиях.

Что касается ваших примеров:
1. Изменились параметры корректного пользователя
Есть (или будут) такие тесты, которые это проверяют. Поэтому весьма штатная ситуация, предусмотренная реализацией типа User. Для всех трех вариантов тестов это не проблема. Наверное следует отметить, что в данном случае объект User - это не объект пользователя, зарегистрированного в системе, а некий тестовый субъект решивший зарегистрироваться или залогиниться в систему.

2. Изменилась форма логина: нужно ввести дополнительный код (инвайт)
Тут два подхода. Наиболее логичным, на мой взгляд, является изменение типа User, у которого помимо атрибутов "имя" и "пароль" будет еще и "инвайт", т.к. этот "инвайт" также является объектом для написания нескольких тестов.
Второй подход - это создание отдельного типа Invite, который в паре с пользователем будет передаваться в метод login. Можно написать два метода login(User u) и login(User u, Invite in), сохраняя неизменными те тесты, где нам неинтересно значение поля Invite. Очевидно, что первый укороченный вариант метода login будет только создавать внутри правильный Invite и вызывать второй метод, как это обычно и делается. Здесь третий вариант проигрывает, т.к. не имеет отдельного метода и возникнет необходимость менять все тесты на эту функциональность.

3. Изменилась проверка того, что пользователь успешно залогинился
Здесь вообще следует отметить, что на практике (при тестировании других объектов) зачастую возникает необходимость делать одинаковые проверки в разных тестах и логично при этом все такие проверки (asserts) выносятся в приватный метод внутри тестового класса. Поэтому, что в первом, что в 3м варианте все-равно будет метод checkIsLoggedIn, в который и надо будет внести изменения. Во втором варианте тестов этот метод принадлежит не тесту, а типу User.



#101312 переход на WebDriver

Отправлено автор: LeshaL 20 февраля 2012 - 11:55 в Selenium - Functional Testing

Вы написали 6 строчек кода, тогда как можно написать 1 при инициализации драйвера (для implicit wait). И далее забыть об этих ожиданиях в своем тестовом коде, т.к ожидание будет включено при каждом поиске элемента.
Плюс к этому зачем писать свой метод, если уже есть готовый?



#101320 переход на WebDriver

Отправлено автор: LeshaL 20 февраля 2012 - 13:53 в Selenium - Functional Testing

Если честно, я не совсем понял как работают те методы, поэтому и написал свой :blush:

Там же написано как работает неочевидное (implicit) ожидание. Драйвер раз в 500мсек опрашивает модель и если элемент появился - возвращет его, если нет, то падает с exception по истечении времени ожидания. Поэтому, если у вас, например, 3 места - элемент А появляется через 5 сек, элемент Б через 2 сек, а элемент С есть сразу - то ставьте 5 и оно будет одинаково хорошо работать во всех трех случаях. При этом установка значения 5 надо сделать всего один раз и больше не трогать.

Единственно, если элемент Б или С не появлется вовсе, то драйвер будет ждать максимальное время.

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



#94511 QA Engineer.... в недалеком будущем

Отправлено автор: LeshaL 21 сентября 2011 - 05:00 в Личный рост, карьера, развитие

Пришла рассказать о своих небольших достижениях.

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

Всех желающих приглашаю поглядеть на мое "детище"!

Мое, сугубо личное мнение - делать еще один форум это не польза, а вред. Чем больше форумов, тем меньше на них людей и полезной информации.



#108928 В замешательстве, какую Severity ставить багу

Отправлено автор: LeshaL 22 августа 2012 - 15:16 в Начинающему тестировщику

При выполнении тестового задания самое главное не то как вы проставите северити, а то как вы объясните почему вы поставили такую северити.
Выбираете систему оценок и оцениваете найденные баги, в каких-то местах объясняете почему такая оценка.



#93073 Отдел тестирования и техрайтер

Отправлено автор: LeshaL 23 августа 2011 - 20:23 в Про тестирование обо всём подряд

Присутствие техрайтера - обязательное условие для команды? Можно считать ситуацию нормальной, если документацию пишут сами разработчики?

Беда, коль пироги начнет печи сапожник... (с) Иван Крылов.

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



#93462 Отдел тестирования и техрайтер

Отправлено автор: LeshaL 30 августа 2011 - 21:00 в Про тестирование обо всём подряд

Вы не поверите, у меня подобное было. Когда заполняла договор, были поля "Секретный вопрос" и "Ответ на секретный вопрос". В такие места обычно любят писать девичью фамилию матери. Написала... Через некоторое время случилась неприятность с этой карточкой - нужно было разблокировать её. По телефону девушка спрашивает: Ваше кодовое слово? Я сначала испугалась, потому что никаких кодовых слов не помню. Через несколько секунт догадалась, что это ответ на секретный вопрос имеется ввиду. :crazy:
Смешно, потому что догадаться, что тебя спрашивают легко. Но несколько секунд страха: "Какое кодовое слово??? Я не помню такого!!!" всё же неизбежны.

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



#93072 Очень хитрая форма регистрации на майл.ру

Отправлено автор: LeshaL 23 августа 2011 - 20:08 в Selenium - Functional Testing

а вообще вопрос "зачем" это офтопик :)
Мы тут поставленные задачи решаем.
Примет вообще интересный по сути.

Конечно можно решать задачи через жопу. А можно пойти на сервис типа http://mailinator.com/ и решить для себя проблему раз и на всегда.



#93251 Классы эквивалентности для строки, которая обозначает число

Отправлено автор: LeshaL 26 августа 2011 - 14:00 в Портал Software-Testing.Ru

Ну т.е. я ВООБЩЕ не понимаю, что это за степень, ну и тем более - как ее обосновать!!!! :crazy: :blush: . :blush: ( :blush: )

Может быть это количество представителей данного класса эквивалентности?
А обоснование - от задачи исходить должно и от возможных вариантов.

Пример. Есть функция fac(int i) - считает факториал. Разбиваем значения по классам эквивалентности
1) отрицательные, 2) 0, 3) 1, 4) 2, 5) >2 6) max_int, 7) max_allowed, 8) min_int ... можно еще напридумывать, но к делу уже не относится.
Сколько брать представителей из какого класса?
Понятно, что для классов 2) 3) 4) 6) 7) 8) - есть только один представитель класса, его и возьмем.
Что делать с классами 1) и 5)?
Для класса 1) я бы взял -1 (вдруг проверка на отрицательные числа сделана так: if(i < -1) return "only positive values") и еще одного любого представителя класса. Альтернативно -1 можно сделать отдельным классом.
Для класса 5) я бы тоже взял 2-х представителей. Чтобы избежать антипатерна happy path test. В конкретном случае может быть такая реализация метода, которая возвращает не вычисленный факториал, а константу, равную факториалу числа поданного на вход (тут пример с факториалом: http://www.ibm.com/d...brary/os-junit/).



#93070 Что считать багом?

Отправлено автор: LeshaL 23 августа 2011 - 19:51 в Тест-дизайн и ручное тестирование

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

Конечно, случаи разные бывают. Но из описания понятно, что баг не исчез, а остался. Меня-то это зацепило.
И сделать сообщение об ошибке, в случае если exception ожидаем ничего не стоит. Абсолютно. 5 минут фикс + 25 тестирование программистом, если конечно в программе вообще есть унифицированный механизм сообщения об ошибках.
Пользователю, в подавляющем большинстве случаев exception ничего не скажет, но сообщение вида "Ошибка возникла потому, что вы нажали сюда, а потом сюда. Так делать нельзя. Сначала надо нажать туда, а потом сюда" - скажет. И это решит проблему. Повторюсь. Это ничего не стоит и нормальный программист сможет легко найти путь исправления, и убедить руководителя, что 30 минут его времени будет потрачено не зря.



#107093 Мотивация нового сотрудника

Отправлено автор: LeshaL 25 июня 2012 - 21:40 в Про тестирование обо всём подряд

Это у вас человек на первый-второй день так работает? Тогда самое время признать свою ошибку и исправить её. То есть уволить этого сотрудника. Если, конечно, вы всё адекватно описали. В любом случае выглядит так, что вы совершаете ошибки, уж извините.

Поддерживаю. Желание из такого сделать конфетку ни к чему хорошему не приведет. Вы либо его уволите позже, когда все с ним намучаются. А чем дальше, тем сложнее будет уволить, будет жалко потраченных сил и тд. Либо он достанется кому-нибудь другому (в другой отдел, или вы уйдете, например на повышение итд). Уж поверьте, добрым словом по поводу такого работника вас поминать не станут.
А если есть команда, то за все косяки данного сотрудника придется расплачиваться членам команды - доделывать за него, тратить время на объяснения (в пустую, как понимаю) и тд.