Нужен тестировщик в команду

понедельник, июля 09, 2018

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

  • Писать тест план. 
  • Определять: что, как и почему будем тестировать. 
  • Написать тесты или чеклисты. 
  • Протестировать и подготовить отчет. 
У нас рельсовый транспорт, иногда очень весело, а иногда "срывает мозг". Немного рассказывал об этом на конференции - видео в предыдущем посте.


Официальное описание вакансии

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

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

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

Видео выступления на SQA Days-23. 25-26 мая 2018. Тестирование проектов с высокой долей ответственности: рельсовый транспорт.

четверг, июля 05, 2018

Тестирование проектов с высокой долей ответственности: рельсовый транспорт from Vlad Orlikov on Vimeo.


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

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

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

Что я увидел на EuroSTAR Software Testing Conference 2017

понедельник, января 15, 2018

Очень долго хотелось описать ,что получилось увидеть и услышать на EuroSTAR 2017 в Копенгагене прошлой осенью.
В первую очередь, запомнилась безусловно, атмосфера и стпень организованности. Но тут нечего и удивляться, это уже давно бизнес. Это была уже 25 ежегодная конференция. И, как сказала бессменная ее организатор: "..начиная с самой первой - все они были прибыльны. :)..."
Если же кратко и по сути:
1. Было, как обычно, 2-3 толковых доклада за те 2 дня, что мы там были.
2. Получилось поговорить с Paul Gerrard - он пытался показать одну из веток будущего, где есть помощник-авто-бот
3. Была толковая часть выставки разного софта, некоторые вещи действительно интересны.
4. Копенгаген красивый город :)

