• Главная
  • О сайте
  • Архив

Normal testing

From the programmer's worst friend

Feeds:
Записи
Комментарии
« Эй, протри глаза! Нет идеального тестирования!
Надо заниматься фигней! »

Певца попросят спеть

15.10.2010 Автор: Алексей Лупан

На рулезнейшем форуме суперспециалистов по тестированию спрашивают следующее:

Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше issues на бета-версии сайта. В ответ от меня ожидается issue document. Погуглив, я обнаружил несколько template’ов issue document, однако мне не совсем понятно, что с ними делать (а точнее, практически, совсем не понятно)  🙂

Пожалуйста, подскажите, как лучше составить этот самый issue document(я имею в виду в основном оформление, есть ли какие-то стандарты?), чтобы произвести хорошее впечатление на HR отдел компании. Да, чуть не забыл. На все про все у меня всего пару дней. Очень прошу, не медлите с ответами.

Ну, прям, не медлить…

Тут есть о чем помедлитировать.

Налейте мне еще коньяку «Chisinau», бо я сегодня разочаровался в Johnny Walker Red Label, и мне нужна реабилитация.

Если нет «Chisinau» — достаньте его где угодно, не грузите меня подобными мелочами.

Проблема только в том, что меня не спрашивали.

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

Уважаемый сэр молодой тестировщик,

ежели вы так хотите произвести впечатление на HR (она после этого потребует взять ее замуж, вы к этому готовы?), тогда вам следует знать, что слово «Issue» на языке Вильяма сукина сына Шекспира означает «вопрос, который надо обсудить«. Односложно на русский язык это слово перевести сложно, поэтому большинство произносит его как «ишшу».

Например, в рулезнейшем баг-трекере Mantis каждая запись называется issue. Баг там записан, или задача, или вопрос — это все issues.

Они вам предложили просто, весело, задорно и бесплатно протестировать их приложение, и предоставить им максимально большой список багов.

Если вы действительно хотите очаровать HR-отдел, то не ищите шаблоны issues. Вам нужен шаблон написания багов.

Шаблон такой:

1. Сделать это.

2. Сделать то.

3. Сделать то-то.

[…] сделать то-то и это-то.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ

Такой-то.

ПРОБЛЕМА

Происходит то-то и сё-то.

Скриншот прилагается.

Запомните как гамму до минор на контрабасе: баг без скриншота — что фильм «Кавказская пленница» без спортсменки, комсомолки, и как ее там звали (уже забыл).

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

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

Не программист, а менеджер? Суть не меняется. Не златокудрая же шатенка по имени HR-отдел будет ваши баги читать?!

Если вы нашли баг в предыдущей фразе — позвоните нам по телефону 555 28 16 88, спросите Джонни из ФБР.

Количество шагов для воспроизведения в описании бага зависит от того, насколько вы уперты и талантливы. Чем меньше, тем лучше, кагбэ…

В принципе надо понимать, что описание бага будет кто-то читать, и по указанным вами шагам будет пытаться воспроизвести описанную вами проблему. Если описание правильное — вам зачтется в другой жизни. Если описание неправильное, запутанное, сложное и неоднозначное, то — «ваши рыжие кудри примелькаются», к вам придут домой, и вас будут бить, Шура. Ибо описывать баги надо просто и однозначно, а не «как все».

2)

С другой стороны, подобное «домашнее задание» вызывает у меня крайнее подозрение. Вот такой я крайне подозрительный.

Понимаете, мне кажется, что «домашнее задание» должно показать, как вы ВООБЩЕ умеете думать в области «поиска багов», а не требовать список багов.

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

* Да, я знаю, что в русском языке нет слова «ихней».

Зато есть химический элемент «ихний» — его скоро должны открыть, это принесет в казну много элементов типа argentum.

Зато все ваши баги будут с вниманием рассматривать и радоваццо, что нашелся божий человек, калик перехожий, коий нам столько багов накатал, дай ему, Ивану-дураку-царевичу, бог здоровья, гей он еси молодец…

