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

Недавно выступала на 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, из которой можно почерпнуть новые идеи "а как это сделать у нас". Радует, что есть и такие доклады, не все же делать для новичков, на что остальные ругаются "кэп, кэп" 

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