Resetting MySQL root password

Somehow I got banned from own MySQL server installed on my Mac running OSX Moutain Lion. Every time I tried to log in as root (my only user) I would get: mysql access denied for user ”@’localhost’

Don’t know how I ended up in that situation, but write here how I got out, for others to know (and for me to remember). The deal is basically to reset the root password.

The solution is in this blog post: http://innovativethought.net/2007/05/17/resetting-your-forgotten-mysql-password/

Here are the step I followed with MySQL 5.5.28 running on OSX 10.8.3:

  • turn off mysql server
  • first terminal: sudo /usr/local/mysql/bin/mysqld_safe –skip-grant-tables
  • second terminal:
    launch the admin console: /usr/local/mysql/bin/mysql mysql
    reset the password: UPDATE mysql.user SET Password=PASSWORD(“newpwd”) WHERE User=”root”; FLUSH PRIVILEGES;
  • turn on mysql server

EDIT : got stuck a couple of days later with the same problem and the same solution did not work. I used the little scripts provided there: http://code.macminivault.com/

Retour sur Mix-IT 2013

Le 25 avril dernier, j’ai assisté à la première journée (sur 2) de Mix-IT à Lyon organisée par le Lyon-JUG et le Club Agile Rhône-Alpes. Comme l’année dernière, l’organisation était excellente et globalement les sessions ont été de très bonnes qualité. Cela a aussi été l’occasion de retrouver et rencontrer (grâce à Ludo entre autre !) des agilistes et javaistes de toute la France.

Voici un rapide retour sur les sessions auxquelles j’ai pu assister.

  • “Jouez, apprenez” par Christian Martinez. De l’intérêt de (se) former par le jeu.  La session résonnait avec d’autres que j’ai pu voir sur les “innovation games” (comme celle de Grilog l’année dernière). Malheureusement, la pédagogie par le jeu n’a pas été mise au service de cette présentation que j’ai trouvé un peu poussive.
  • Introduction au NoSQL avec CouchBase” par Tugdual grall. Se voulait être un atelier mais il a plutôt s’agit d’une présentation magistrale (note pour l’orga: limiter le nombre de participant quand il s’agit d’un atelier ? 15/20 pers ?). La session aura déjà eu pour intérêt de me permettre de faire la différence entre CouchDB et CouchBase ! Tugdual a très bien vendu son histoire. Introduction claire sur le NoSQL puis premiers pas dans l’installation et la configuration de CouchDB (l’interface web pour administrer et monitorer semble d’ailleurs assez bien faite). Il a ensuite expliqué les notions de vues et d’index pour acceder aux documents stockés (JSON en général).
  • deux ans dans le flux” par Olivier Azeau . Ma session préférée de la journée. Un retour d’experience sur des constats et choix que son équipe (agile/scrum) a du faire face à l’échec d’un nouveau projet (nouveau produit, nouvelle techno). Les sujets de branche unique et d’estimations probabilistes ont eu le mérite de faire réagir la salle et d’en faire réfléchir plus d’un sur sa pratique ! Le billet d’Olivier sur la conférence mérite lui aussi une lecture.
  • “The hitchhikers guide to UXing without a UXer” par Chrissy Welsh. Introduction au monde des UX. Se voulait être un guide pour apprendre à faire de la UX sans UXer, mais a surtout été une longue présentation des outils/concepts manipulés par le monde de la UX. On a retrouvés nos amis les personas et les wireframes. Tout ça était très interessant, mais m’a laissé la même impression que si un paysagiste venait me parler de l’élaboration de mon jardin : ça serait bien de travailler avec lui mais je ne suis pas sûr que j’en aurais vraiment pour mon argent.
  • Concevoir son développement par l’API” par Éric Daspet et David Larlet. Session sur les API que les orateurs ont fait en mode discussion avec la salle sur des sujets qui ont dépilés par ordre décroissant d’intérêt pour l’audience (mesure de cet intérêt fait à l’aide d’un doodle avec la session. Bonne idée !). Points abordés interessants mas difficiles à suivre vu la configuration de la salle (grande salle, pas de micro, bruit de clim’). Il a été de nouveau question de points abordés par David lors de son lighting talk, notamment du fait de mettre des liens dans les objets retournés par les API. Ces sujets méritent effectivement discussion. A poursuivre !

La journée du jeudi s’est terminée par une soirée très sympa au Blogg (mélange entre un pub anglais et un biergarten allemand !). L’occasion de poursuivre les discussions de la journée.

Un seul regret ? Avoir manqué la deuxième journée avec la session de Johan et Remy ainsi que la keynote finale du lendemain par Audrey et Aline sur l’apprentissage de la programmation ! Ca promettait d’être interessant et animé tout ça !!

Encore merci aux organisateurs et orateurs pour ce très bon cru !

Devoxx France 2013

Quick feedback from Devoxx France 2013.
Favorite session was, no surprise, test related:
“tests, pourquoi, comment”
Valtech guys working on Mappy project made a broad presentation about the way they envision and perform their testing activities.