А если и скажут, что подходите, то работа у вас будет такая же унылая, как подъезд дома номер 5 по улице Кантемир в городе Костюжены, ибо оценивать ваши качества будут по количеству находимых вами багов. Это я вам, почему-то, гарантирую.

А почему?

А потому, что работа тестировщика (прошу стать прямо и включить мозг) не заключается в поиске багов.

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

Просто В ОБЩЕМ самым заметным результатом работы тестировщика является сборник багов, поэтому нормально, если окружающие  так считают.

Пусть считают, делов-то.

Хуже, когда дело доходит до «Я тут нашел баг, а ведь это твоя работа, баги находить…«

Если в компании считают, что количество багов — показатель крутости тестировщика, то компания, скорее всего, небольшая, только-только начинает развиваться, и расти там (вы же мечтаете о карьерном росте до программиста, не так ли? Не врите, поначалу все об этом мечтают, это нормальное животное человеческое желание) вам не придется ни ввысь, ни вширь, ни вглубь.

И в мире станет на одного ненавистника профессии тестирования больше. А я в таком мире жить не хочу.

Конечно, певца при приеме на работу попросят спеть, кулинара — приготовить, путану — мгм, дизайнера — нарисовать, программиста — написать код. Если всё это правильно, тогда и тестировщика надо попросить при приеме на работу найти баги 🙂 Логика просто нерушимая, как СССР, который, как вы помните, разрушился ко всем чертям.

Но все это должно быть сделано как пример, а не как «у нас тут есть вот работа, сделай её, и мы решим, брать ли тебя, или нет, гыгыгы«.

Вам же предложили не решить пример, а сделать работу. «Найти как можно больше issues на бета-версии сайта» — я это воспринимаю именно так.

Если у вас есть возможность еще поискать работу — поискайте её ещё.

3)

Искренне рекомендую следующее:

  1. Все-таки протестировать предложенное приложение и постараться найти там как можно больше багов. Просто для самоуважения. Список этот можете себе на стену повесить — он ваша интеллектуальнейшея собственность.
  2. Забить на мечту о работе в той крутейшей компании.
  3. Продолжать искать работу.
  4. Найти работу, на которой работают правильные люди.

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

  1. Вот приложение. Вот в нем есть такая-то функциональность.
  2. Вот какие к этой функциональности предъявляются требования (вам кладут на стол список требований, или, может быть, краткое описание задач, которые выполняет этот функционал).
  3. Пожалуйста, расскажи, как ты это дело будешь тестировать. Какие есть идеи, на какие аспекты ты обратишь внимание в первую очередь, а на какие забьешь болт, с чего начнешь и когда намереваешься завершить тестирование, где и как будешь искать информацию о тестируемой теме, и где ты возьмешь болт, чтобы им забить, если надо будет забить, как уже говорилось…
  4. Не нервничай и не сучи ножками — тут все когда-то сидели точно так же, как и ты, и думали, думали, думали. Ты тоже думай.

Ну, а когда найдете себе работу с правильными людьми, вернитесь к той самой HR-отдел (цветы прихватите, а не только банку пива) и скажите ей все те комплименты, которые вы хотели сказать, но постеснялись.

Вдруг это ваша судьба?

Вот что я сказал бы, но проблема в том, что меня об этом не спрашивают.

Реклама

Ваша оценка:

Поделиться ссылкой:

  • Tweet
  • по электронной почте
  • Печать

Понравилось это:

Нравится Загрузка...

Похожее

Опубликовано в Печали, Постановка мозгов, Соображения | Отмечено Вопросы и ответы, Импрессионизм, Поначалу оно всегда так, Mantis | 32 комментария

