Уважаемые коллеги!
ПОЗДРАВЛЯЮ С НОВЫМ ГОДОМ!
Желаю Вам новых и интересных проектов!
Желаю Вам незаменимых знаний!
Желаю Вам умопомрачительных достижений!
Новых целей и средств их достижения!
Семейного и финансового благополучия!
С НОВЫМ 2010м ГОДОМ ТИГРА!!!


Рано или поздно кто-то пытается оценить работу сотрудников с помощью метрик. Скользкая это тема. Адекватность таких метрик всегда под большим вопросом. Один из аспектов таких метрик освещает цитата Голдратта Элия («Синдром стога сена»):
«Если ты меня оцениваешь нелогично… не жалуйся на мое нелогичное поведение».

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


P.S. Рисунок отсюда.


Что же это такое, анализ граничных значений? Да-да, техника написания сценариев тестирования. Этот подход очень тесно связан с разбиением на классы эквивалентности, т.к. именно классы являются источником тех самых границ!
Почему может быть полезен данный подход? Как в коде задаются ограничения? Ага, обычно знаками больше, меньше, равно. И ошибку можно «накодить» (практически, можно нашкодить :)) запросто, поставить не то значение в выражении, не тот знак. Вернемся к нашим карандашам (см. Разбиение на классы эквивалентности), в зависимости от заказанного количества карандашей различается стоимость:
  • 1 – 100 – 10 руб. за карандаш;
  • 101 – 200 – 9 руб. за карандаш;
  • 201 - 300 – 8 руб. за карандаш и т.д. С каждой новой сотней, цена уменьшается на рубль.

Максимально можно заказать – 1000 штук. Анализ граничных значений очень интересуют границы интервалов значений, на то он и «анализ граничных». Используя метод эквивалентного разбиения, были выделены следующие классы:

  1. Невалидное значение: >1000 штук;
  2. Невалидное значение: <=0;
  3. Валидное значение: от 1 до 100;
  4. Валидное значение: от 101 до 200;
  5. Валидное значение: от 201 до 300;
  6. Валидное значение: от 301 до 400;
  7. Валидное значение: от 401 до 500;
  8. Валидное значение: от 501 до 600;
  9. Валидное значение: от 601 до 700;
  10. Валидное значение: от 701 до 800;
  11. Валидное значение: от 801 до 900;
  12. Валидное значение: от 901 до 1000.

Самое время взяться за граничные значения этих самых классов. Нужно брать не только само граничное значение, но и отступать на шаг вверх/вниз (на самый, самый малюсенький из возможных шажков). Для выше написанных классов получаем:

  1. 999; 1000; 1001;
  2. 1; 0; -1;
  3. 99; 100; 101;
  4. 199; 200; 201;
  5. 299; 300; 301;
  6. 399; 400; 401;
  7. 499; 500; 501;
  8. 599; 600; 601;
  9. 699; 700; 701;
  10. 799; 800; 801;
  11. 899; 900; 901;
  12. аналогично классу №1.

Итак, получаем по 3 значения для границ, а также берем по одному значению из «тел» классов эквивалентности, итого: 33 + 12 = берем для проверки 45 значений. М-м-м-м-м, это больше 12, но гораздо меньше 1000. Да еще и проверяем не только валидные значения, но и невалидные! Но это только две техники из… продолжение следует…

Автоматизация тестирования, применяемая по месту, по времени и по теме весьма и весьма полезна. А если инструмент автоматизации бесплатный, мммм… «ни в сказке сказать, ни пером описать».

Selenium – набор инструментов для автоматизации тестирования веб-приложений на различных платформах. Официальный сайт
тут. Там же можно посмотреть описание всего этого добра и, да-да, скачать.