My take aways:

  • automated tests are a form of specification that are always up to date. When you are not sure about the expected/actual behavior of your product, automated tests are a better fit than user manual (could be obsolete)
  • testing activites can be gamified. Did not check yet : pair hero and TDGotchi
  • set some timeout to your tests (easy and convenient in Robot Framework and TestNG)
  • launch your tests in parallel. See this interesting presentation from TradeShift and their blog article about it.

Many things to try out !

Robot Framework, REST and JSON

The software I am testing with Robot Framework offers a REST API as main entry point. So the question arose of what library to use to write my Robot tests.

First one I tried was the robotframework-restlibrary.

  • Pro: it is test-oriented and works well with Robot
  • Con: some features are missing (inspecting returned headers for example) and there is no community/activity around it (no commit since 2009)

I used it for a couple of weeks for my first tests but once I reached the limitations of the library, I quickly looked for another one.

I bumped into 2 others libraries tagged as “REST” and “Robot Framework”

but none of them seemed to be a good fit for me (not much documentation, not the right level of keywords, not very active…). Though, the second one was built on “requests library” which seemed to be worth looking at.

Requests Python Library is not Robot or Test oriented but the feature support is very wide, the use guide is very detailed and the community looks very active.

Here is a simple example of how to use it with Robot Framework:
(we use jstontest.com that sends back a json object when we do a get)

*** settings ***
Library  Collections
Library  requests
*** test cases ***
simpleRequest
    ${result} =  get  http://echo.jsontest.com/framework/robot-framework/api/rest
    Should Be Equal  ${result.status_code}  ${200}
    ${json} =  Set Variable  ${result.json()}
    ${framework} =  Get From Dictionary  ${json}  framework
    Should Be Equal  ${framework}  robot-framework
    ${api} =  Get From Dictionary  ${json}  api
    Should Be Equal  ${api}  rest

The trick then is to create appropriate keywords for often-used command.
For example, to check the value of a property in a one-level json object, we could have this keyword:

json_property_should_equal    
    [Arguments]  ${json}  ${property}  ${value_expected}
    ${value_found} =    Get From Dictionary  ${json}  ${property}
    ${error_message} =  Catenate  SEPARATOR=  Expected value for property "  ${property}  " was "  ${value_expected}  " but found "  ${value_found}  "
    Should Be Equal As Strings  ${value_found}  ${value_expected}  ${error_message}    values=false

I am still looking for a good json lib to create/read/update my json objects.
In the meantime I built a collection of keywords like the one mentioned here.

Hope this help some people facing the same kind of starting point (robot + rest + json).
Ping me if you want some more details.

MOOC on software testing

Not a day without Mooc being mentioned. Thought it was about time to try one. So I just started Udacity course on software testing. And it was quite a surprise to see how the topic is opened up. No long definition of the different types of tests (black box, white box, exploratory, manual, automated…). The first examples are unit-test-like ! the first tester is the developer and the first test are codes, hence (automated) unit-like tests. That can seem obvious but general acceptance of software testing is a bit different. Here is a section of the wikipedia article about software testing :

“Software testing, depending on the testing method employed, can be implemented at any time in the development process. Traditionally most of the test effort occurs after the requirements have been defined and the coding process has been completed, but in the Agile approaches most of the test effort is on-going”

So the whole Agile/XP way of programming is becoming so mainstream that it is not mentioned and is just the way software testing is presented.

Will see how is the rest of the course goes…

Robot Framework Introduction

Did a little presentation of Robot Framework at Human Talk Grenoble about Robot Framework. Quite difficult to sell that kind of tool to an audience into web development with no or few experience of tests. This is more easy when talking to bigger team working on more traditional (old) softwares. Have to understand more about the possibilities and constraint of web development to understand how Robot could be used for the business/functional logic of the web projects.

GRILOG conference about software quality

On october 18th, GRILOG (Grenoble Isère Logiciel) organized a mini-conference about software testing. There were six lightning talks performed by different Grenoble area software actors.

Agility was not mentioned in the topic of the night, nevertheless, most of the presenters agreed on numerous notions that are central to Agile Testing :
– quality/tests are not handled at the end at the project (Eric Pierrel, Itris Automation)
– to have feedbacks very early in the project (Anne Pellegrin, Multicom). She explained the Wizard of Oz experiment ! Very interesting. Made me think about Pretotyping by Alberto Savoia.
– tests are driving the projects (Remy Dujardin, Hardis) and the whole project team should be involved in it.

So it is interesting to see how Agile was over-represented once we started to talk about quality in software. Agile is still a big topic in the area. A recent prove is the craze to get the tickets for Agile Grenoble 2012 conference. It sold out 2 weeks before the events. 500 tickets for a city like Grenoble is quite an indicator.

Slides and video of the presentations (all in french) are available online.

