Комментарии 19
Чем лучше ты как тестер, тем больше тебя ненавидят
Возможно, дело в подходе? «Треть коллектива» — это слишком много, чтобы списывать на странности отдельных людей.
Программисты с «тонкой душевной организацией» плохо бы уживались в коллективе, ибо код-ревью твоего кода коллегами
Конечно, на замечания QA-специалиста обижаться глупо и непрофессионально, но некоторый такт в отношениях должен быть с обеих сторон.
Любопытно, что с «тонкой душевной организацией» я сталкивался далеко не на всех работах (и не зря сделал в статье акцент на прошедшем времени, поскольку последнее время я действительно такого не встречаю). При этом я не возьмусь оценивать, как именно были выстроены процессы разработки в тех компаниях — способствовали они «профилактике» недовольства тестерами или нет. Я лишь отметил, что такой факт имел место.
Судя по статье, я со своими тремя сертификатами ISTQB Advanced Level, обучение и получение которых мне оплатила моя «шарашкина контора», не пройду собеседования у автора — у меня нет и не было серьезности и заинтересованности в SQA days или других возможностях послушать, как кто-то другой рассказывает, какой он крутой тестер.
Вот везде пишут пугалки, что разработчики недолюбливают тестировщиков, вплоть до «ненавидят». Ни разу с таким не сталкивался. Возможно, это связано с личными особенностями тех самых тестировщиков.
Когда ненавидят тестировщика это показатель неправильного процесса разработки и нездоровой атмосферы в компании, а вовсе не его профессионализм.
И скажите, что кроме «показать заинтересованность» дало вам посещение SQA days и подобных мероприятий? Должны ли кандидаты еще не попав к вам на работу тратить свои средства, чтобы показать интерес?
И скажите, что кроме «показать заинтересованность» дало вам посещение SQA days и подобных мероприятий? Должны ли кандидаты еще не попав к вам на работу тратить свои средства, чтобы показать интерес?
Выше я ответил уже про процессы. Не возьмусь их оценивать.
Про конференции — я имел в виду немного иное.
Тестирование — активно развивающаяся отрасль. Здесь все меняется довольно быстро, поэтому оставаться «в теме», ни на кого не оглядываясь, сложновато. Не получится сохранять квалификацию, не изучая ничего сверх текущей работы. Вообще зашоренность на работе — это плохой признак. Текущая задача обычно держит тебя в рамках одного направления, в то время, как отрасль развивается, условно говоря, «во все стороны».
Чтобы компенсировать постоянно усугубляющийся перекос в конкретном направлении, можно следить за публикациями передовых команд, смотреть интересные именно технологические (а не 100% самопиарные) доклады на Ютубе. Но, честно говоря, я не встречал на собеседованиях кандидатов, которые бы действительно тратили на это время. Увы. Конечно же, я пытаюсь это обнаружить. Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.
Вопрос про конференции — это своего рода «последняя надежда». Если кандидат не интересуется ничем, но хотя бы съездил на конференцию — значит отрасль ему не безразлична (не все потеряно). Конференция — это не столько подборка конкретных докладов, сколько выбранный оргкомитетом список тем, на которые стоит обратить внимание (в изложении докладчиков конференции или других спикеров — это не так важно).
Конечно же, отрицательный ответ на вопрос о конференциях с лихвой перекроют обширные знания, сертификация и т.п. — тут важно помнить про изначальную цель.
Про конференции — я имел в виду немного иное.
Тестирование — активно развивающаяся отрасль. Здесь все меняется довольно быстро, поэтому оставаться «в теме», ни на кого не оглядываясь, сложновато. Не получится сохранять квалификацию, не изучая ничего сверх текущей работы. Вообще зашоренность на работе — это плохой признак. Текущая задача обычно держит тебя в рамках одного направления, в то время, как отрасль развивается, условно говоря, «во все стороны».
Чтобы компенсировать постоянно усугубляющийся перекос в конкретном направлении, можно следить за публикациями передовых команд, смотреть интересные именно технологические (а не 100% самопиарные) доклады на Ютубе. Но, честно говоря, я не встречал на собеседованиях кандидатов, которые бы действительно тратили на это время. Увы. Конечно же, я пытаюсь это обнаружить. Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.
Вопрос про конференции — это своего рода «последняя надежда». Если кандидат не интересуется ничем, но хотя бы съездил на конференцию — значит отрасль ему не безразлична (не все потеряно). Конференция — это не столько подборка конкретных докладов, сколько выбранный оргкомитетом список тем, на которые стоит обратить внимание (в изложении докладчиков конференции или других спикеров — это не так важно).
Конечно же, отрицательный ответ на вопрос о конференциях с лихвой перекроют обширные знания, сертификация и т.п. — тут важно помнить про изначальную цель.
Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.
Можете перечислить какими знаниями и умениями должен обладать любой тестировщик?
Тестировщику точно нужны два качества: внимательность и усидчивость. Необходима база в ИТ. А остальному при желании можно научиться.
Вы, вероятно, интересуетесь знаниями, необходимыми для старта карьеры? Рекомендую поискать стажировку в какой-нибудь компании и посмотреть список требований к кандидатам.
Вы, вероятно, интересуетесь знаниями, необходимыми для старта карьеры? Рекомендую поискать стажировку в какой-нибудь компании и посмотреть список требований к кандидатам.
Что такое Jyton?
Спасибо! А то мне Google постоянно менял на Python, думая что я опечатался. Пошёл изучать. :)
Откровенно говоря, я не советовал бы использовать Jython с RF (как раз ту связку, что упомянута в моем рассказе).
Robot Framework сам написан на Python, и под него есть много библиотек именно на Python, позволяющих реализовать практически все, что угодно (вообще RF — мощный инструмент, который лично мне очень нравится). Jython — это попытка адаптировать все это «богатство» под разработку на Java. Но в связке RF+Jython многие библиотеки Python не работают (а вместе с тем и все, что использует эти библиотеки — как некоторые библиотеки самого RF).
Своих библиотек под Jython практически нет. Когда мы уперлись в это в «боевом» проекте, пришлось потратить время на ковыряния в тех немногих библиотеках, что все-таки существуют (как было описано выше), а остальные нужные нам библиотеки просто переписывать под Jython своими силами.
Кстати, об этом проекте мой коллега писал статью: habr.com/company/maxilect/blog/424333. Правда, он не акцентировал внимание на том, насколько много усилий ушло на то, чтобы заставить все это корректно работать. Он пришел на проект, когда там была написана уже масса тестов.
И даже несмотря на то, что я в итоге заставил все это работать, от RF на том проекте впоследствии отказались — перешли на стек, более подходящий для разработки на Java.
Robot Framework сам написан на Python, и под него есть много библиотек именно на Python, позволяющих реализовать практически все, что угодно (вообще RF — мощный инструмент, который лично мне очень нравится). Jython — это попытка адаптировать все это «богатство» под разработку на Java. Но в связке RF+Jython многие библиотеки Python не работают (а вместе с тем и все, что использует эти библиотеки — как некоторые библиотеки самого RF).
Своих библиотек под Jython практически нет. Когда мы уперлись в это в «боевом» проекте, пришлось потратить время на ковыряния в тех немногих библиотеках, что все-таки существуют (как было описано выше), а остальные нужные нам библиотеки просто переписывать под Jython своими силами.
Кстати, об этом проекте мой коллега писал статью: habr.com/company/maxilect/blog/424333. Правда, он не акцентировал внимание на том, насколько много усилий ушло на то, чтобы заставить все это корректно работать. Он пришел на проект, когда там была написана уже масса тестов.
И даже несмотря на то, что я в итоге заставил все это работать, от RF на том проекте впоследствии отказались — перешли на стек, более подходящий для разработки на Java.
Спасибо за пояснение! У нас в компании пока что реализация BDD_Behat + Facebook Webdriver + Selenium Server со своим фреймворком написанном на PHP. То есть мы пишем заранее обусловленные команды на русском языке, а далее смотрим на результат. Нативнее использовать всё таки язык программирования напрямую, но тут появляется более высокий порог входа в компанию, и полностью новая реализация автоматизации тестирования. Компания пока-что на это не готова.
Сам отдельно изучаю Python в связке с Selenium WD. Да и вообще смотрю что да как, чтобы сделать революцию тестирования в нашей компании.
Сам отдельно изучаю Python в связке с Selenium WD. Да и вообще смотрю что да как, чтобы сделать революцию тестирования в нашей компании.
Никогда не понимал людей который злятся на тестеров. Тестер это твой друг и товарищ, который подтирает твои косяки, пока их никто не увидел. Я наоборот переживаю если ребята ничего не нашли. Значит плохо тестили и это вылезет в продакшене.
новички очень много внимания уделяют негативному тестированию – как бы что сломать
Вообще часто встречаюсь с совершенно неверным утверждением, что, мол, задача тестировщика попытаться сломать приложение. Дорогие читатели, выкиньте эту чушь из головы навсегда. Тестировщик ничего не ломает, он находит то что уже было сломано. Задача тестировщика предоставлять информацию о работе приложения. И это включает в себя и положительное тестирование. Ведь обычно больше того, что работает чем того что не работает.
У меня такая стратегия: то что работает, покрывается автотестами. Что не покрыто тестами, проверяется вручную, и заводятся тикеты. Тикет решен — пишется автотест, подтверждающий что оно работает.
Чем лучше ты как тестер, тем больше тебя ненавидят
Это зависит от подачи. Я научился нейтрально подавать информацию и никаких конфликтов у нас нет. Сегодня разработчики сами иногда подходят ко мне, просят что-то проверить, спрашивают есть ли у нас автотесты на какой-то функционал.
[...] тестирование – это стиль жизни. [...] Я всегда живу с ощущением того, что все должно соответствовать требованиямЯ тоже заметил это за собой, но не знал как это описать. Я стал гораздо строже относиться к проявлениям низкого качества, в сервисах, продуктах. Если происходит какой-то косяк или повод для рекламации я не моргнув глазом пишу репорт производителю или продавцу. И безо всяких эмоций добиваюсь решения. Именно эта профессиональная позиция: проблема, если это проблема, должна быть решена. Никаких компромиссов.
В прошлой жизни, я бы наверное не знал как подступиться к описанию, а еще бы мучался писать и оставить как есть.
Кстати, я заметил, что быстро написать полезный репорт — навык, которому нужно обучаться. Меня в свое время на правильный путь навел гневный комментарий разработчика, который был в корне не согласен с моим описанием проблемы. Он сказал:
«Просто скажи, что ты делаешь и что видишь, а не то, что тебе кажется!»
Это был самый полезный урок по тестированию, который я когда либо получал. Я научился писать репорты так, чтобы в них не было тестировщика, а был пользователь. И с тех пор никаких конфликтов с разработчиками у меня не возникало. А я стал следить за своим мировосприятием, ведь это необходимо, также как поверка измерительных приборов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обратной дороги нет: личный опыт тестировщика