Дальше попробую вспомнить, что запомнилось с разных докладов.
Стоит сказать, что во время регистрации надо было указать, на какой из 4 часовых воркшопов пойдешь - и я решил посмотреть, что нынче показывают называя Agile и Scrum 
1. The Mindset of Testing in Scrum (Carsten Feilberg, House of Test Aps, Denmark.) 
После коротких слов вступления, нам раздали карточки и попросили спланировать (т.е. дать оценку), сколько какая задача займет и выбрать те, что мы "сделаем" за мифический "спринт". После обсуждения в команде и выполнения оценки, выяснилось, что людям проще сказать так: "мы тут все спланировали, но давай уменьшим вдвое, потому что я чувствую ,что не сделаем". Уговорить увеличить оценку по конкретным задачам, которые "беспокоят", не вышло. В итоге сделали в 2 раза больше, чем планировали. Заказчик был бы рад :):) Но качество в итоге было под вопросом, потому что как обычно - в конце вместо перепроверки, нахватывали еще задачек :). Тему авторам раскрыть не получилось.. или по крайней мере я не уловил раскрытия темы :(.
2. Тема конференции была The Magic of Testing. И в качестве развлечения, а так же приближения темы к жизни, перед всеми вместе выступил иллюзионист со своими историями - как они тестят свои фокусы... Кстати, некоторые они по полтора года готовят - вот уж не думал.
3. И наконец-то мы попали на стендовые доклады, где хотелось услышать чего-нибудь интересного.. "Thinking About Test Management…" Geoff Thompson (Planit Testing, UK.) - доброжелательный господин долго рассказывал о Tester skills, Team roles, Motivation, Delegation, Negotiation, Influencing - и других баззвордах. Оно вроде и толково было, но столько тем за 40 минут можно только обозначить и показать, куда копать. Где-то так он и сделал.
4. Под занавес первого своего дня я попал на The "Risk Questionnaire" Adam Knight (River, UK.) Доклад больше походил на книжный, но обработанные им риск опросники (или как это лучше перевести?) могут помочь тем, кто задумывается или отвечает за управление рисками.
Второй день начался намного веселее. 
1. Утром были LIGHTNING STRIKES, когда многие авторитетные люди за 3-5 минут задвигали какую-то умную тему. Коротко, быстро и по делу. Майкл Болтон решил спеть... :) о том, что такое тестирование, что оно в себя включает.  
2. Затем был "Testing With An Invisible Friend" Paul Gerrard (Gerrard Consulting, UK.) 
Он рассказывал и пытался показывать демо "автоматического помощника", который может помочь проводить тесты, подсказывать, что тестер что-то забыл, на чем остановился и т.д. в общем, электронный секретарь на базе "говорилки" от известного бренда. Получилось после доклада с ним поговорить на чуть более интересную тему - автоматизированное распознавание функциональности приложения и его тестирование.. Он утверждал, что ему показывали по дороге на конференцию именно такую штуку с эффективностью на 80% 
3. На кофе паузах была возможность толково поговорить и послушать про тулы - в основном, в тренде, как обычно, автоматизированное тестирование. Было несколько тулов по анализу состояния билдов. Они включаются в сборку и к репозиторию - цель посмотреть, что поменялось, и убедиться, что измененная функциональность проверена. 
4. "A Pixie Dust Recipe For Automated Tests That Fly" Noam Kfir (Independent Consultant, Israel.) 
Толковый доклад про то, что автотестеры получаются из тестеров и подготавливаются достаточно быстро, а по сути - приобретают вторую профессию, которая уже ближе к программированию. В то же самое время, программисты учатся программировать значительно дольше проходя много этапов проб и ошибок и т.д. Поэтому он пытался рассказать про те области, которым надо учить автотестеров, чтобы результат их труда был качественнее, а код лучше. 
5. Следующим докладом был "How the Three Amigos Made Us A More Effective Team" Sylvia MacDonald (NewVoiceMedia, UK.) 
Этими тремя друзьями оказались PO, QA и Dev. Краткая история о поставленном процессе в рамках конкретной компании. Вывод можно сделать достаточно простой - больше говорите, чтобы больше понимать, а решения принимайте вместе. 
6. После обеда пошел на "философский" доклад "Testing Social Responsibility - Future Challenges" Marta Firlej (SoftServe, Poland.), Co-Speaker – Łukasz Pietrucha (TestArmy, Poland.)
Ребята подняли интересную тему - на сколько, то, что мы делаем, является социально ответственным. На соклько мы, участвую в проектах, видим свою ответственность перед обществом - а не просто "делаем" проект. 
В качестве примеров: у них в Польше разработали удаленную систему снятия показаний со счетчиков, когда специалист идет по улице и снимает показания с домов. Но при этом никакой безопасности не было в протоколе, и любой желающий мог понять, есть ли кто дома - ну и обворовать :) 
Или безопасность детей с электронными игрушками: когда "хакер" взломал игрушку и чуть не свел с ума ребенка, разгвоаривая с ним. 
ИМХО: Я по этой теме лично для себя решил, что не хочу работать в играх - потому, что мне кажется это "убиванием" времени людей. Да они это делают по своей воле, да сами выбирают - но я не хочу в этом участвовать. 
7. И закончилаcь для меня конференция докладом "Testing A Moving Target: How Do We Test Machine Learning Systems?" Peter Varhol (Dynatrace, USA.) и Co-Speaker – Gerie Owen (Eversource Energy, USA.) Видимо усталость за два дня дала о себе знать - очень грустный доклад, но в то же время дал пару мыслей на подумать. Проблема: сложно опредлить стартовую точку, сложно определить и повторить тестовую среду и состояние системы - что в таких случаях делать. Решение: подготавливайте толковые данные на входе, проверяйте только то, что вам необходимо. 

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

Из плюсов стоит отметить свободное общение с разными людьми - готовы рассказывать и слушать. В общем - одно удовольствие!

Были еще и официальное празднование 25-летия, и Party - но это уже другая история.

 Вся программа и презентахи всех долкадов были доступны всем участникам за 2 недели, до начала конференции.

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

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

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

Поездка на конференцию EuroSTAR 2017

четверг, октября 26, 2017

Так сложились обстоятельства, что у меня с командой получается поехать на конференцию EuroSTAR 2017 в Копенгаген. Возможно кто-то из читателей был на этой конференции ранее и может поделитсья опытом и отзывами?


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

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

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

Процесс разработки и ведения автотестов

вторник, августа 15, 2017

Вот пример того, как был организован процесс разработки автотестов на одном из проектов. 

Указаны все (или почти все) тулы и средства с их версиями.

Если есть вопросы - пишите, расскажу детали.

Процесс разработки автотестов


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

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

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

Видео моего доклада на SQA Days 2012 (+HD)

понедельник, марта 18, 2013


