20 июня 2016

Мероприятие: QA Meetup в Нижнем Новгороде


Собственно говоря, то что было проанонсировано мной вот тут случилось.
Я последнее время люблю выезды на такие вот узкоспециализированные мероприятия по причине релевантности аудитории и демократичности формата.

Место

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


Организация

Все хорошо, все вовремя.

Доклады

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

Юлия Сомова про микросервисы которые помогают автоматизации тестирования Почты@Mail.Ru. Слушая доклад Юли я пришел к мысли? что спустя какое-то время любая большая (ну или значимая) автоматизация тестирования становится похожей на соседей по отрасли.

Алексей Халайджи про автоматизацию тестирования IOS - хорошо и с инсайтами.

Максим Богуславский - про то как взращивать в себе автоматизатора. Годно.

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

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

Слайды презентации



Видео - спасибо киностудии Boguslavsky Films и главному режиссеру, сценаристу и видеооператору Максу Богуславскому за то, что попытался сделать из моего выступления блокбастер :) . Видео остальных докладов будет позже.

Часть 1


Часть 2



Код лежит на гитхабе
https://github.com/kronar/testcontainers-eval

16 июня 2016

Напочитать: Автоматизация тестирования: Disruptor


Два доклада про тестирование в LMAX  вдохновили.
Потому и  Disruptor.

1. Адовый рассказ про то как делать Continuous Delivery на биржеквых проектах от LMAX.
2. Продолжение темы, только более философское, но тоже от выходца из LMAX.
3. Про автоматизированное тестирование CRIU и суровый линуксовый жесткач
4.  Подборка статей от пользователя @irony_iron на хабре про автоматизацию очень сурового системного тестирования - антивирусы и перезагрузки, инсталляторыавтологины в винду. Очень хардкорно!
5. XPath, JsonPath... теперь GPath - очередная path-нотация для JSON. Но в RestAssured.
6. Про то как скалировать тестирование на Robot Framework под Docker - презентация, видео, код
7. Про Jenkins Workflow - с картинками и примерами.
8. Log4J теперь говорят не тормозит.
9. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests - и другие интересности от Google как они борятся с  flaky tests. Спойлер: все банально!!!
10. Про автоматизацию тестирования c мобильными устройствами , но не теми про которые вы подумали.
11. Маленький хак для тех кто использует Spring Test.
12. Гойко Аджич про то как сократить издержки на большие тестовые наборы - на самом деле тэги по функциональности, отсутствие зависимостей при запуске тестов, выделение утилитарного слоя кода, хорошие имена для тестов.
13. Про то как взять и упороться функциональщиной из Java8 в Selenium-тестах - с примерами и картинками.
14. Очень полезная вещь - Jenkins-у можно править конфиги удаленно, сам несколько раз пользовался.
15. PowerShell и Jenkins.
16. Github выпустил Spectron 3.0 - тестовый фреймворк для своего поделия Electron (Desktop приложения на node.js) написанный поверх  CrhomeDriver и WebDriverIO.
17. Maven + JUnit + интегрционные тесты  и все как мы любим.

10 июня 2016

Книга: Уильям Детмер. Теория ограничений Голдратта.

Собственно давно я не писал обзоров на книги.
Тому была масса причин: во-первых, пачка книжек купленная у МИФа (Кэрол Дуэк и Осознанность) оказались полным фуфлом, где авторы размазывают одну мысль на 400 страниц, а во-вторых, хотелось хорошего, "тяжелого", чтива, с хардкором, мыслями, так чтобы котелок кипел.
Вот собственно и достал с полки ту книгу, которая стояла в списке на прочтение еще с момента отзыва на нее Макса Дорофеева.


Итак, если вы не читали "Цель" и "Цель-2" Голдратта и/или не знакомы с Теорией Ограничений, то нырять в эту книжку вам не стоит вообще - ни в скафандре, ни без него.
Как я писал ранее, во втором томе "Цели" Голдратт обрисовал практические случаи применения тех или иных инструментов, но не расскзаал методику, видимо оставляя для себя возможность заработать не только на книге, но и на тренингах.

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

Итак, "мыслительные инструменты" Голдратта по факту состоят из 5 деревьев которые нужно  последовательно применять при проведении изменений:

  1. Дерево текущей реальности - чтобы понять что менять
  2. Диаграмма рзарешения конфликтов - чтобы понять конфликт интересов который не позволяет провести изменения 
  3. Дерево будущей реальности - чтобы проверить куда приведут изменения и приведут ли они туда куда нужно, какие еще последствия будут
  4. Дерево перехода - позволяет ответить на вопрос "что еще нужно для того чтобы все получилось?" и определить с какими препятствиями вы столкнетесь.
  5. План перехода - пошаговый план проведения изменений, вытекающий из предыдущих 4 пунктов. 
Читая книгу, меня не покидало ощущение того, что я все это уже где-то видел и даже делал.
Не, ну на самом деле: дерево текущей реальности - это Root-Cause Analysis как ни крути, диаграмма разрешения конфликтов - это суть есть mind-map, только выстроенный по определенной семантике.

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

Собственно наверное рафинированным смыслом книги и является - вложить в голову читателю две вещи:

  1. Стандартный менеджерский фреймворк "Что менять? На что менять?  Как провести изменения чтобы все не разлетелось к херам ну и результаты тоже было бы неплохо поиметь ?"
  2. О чем нужно еще подумать при ответе на каждый вопрос из п.1 
