Нет доступа к коду? Проверяй все!

Недавно выступала на Education Day в нашей компании, рассказывала о тест-дизайне на примере треугольника. Какие тесты можно написать? В частности, можно логически прикинуть, что треугольники бывают разные - равнобедренные, равносторонние, разносторонние.

И в конце один разработчик спросил "А зачем нам проверять, равносторонний треугольник или разносторонний, если нам площадь нужна? Это же одинаковые тесты". Иногда - да. Но, когда мы тестируем черный ящик, мы никогда не знаем заранее, а программистам, как известно, верить нельзя 

Расскажу историю из жизни, подтвердившую эту теорию не далее как сегодня.

Есть у нас, значит, некий калькулятор. Не в смысле виндового калькулятора, а просто есть 8 разных атрибутов (а1, а2, а3... а8), у каждого свой вес и общий должен быть равен 100%.

Атрибутика имеет свои типы и мы хотим, чтобы было неважно, сколько у нас атрибутов типа а4, если у него вес 40, то он будет 40, будет у нас один а4, два или больше.

Такой вот алгоритм. В требованиях указываем эти веса, отдаем разработчику. Он выполняет, передает задачу мне.

Как будем тестировать? В моем случае - автоматизировать.

• Сначала выполняем модульные тесты, дергаем каждый атрибут в отдельности и убеждаемся, что у калькулятор выдает вес данного конкретного атрибута. 
• Потом проверяем, что если вобьем парочку, будет сумма. 
• Потом проверяем, что сумма всех-всех-всех будет 100%. 
• Потом проверяем, что если у нас 2 атрибута а4, то результат его вес учитывается 1 раз.
• Потом проверяем негативные тесты (если нюансы в алгоритме).

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

Но начать, конечно, надо с простых проверок алгоритма. И вот я начинаю писать тесты:

• Только а1
• Только а2
• Только а3

Потом у меня возникает некий вопрос в реализации и я обращаюсь к разработчику:

Ольга Киселева: Привет! Слушай, имеет ли смысл тестировать вот это и это в обоих методах, или они примерно одинаковы, пишем основные тесты в одном месте, а во втором парочку базовых, чтобы не копипастить лишнего? Отличаются ли эти методы?

Разработчик: Помни что формула расчета полностью покрывается юнит-тестами. 

Разработчик: Не сильно, все рассчитывается в одном месте.

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

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

Но интересно жеж! Дай-ка, думаю, посмотрю, что ты там понаписал. Благо, в JIRA есть у нас закладка Mercurial Commits и я могу отследить, что там разработчик накоммитил. Смотрю, ага! CalcTest.java - то, что надо.

Открываю, начинаю читать... И что я там вижу? Каких-то жалких 3 теста!!!

Один на одиночный атрибут а1, второй на сумму а1 + а2 + а3 и полная сумма, 100%.

Разговариваем дальше:

Ольга Киселева: и это ВСЕ? О_О

Ольга Киселева: 3 тестика?!

Ольга Киселева: то есть мне основные тесты в этот класс написать, да?  В API парочку, чтобы на верхнем уровне тоже поймать, да?

Разработчик: ага

Разработчик: много тестов не значит хорошо

Разработчик: эти 3 теста все покрывают))

Ольга Киселева: 3 тестика!!!

Ольга Киселева: ничего они не покрывают) у тебя четкие требования на каждый атрибут 1 число, а ты 1 число проверил и пошел сумму фигачить

Ольга Киселева: сумма тоже важна

Ольга Киселева: но отдельно каждое число

Ольга Киселева: отдельно сумма ]:)

Ольга Киселева: сама напишу)

Разработчик: пиши, но ваще сумма такая весчь, она слагается из кусочков

Вот так вот отдавать проверку алгоритма на откуп разработчика. А если бы у меня не было доступа к коду? Если бы я тестировала вручную, допустим? Вот поверишь, что весь алгоритм уже покрыт, не проверишь и все... 

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

Нет, оно, конечно, работает. Но автотесты зачем нужны? Чтобы ты потом внес изменение и у тебя отъехали тесты, показав, что ты задел эту часть, этот модуль.