Промышленный подход к автоматизации тестирования

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

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

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

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

Mindmaps о тестировании

пятница, февраля 01, 2013

Ух и хорошая же ссылка попалась мне на просторах сети.

Здесь куча очень толковых интеллект карт о тестировании.

Вот только малая часть того, что есть по ссылке:

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

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

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

Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. SQA Days 2012

понедельник, декабря 10, 2012


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

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

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

Оценка работы тестировщиков

понедельник, июня 11, 2012


Какой бы ни был сейчас год; сколько ни прошло времени со времен публикации голубой книги Канера, Фолка и Нгуена; сколько бы не говорили про тестирование в различных гибких и не совсем методологиях - главная задача тестировщика и менеджера тестировщиков:

Четкая и прозрачная фиксация ожиданий от группы тестирования.

До тех пор, пока нет как-либо прописанных ожиданий и четкой уверенности в том, что действительно ожидается от команды тестировщиков - начинать любые работы - бесполезно!

Чтобы вы не сделали, умелые тестировщики, это все равно не будет иметь должного эффекта. ;) 
Сколько раз в умных книгах писали - главное договориться на берегу. Но, как ни крути, учиться на своих ошибках как-то ближе к телу.

А что до названия поста, то оценка работы тестировщиков в итоге сводится к одному - сделано ли то, что ожидалось :) В этом выражении можно слово "тестировщиков" заменить на программистов, аналитиков... Но есть одно НО: программисты производят в конечном итоге "код", аналитики - постановки, а вот результат работы тестировщиков - "нематериален".

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

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

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

Видео выступления на SQA Days 10 - Эффект Горизонта

четверг, марта 01, 2012

Ну вот и дошло до меня видео моего выступления на SQA Days 10.
Качество звука не очень, а за кадром ещё и смех посторонний - но лучше это, чем вообще ничего :).

Отдельное спасибо Стасу Фомину за запись и оцифровку.

Смотрите, и, чур, помидорами не бросаться ;)


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

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

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

Эффект горизонта

вторник, октября 04, 2011

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

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

Как же этот эффект проявляется в тестировании:
  • Неправильно выбираются тесты для автоматизации
  • Ошибки в выборе тестов для прогона при ограниченном времени
  • Ошибки при планировании тестирования
  • Ошибки в выборе средств тестирования(от багтреккера до документов) и автоматизации


Методы сглаживания эффекта или как с этим бороться?

Для сглаживания последствий придумано несколько алгоритмических решений, суть которых:
  1. Расширить уровень горизонта за счет поиска «интересных» мест и продвижения «тихих» или «громких» ходов (Quiescence search)
  2. Минимизировать потери при максимизации прибыли (Minimax| Maximin) и его уточнение с помощью отбрасывания более «слабых» уже найденных ходов (Alpha-beta pruning)


Теперь же о главном…

Как можно применить указанное выше:
  1. Расширяем просмотр «Шахов»: «Шахи» - ключевые моменты бизнес процессов, ситуации, в которых от приложения требуется особая «багоустойчивость»; рассмотрение возможных последствий в узлах процесса тестирования
  2. Расширяем просмотр «Атак»: рассматриваем варианты поведения системы в особенно «популярных» для пользователя местах; варианты развития событий после внесения изменений в процесс тестирования
  3. Расширяем просмотр «Потенциальных угроз»: где произошли изменения; где будут происходить изменения в будущем (активная разработка модуля)
  4. Определяем уровень доступного горизонта - определяем области, необходимого расширения горизонта  - строим свое дерево познания предметной области и процессов.


Вместо заключения:
  1. Люди обычно обладают довольно хорошей интуицией, чтобы решить, совершать ли ход, хотя он и мало обещающий, или до последнего искать выигрышный.
  2. Любая цель подчиняется эффекту горизонта: достижение каждой цели влечет за собой мгновенную постановку новой.



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

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

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

Тестирование оптимизации...

среда, сентября 21, 2011

В процессе тестирования поставок клиентам часть задач (около 10%) связана с оптимизацией кода на SQL.
Понятно, что проверить во первых стоит проверить, не поломалась ли функциональность приложения и только затем перейти ко второй фазе - непосредственная проверка оптимизации.

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

