2013-11-07: SQAdays - английский день

Короткая ссылка: SQAdays-14-mtsepkov-EnglishDay

Ссылки сюда (2) →

Сегодня прошло новое мероприятие в формате SQAdays-14 во Львове — английский день. Два трека докладов англоговорящих спикеров из разных стран Европы и США, многие из которых приехали с конференции EuroSTAR. И это важно, потому что дает возможность соотнести себя и свою компанию с мировым уровнем, понять свое место в глобальном сообществе. Отметим, что конференция шла на английском языке и без перевода, что было фишкой и служило тем же целям. И даже Влад Орликов открывал этот день по-английски.

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

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

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

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

Итак, обзор докладов.

Wiktor Żołnowski. You can write automated acceptance tests even if there is no functionality yet!

Code Sprinters. Cracow, Lesser Poland District, Poland.

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

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

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

Raul Liive. Software development outsourcing via the eyes of purchacer

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

Željko Filipin. How software that runs Wikipedia is tested

Wikimedia Foundation. Zagreb, Croatia

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

René Tuinhout. The tester's dilemmas

Groningen Area, Netherlands.

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

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

В целом рассказ о расширении области тестировщика с традиционных acceptance test практически на всю правую ветвь V-модели разработки.

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

Sogeti Finland Oy. Espoo, Finland.

TPI — это Test Process Improvement. А TPI NEXT — методология неуклонного улучшения тестирования, business 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. Наверное, все оно правильно, и об этом стоит думать, но вот в применимости этого формализма у меня сомнения. Прежде всего потому. что он представляется мне слишком сложным для столь скромной области, которую занимает тестирование относительно всей области разработки софта.

Jim Holmes. Four Crucial Tips for Automated Web 2.0 Testing

Telerik. Ohio Area, USA

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

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

René Tuinhout. Passionate Partnering, for Testers

Groningen Area, Netherlands

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

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

Olivier Denoo. Who Killed MyProd?

ps_testware SAS. Liège Area, Belgium.

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

Dzmitry Harachka. Generalization in Auto-Testing. How we put what we had into new Technological Platform XML2Selenium

JazzTeam. Minsk, Belarus

Был на небольшом кусочке. А рассказ был о платформе XML2Selenium, которая позволяет писать тесты на XML с использованием ООП с его плюшками, выделяя ядро и plugins. С разными подробностями.

Jim Beattie. The evolution of QA at JUST EAT

Just-Eat Group. London, United Kingdom

Рассказ о том, как устроено тестирование в компании 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.

Lucjan Stapp. Why I do not like to be a tester in Agile project?

Polish Testing Board. Warsaw, Poland.

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

Knud Hangaard. How to manoeuvre as test/QA responsible in agile teams to get the right product quality

Saxo Bank. Copenhagen, Denmark

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

В целом процесс описан достаточно подробно, с состояниями, командами и прочим. Но именно Как, без Зачем и Почему, а оно не интересно :( Разве что чуть-чуть подглядеть.

---

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— MaksTsepkov • 02:34, 8 ноября 2013 • нет комментариев