А ведь мы можем изменить код так, чтобы у нас ничего не упало. Например, перепутать коэффициенты а3 и а2. У нас написан тест на а1 + а2 + а3. И он пройдет, все же хорошо, от перемены мест слагаемых сумма не меняется.

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

Нерадостная перспективка 

Отсюда делаем вывод - разработчикам верить нельзя!! Особенно, когда они говорят "это полностью покрыто unit-тестами", ага, полностью... Вот сижу сейчас и наслаждаюсь, что могу на нижнем уровне нафигачить тестов, без всяких дополнительных параметров. А там ведь даже сам алгоритм можно и так повернуть, и сяк, и вот так! Ух! Так интересно  А они - 3 тестика...

ТМ. Описание автотестов по помидору

Применение практик тайм-менеджмента в действии!

Я уже писала про интересную книжку про методику работы по помидорке (Штаффан Нётеберг, Тайм-менеджмент по помидору).

Чем книга хороша? Описывает ровно одну методику. А когда мы читаем все остальные книжки, то там столько всякого разного! Но в итоге читаются они как роман - "да, да, было бы интересно, но у меня точно не получится". Или "ой, ну здравствуй, кэп, это же очевидно". В общем, как-то оно не внедряется все.

А вот технику помидорки я держу себе на уме и применяю к нудным задачкам.

Знаете, как бывает? То ли задача надоела (например, пишешь автотесты несколько дней подряд), то ли настроение такое, то ли еще что. Но в итоге - вот она, задача, вроде как делать недолго, а процесс растя-я-я-я-гивается. Кофе попить, клиенту ответить, с коллегой обсудить другую задачу, проревьюить скоуп своих активностей, да мало ли что можно найти!

Так и у меня сегодня. Прихожу на работу, а тут бац - собеседование. А потом через 15 минут уже на обед уходим (я с 12 на работе). Занялась задачей, которая досталась мне "по наследству", автотесты написаны, надо проревьюить и сделать описание. Но не идет и все тут! До обеда наваяла, там делов то, десяток тестов описать... Что сложного?

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

Тут то и помогает помидорка. Во-первых, оценить, куда уходит время. А во-вторых, сосредоточиться. Потому что когда работа не идет, хочется почитать скайпик, почту, пойти попить кофе... В общем, потратить время куда-нибудь еще

Поэтому заводим таймер и погнали! 25 минут занимаешь одной задачей. Никакого скайпа, аськи, почты, отвлечения на коллег и так далее. Только твоя задача. Больше ничего.

Потом, в идеале, 5 минут отдыха и по-новой. Но у меня так редко получается. То уйдешь больше чем на 5 минут, то коллега что-то спросит, пойдешь инфу искать... В общем, не получается у меня делать правильно. Да, видимо, пока особо и не надо. Поэтому этот метод я применяю именно когда чувствую, что меня тянет куда угодно, только не к задаче.

25 минут поработал, потом иди отдыхай. Опять поработал, опять отдыхай. И знаете, действительно помогает! Ты видишь какой-то прогресс, а не так, что "день прошел, ничего не сделал". Нет, "полчаса прошло, описал 5 тестов", уже неплохо.

Кстати, когда я сегодня завела помидорку, я потом в осадок выпала, за 25 минут я описала 3 теста из 7! Я не вставала из-за стола сходить за чаем или фруктами. Я не открывала мессенджеры или почту. Я не сидела-мечтала, я делала эту задачу. И такой результат!!! Вот оно, казалось бы, простое занятие. Как думаете, при планировании времени стоит выделять по полчаса на 3 тестика, которые ты даже не пишешь, а описываешь? Нет. А потом удивляемся, почему не укладываемся в сроки.

Тут стоит заметить, что утром я описала простенькие тесты, а эти уже сложные пошли. Заодно я там небольшую ошибку нашла из серии "копипаста наше все", копипастой же и исправляла. Так что, тут подправить, там подкрасить (чтобы разделить участки теста, покрасить их в разные цвета в экселе), тут описать, там подумать, что еще можно сделать, хватает ли этих тестов...

Поэтому так долго. Пока вникнешь в сложную логику... За вторую помидорку я допилила 3 теста и уже переключилась на другие. Это мне чем-то напоминает кривую производительности при найме нового сотрудника. Сначала производительность отдела падает - сотрудник учится, ничего пока не делая, а остальные ему помогают, тратят свое время. Потом кривая начинает ползти вверх и вот мы получили ожидаемый прирост.