Используя надстройку над Firefox Selenium IDE, записываем и воспроизводим тесты. IDE позволяет экспортировать тесты во множество различных языков (включая Ruby, PHP, java, perl, C# и Python). Меня интересует связка Firefox-Selenium-JAVA. Почему? А не скажу, корыстные цели у меня :). Если будут появляться интересные моменты, буду описывать.

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

  • Скачиваем Selenium IDE & RC, устанавливаем (RC просто распаковываем, место расположения запоминаем). Все что нужно, перезагружаем.
  • Открываем Firefox. Разворачиваем меню «Инструменты» и о чудо! Видим подменю «SeleniumIDE». Кликаем дрожащей рукой уверенно и радостно. Если SeleniumIDE не видим, то, либо не установили, либо Firefox не перезагрузили.
  • И вот ОНО, «фриварное» чудо, перед нами. Уже записывающее, между прочим. Дабы остановить/начать необходимо нажимать кнопку с красным кругом :). Предлагаю посмотреть, как ЭТО работает на следующем примере:
  • Проверяем, что SeleniumIDE пишет (красная кнопка нажата).
  • В адресной строке Firefox пишем: wikipedia.org.
  • На заглавной странице в выпадающем меню выбираем язык: English.
  • В строку поиска вводим: testing. Жмем ввод.
  • На странице результата поиска кликаем по: Software testing.Заканчиваем запись.
  • Видим следующее в Selenium IDE:


  • Полюбовались? Попробуем нажать на кнопочку play? Вау, оно живое! Порадовались? Ну хватит, хватит, давайте продолжать. В IDE в меню файл выбираем Export Test Case As->Java(Junit)-SeleniumRC. Я использую имя: TrySelenium.java. Пойдем посмотрим, чего там на экспортировалось?

package com.example.tests;

import
com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

public
class TrySelenium extends SeleneseTestCase {
public void setUp() throws
Exception {
setUp("http://wikipedia.org/", "*chrome");
}
public void
testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software
testing");
selenium.waitForPageToLoad("30000");
}
}

Имеем-с класс (название должно совпадать с именем файла!), содержащий последовательность вызовов селениум-методов, реализующих последовательность наших действий. Красота! Однако, хочется все это добро запустить через Selenium RC, а почему? Да потому, что Selenium RC позволяет преобразить записанный тест в оружие автоматизированного тестирования, используя мощь языка программирования и селениумовский библиотечных классов (громко сказано, а? а вдруг и правду может!). Для начала так далеко заходить не будем, а просто немного преобразуем java-код, дабы запускалось через RC.

import com.thoughtworks.selenium.*;
import junit.framework.*;
import java.util.regex.Pattern;

public class TrySelenium extends SeleneseTestCase {
public void setUp() throws Exception {
setUp("http://wikipedia.org", "*chrome");
}
public void testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software testing");
selenium.waitForPageToLoad("30000");
}
public static Test suite(){
return new TestSuite(TrySelenium.class);
}

public static void main(String args[]){
junit.textui.TestRunner.run(suite());
}
}

  • Надеюсь, JVM у вас в наличие? Будем считать, что да. Запускаем selenium-server. Открываем терминал, перемещаемся в папку, куда распаковали зипник с Selenium RC. Выполняем: cd selenium-remote-control-1.0-beta-1/selenium-server-1.0-beta-1 (Циферки зависят от скачанной версии!). И запускаем: java -jar selenium-server.jar. Можно запускать и в интерактивном режиме, но пока не трогаем. Смотрим, что не ругается, и радуемся, радуемся. А если ругается, текст ошибки «в зубы» и на просторы Интернета… Добились запуска? А кто бы сомневался.
  • Пришло время компилировать и запускать java-код. Инструкция (см. выше) предлагает поменять переменные среды, как сказано ранее, идем в обход. В папке, где обитает наш java файлик создаем директорию lib, в нее переписываем следующее добро: 1) Отсюда …/selenium-remote-control-1.0-beta-1/selenium-java-client-driver-1.0-beta-1/selenium-java-client-driver.jar; 2)Junit у Вас есть? Нет, ну так качаем, качаем. Отсюда в папку lib добро копируем …/junit-4.6/junit.jar.
  • Открываем еще один терминал, компилируем: javac -cp lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium.java. Ошибки не выпрыгнули? Хорошо! Выпрыгнули? Читаем, вникаем, в java-файл возвращаемся, исправляем, компилируем, повторяем, пока не перестанут выпрыгивать ошибки!
  • И вот он! Момент истины. Запускаем наше творение: java -cp .\;lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium. Ура! Оно живое! Браузер открывается, в поле текст запроса вводится… А если ошибка вываливается? Опять же читаем, понимаем, ищем решение! А потом радуемся, радуемся, что «каменный цветок» выходит!

Конечно же, приведенный пример очень и очень прост, ничего особенно стоящего он не делает. Но он поможет начать. На сайте Selenium «вагон и маленькая тележка» документации, а на просторах-то «нашего всего» интернета. Дерзайте!

