Архив за месяц: Июнь 2016

30 Day Testing Challenge, Are You In?

The Ministry of Testing just launched a 30 Day challenge for testers. Starting on 1st July, you will need to do one goal per day to pass the Challenge. Some tasks seems tricky and funny, but it’s a challenge, isn’t? 🙂 Print this list, stick it near your desk and mark the passed goals. Have fun-ctional testing!

30-Day-Challenge_500px

Trainers: Gruyere

Gruyere (Грюйер, назван в честь одномённого сорта сыра) — веб-приложение для тренировки поиска уязвимостей, разработанное Google. Может работать как удалённо без установки (https://google-gruyere.appspot.com/start) — этот вариант весьма удобен, так и локально (все файлы сайта — https://google-gruyere.appspot.com/gruyere-code.zip). Само приложение написано на Python, но его знание не требуется если вы хотите просто потренироваться ломать этот сайт :), однако будет полезным если вы захотите (а вдруг?) исследовать исходный код и пофиксить баги.

Что можно потестить/повнедрять на этом сайте (ниже указаны ссылки на лекции-задания):

Нужно отметить, что сайт не использует SQL, т.е. SQL Injection потестить не получится.

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

Gruyere_Main_blog

Обзор сканера уязвимостей Skipfish

Авторы: Google (Michael Zalewski, Niels Heinen, Sebastian Roschke, etc.)
Лицензия: Apache 2.0 (бесплатно)sf_name
Страница проекта: code.google.com/p/skipfish/
Последняя версия: 2.10b (Dec 4, 2012) / входит в сборку Kali Linux, отдельно ставить не надо.
Аналоги: Nikto, Websecurify, Netsparker, w3af, Arachni

Согласно описанию разработчика, утилита предназначена для проведения разведки на предмет защищённости тестируемого веб-приложения. Она создаёт интерактивную карту сайта с помощью рекурсивного- и основанного на словарях анализе, после чего сканер применяет к полученным элементам различные проверки защищённости (обещают, что non-disruptive, но в любом случае тестирование лучше проводить не на продакшне). По окончанию работ формируется отчёт для анализа результатов человеком.
Читать далее

7 reasons why manual testing will never die

MS_Office_2010_bug_with_font_size

OK, let’s talk about the current fad of some teams thinking they could achieve 100% coverage by their automated tests and resting on their laurels after that. And why the automated testing cannot solve all your QA needs.

  1. Robots are testing your code, but your users aren’t robots. It means if you are developing software designed to use by human, you would want to make sure it’s looking good, working stable.
  2. Automated testing could take more time to run than the manual one. Sounds ridiculous, but it is if your interfaces are often changes or your project lifecycle is relative small, you may found that more time wasted on development or maintenance your automated testing code in comparison if we would done it manually.
  3. Exploratory testing cannot be simulated. Let’s face it — our users usually don’t like reading manuals or follow formal ways as we designed software to use. Users would intuitively explore software and learn how to use it in that manner. We cannot predict all the users workflows and document them, thus we have to manually do exploratory testing.
  4. False alarms and false positive. Automated tests should be well tested itself to make sure it works as we want to. And they need to be reviewed periodically, especially if you started getting too small or too much alarms.
  5. If you use it — you know it. Testers who are manually testing its software know it better (workflows, UI, workarounds, features, etc). Remember how many times your Dev’s asked you how works the application they are developing? It’s because they are looking on the code most of the time, whilst you are on the user interface.
  6. 100% coverage is a myth. We may define tons of requirements for our app and even try cover all of them, but there is always a risk we missed something or new requirements appears after the release. Whilst this applies to both manual and automated testing, we should bear in mind that first 30% of coverage would be easy to automate, second 30% is relatively hard and I suppose 10-40% requirements cannot be automated for various reasons.
  7. Automated testing frameworks cannot predict the bugs. Or consult you about the possible bottlenecks in architecture you are going to implement. Some bugs has common reason, but appears in different places. And some of them are hard to reproduce, but easy to explain. Human may provide deep analytics based on its practice and experience.

In conclusion, although today is much less open positions required manual testing skills only and automated testing development becomes mandatory knowledge, we still need manual testing in our SDLC and we will need this as long as people will continue to use computers. Automated testing may reduce the amount of routine in our day-to-day duties, but we should still keep an human eye on what we are delivering to our customers (despite the fact that our auto-tests could indicate 100% passed rate).

p.s. On the picture displayed an issue found on MS Office 2010 — if you try to input text instead of expected number in font size field then switch to any other field — app will crash and you lose your work. This bug has been fixed in later versions of MS Office.