« Я тестер ! »

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


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

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

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

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

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

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

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

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

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

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

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

Гляньте-ка вот на эту карту мира!

Странного ничего не находите?..

А это всего лишь южно-ориентированная карта мира.

Пару заметок для тестировщиков далее...


Эта картинка показывает на сколько важно по-новому смотреть на продукт, который вы тестируете.

1. Переключитесь на другую задачу на пару дней/часов.

Это дает возможность освежить взгляд и увидеть то, что примелькалось.

2. "Прогуляйтесь" по продукту с кем-нибудь из команды.

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

3. Посмотрите демку конкурентов.

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

4. Попросите конечного пользователя или Project manager'а рассказать о продукте его словами

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

Источник на английском: Joel Montvelisky qablog.practitest.com

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

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



Несколько пунктов, влияющих на то, как должно быть написано письмо:

WHO		HOW
Позиция и авторитет		Тон письма: подчиненый - > начальник начальник - > подчиненый равный к равному
Количество знаний о теме сообщения		Степень детализации информации
Отношение к теме письма		Положительное, отрицательное, нейтральное
Суть сообщения		Какие факты нужно упоминать и в каком количестве?

В зависимости от отношения используется разная структура сообщения. В начале говорим информацию, если отношение положительное, затем объясняем/уточняем (дедуктивная структура). В начале объясняем/описывает/приводим доводы, а потом сообщаем новость, если отношение отрицательное (индуктивная структура).

Процесс, который проходит сообщение:

1. Привлечение внимания
2. Понимание
3. Согласие
4. Дествие

На каждом из этапов отсеивается порядка 10%. Итого, будет хорошо, если только 67% (0,9*0,9*0,9*0,9) посланных сообщений дойдут до стадии Действие - цели письма.

У каждого запроса/письма должна быть цель достигнуть Действия получателя. Бездействие - это одна из форм действия (например, Вас не уволили - какое приятное бездействие)

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

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

Ещё говорили о:
- культуре/национальность получателя (линейно-активная, мульти-активная, реактивная) и её влиянии на восприятие информации
- как говорить "нет" politely
- о 3S (Short, Simple, Specific) и 5H+W (Why, Where, What, Who, When + How )
- многом-многом другом

Не думаю, что тренер попадет на мой блог, но все равно говорю ему спасибо.
Тренер: Сергей Кузин

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

Давеча посмотрел фильм ПОП Владимира Хотиненко. Там главный герой рассказывает нерадивому мужу о семейных отношениях между мужем и женой (мой вольный пересказ):

... Без жены я (мужчина, поп) всего лишь единица. Жена без меня — 0. А вместе мы образуем 10 (десятку)...
... Жена — это мой точильный камень. Благодаря ей, то что я делаю получается значительно лучше, чем без неё...

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

Программирование без тестирования способно что-то делать — назовем результат 1. А вот при включении в разработку тестирования (которое само по себе 0) — получаем в результате 10 (десять).А про то, как тестировщики в процессе работы помогают программистам «заточить» продукт, и говорить нечего.

P.S.: надеюсь что этот пост немного объяснит мою точку зрения о тестировании, которая, возможно, была не правильно понята судя по комментариям к этому посту.

P.P.S.: уважаемые девушки, по поводу того, что в притче девушка названа 0 — претензии к автору романа или сценаристу фильма :)
Текст сообщения и комментарии...