Fun ConfetQA. День третий и последний!

Да да, вот он и прошел - последний день конференции! И пусть сама конференция - конфетка, но сегодня у меня блог охраняет сова.

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

А дело все в том, что... Аааа, да ладно, будем по порядку.

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

Потом выступал Александ Булкин. Он рассказал нам о тестировании SMART-TV. А ведь 5 лет назад казалось, что такого не бывает) Айфоны, айпады, SMART-TV... Как быстро летит прогресс. Уже и тестировать это все надо! Возможно, и вам завтра надо будет. А прикиньте, как это? Пришел такой с тестирования программ - и на тебе,тестируй телик! А что, как, за что хвататься? Не знаете? Воооот... А Александр знает - и готов с вами поделиться. Просто послушайте этот доклад)

И вот уже потом... Выступала Ирина Винокурова! Любительница сов :) Но ей можно - она же именинница! О чем хитро сказала только в самом-самом конце :) Но то знали! Мы все знали и поздравили ее еще в полночь!

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

Я сейчас не работаю со студией (потому что я работаю с java-кодом...), но студию люблю и всегда любила) Так что познавательный доклад. Ну а если ваши разработчики пишут в студии и юзают ТФС - то флаг вам в руки! Ира рассказала, как можно применять уже купленную для разработчиков программу в своих коварных тестерских целях! Дерзайте!

Ну и наконец, закрывала концеренцию ее главная звезда - Татьяна Зинченко! Таня рассказывала нам об интеллект-картах, как их рисовать и что они умеют. Чувствуется опыт тренерства, виден профессиональный подход! Очень жаль, что я болею и плохо соображаю, не смогла назадавать все вопросы, к которым готовилась, едва узнав, что на конфетке будет такая интересная тема  Но ничего! Я оклемаюсь и приду на форум! Ха-ха-ха!

Там и увидимся, чао, ребят!

Test Automation Days - февраль, Киев!

Портал по автоматизации automated-testing.info во главе с главным вдохновителем Поляруш Михаилом проводит первую на просторах СНГ выделенную конференцию исключительно по автоматизации Test Automation Days.

Test Automation Days - это  знаменательное событие в мире автоматизации и соберет лучших автоматизаторов-практиков, которые с радостью поделятся своим опытом со всеми желающими.

На данный момент организаторы конференции активно работают над программой конференции, чтобы она была максимально  интересной и познавательной для всех автоматизаторов, вне зависимости от опыта. Сейчас, за 3 месяца до конференции, уже более 14 докладчиков. И это еще далеко не предел, автоматизаторы из Украины, России и Беларуси в скором времени присоединятся к команде докладчиков. Это будет грандизный технический бум! Только технические и полезные доклады и советы, проверенные практикой и опытом.

Вас ждет множество докладов на разнообразные темы (и это не окончательный список):

• Философия и построение тестового фреймворка на основе BDD в PHP проектах,  Зозуленко Алексей
• Автоматизация тестирования как сервис, Павел Сташевский
• Тестирование производительности и функциональности бэкэнда клиент-серверных приложений, Владимир Примаков
• Основные ошибки внедрения ATDD, BDD, CI, CD на проектах, Резчиков Алексей
• Быстрое расширение Robot Framework под свои нужды, Михаил Поляруш
• Новый подход к автоматизации регрессионного тестирования с использованием BDD на основе WebDriver, Бордюг Иван
• Тестирование производительности веб приложений в Visual Studio, Юлия Соловьева
• Автоматическое генерирование тестов в SoapUI, Михаил Дырда
• 3 инструмента: 3 истории нагрузки, Ирина Горшенина
• Test Environement on Demand (in Cloud), Дмитрий Махно
• Перешагнуть через ADB Shell, Сергей Высоцкий
• Проблемы автоматизации крупных проектов: TestComplete, Дмитрий Марков
• За пределами PageObject, Дмитрий Жарий
• Keyword-driven testing, Геннадий Алпаев

Мы уверены, что независимо от того, являетесь ли Вы опытным автоматизатором, недавно начали работать в этой сфере или только собираетесь стать на путь автоматизации, Вам будет интересно!

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

Однако не зря событие называется Test Automation Days, помимо конференции будет проведена серия тренингов и мастер-классов по автоматизации, что позволит Вам получить не только теоретический опыт, но и много практики.