Куча первая - проблемы БД:

  • фоновые процедуры (служебные job'ы и процедуры приложения, выполняемые в фоновом режиме)
  • "служебные" активности БД: пересчет индексов, высвобождение temp'овых таблиц, оптимизация хранения данных на жестком диске
Куча вторая - проблемы данных и процессов приложения:

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

Часть проблем, безусловно решается разными дополняющими и исключающими друг друга методами.. но возникает резонный вопрос:
Зачем все танцы с бубном, которые займут ещё и кучу времени, если мы изобретаем велосипед для нагрузочного тестирования?

Рассуждая так, прихожу к выводу, что толковое тестирование оптимизированных процессов* провести не получится, без организации нагрузочного тестирования с соответствующим исследованием и постановкой отдельного процесса.

Но тогда возникает резонный вопрос у заказчика - а был ли мальчик?  А исправили ли медленную работу ПО?

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

----------------
*Рассматриваем ситуации оптимизации процедур и функций в рамках произведения комплексных процессов: закрытия операционного дня банка; пересчет PnL и PV позиций; обработки 1000К сообщений для отправки и т.д. (код, а не бизнес-логика этапов процесса)

P.S.:  все хотел куда-нибудь серых человечков добавить :)

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

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

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

Боец тестирования банковского ПО в Минске, Гродно или Бресте будет успешно принят на работу

пятница, марта 25, 2011


Если ты не раз вспоминал программистов добрыми словами за ошибки и медленную работу программного обеспечения отделения твоего банка – есть шанс это исправить.

Ко мне в команду нужны бойцы невидимого фронта тестирования.

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

Плюсом будет:
- знание любого скриптового языка
- знание SQL
- опыт тестирования
- огромное желание стать тестировщиком
- знание правил бухгалтерского учета

Если ты студент(ка) или не имеешь опыта работы, но безумно трудолюбив(а) и талантлив(а) – пиши, возможно именно для тебя осталось место!

Писать на colvir[гав]yatester.ru или нашему HR - ohaetckaya[гав]colvir.ru

О компании.


Кстати, знание английского вовсе не требуется – совещаемся и пишем по-русски J

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

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

| 0 ответов, оставьте свой...

Никогда не говори никогда и другие 10 никогда...

пятница, февраля 25, 2011

Десять фраз, которые не должны звучать из уст тестировщика:

1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...

Источник

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

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

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

Возможно ли построить идеальный процесс тестирования?

пятница, октября 29, 2010

Проблема создания процесса тестирования много раз поднималась на конференциях, круглых столах и семинарах. Вооруженные тестировщики возвращаются на свои рабочие места и пытаются воплотить в жизнь советы своих старших товарищей, пытаясь создать идеальный процесс тестирования. Давайте попробуем разобраться в самой постановке вопроса: «Возможно ли построить идеальный процесс тестирования?»


ИПТ

На первый взгляд кажется, что самым верным ответом на поставленный в теме вопрос будет слово «Нет». Предлагаю немного углубиться в тему вопрос, возможно даже помечтав...

Что такое?

Идеальный процесс тестирования для меня – это процесс который позволяет решать поставленную задачу максимально эффективно, а так же создает комфортные условия для этого. Идеальный процесс, когда «лучше уже и не надо!»
Хотя само понятие ИПТ достаточно не однозначно, потому что каждый читатель может выдвинуть свои критерии идеальности процесса.

ИПТ не существует

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

ИПТ существует

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

Как?

Создание ИПТ сопряжено с набором следующих действий, которые следует повторять в течении проекта:

I. Описать то место в проекте, времени и команде, в котором вы находитесь;

II. Идентифицировать проблемные места
     1. идти от проблемы
     2. с точки зрения цели:
  • удобный для достижения цели
  • предсказуемый результат
  • понятный объем работ
III. Приоритизировать проблемы
     1 решать по одной из каждой выделенной области в единицу времени
     2 параллельное решение из несмежных областей

IV. Внести изменения
     1 мотивация команды
     2 обратная связь
     3 довести изменение до конца

V. Проанализировать результат

Несколько примеров

Пример первый.

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

- частое обращение ПМа за информацией о состоянии задач, расчетным временем их исполнения -
введено и применяется сразу практически всей командой: обновление статусов задач в багтрэккере, выставление перед началом и изменение estimations в процессе работы над большими задачами.Убедившись в достаточной верности данных – ПМ реже задает свои вопросы.

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