Снова хочу процитировать Канера и Ко, а именно их «Lessons Learned in Software Testing».


Programmers are like tornadoes. Think of them as forces of nature.
Мой вольный перевод: «Программисты как торнадо. Воспринимайте их как силы природы».


Силы природы, силами природы, конечно. Но не все программисты такие :). Они все разные, как и тестировщики!
Работая в компании, выпускающей коробочный продукт, я себя чувствовала по другую сторону баррикад от разработчиков. Отдел разработки и отдел тестирования имели свои цели. И разработчики воспринимали нас как «врагов» их творчества :) Что-то от сил природы в них было!
А вот в проектной команде разработчики оказались надежными соратниками, «опора» в тестировании так сказать. Правда и я уже была более опытным работником :)
Я сторонник того, что программист - не враг, а отличный коллега. Если разработчик для вас враг, может быть дело в ВАС!


И опять я хочу процитировать Сема Канера и Ко. Эта фраза повстречалась мне в «Lessons Learned in Software Testing» (кстати, очень советую почитать, лаконично, полезно и, иногда, с юмором).
«It’s not a sin in testing to miss a bug. It’s only a sin to be
careless, thoughtless, or not to learn from your experience».
Мой вольный перевод: «Пропустить баг не есть грех. Грешно быть небрежным, неразумным или не учиться на своих ошибках».

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

Если случился такой «грех», важно понять причины и не допустить повторения в будущем.


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

Java™ Tutorial, Third Edition: A Short Course on the Basics By Mary Campione, Kathy Walrath, Alison Huml: "Comments make your code more readable; they help explain your code to others and serve as reminder to yourself when you maintain your own code"


Вольный перевод: "Благодаря комментариям код становится более читабельным, понятным и поддерживаемым".

Не стоит забывать про это и при создании автоматизированных тестов. Если конечно Вы занимаетесь автоматизацией серьезно, а не с целью освоения бюджета :)

P.S. Посмотрела я на блоги коллег и поняла, что с цитатой дня я погорячилась :) Пусть будет просто рубрика "Цитирование", без временных ограничений!


P.S.S. Картинка взята отсюда.


Все мы совершаем ошибки, порой очень глупые. Что тут поделаешь? Мы люди, а людям свойственно ошибаться. 9-го июня прошел бесплатный вебинар, на котором небезызвестный Рекс Блэк рассказывал о 10 худших вещах для тестирования (о 10 не очень умных вещах, которые он делал тестируя). Мистер Блэк обещался выложить презентацию в библиотеке сайта своей компании http://www.rbcs-us.com/.

Я же хочу вольно пересказать эти 10 вещей на русском. Приступим.

1. «Тестировать только то, что может инструмент автоматизации». Честно признаюсь, такого я не встречала, но оказывается, бывает.

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

3. «Писать «плохие» отчеты об ошибках». А ведь отчет об ошибке – это своего рода «лицо» тестировщика.

4. «Забыть, что тестирование – это услуга». Такого пока тоже не встречала.

5. «Игнорировать ключевых заинтересованных лиц». Это как минимум глупо, ведь эти самые ключевые заинтересованные лица просто кладезь «полезной» для тестировщиков информации.

6. «Сообщать плохие новости «плохо»». Опустить руки и сказать, что все «плохо» - проще всего, а вот предложить варианты выхода из «кризиса» - это уже очень интересно.

7. «Не определить цель тестирования». Вопросы задавать очень полезно, тут не поспоришь.

8. «Брать ответственность за качество только на себя». Качественным продукт может стать только благодаря усилиям всех членов команды, только тестировщики «воз не вытянут».

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

10. «Игнорировать неверные ожидания». Очень часто люди ждут от вас того, что вы сделать не можете. Может, стоит этих людей просветить?

Не скажу, что эти 10 «худших вещей» является открытием или откровением. Каждый из нас встречался с частью, а может и со всеми. Давайте же учиться на чужих ошибках!

А вы совершали ошибки, которые никогда не повторите?

P.S. Ожидаются еще бесплатные вебинары:

Six Surprises from Test Assessments July 1, 2009
ISTQB Advanced Certification August 5, 2009
Five Testing Best Practices September 3, 2009

Дополнительную информацию ищите на сайте компании Рекса Блэка.

P.S.S: картинка взята отсюда.


Планирование. "Как много в этом слове?". Не всегда тестировщиков допускают до планирования, а жаль. Сегодня хочу привести одну из моих любимых цитат.


Эффи Джонс: "Неудачное планирование - это запланированная неудача".


К сожалению, очень часто планированию не уделяют достаточно внимания. Почему? Русская традиция надеяться на "авось"?

Или же планирует только один человек за всех. Но может ли это всегда работать в разработке ПО?

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

P.S. Картинка взята отсюда.

Слушала 9-го июня вебинар Рекса Блэка (подробнее напишу в следующем посте). И очень мне понравилось следующее:
"Testing is only valuable when it connects to something the organization and the other stakeholders value".
Без комментариев!



James Bach: "Requirements are the result of ongoing struggles between what we want and what we can have".

Мой вольный перевод: "Требования - это результат непрерывной борьбы между тем, что нам хочется, и тем, что можем получить".

В самом деле, требования редко когда стоят на месте. Как только будующий пользователь увидит демо-версию, сразу захочет что-нибудь изменить или добавить :) Да и без демо-версий чего-то все время хочется изменить или добавить :)


Доброго времени суток!

Этим постом хочу начать ежедневное (с выходными днями и отпусками:)) цитирование интересных (по моему скромному мнению :)) высказываний, мыслей и т.п.

Приступим-с...

Абрахам Маслоу: "Если молоток - это единственное, что у вас есть, то каждая проблема покажется вам гвоздем".


Частенько встречала, что если есть какой-то тул для автоматизации тестирования, то срочно нужно ВСЁ автоматизировать. А какие "гвозди" и "молотки" встречались в вашей профессиональной деятельности?


Чтобы тестирование было эффективным необходимы (прошу заметить, что только необходимы, а не достаточны) эффективные сценарии тестирования. Для создания эффективных сценариев тестирования существуют различные подходы, техники, методы. Рассмотрим разбиение на классы эквивалентности.

Согласно толковому словарю Ожегова класс - относительно целостное множество каких-нибудь единиц, существующее в составе сложного единства, расчленяемого на такие множества. Согласно БЭС, эквивалентность – отношение типа равенства.

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

Рассмотрим пример. Допустим, мы тестируем Интернет-магазин, продающий карандаши. В заказе необходимо указать количество карандашей (максиму для заказа – 1000 штук). В зависимости от заказанного количества карандашей различается стоимость:
  • 1 – 100 – 10 руб. за карандаш;
  • 101 – 200 – 9 руб. за карандаш;
  • 201 - 300 – 8 руб. за карандаш и т.д. С каждой новой сотней, цена уменьшается на рубль.

Если тестировать «в лоб», то, чтобы проверить все возможные варианты обработки заказанного количества карандашей, нужно написать очень много тестов (вспоминаем, что можно заказать аж 1000 штук), а потом еще все это и протестировать. Попробуем применить разбиение на классы эквивалентности. Очевидно, что наши входные данные мы можем разделить на следующие классы эквивалентности:


  1. Невалидное значение: >1000 штук;
  2. Невалидное значение: <=0;
  3. Валидное значение: от 1 до 100;
  4. Валидное значение: от 101 до 200;
  5. Валидное значение: от 201 до 300;
  6. Валидное значение: от 301 до 400;
  7. Валидное значение: от 401 до 500;
  8. Валидное значение: от 501 до 600;
  9. Валидное значение: от 601 до 700;
  10. Валидное значение: от 701 до 800;
  11. Валидное значение: от 801 до 900;
  12. Валидное значение: от 901 до 1000.

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

Приложение.
В качестве дополнения хочу привести парочку определений Equivalence partitioning.

Сем Канер, Джеймс Бах и Брет Петтихорд в Lessons Learned on Software Testing называют эту технику – Анализ классов эквивалентности (Equivalence class analysis) и определяют ее следующим образом:
«Класс эквивалентности – это набор значений переменной, который считается эквивалентным. Тестовые сценарии эквиваленты, если a) они тестируют одно и тоже; b) Если один из них выявляет ошибку, то и остальные выявят ее; c) Если одни из них не выявляет ошибку, то и остальные не выявят. Если определен класс эквивалентности, протестируйте только одно-два значения из него».

RSTQB

определяет технику следующим образом:

«Эквивалентное разбиение: Разработка тестов методом черного ящика, в которой тестовые сценарии создаются для проверки элементов эквивалентной области. Как правило, тестовые сценарии разрабатываются для покрытия каждой области как минимум один раз».