Тренинги:

• Основы автоматизации тестирования ПО
• Автоматизация веб-приложений с Selenium WebDriver на Java
• Автоматизация веб-приложений с Selenium WebDriver на Python
• Управление автоматизацией тестирования ПО
• Автоматизация тестирования ПО  с TestComplete
• Нагрузочное тестирование с JMeter

Мастер-классы:

• Automated Testing DoJo
• Selenium WebDriver
• Нагрузочное тестирование c JMeter
• Практикуемся программировать на Python
• Практикуемся программировать на Java

Не пропустите свой  шанс поучаствовать в столь грандиозном событии в мире автоматизации! Регистрируйтесь прямо сейчас.

Следите за новостями http://atdays.com/ и twitter @at_days или по хэш тегу #atdays

До встречи на конференции!

Fun ConfetQA. День второй!

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

То идея у коллег появится. То Заказчик что-то спросит во время доклада. Не скажешь же ему "Извините, абонент не абонент, он слушает #confetqa"

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

Fun на то и fun, чтобы разрывать шаблоны! Вот уже второй день Таня играет с нами в игру "перетасуй расписание". Я уверена, что завтра Ира будет выступать первой (Ира, готовься!).

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

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

Вторым выступал Алексей Баранцев с рассказем про pairwise. Алексей, как всегда - отличная, четкая речь, симпатичные слайдики и все по делу, по делу... Не знаете про pairwise? Не знаете, зачем он нужен? Бегом смотреть доклад!

Я, правда, это уже знаю и слышала. Зато было забавно читать твиттер, как у людей сносило шаблоны "Аааааа, PICT и это умеет, ВААААУУУУ!!!!"

Да, PICT такой! Он вам еще и не то покажет))))

Последним выступал Андрей Кузьмичев с рассказом про Selenium IDE. В результате его доклада вспызнули споры, это был доклад для ручного тестировщика или все-таки для автоматизатора? Ребята уверяли. что автоматизация рутины все равно автоматизация. Мне тут понравился ответ Тани Зинченко - "ну да, а PICT это тоже автоматизация".

Люди часто забывают, что все, что им помогает, является автоматизацией рутины. Даже JIRA (или какой багтрекер используете вы)! Это тоже автоматизация... Поэтому доклад о возможностях IDE без кодинга вполне уместен и на конференции ручных тестировщиков. Хотя мы то с вами знаем, что Андрей так народ переманивает, чтобы ручные увидели - захотели - попробовали... А потом пришли на конференцию автоматизаторов!

Правильно, Андрей! Так держать!

Ну а мы пока расходимся в ожидании последнего денечка... Что же Таня нам приготовила там?

Fun ConfetQA. День первый!

Привет привет! В эфире радио "Маяк тестировщика". Сегодняшний курс - онлайн конференция #confetqa. Это которая Fun. Это значит "смешно" - весело о главном!

А что же главное?

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

А иначе как руководить подчиненными? Не зная основ? Как писать автотесты, не умея написать простой?

В общем, очень полезная конференция! Которая находит отклик во всех сердцах - как начинающих, так и продвинутых.

Что же у нас сегодня в эфире? Точнее, кто? Открывать конференцию должен был Сергей Атрощенков, однако у него  возникли проблемы с микрофоном (ну конференция тестировщиков же, о чем речь!).

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

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

После ее доклада я взбодрилась и теперь уже с интересом слушала, а что же скажут дальше. А дальше Андрей Ладутько рассказывал о gamification в тестировании. Вы никогда не пробовали превратить работы в праздник? И как, получалось? Поделитесь опытом с Андреем, а он расскажет вам о своем. Нам вот уже рассказал, где и как можно попробовать сделать игру вместо нудной работы.

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

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

Карл Вигерс. Разработка требований к программному обеспечению

Ссылка на OZON.

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

Я задумалась над этими словами и поняла - очень емкое высказывание  Действительно, в книге раскрыто очень и очень много тем. Поэтому для начинающего аналитика она вообще mast-have, а для продвинутого - есть что почерпнуть.

Я выписывала оттуда интересные мысли и цитаты, все ссылки:

• Приоритеты проекта
• Компромиссы для атрибутов качества
• Работать рядом или удаленно - есть ли разница?
• Что такое прототип и для чего он нужен?
• Изменение не бесплатно - анализ влияния.
• Автоматизация - наше все?

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

Говоря это, я вспоминаю, как готовилась поступать в МГТУ им. Баумана. Физика шла у меня не очень хорошо, поэтому я занималась с репетиторами из института. Первый репетитор говорил хорошо, объяснял доступно... Поэтому, сидя рядом с ним, я все занятие кивала, "конечно, понятно". А потом приходила домой и не могла решить сама ни одной (!) задачи. И куда девалось "все просто и понятно"?

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

Так что могу на собственном опыте гордо сказать - все. что звучит легко, просто, понятно и красиво, перестает таким быть до первого столкновения на практике. Поэтому просто прочитать книгу / посетить тренинг - мало. Надо что-то сделать. Самому. Иначе - никак.

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

А еще в конце книги есть приложения. Некоторые показывают на примере кратенько все то, что проходилось в предыдущих главах. Но меня особенно заинтересовало приложение А. "Самостоятельная оценка применяемых вами приемов работы с требованиями". Это такой тест, который, во-первых, показывает ваше текущее положение дел (правда, там не даны ответы, как оценивать, но долго ли умеючи? Поделить общее число баллов, которых 100, на 4 - и вот вам 4 категории, плохо, неплохо, хорошо, отлично)

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

Вот например, как вы считаете, какой ответ лучше:

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

Меня до сих пор терзает подозрение, что это какой-то прикол... Он, видимо, из серии "автоматизация - наше все". Если есть инструмент, то все, что перечислено в 3-ем пункте, уже не нужно? о_О

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

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

Резюмируя - книга рекомендуется всем. кто собирается писать требования. И даже тем, кто собирается их тестировать. "Врага надо знать в лицо"

Шучу, требования нам не враг, а очень даже друг, что не раз обосновывается в этой книге, хотя я и предвижу холивары на тему "а нам и без них хорошо, у нас Заказчик такой". Бывает, да. Но, согласитесь, находить баги на этапе требований приятнее, так как исправляются они быстрее и дешевле!

Автоматизация - наше все?

И еще одна интересная цитата из книги Карла Вигерса. Все статьи по книге:
[1] [2] [3] [4] [5] [6]

Сама цитата:

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

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

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

Но ведь абсолютно применимо! Дай тот же Test Complete или Selenium в руки человека, которому эта автоматизация нафиг не нужна - и каких результатов он достигнет? Ну максимум попробует обосновать, почему конкретно здесь, в этом команде и этом проекте автоматизация не работает. Ну вот потому что.

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

И ведь будет - потому что коллега найдет таки ответ на поставленную перед ним задачу. И даже если начиналось все с горящих глаз "сделаем 100% автоматизацию и не будем регрессию вообще проводить", то результат все равно будет. "Теперь у нас 80% автоматизировано и мы можем вместо унылой регрессии проводить exploratory, находить новые ошибки и увеличивать покрытие тестами более сложных участков!".

Согласитесь, более реалистичный результат

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

Помните про кривую обучения. И помните про то, что никакая автоматизация не спасет от потухшего взора!

Изменение не бесплатно - анализ влияния

И еще одна интересная цитата из книги Карла Вигерса. Все статьи по книге:
[1] [2] [3] [4] [5]

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

Списки могут помочь не только аналитику, но и тестировщику. Для ответа на вопрос "а все ли я учел, а все ли я проверил?"

Список возможных последствий предложенного изменения.

1. Конфликтуют ли какие-то из требований в базовой версии с предложенным изменением?
2. Конфликтуют ли какие-то из отложенных требований в базовой версии с предложенным изменением?
3. Какие могут быть технические или бизнес-последствия, если изменение не будет внесено?
4. Какие могут быть побочные негативные эффекты или другие риски, если изменение не будет внесено?
5. Повлияет ли негативно предложенное изменение на требования к производительности и другие атрибуты качества?
6. Выполнимо ли предложенное изменение в рамках известных технических ограничений и квалификации специалистов?
7. Не потребуется ли для реализации предложенного изменения неприемлимое количество компьютерных ресурсов, необходимых для разработки, тестирования или операционной среды?
8. Нужно ли приобрести какие-либо средства для реализации и тестирования этого изменения?
9. Как предложенное изменение повлияет на последовательность, зависимости, усилия или продолжительность задач, включенных в настоящее время в план проекта?
10. Потребуется ли создание прототипов или другая информация пользователей для проверки предложенного изменения?
11. Сколько затрат, уже вложенных в проект, будут потеряны, если принять эти изменения?
12. Не увеличится ли затрата на единицу продукта при принятии изменения, например, за счет увеличения оплаты лицензирования продукта приглашенными специалистами?
13. Повлияет ли изменение на планы по маркетингу, производству, обучению или поддержки покупателей?