Пример – второй.

Крупная оффшорная компания. Выделенный центр разработки для одного западного информационного агентства составом в Х человек, из которых 30-40 человек – группа тестировщиков.

- стремясь улучшить процесс для всей группы, изменения вносят на всех, проверяя на одной из групп.
Изменения успешные для группы из 5-7 тестировщиков валяться на группе из 2-х человек, т.к. они работают с другим типом ПО, у них свой «подкрученный» процесс тестирования.

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

В дополнение хочу показать карту памяти, которую я использовал для подготовки этого сообщения:


Спасибо mindmeister за сервис.
Текст сообщения и комментарии...

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

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

Why? Why not? Why not me? Why not now?

вторник, октября 26, 2010



Не совсем про тестирование, но очень понравилось:

"For true success ask yourself these four questions: Why? Why not? Why not me? Why not now?"
(с) James Allen

"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "
(с) Джеймс Аллен

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

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

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

20 причин почему не надо тестировать

воскресенье, октября 24, 2010

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


1) Нам не требуется такого уровня тестирования.
2) Это стоит до{хрена} кучу денег.
3) Слишком долго будете копаться.
4) Тестирование никогда «не завершится полностью».
5) Мы никогда не знаем, сколько времени уйдет на тестирование.
6) Слишком академично, мы же не NASA.
7) А его собственно и в плане то не было.
8) Тестирование сильно тормозит выход продукта.
9) Кастомер просто весь в нетерпении, а ваши тестеры тормозят процесс.
10) Тестирование выставляет нас идиотами.
11) А какой толк вообще от тестирования?.
12) Пока тестеры нароют все баги – рынок ушагает от нас.
13) Да и вообще всем пофигу на эти баги.
14) А собственно тестирование вообще не дает ответа ни на какой вопрос.
15) Разрабы сами все протестят.
16) Не надо ломать систему, и так работает не очень.
17) Пользователь сам найдет баг и мы все пропатчим.
18) Ну нет у нас времени, чтобы написать требования.
19) И вообще, тестеры никогда не находят самые нужные баги.
20) Тестирование все равно никогда не найдет всех багов.
Текст сообщения и комментарии...

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

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

Верное отношение...

среда, июля 21, 2010

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

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

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

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

Как это сделать? — Ответ для каждого случая свой, но для себя выделил несколько простых вопросов, которые помогают в разговоре:

1. Какая выгода менеджеру/девелоперу лично?
Иногда ясные факты сказанные громким голосом вполне действенны — даже если вы думали, что их все и так знают.

2. Можно ли сделать так, чтобы количество действий с их стороны или изменений в жизнедеятельности было минимальным?
Нас не напрягает, если от нас не требуют активных действий или не происходит изменения того, к чему мы так привыкли. (Использовал это часто, на сколько позволяли обстоятельства)


3. А проект/задача от этого выиграют?

Не такой влиятельный аргумент для людей, чем первые два, но так же имеет место среди списка причин внедрения «улучшений». А как бы хотелось, что бы это был самый важный :)

4. «Улучшения» выглядят как улучшения или как очередные заморочки тех, у кого работы не много?

5. Получено ли подтверждение/разрешение от «высокого» менеджмента?
Удар ниже пояса, но некоторых приходится «убеждать» именно так :(

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

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

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

Процесс это не про документы, это про людей.

вторник, июля 06, 2010

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

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

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

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

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

Первоисточник дороже всего!

среда, июня 23, 2010

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

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

Ошибается каждый, но детские ошибки делать НЕ позволительно!

Это была лирика, а теперь выводы.

Есть ситуации, когда другого выхода нет и приходится описывать то, что есть. Но если есть хоть небольшая возможность - изучайте первоисточник! Все его интерпретации могут быть:
- однобокими
- ложными
- недоправильными
- иметь больше деталей, чем оригинал
- и т.д.
Попросите 2-3 человека описать Красную площадь или Статую свободы - получите ли вы одно и то же описание? А если посмотите сами на картинку..а если потом "вживую" - сколько разных описаний вы получите?
Текст сообщения и комментарии...

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

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

Подписаться на: Сообщения (Atom)