Изменения

Сегодня прошло новое мероприятие в формате [http://sqadays.com/ru/index-news.sdf/sqadays/sqa_days14 SQAdays-14] во Львове - — английский день. Два трека докладов англоговорящих спикеров из разных стран Европы и США, многие из которых приехали с конференции [http://www.eurostarconferences.com/ EuroSTAR]. И это важно, потому что дает возможность соотнести себя и свою компанию с мировым уровнем, понять свое место в глобальном сообществе. Отметим, что конференция шла на английском языке и без перевода, что было фишкой и служило тем же целям. И даже Влад Орликов открывал этот день по-английски.

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

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

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

А из общего пожелания докладчикам и организаторам конференции я бы отметил две вещи. Во-первых, надо жестко запретить примеры про форму логина. Потому что она настолько тривиальна, что скучна. Во-вторых, смерть от powerpoint PowerPoint докладчики изучили (не все, только продвинутые), и теперь им надо объяснять, кто что когда на слайде креативная картинка, под которую долго-долго что-то говорят, то это тоже плохо. Особенно , когда говорят монотонно. Мне лично слайды, где много букв даже больше нравятся - — при условии, что докладчик их не читает - — получается документ, который можно на досуге внимательно прочесть. Вот так.

Хороший докладчик с веселым троллингом во время доклада, даже с самого начала. Кто тут тестеры - — лес рук. Кто SQA-инженеры - — тоже лес. А вы разницы не видите? А если видите, то кто же вы.

Рассказ про ATDD - — Acceptance TDD, потому как просто TDD - он — для разработчиков. Про требования, которые должны быть. , чтобы это хорошо работало - — INVEST: Independent, Negotiable, Valueable, Estimatable, Small, Testable.

Правда, не говорит, как этого достичь. И даже в вопросах на эту тему - — поплыл. А дело в том, что простая декомпозиция этого не дает, она дробит целостность. Это как требование писать короткими предложениями - : она сильно ограничивает , и не любые тексты можно так написать, сложные смыслы во всей полноте передать не получится. Я тут не удержусь от ремарки - : как этого достичь, рассказывал Ивар Якобсон в своем мастер-классе на SECR, подробности можно прочитать [[Блог:Максима Цепкова/2013-10-23: SECR. Мастер-класс Ивара Якобсона Use-Case 2.0|у меня в обзоре]], там же ссылки на материалы.

Skype. Tallinn, Estonia. На мой взгляд, доклад не слишком удался, прежде всего из-за формы - : длинный монотонный рассказ на фоне слайдов с креативными картинками. Сутью той части, которую я слушал , были рассказы про индийских аутсорсеров - — дешево, но не качественно.

Достаточно плотный рассказ, как тестируется wikimedia - Wikimedia — движок wikiWiki. Как человек из CUSTIS, в которой wikimedia Wikimedia используется внутри и потому развивается, и Виталий Филиппов контрибутит нашит наши доработки в вики, я представляю, что тестирование там не экстаэкстра-замечательное/ , да и код тоже. Потому как цели - — другие. Но - вполне на уровне. И то, о чем говорил докладчик - , — некоторая планка для приличных web-проектов, которая должна присутствовать.

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

Как пример такого тезиса: Test manager are obsolete - — Go to Obsolete! Развитие его - — тестирование как отдельные отделы — не слишком живо, но как процесс - — есть, им надо управлять , и потому сейчас test manager - не должность, а роль.

==Wiktor Żołnowski. Reversed Test Pyramid - — Testing and dealing with Legacy Code== Второй доклад Виктора удался. , на мой взгляд, хуже первого. Он показывал, что та стройная картина тестирования, которая выстроена гуру, не работает для legacy-кода. Ну да, не работает, а что, кто-то сомневался? А вот позитивной части о том, как с этим быть - , — практически не было. Кроме идеи построения пирамиды тестов сверху, от GUI - , потому как оно — единственное, что точно дается в ощущениях и можно протестировать. Ну и дальше - — рефакторить и рефакторить, мысль о переписывании отвергается...

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

==Tapani Aaltio. Test Process Improvement with TPI NEXT - — what the model does not tell you but you should know==

TPI - — это Test Process Improvement. А TPI NEXT - — методология неуклонного улучшения тестирования, business drivemn driven testing. 16 key area in 3 groups: stakeholder relations, test management, test profession. 4 matirity levels: Initial - — Controlled - — Efficient - — Optimizing. Внутри уровней - — еще подуровни, по каждой из 16 областей - свои, всего 157 check point. Наверное, все оно правильно , и об этом стоит думать, но вот в применимости этого формализма у меня сомнения. Прежде всего потому. что он представляется мне слишком сложным для столь скромной области, которую занимает тестирование относительно всей области разработки софта.

Практические приемы по написанию тестов, правильного правильных с точки зрения сопровождения и поддержки написания xpath и другими способам работы с web-интерфейсами. В целом оно — по делу, имея нехилый опыт xsl , сам многое могу оценить.

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

Второй доклад Рене, с провокациями и троллингом. Началось сначала - — в середине традиционного "вы «вы кто"?», на которое не все поднимают руки, попросить поднять сначала мужчин, потому потом женщин, а потом заметить, что остальные, наверное, не определились :)

Рассказ был о техниках тестирования: equivalence partitioning, boundary value analysis, decision table, state transition testing, process testing. Ну и о других тоже, но коротко. А еще - о том, что тестировщики часто смотрят на мир через розовые очки, а оно вредно для результата получается.

Неторопливый рассказ. История про фейл продукта - : что думают участники команды о причинах, друг о друге. Завораживает. Хотя беллетристика - : анализа и вариантов там нет. А заключение - тривиально, хотя и верно: думайте каждый день "что , «что не правильно, что я могу изменить"изменить».

Рассказ о том, как устроено тестирование в компании Just Eat - — local takeaway online. К ней подключены 36000 ресторанов в 13 странах. И у них 10 тестеров в Англии и 6 в Киеве.

Техники, которые раскрывались - , — efficient process, exploratory testing (testing gaps), crowdsourcing, using users. И состав используемых документов - : test strategy, test approach, test plan, entry-exit criteria, test cases, test execution matrix, test evidence.

На этом докладе я не был, но говорят, докладчик скучно рассказывал, что agile - Agile — хорош, но получается обычно не очень :) Вспоминается бессмертное Черномырдина "Хотели «Хотели как лучше, а вышло как всегда"всегда». Простите, что распространяю слухи...

Банк специализируется на услугах по торговле на валютной бирже, FX trade, предоставляя их в 25 странах. У них 1300 сотрудников, из них 700 IT-шников. Разработка - inhouse, большие проекты. Показывал development model - — интересные agileAgile-кольца, организованные в конвейер/водопад(? ), это надо будет посмотреть, потому что на экране деталей видно не было.