Но ведь есть упадок вначале! Так и тут. Вначале вникаешь и долго тупишь, а потом хоп - и все быстренько сделал! Но если сидеть оценивать, то вроде как это все легко и мы смотрим сразу на ту часть кривой, где выходим в плюс. А надо быть реалистами

Вообще, сегодня еще раз убедилась в эффективности техники. Вроде простая. Элементарная буквально. Но как помогает! Или я одна такая, которой периодически хочется поотлынивать от работы? А тут вроде поставил себе цель "25 минут не отвлекаешься" и сразу такая сосредоточенность. Ну и что, что скайп с почтой мигают? За полчаса никто не умрет, не получив моего ответа. Подождет. Все подождет. А главное, недолго! И с результатом

Используйте the IEEE Standart 829. Не используйте the IEEE Standart 829

В книжке Lesson Learned in Software Testing идут подряд 2 замечательных совета:

• 145. Use the IEEE Standart 829 for test documentation.
• 146. Don`t use the IEEE Standart 829.

Не буду, пожалуй, приводить тут пусть и вольный, но перевод советов.

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

Нельзя просто взять и втупую заполнить стандартный шаблон, все-все-все его поля. Это вам не по-мо-жет! А поможет вам стандартное "СЯДЬ И ПОДУМАЙ!". Подумай, что тебе на самом деле нужно, какой цели ты хочешь достичь и поможет ли тебе в данном случае этот стандарт? А если нет, то зачем он тебе нужен? Начальство требует, так как "стандарт же, это не может быть плохо"? Ну так вперед, развивай навыки коммуникации и убеждения в том, что это все не так, как кажется. Пригодятся еще, с разработчиками сотрудничать

Ron Patton. Software Testing

Мои выдержки из книги:

1. Что же такое - баг?
2. Цель тестировщика
3. Тест дизайн VS дизайн кода
4. Не забудьте про документацию пользователя!
5. Финальной версии спецификации не бывает
6. Чем полезен доступ к коду...
7. Black-box, white-box, static, dynamic...

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

Книжка по основам тестирования, затрагивает все основные моменты, которые вам стоит знать. Имхо, для начинающих она на втором месте после Lee Copeland. Русский аналог Романа Савина. конечно же, крутой. Но у Романа короткая книжка, которая помогает быстро понять основы. А Lee и Ron раскрывают каждую тему подробнее.

Поэтому, конечно же, я считаю, что такие книжки тоже надо прочитать! Мне, кстати, Паттон так понравился, что я купила эту книжку себе в личную коллекцию. И нисколько не жалею!

Хотя немного забавно было, в конце книги была примерно такая фраза "для новичка... А вы, конечно же, новичок, раз читаете эту книжку". Хе-хе, интересный вывод. Я уже далеко не новичок и особо новое в книжке не нашла, но мне все равно было интересно. Было бы здорово, конечно, прочитать ее на заре моей карьеры!

Но даже если вы не новичок, книга помогает:

1. Структурировать информацию.
2. Посмотреть на уже привычные вещи по-новому.

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

Так что, новичок вы или "старичок", книжка очень полезная, интересная и грамотная. К прочтению крайне рекомендуется

Добавила книгу в общий список прочитанных мною книг.

Совет фрилансеру - разделяй рабочее место и место отдыха!

На прошедшей SQA Days 14 выступала с докладом Ирина Винокурова, она фрилансер. О чем, собственно говоря, и рассказывала. О сложностях такой работы, о ее преимуществах и тд и тп.
Особенно мне запомнилась фраза "разделяйте рабочее пространство и личное".

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

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

Но обычно в выходные дни много других дел. Которые из серии "если ты не найдешь время отдохнуть, то потом придется найти время поболеть". Поэтому очень редко выдаются дни, когда ты отдыхаешь дома, весь день. И перед этим днем думаешь "ну все! Столько всего завтра успею, чего не успеваю делать в будни вечером!!". Ага. Конечно. А потом садишься перед ноутбуком, который домашний и отдыхаешь, расслабляешься, смотришь киношки, уходишь поспать...

Нет, конечно, я не хочу сказать, что это плохое времяпрепровождение  Очень даже полезное! И нужное! Хотя бы иногда...

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

Тут очень кстати вспомнился Ирин доклад и я смогла сформулировать, почему я это делаю. Потому что в привычном кресле, за домашним ноутом я найду себе занятие, которое будет чем угодно, только не работой. А вот если пересяду, достану другой ноутбук, то как бы подам телу и мозгу сигнал "ага, я работаю, сосредоточься!".

Так что, ребятки, фриланс фрилансом, но будьте готовы к тому, что мечты о "лежа в постельке лениво потыкаю кнопочки" останутся мечтами. Потому что так работы особой не получится. А не будете работать - зачем вы такие ленивые нужны работодателю? Фрилансер должен уметь сказать себе "я работаю!" даже тогда, когда другие отдыхают. А это иногда дается очень нелегко

Летняя школа 2013 со слов Марии Шах

Участница летней школы 2013 Мария Шах делится своими впечатлениями (за фото отдельное спасибо Екатерине Михеевой):

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

Помимо хорошо спланированных и организованных занятий  с Наташей и Алексеем (с 10.00 до 13.00 и с 19.00 до 21.00) оставалось время понежиться на пляже, а также посетить выставки и экскурсии. Сами занятия дали хороший толчок мне, как начинающему тестировщику, в плане направлений развития. Очень полезно было пообщаться с тренерами и более опытными специалистами лично.

Отдельно хочу отметить место проведения конференции (пансионат Крымское чудо, посёлок Береговое под Феодосией): радушные хозяева, вкусные обеды (особенно фирменный плов от хозяев), приятная атмосфера и море цветов.

SQA Days. Второй день!

Вот и закончилась конференция... А теперь собираем мысли в кучку и вспоминаем, что же было вчера...

1. Руфина Сарварова. CI: Автоматизация сборки, развёртывания и тестирования

Честно говоря, на доклад я опоздала, пришла только в середине. В первый день конференции доклады начинались в 10:15, я к этому времени и подошла. А во второй то день доклады были с 10 утра! Я про это вспомнила слишком поздно 

Я не Максим Цепков, чтобы быстро въехать в контекст, заглянув ненадолго. Поэтому сильно много о докладе не скажу. С задних рядов было не очень хорошо видно, что же там, на слайдах. И рассказ давался тяжело без вводной. Но в принципе интересно, Руфина рассказывала , что как у них происходит "а вот потом этот скрипт сам деплоится туда, разворачивает вот то и делает вот так".

Это success-story, из которой можно почерпнуть новые идеи "а как это сделать у нас". Радует, что есть и такие доклады, не все же делать для новичков, на что остальные ругаются "кэп, кэп" 

После доклада Руфины я переползла в секцию С.

SQA Days. Первый день!

А вот и первый день основной (русскоязычной) конференции подошел к концу. Давайте сразу подведем итоги!  

1. Алексей Лупан, Олег Колька Excel всё подскажет или "Вот сколько времени понадобится на тестирование" (мастер-класс)

Интересная тема... Не совсем актуальная для меня, так как такой инструмент в данный момент не сильно нужен. Но в целом интересно. Вдруг тебя закинут на новый проект, без документации - "На, тестируй!". Сколько времени надо? Обычно люди теряются и не могут даже грубую оценку назвать.

SQA Days 14. English Day

Всем приветики из славного города Львова!!

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

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

Вообще разница в 2 часа довольно прикольно смотрится. Улетела из Москвы в 11 утра, прилетела во Львов в 11 утра, плохо разве?) В аэропорту встретилась с Владиславом Орликовым, организатором конференции. Он меня любезно подкинул до отеля, где я распаковалась. Номер, кстати, очень уютный!

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

К (кассир) - Вы знаете, чтобы я могла обменять вам рубли на гривны, я должна зарегистрировать вас в банке, а это долгая процедура. Вам лучше попросить кого-то с украинским паспортом вам помочь.
Я - о_О

Оборачиваюсь к очереди сзади меня и говорю женщине:
- Простите, а у вас есть украинский паспорт?
- Ну да.
- А можно мне наличку (машу рукой в сторону кассира, которая держит в руках мои деньги) поменять по нему?
- Хорошо (Пожав плечами, женщина отдала кассиру свой паспорт).

Ого! Я бы в Москве подумала, что меня одурачить хотят... Непонятно, как, но явно хотят! А тут эвона как...

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

Погуляла, погуляла, да и поехала назад. Ну, думаю, пока хватит. Сейчас прилягу подремать, потом еще раз поем волшебной вкусной пищи и снова спать. Ага. Легла в 5, проснулась в полночь... Вот так вот тебе вставать в 5 утра, ложась в час ночи, еще и 2 дня подряд. Ну и ладно, с чистой совестью уснула дальше.

А утром, утром меня ждала конференция! Конференция принимает новый формат, в этот раз у нее появился отдельно выделенный English Day с приглашенными спикерами из разных стран.

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

Поэтому расскажу о том, что запомнилось и что я смогла "перевести" себе мысленно:

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

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

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

В этом докладе он говорил о базовых вещах, о которых, тем не менее, стоит всегда помнить!

Некоторые мысли звучали провокационно:

TDD - is not for testers. It is for developers.
ATDD is for testers - Acceptance Test Driven Development.

В общем-то, не так важно, как что называть, казалось бы..

Еще Виктор говорил о том, какие должны быть требования:

• Independent.
• Negotiable.
• Valuable.
• Estimated (тут мы должны держать в голове, что Software is investition).
• Small (иначе никто не станет их читать).
• Testable.

Ну а потом Виктор стал отвечать на вопрос "КАК?". Как писать такие тесты? Были примеры выдержками из кода, было описание, как лучше расставлять value, goal, action. А то иногда их пишут в таком порядке, что неочевидно, зачем это все вообще надо!

В общем, куча всего полезного было. Запись вполне можно посмотреть, рекомендую 

2. Željko Filipin How software that runs Wikipedia is tested 

Как интересно отметили в твиттере, доклад в конечном итоге свелся к тому, что нужна помощь, нужны люди. Логично!

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

• Communication.
• Maintability (не так очевидно, как сделать хорошо). Solve the problem - Page Object Pattern.
• Combinator explosion (operation system / browser / version). Solve the problem - Source Lab.
• Visibility / transparency (code: git, gerrit, github)
• Code reuse.
• Speed.

3. René Tuinhout The tester's dilemmas (Workshop)

Сама не было, но народ очень хвалил, и в твиттере, и в реальности!

4. Wiktor Żołnowski  Reversed Test Pyramid - Testing and dealing with Legacy Code

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

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

Еще что-то интересное выхватила мельком из доклада, но не было ручки под рукой :(((

5. Jim Holmes Four Crucial Tips for Automated Web 2.0 Testing (Workshop)

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

Но зато применимы сам ИДЕИ! Которые тут можно послушать...

Ну а дальше - код, код, код. Какие локаторы можно использовать? ID, CSS, XPath. И вот смотрите, я прогоняю тест и у меня все хорошо. Тест зелененький, а зелененький - это хорошо! Вообще Джим тоже отличный спикер, шутил удачно, не волновался, речь очень интересная сама по себе. Кстати, он и последний доклад делал, тоже очень интересно и живенько, но там я не успела ухватить основную идею...

Да, так вот, зелененький тест - хорошо. НО бах, что-то поменяли и тестик покраснел. А red - is sad. Так что давайте посмотрим, что делать. Ага! Если использовать ID, то нам будет все равно на изменение формы!

Ну или еще можно использовать "правильный" XPath. Неправильный лучше не юзать, а правильный - почему бы и нет? Правильный, это когда мы ищем уникальную привязку. Но не "4 элемент сверху", а то, что находится рядом. Например, некий label, почему нет?

Ну и так далее, Джим рассказывал и показывал на примерах разные фишечки автоматизации. Интересный доклад!

Вот такой вот получился English Day. Я считаю, вполне продуктивный! И интересный и познавательный! Жаль, я не успела попасть на Who killed My Prod? Заболтались в кулуарах, а там Оливер переодевался на публике, специально туфли покупал под свой спич, эх! Я думаю, это было бы прикольно посмотреть!

Если говорить об организации - то все вообще на высоте! О скидках в отеле организаторы договорились, бесплатные автобусы из центра запустили, на кофебрейках постоянно было куча сладкого + чай / кофе! С презентациями тоже помогали, как могли. Свет, опять же, регулировали, чтобы пересвета на слайдах не было!

А еще на раздаточных листочках с расписанием написали номера страниц в блокноте - это оооочень удобно! Хоть не надо все листать и искать! Супер-фишка, спасибо за нее! Жаль только, что не получилось настроить все телевизоры на синхронную трансляцию слайдов, но, с другой стороны, и так проектор большой и все видно!

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

Ну а потом, а потооооом была шикарная мини-афтерпати. Мы приехали в кафешку, в которой уже все было готово к нашему приходу и стали отмечать нашу встречу! Тут уж я фото не дам, пусть Максим делится 

Но тоже интересный опыт, так как прямо напротив меня сидел тот самый Оливер, на доклад которого про злостное убийство прода я не попала. И мы старались общаться на англ языке. Иногда трещали между собой, смеялись, а потом переводили. Но опыт интересный, да!

А еще зарубежные гости сильно удивились традиции "корми на убой", все уже поели, салатики так, сало с хлебом, фаршированный карп, блинчики с курочкой... А тут БАХ - и приносят варники. Ну ладно, поели. А потом БАХ - и приносят основное блюдо. Тут уже гости сделали вот так о_О. А чо, раньше не основное было? Не переживайте, дорогие гости, впереди еще десерт! 

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

И следующие 2 дня обещают быть не менее интересными, я уже присмотрела себе несколько докладов, на которые очень хочется сходить, надеюсь, они оправдают мои ожидания!

Folks. Исходный код и инструкция по установке

Эта статья актуальна для версии folks 1.0. Актуальная версия лежит в bitbucket, все инструкции — в конфлюенсе

Коллеги, всем привет!

9 ноября в 12.45 я выступаю на конференции SQA Days 14 с докладом Автотесты на уровне API для Java-приложений.

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

Приложение называется Folks - оно содержит в себе информацию о людях, которые приехали на конференцию, позволяя по этой самой информации искать, сортировать и фильтровать данные.

Исходный код приложения можно скачать по этой ссылке.
Source code - download.

Далее описаны:

• Установка приложения.
• Запуск теста на поиск.

Установка приложения

Установка очень простая - скачали архив, распаковали.
Подключили библиотечки, которые лежат в папке lib, как внешние библиотеки - все, можно запускать!

Но я, пожалуй, распишу подробнее для любимой среды разработки:

1. Скачиваем и устанавливаем среду разработки IntelliJ IDEA (есть бесплатная версия)
2. Скачиваем и устанавливаем последнюю версию jdk. Обращаю внимание - нам нужно именно JDK, не JRE!
3. Запускаем IDEA.

4. File - Open. Открываем pom.xml из распакованного проекта folks.
5. File - Project Structure. Можно, кстати, открыть по горячим клавишам или по быстрой кнопке на панели

6. Настраиваем Java.

Закладка Project в структуре - нажимаем new и указываем путь к скачанному и установленному jdk, получится примерно так - C:\Program Files\Java\jdk1.7.0_40

7. Настраиваем внешние библиотеки.

Закладка Modules в структуре - вначале удаляем оттуда все лишнее, оставляя только java (когда открываем как maven-проект, там может оказаться куча всяких зависимостей, которые нам не нужны). Подчистив все, нажимаем на "+" - кнопку добавления библиотек.

В выпадающем меню нажимаем "Jars or directories".

А дальше выбираем все, что лежит в folks/lib.

Получаем такой вид

Не переживайте, что тут отображается только одна библиотечка, хотя подключили мы много. Это или глюк идеи, или где-то настраивается... В общем, не суть, на самом деле все подхватилось!

Жмем Apply - Ok и теперь наш код больше не светится красным, он готов к запуску!

Запуск теста на поиск.

Открываем java-класс -  C:\folks\src\test\java\ru\olgak\folks\service\SearchCase.java

Встаем на название класса, нажимаем правой кнопкой мыши и запускаем - Run 'SearchCase'

Наслаждаемся результатом 

А после конференции я более подробно распишу, как писать сам java-код. Терпение! И все будет