After the  presentation, I had the chance to chat a bit with a local university teacher in software engineering. He was a bit skeptical about this “whole Agile thing” and was happy to outsource this part of the program to an external presenter… a guy from a local IT department. So, academic and business do talk together sometimes….(“please, help me present Agile !”)

 

Software testing : the gap between academic and business circles

Last time I made a presentation to an audience about my work as a software engineer for a software vendor, I was asked if I were aware of a team of researchers in the local university studying…. software testing. The answer won’t surprise the french reader : of course I never heard of those guys.

Back when I was a student in computer science in a french university, I felt we did not deal enough with the business world. I was happy with the very academic way we were taught computer science. I felt a bit awkward about the research topic that were covered by the researchers (articles answering to articles mentioning articles…. but not much about the use of all this). For example, we spent hours on the “theoretical network” (the OSI’s 7 layers) and just mentioned what was actually used in company’s network. Or we discussed “theory of database” but first time I really used one was year later (Oracle !). Maybe that was ok after all. Still, I did not follow the PHD path and went in the software business world.

Now 15 years later (yes), I see this from the other side and I feel the same disappointment. To be very factual, in the software testing world there is of course tons of books, conference, mentors, tools and methods that are coming from the trenches. And in a parallel world, there is a research field :

My concern is : how come none of the software tester I know have ever read those paper or attended such a conference ? And why I never met any researcher in all the Agile Testing conference I went ?

I guess that in some fields academic and business meet more. For example, complex static tests performed on high quality demanding software takes a lot from academic research (e.g. Polyspace, french startup acquired by Mathworks a couple of years ago).

I wonder what is the situation in other country were software testing is big (US, Germany, India for example).

How Google tests software

Just finished “How Google tests software” book written by some Googlers. It is very much worth reading. I have very few informations about how testing goes at Google but as far as I could tell it seemed quite an honnest account on their practices. Here are some informations/data I found to be worth sharing.

First, it seems that a lot of the google testing culture comes from Patrick Copeland who joined the company in 2005 (a bit late in their history as they started a couple of years before 2000). At that time they were 50 full time testers and the culture of test was quite low (and bad) to say the least. It took years to Patrick and his teams (including Alberto Savoia and James Whittacker, authors of the book) to reach their idea of how quality should be managed.

Even if the word “agile” does not appear in the book (probably not much used within Google), one can detect a lot of Agile practices at Google. The major ones beeing the full integration/collaboration between developers and testers, the production in the most continuous way (up to the deployment) and the goal to reach a pyramide-shaped automation portfolio (much unit test, few end-to-end).

One point that is very much stressed and not so spread is the fact that they decided that testers should be as good programmers as programmers themselves. Basically they first stated that programmers (software engineers) were going to test as much as all the other engineering people (everyone is in charge of quality). Second step was to change the name of the testers/QA to “software engineers in tests” and “tests engineers” to make them more equal to programmers. And finally those SET and TE where in charge of helping the teams to test/automate, not just test. Given this, it became clear that finding the right people for the job was quite tough. All the parts about the hiring process are interesting.

Another quite counter-intuitive fact is that the methods and tools are not so centralized in Google. They are going in this direction and the best tools/methods they came up with are quite popular inside (and even outside as the release some tools). But even basic opinions like “how much automation versus exploration” seem to differ from one test manager to another. The book is quite honest and humble about this and does not try to sell THE google way of testing.

The future of the test as seen by James Whittaker in the last chapter is quite unexpected to ! He figures that testing will disappear as a job because it will so much become everyone else responsibility (Product manager,  programmers…. customers ?) that the job will be diluted in the company.

Other misc facts :
– Google does not really think in term of dev/qa ratio. In their model with SET and TE, it does not make much sense
– the whole continuous integration system was very complex to set-up. Testing teams pushed a lot to have it and it became, of course, the backbone of their organisation
– they try to build automated test cases that are independent of the order in which they are run and that let the “system” in the same state they discovered it. This allow to run all the tests in parallel. This is a good practice I tried myself, and it appears to be not so easy to build and maintain.

Oh…. and my favorite paragraph about automation :

“The larger an automation effort is, the harder it is to maintain and the more brittle it becomes as the system evolves. It’s the smaller, more special purpose automation that creates useful infrastructure and that attracts the most software engineers to write tests.
Overinvesting in end-to-end automation often ties you to a product’s specific design and isn’t particularly useful until the entire product is built and in stable form. By then, it’s often too late to make design changes in the product, so whatever you learn in testing at that point is moot. Time that testers could have invested in improving quality was instead spent on maintening a brittle end-to-end test suite.”

Amen !

 

 

Testing at Google

Google testing blog is waking up after a long silence !

They were probably busy handling HR issues as 2 main actors of google testers left Google :

1) James Whittaker who shared his thought about leaving google

2) Alberto Savoia who is famous for his “test is dead” talk)

Funny thing is that James Whittaker was writting a book about “how google test software”. Now the book just released while James is at Microsoft already !

So, the book is available

And Google Blog is starting to discuss its testing strategy again.

Next steps for me : read James book and share some feedbacks…