Книга оснащена массой иллюстраций и примеров - неудачных в большинстве своем, надо сказать.

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

Итого
Читать - стоит.
Голдратту за "мыслительные инструменты" - 4 с минусом - мог бы и сам с нормальными примерами расписать.
Детмеру и российскому изданию - 3 с минусом - только потому, что тренинги стоят сильно много денег.

07 июня 2016

Анонс: 17 июня - QA Meetup в Нижнем Новгороде


17 июня в Нижнем Новгороде будет проходить QA Meetup.


Адрес:  г. Нижний Новгород, Ковалихинская, д.8, Центр Мировой Торговли, Медиа Страйк Холл (10 этаж)

А ну и да, спойлер доклада, как обычно




02 июня 2016

Они учат тестировщиков программировать



История и причины возникновения научной дисциплины
критически важны для понимания самой дисциплины.
Н.М. Светлов, первая лекция по Теории Систем и Системному Анализу.


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

Вы знаете кто такой Бэри Боэм? 
Это все было задолго до всяких Lean/Minimal Viable Product, а идеи-то те же.

Так вот, разработка Боэма и тестирование Бейзера - это одна история нашего тестирования, да и вообще всего IT.
Точнее даже первая, которую в контексте тестирования начал Джерри Вайнберг в 1958 году:

We made the first separate testing group that I know of historically (I’ve never found another) for that Mercury project because we knew astronauts could die if we had errors.We took our best developers and we made them into a group. It’s job was to see that astronaut's didn’t die. They built test tools and all kinds of procedures and went through all kinds of thinking and so on. The record over half a century shows that they were able to achieve a higher level of perfection (but it wasn’t quite perfect) than had ever been achieved before or since.


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

А история первая потому, что вторая выродилась из нее. Иначе и быть не могло.
Вторая история тестирования - это история тестирования коммерческого ПО.
Это как раз про конец 70-х - начало 00-х - именно в этот период компьютеры перестали быть (массово, я имею ввиду) прерогативой военных и крупного или окологосударственного бизнеса, и стали доступны среднему и малому бизнесу. Именно здесь цена ошибки измеряется не коллапсами на уровне страны или поражением в войне с кучей людских потерь, а всего лишь деньгами. Именно здесь есть высокая конкурентная среда, высокая скорость изменений, драка за каждый процент рынка.

И тестировали этот коммерческий софт тогда в том числе и те, кто вышел из околовоенки.
Именно этим я объясняю лично себе, то количество "незаменяемого" софта написанного на COBOL/FORTRAN и прочем - это хороший софт написанный для коммерции, но с критериями качества, унаследованными от "военки".
Вообще весь второй этап  можно охарактеризовать одним словом - специализация.
Потому, что тогда нужно было делать много сравнительно похожего софта, это было массовое производство, с присущей ему специализацией и конвеером.
Нужно рисовать много UI, нужно много администрировать БД, нужно писать много технической документации.
И специализация людей для каждого этапа - дело вполне себе логичное и даже эффективное.

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

Так вот, собственно говоря, причем здесь "Они учат тестировщиков программировать" ??

А вот, на мой взгляд, ситуация из которой выросло тестирование в первом этапе нашей истории - когда мы делаем высокорисковые проекты, с совершенно непонятным результатом, в совершенно неизвестном домене, где все во что ни плюнь - пипец (!!!), инновации!!!! -  она структурно идентична той ситуации которая сейчас, на третьем этапе нашей истории, наблюдается на рынке, когда все хотят автоматизацию тестирования, чтобы тестировщики валидировали продуктовые идеи, умели читать логи и мониторить продакшен,да еще и в юзабилити разбирались.
С той лишь разницей, что тогда были системы ПВО/ПРО / межконтинентальные ракеты/ Буран , а теперь AirBNB/ беспилотные автомобили/Amazon Prime, который доставляет покупки дронами.

Это все, кстати, и не про тестировщиков тоже - у погромистов (опечаток тут нет) те же самые попабольки - давайте, вы, погромисты, будете знать как это все разворачивается в продакшене, как и где и из чего сделан CI, построите мониторинги, будете работать с метриками с продакшена, запускать A/B тесты на живых пользователях и при этом не требовать прибавку к зарплате на ношпу и анальгин (виски вам может еще наливать???) за то что это типа не ваша работа.
Термин full-stack developer шагает по сайтам для поиска работы.
Потому что в большинстве случаев сейчас не нужно "хорошо, но только вот это", нужно "нормально, но все", так чтобы взлетело, а там посмотрим что пользователи скажут, подкрутим.

Тестировщиков учат программировать, програамистов тестировать и все это в угоду одному - скорости бизнеса.

Все разговоры и выступления типа Testing is Dead/Testing is not Dead - это все стандартная пропаганда молодой поросли, чтобы побыстрее вытеснить старую плесень ну или нечто сродни рыку молодого льва в саванне, когда старших нет рядом и никто не может дать по башке.

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

Совершенствоваться не обязательно. Выживание — дело добровольное. © Эдвард Деминг.

P.S. откопал в просторах интернетов вот такую вот летопись