И напоследок, любая поисковая система (я предпочитаю, google) выдаст вам кучу определений, пояснений и примеров.



Согласно он-лайн словарю multitran.ru, exploratory – исследовательский, разведочный. Итак, что же такое exploratory testing. Ниже описано как это вижу я.

Очень полезная техника тестирования. Я люблю называть её «тестирование в свободном полете». Ошибок бесконечное множество. Все найти невозможно (если это конечно не программа «Hello World!»). Мы пишем сценарии тестирования, мы прогоняем их по нескольку раз. Проторенная тропинка – это конечно хорошо, но пользователи все-таки не роботы. Рука может дрогнуть, и очередной клик мыши может привести к появлению сообщения об ошибке. Поэтому неплохо периодически прибегать к свободному полету.

Итак, вы планируете провести несколько раундов тестирования, выделите пару часов (полдня, или день, как позволяет время) на exploratory testing. Допустим, тестировщик «Вася» тестировал функциональность А, а тестировщик «Ира» функциональность В. Пусть в конце раунда «Вася» «потыкает» функциональность В, а «Ира» функциональность А. Только не по тестовым сценариям, а просто так, куда душа пожелает. Пусть они каждое действие свое начинают с вопроса «А что, если … ?», пусть исследуют, разведывают. Мой опыт показывает, что данный подход дает положительный результат. Либо найдется серьезная ошибка – и нужно будет задуматься о качестве тестовых сценариев, либо мелкая, но её исправление удовлетворит заказчика еще больше, чем не исправление, а тем более не нахождение :)

Я не считаю, что exploratory testing можно использовать как самостоятельную технику тестирования, ибо только оооооочень опытный, знающий продукт и предметную область, специалист сможет выдать «хороший» результат. А вот как вспомогательная техника – да, весьма полезная штука. К «свободному полету» следует подключать не только членов команды тестирования, а любого свободного члена проектной команды. Ведь даже PM может находить ошибки, и очень любопытные :)

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

Разные люди приходят на собеседование. Но больше всего меня поражают те, что хотят стать разработчиком, но идут на позицию в тестировании, и работают в тестировании не первый год. Да и объяснить, почему это так толком не могут.
Кто же виноват в такой ситуации? Сам человек? Его начальник? Его, так называемый, people manager? А что вы думаете по этому поводу?

Оригинал статьи: Lost in Translation
Об авторе: Пейсон Хэлл системный инженер и консультирующий руководитель проектов в Catalysis Group в Калифорнии. В течении 26 лет он консультировал различные проекты в частном и государственном секторе в Северной Америке и Европе. Связаться с ним можно по адресу: payson@catalysisgroup.com.

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

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

Система еще не была собрана, однако по слухам производительность уже тестировали, мне не хотелось ставить команду в затруднительное положении прямо на проектном собрании. Вместо этого, я решил разобраться в ситуации и дать им шанс ее разъяснить, для этого я спросил «Когда вы думаете провести тестирование производительности, и сколько оно по вашему займет времени?». Ответ архитектора потряс меня. «А мы уже провели тестирование производительности и результаты хорошие».

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

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

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

Я очень резко поинтересовался у моей знакомой, занимающей пост Руководителя команды «Что он нес? Мы оба знаем что никакого тестирования производительности не проводилось!»

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

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

Пару месяцев назад на форуме it4business шли дебаты о статье «Нас не учат «как», нас учат «чему-то»» (http://it4business.ru/forum/topic13672.html). А вспомнила я про эти дебаты, слушая с дочкой детские песни. Есть такая песня «Точка, точка, запятая...» и в ней есть замечательный ответ на вопрос зачем нам учить кучу предметов, которыми мы по большой части никогда не будем пользоваться в работе, да и в жизни.

«Что Вы! Что Вы!
Это важно!
Чтобы вырос он отважным
Чтобы мог найти дорогу,
Рассчитать разбег
Это трудно, это сложно
Но иначе- невозможно
Только так из человечка
Выйдет Человек»

Просто в университетах из нас пытаются сделать «Человеков» :) Лично я не жалею, что меня учили сопромату, теормеху, тмм, механике машин и т.д. Я знала куда иду учиться. Да и при правильном подходе данные предметы не вызывают проблем. Зато теперь я знаю, что могу решить поставленную задачу, если захочу :)