Список возможных элементов ПО, затрагиваемых изменением.

1. Определите все необходимые изменения пользовательского интерфейса, дополнения или удаления.
2. Определите все изменения, дополнения или удаления, которые необходимо внести в отчеты, базы данных или файлы.
3. Определите компоненты дизайна, которые придется создать, изменить или удалить.
4. Определите файлы исходного кода, которые необходимо создать, изменить или удалить.
5. Определите все изменения, которые привется внести в уже созданные файлы или процедуры.
6. Определите существующие варианты тестирования элементов продукта, целостности, системы и приемлимости, которые необходимо изменить или удалить.
7. Определите необходимое количество новых вариантов тестирования элементов продукта, целостности, системы и приемлимости.
8. Определите все экраны справки, обучающие материалы или другую пользовательскую документацию, которую необходимо создать или изменить.
9. Определите все компоненты приложений, библиотек или оборудования, на которые повлияет изменение.
10. Определите все стороннее ПО, которое должно быть приобретено или лицензировано.
11. Определите влияние, которое предложенное изменение окажет на планы управления проектом ПО, проверки приемлимости качества, управления конфигурацией и другие планы.

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

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

Нужно ли тестировать кнопку "Отмена"?

Когда-то, давным давно... Тестировала я маленький проектик А. У меня было всего лишь 1-2 разработчика, поэтому я зачастую скучала. И в итоге ушла помогать тестировать проект Б, самый большой в нашей компании. Но оставаясь единственным тестировщиком А.

До того, как таки отпустить меня на проект Б (ох уж мне эта ревность ), начальник сначала решил придумать мне задач. В частности, расписать тест-кейсы в TestComplete. Все тест-кейсы. Вообще. От слова "совсем". Я начала писать, ему не понравилось. Не подробно. Тогда то он и дал мне ссылку на статью Топ 13 ошибок тестировщика. За что ему огромное спасибо, вот ведь, до сих пор помню...

Так вот, прочитала я статью, где-то устыдилась, где-то вдохновилась... Да и делать все равно было нечего, пока разработчики на тестовую не выложатся... Расписала я тесты, прям загляденье!

Например, делаем мы действие и у нас стандартное такое окошко "А вы уверены, что этого хотите?". Даже на такое окошко я расписывала тесты подробно:

• Подтвердить действие, нажав на кнопку "Ок".
• Отклонить действие, нажав на кнопку "Отмена".
• Отменить действие, нажав на крестик в правом верхнем углу.

Очень подробненько все. А в итоге ради кого я описание заполняла? Самой мне было достаточно прочитать названия тест-кейсов, чтобы понять, что надо проверить. А нового тестировщика так и не появилось на проекте до его закрытия.

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

Например, у нас есть поле с индексом, обрабатывает только 6 цифр. И понеслась:

• Позитивный - 6 цифр, сохраняем;
• Негативный - 5 цифр, сохраняем;
• Негативный - 7 цифр, сохраняем;
• Негативный - пустая строка, сохраняем;
• Негативный - символы, сохраняем;
• Негативный - ...

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

Общалась вчера с Ириной Винокуровой, одной активной тестировщицей, которая уже начинает покорять просторы интернета своим блогом и выступлениями

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

А теперь представьте, что это нашел пользователь... Вообще, вспоминая проекты SharePoint, я уже видела что-то подобное. И не только с кнопкой "Отмена". Можно, например, сидеть, сидеть на страничке, а потом бац - и "назад" в браузере надать. А тебе БАЦ - и 400 Bad Request о_О

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

Не забывайте о "мелочах", иногда и они нас удивляют...