комментария 32

  1. на 09.11.2010 в 15:56 Albert Gareev

    Вопросы на нестандартное мышление.

    Некоторые из них задавали мне, другие читал у людей в блогах. Все хотел запостить… наконец есть время перевести.

    НравитсяНравится


    • на 09.11.2010 в 15:57 Albert Gareev

      В корзинке лежало 6 яиц. 6 человек подошли, взяли по одному яйцу каждый, и ушли. Но в корзинке осталось одно яйцо. Как это возможно?

      НравитсяНравится


    • на 09.11.2010 в 16:07 Albert Gareev

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

      НравитсяНравится


    • на 09.11.2010 в 16:11 Albert Gareev

      Почему колодезные люки круглые?

      НравитсяНравится


    • на 09.11.2010 в 16:22 Albert Gareev

      Примем, что на Земле живет ровно 5 миллиардов человек. Считаем только для левой руки. Берем количество пальцев на руке первого человека, и перемножаем на количество пальцев на руке второго человека. Полученный результат перемножаем на количество пальцев на руке третьего человека, и т.д.
      Какое число будет для всего населения Земли?

      НравитсяНравится


    • на 09.11.2010 в 16:29 Albert Gareev

      5 кусочков угля, морковка и шарф лежат в траве недалеко от дома. Никто их там не оставлял, как же они там оказались?

      НравитсяНравится


    • на 09.11.2010 в 16:47 Albert Gareev

      На столе в беспорядке лежит 20 монет одинакового достоинства. Половина лежит орлом кверху.

      Задача. С завязанными глазами и в перчатках, разделить монеты на два набора по 10 в каждом. Количество «орлов» и количество «решек» в первом наборе должно совпадать с количеством «орлов» и количеством «решек» во втором наборе.

      Изначальное количество «орлов» и «решек» неизвестно.
      Доступные действия: передвинуть монету; перевернуть монету.
      На слух и на ощупь монеты воспринимаются абсолютно одинаково.

      НравитсяНравится


  2. на 21.10.2010 в 20:04 Albert Gareev

    К теме — скриншот как альтернатива ручки.

    «The Impossible Challenge» by Darren McMillan — http://bit.ly/bP9seH

    С одной формы накопали чуть ли не сотню дефектов

    НравитсяНравится


  3. на 20.10.2010 в 13:51 Сергей

    Я таки жил довольно долгое время в том известном поселке Костюжены 🙂

    НравитсяНравится


  4. на 19.10.2010 в 13:25 Timeon

    >Понимаете, мне кажется, что “домашнее задание” >должно показать, как вы ВООБЩЕ умеете думать в >области “поиска багов”, а не требовать список багов.

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

    2) Показывает умение описать проблему, не скатываюсь да у Вас здесь вообще не работает :).

    3) Примерно можно оценить уровень наблюдательность кандидата. Если люди принципиально не способные видеть проблемы.

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

    НравитсяНравится


    • на 19.10.2010 в 20:58 stansult

      +1

      4) Можно оценить, как кандидат умеет расставлять приоритеты. Оптимально он должен вначале дать самые серьёзные проблемы, и только в конце — опечатки и т.п.

      НравитсяНравится


  5. на 18.10.2010 в 06:14 stansult

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

    фигня, пардон май френч
    в основном тестеры нужны для поиска багов
    дело, конечно, не в количестве, а в качестве

    > > вы же мечтаете о карьерном росте до программиста, не так ли?

    то есть по-вашему тестер — это такой типа недо-программер, которому расти некуда — только в программеры?
    ерунда 🙂

    НравитсяНравится


    • на 18.10.2010 в 10:44 Алексей Лупан

      Нет, по-моему, тестер — отдельная боевая единица в составе команды разработки.

      НравитсяНравится


      • на 18.10.2010 в 20:29 stansult

        согласен
        но не думаю, что путь ему — только в программеры (хотя это тоже неплохо)

        НравитсяНравится


        • на 18.10.2010 в 22:03 Алексей Лупан

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

          Однако же, уже много лет работаю тестировщиком, и программированием занимаюсь в мелочах, но полностью становиться программистом уже давно расхотел. И проектами управлять тоже не свербит — я управляю тестированием, и этим доволен. «Меня прёт!» 🙂

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

          Тому причиной и оценка занятия сквозь призму социализации, и то, что зарплаты у программистов В ПРИНЦИПЕ на порядок больше, чем у тестировщиков.

          Но в тестировании есть всё — и фан, и деньги, и социальное положение. Я окончательно прозрел только тогда, когда впервые получил в роли достаточно обычного тестировщика зарплату матерого программиста.

          НравитсяНравится


          • на 19.10.2010 в 05:41 stansult

            сложная цепочка 🙂
            теперь понял

            НравитсяНравится


  6. на 16.10.2010 в 18:38 Albert Gareev

    «… вам кладут на стол список требований …»

    Молодому бойцу, может, и дадут. А опытному хитро скажут — «сам выкручивайся».

    Кстати, совсем необязательно делать привязку к тестированию программ.

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

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

    НравитсяНравится


    • на 16.10.2010 в 19:53 Antony

      а зачем, простите, проводить тестирование степлера или ручки? для того, чтобы показать свое нестандартное мышление, накопленный опыт, умение думать в стрессовых ситуациях? если пришел соискатель на вакансию тестировщика ПО, зачем ему давать тестировать всякую муть — кресло, кружку, пенал…

      НравитсяНравится


      • на 16.10.2010 в 20:18 Алексей Лупан

        Сорри за вмешательство.

        Это просто один из способов проверить ПРЕДРАСПОЛОЖЕННОСТЬ человека к тестированию. Не лучший по многим параметрам, но распространенный.

        Если хочется четки привязываться к ПО, то можно предложить сферические протестировать поля ввода логина и пароля, например…

        НравитсяНравится


        • на 16.10.2010 в 21:40 Albert Gareev

          @Antony

          а зачем, простите, проводить тестирование степлера или ручки?

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

          для того, чтобы показать свое нестандартное мышление,

          — Наоборот, стандартное тестерское мышление.

          накопленный опыт,

          — Да, опыт. Но не опыт тестирования ручек, а опыт тестирования вообще.

          умение думать в стрессовых ситуациях?

          — Ну если только само собеседование засчитывать за стрессовую ситуацию.

          если пришел соискатель на вакансию тестировщика ПО,

          — Дело в том, что с отношением «моя работа строго от сих до сих» человек вряд ли станет успешным в данной профессии. Зачем тогда вообще себя мучить? Есть и другие занятия в ИТ.

          зачем ему давать тестировать всякую муть – кресло, кружку, пенал…

          — Хотелось бы уточнить, это пенал — «муть», или тестирование пенала — «муть».
          Допустим, только пенал. А чем тогда репорт на 1000 строк не муть? Или третий раз за неделю regression? Ведь это могут быть повседневные обязанности, только на интервью за человеком наблюдают, оценивают, а в его работе надо быть уверенным безо всякого (или с минимальным) наблюдением.

          НравитсяНравится


          • на 16.10.2010 в 22:21 Antony

            @Albert

            Я думаю, демонстрация подхода при тестировании пенала или лифта имеет не очень много точек соприкосновения с тестированием конкретного ПО.

            Еще хотелось бы спросить, где Вы увидели в моем сообщении намек на отношение к работе «с 9 до 6»?
            Да, вникать в продукт человек обязан, его надо пропускать через себя, жить им. Каждодневный выход на работу должен быть хотя бы не в тягость, но и плясать от восторга не стоит.
            С другой стороны, неужели если проводить на работе по 14 часов в день и заниматься ею по ночам, то станешь успешным.

            НравитсяНравится


            • на 17.10.2010 в 00:55 retverd

              А почему не стоит радоваться своей работе, и надо удовлетворяться тем, что она не в тягость?

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

              НравитсяНравится


            • на 17.10.2010 в 12:42 Алексей Лупан

              Роман, не упускай из виду одну нехорошую сторону — в exUSSR корпоративной культуре хвалить и ценить считается излишним («Да, вы хорошо работаете, но так и должно было быть, вас же наняли для того, чтобы вы хорошо работали! Поэтому возвращайтесь в забой, зэка, и не гремите нам тут вашими костями»).

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

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

              Есть и другая грань — люди в семейном возрасте уже начинают ценить размеренность и нетребность прибегать на работу в любое-любое время, хотя в молодости это даже доставляло удовольствие.

              Есть и особенности характеров.

              Если у нашего коллеги отношение к работе на уровне «хотя бы чтоб не в тягость» — вряд ли он поймет твой задор про восемь утра. Мне так кажется.

              НравитсяНравится


            • на 17.10.2010 в 16:15 Antony

              Мне моя работа не в тягость, а очень нравится. Несмотря на то, что иногда приходится проводить regression пять раз за рабочую неделю 🙂
              «Не в тягость» — это не необходимое условие, а достаточное. Ведь никто не станет спорить, что выполнение рутинной работы утомляет. А иногда хочется искры и задора, которые приходится находить не на рабочем месте.
              Про радость приезда на работу к 8 утра. К сожалению, не могу ее разделить с Романом, всего лишь из-за того, что я сова (точнее филин) и по утрам всегда очень тяжело 🙂

              НравитсяНравится


        • на 16.10.2010 в 21:56 Albert Gareev

          @Алексей Лупан

          Да я бы даже сказал не предрасположенность, а степень просветленности.

          К слову, на junior или entry level позиции такое задание не давалось. Тогда мы искали под senior level и/или team lead.

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

          НравитсяНравится


    • на 16.10.2010 в 20:20 Алексей Лупан

      Ну и нормально.

      Основное времяпровождение тестировщика перед приступанием к тестированию основано на том, сможет ли он полностью выяснить требования, или нет 🙂

      НравитсяНравится


  7. на 15.10.2010 в 15:57 Денис Антошин

    Как всегда, с художественной искрой . Спасибо.

    НравитсяНравится


  8. на 15.10.2010 в 12:11 Soulkeeper

    Да-да. Тот самый Soulkeeper. Прочитал. Спасибо, навело на размышления. Действительно, в другой компании мне предложили тестовое задание, к которому возникло меньше вопросов: пару задач на сообразительность и описать, как я собираюсь тестировать одно всем известное приложение. Так что спасибо еще раз. Однако, как Вы понимаете, очень уж тянет цепляться за любую возможность… Думаю, у Вас в свое время, возможно, тоже был такой порыв. 🙂

    НравитсяНравится


    • на 15.10.2010 в 18:05 Алексей Лупан

      Разумеется, все через это проходят, и желание «взять да и сделать» намного важнее осторожничанья и затаенного «поиска подвоха».

      К осторожничанью, кстати, тоже все когда-то приходят 🙂

      НравитсяНравится


  9. на 15.10.2010 в 10:19 Alexey Bulat

    Душевно…

    НравитсяНравится


    • на 15.10.2010 в 18:03 Алексей Лупан

      Дык, «после литры выпитой» © сознание передает бразды правления подсознательному, а что там таится я и сам не знаю 🙂

      НравитсяНравится


  10. на 15.10.2010 в 07:26 noname

    Чётко, даже добавить нечего 🙂

    НравитсяНравится



