Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Тикстоун

Отделим мух от котлет - тестеров от специалистов по качеству.

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

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

На ваши замечания:
Извините за ошибки грамотности, у меня это от стрессонеустойчивости;
Некоторые личности настолько волшебные, что их образ становится собирательным (ничего личного);

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

stmark, а вдруг, послушав вас (взяв пример) неподготовленный читатель превратится в дятла-мутанта?

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

barancev, если вы сменили контекст, уточните пожалуйста, какого рода биллетристику вы хотели бы почитать?

Mystery_Andrew, то как вы стараетесь, боретесь, бьётесь и радеете (стиль вашей рассеяной деятельности) напоминает зомбированного внутрикорпаративными психотренингами "винтика" с хорошо промытыми мозгами. А без фанатизма можно?

barancev, почему нечаянно (да и хорошо, что хоть так)... где ваше стратегическое мышление (я про полноту покрытия)?

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

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

Давайте вместе разберём, с чем обратилась к нам leftCh (см. Отправлено 10 Февраль 2011).
1)
Требования по прикладной части (уточнив, как собирается использовать продукт Заказчик) создаёт бизнес-аналитик.
Требования реализации (проведя экспертизу: в какой инфраструктуре/условиях будет эксплуатироваться продукт, какая архитектура и технологии должны при этом использоваться) создаёт системный аналитик.
Как правило это очень умные и опытные люди (очевидно, первое и последнее слово за ними).

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

2)
Обратите внимание как leftCh отзывается о созидателях (программисты чего-то там напрограммировали), - слух не режет?
Очевидно, был сделан прототип, экспериментировали, дали тестерам поискать слабые места.
Тестеры предоставили отчёт (leftCh помпезно выразился - написали аналитику).
Девелоперы и аналитик им сказали спасибо и приняли (на основании им известных аргументов, фактов, результатов тестирования,..., ограничений на сроки, стоимость,...) решение как продолжить разработку.

Тестировщики сделали то, что от них требовалось. С какого перепугу они претендуют на то, чтобы перед ними отчитывался аналитик о своём решении?
Что они там могут изменить? Ничего.

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

Чем тестировщиков не устраивает данный сценарий? (leftCh, измените его, верните зарплату Заказчику).

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

Тестировщики не разбираются в программировании (или знают его намного хуже разработчиков).
Что они могут изменить в программном коде? Ничего.

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

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

Спасибо, Mystery_Andrew (см. 'Отправлено Сегодня(13.09.2011), 15:23') за рассказ про свою работу.
Делаем выводы:
1) Как поразить Заказчика неадекватом реализованных требований во время сдачи проекта?
До и По ходу разработки правим требования. (...было бы понятно, если бы Заказчик что-то попросил в них изменить...)
2) Как поразить неадекватом Коллег?
Что-то не нравится - берём с потолка сроки на переделку, вымучиваем их (с обоснованием, почему не совпадает) из ведущего разработчика, созываем руководство проектом (пожар - еженедельных летучек не бывает).
3) Почему хорошо иметь стенд тестировщикам?
Не смотря на то, что требования постоянно изучаются и правятся, не понять как все будет выглядеть и работать в конечном счете (люди же не ведают, что делают).
4) Какие предложения вызывают гордость?
Масштабные изменения, которые могут существенно затянуть сроки, сорвать планы, испортить нервы...
5) Какие остаются записки на манжетах?
Плюс не мешало бы ввести тестирование требований (...вы же их до и по ходу разработки внимательно прорабатываете!?)

leftCh, могут ли тестировщики изменить тот сценарий?

Тикстоун

Солидарен с Guriy (см. сообщение 'Отправлено 10 Февраль 2004 - 19:59'), очень помогает, когда последовательность воспроизведения 10000 шагов (например, утечка памяти) - снимаешь avi и тут уж разработчики точно не отвертятся...

Мой вопрос к правдорубу leftCh и его команде: а как в методике (которую пишет ваш отдел) приёмо-сдаточных испытаний вам удалось скрыть данный дефект от Заказчика?
Ответ на ваш вопрос: нет (без пояснений, в стиле Гуру - см. сообщение 'Отправлено 11 Февраль 2011 - 02:53').