Обсуждение закрыто.

  • Aut bene

    Официальный спiвпрацювальник по підготувальні тестувальників компании [Astound Commerce], Киев (QA Trainer).

    Написал свой [глоссарий] терминологии тестирования (english only).

    Неоднократный докладчик [SQA Days], [QA Fest] и других конференций по тестированию ПО.

    Неспешно езжу на «[Волга ГАЗ-21]» 1965 года выпуска.

    Играю что-то похожее на тяжелый блюз [на классической гитаре].

    И так [далее].

  • Присоединиться к ещё 1 372 подписчикам

  • Follow Normal testing on WordPress.com
  • Залежи

  • Темы

    • Без рубрики (7)
    • Документация (16)
      • Тест-план (2)
    • Изображения (133)
      • Видео (38)
      • Комиксы (19)
      • Скриншоты (42)
      • Фотографии (42)
    • Инструменты (65)
      • Debian (11)
      • Книги (16)
      • Макросы (1)
      • Трекеры (15)
        • Баг-трекер (8)
        • Тест-трекер (5)
      • LibreOffice (4)
    • Конференции (129)
      • Подкасты (8)
      • Презентации (50)
        • Слайдкасты (10)
      • Семинары (18)
    • Постановка мозгов (239)
      • Банальное (166)
        • Не смешно (47)
        • Неприятно (13)
        • Печали (15)
        • Радости (57)
        • Смешно (35)
      • В гостях у психиатра (42)
        • Поросенок v2.0 (3)
        • Странности (12)
        • Удивительные баги (17)
      • Level 80 (2)
    • Соображения (196)
      • Балабольник (9)
      • Гипотезы (11)
      • Озарения (51)
      • Откровения (88)
    • Статьи (22)
      • Интервью (5)
      • Опросы (1)
      • Переводы (11)
    • Управляторское (55)
      • Agile (13)
      • Программисты (23)
      • Рекрутинг (8)
    • Учеба в бою (75)
      • Тренировка (11)
      • Фишки (24)
      • Читерство (7)
    • Testing like… (76)
      • Acceptance testing (5)
      • Business Driven Testing (2)
      • Context-driven testing (2)
      • Defect-based Test Design Technique (1)
      • Автоматизация (36)
        • Performance Testing (5)
      • Рецессионное тестирование (1)
      • Юзероиммитатор (14)
      • Exploratory testing (9)
      • тест-дизайн (7)
      • State Transition testing (1)
      • Unit testing (1)
      • Usability testing (2)
    • To Do (10)
      • Анонсы (5)
  • Тэги

    Excel GlobalLogic James Bach Jira Mantis SQA Days SQA Days 7 SQA Days 8 SQA Days 10 Александр Александров Александр Орлов Алексей Баранцев Наталья Руколь Хватит тупить Юля Нечаева
  • Самое читаемое

    • Тестируем поля логин/пароль
    • План тестирования должен быть внятным, четким, небольшим
    • Группирование данных в Excel
    • Как в Excel отображать символ валюты перед цифрами
    • Основные положения тестирования
    • Priority & Severity на пальцах обезъянок
    • А как научиться тестировать?
    • Что такое перформанс-тестирование
    • Запуск Allpairs
    • Zephyr - new Test Management System
  • Комментарии

    • Необходимый минимум документации на проекте — Qsusha к записи Памятка о памятках
    • Lana к записи Как перестать быть джуниором?
    • Алексей Лупан к записи Как перестать быть джуниором?
    • Maksim к записи Как перестать быть джуниором?
    • Maksim к записи Как перестать быть джуниором?
    • Алексей Лупан к записи Памятка о памятках
    • Roman Podolyan к записи Памятка о памятках
  • Блоги о тестировании

    • 1) Блоги тестировщиков на software-testing.ru
    • Про тестинг
    • Selenium IDE — rulezzz!
  • Профессиональное

    • Удобный софт
    • Управление тестированием
    • IT Crowd wikiquotes
    • Testing History
  • Реклама

Создайте бесплатный сайт или блог на WordPress.com.

WPThemes.


loading Отмена
Сообщение не было отправлено — проверьте адреса электронной почты!
Проверка по электронной почте не удалась, попробуйте еще раз
К сожалению, ваш блог не может делиться ссылками на записи по электронной почте.
Политика конфиденциальности и использования файлов сookie: Этот сайт использует файлы cookie. Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.
Дополнительную информацию, в том числе об управлении файлами cookie, можно найти здесь: Политика использования файлов cookie
%d такие блоггеры, как: