They say you should backup your data as often as you attend church. They don’t say what you should do when you delete your backup.
I could mourn the loss of posts dating back 5 years, but i’ll look at it as a new beginning.
They say you should backup your data as often as you attend church. They don’t say what you should do when you delete your backup.
I could mourn the loss of posts dating back 5 years, but i’ll look at it as a new beginning.
We expect numbers for logged-out users to be slightly faster, since there is less logic to do on the backend and there are some missing UI elements on the front-end in some cases.
Conway’s law is an adage named after computer programmer Melvin Conway, who introduced us to the idea back in 1968, yes they had computers back then kids. It states that:
“organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations”.
What do we do about it?
DevOps. While devops is a portmanteau of development and operations, it is not another team. The last thing our IT family needs is yet another functional silo.
DevOps is a set of protocols and practice’s that stresses the importance of communication, collaboration and integration between the software development teams and the rest of our information technology professionals.
We need to start thinking beyond our IDE, we need to start thinking beyond our kanban boards and our service management systems, we need to increase our collaboration and our communication, and we need to make sure that we never create a monster like shared dependency again.
All too often the software test team can have a bad reputation in any given organisation. Over the years i have heard the same reasons as to why the test team are not appreciated in the same way as developers are within the delivery of a project. Here are a few that come to mind readily:
This isn’t just my opinion. Test teams really do get little no love, but why? Rex Black wrote in an article on eWeek.com -
I’ll start with how not to develop a test team. Many IT managers—especially those who have never seen professional testing—assume anyone can do it. They try to get the job done with junior programmers, users or business analysts. While these people have a role to play, by themselves they do a poor job of testing.
Rex touches on something that is important, test teams get a bad name because there is belief that testers just “play” with software until they “break” it, and because “anyone can do it”.
Andrew Faust has this to say on his blog about software testing at Microsoft:
In many companies they [the testers] are seen as the guys who couldn’t cut it as developers. They’re often second class citizens. They aren’t consulted on design, they are far outnumbered and they are seen as an added expense that constantly delays the release of a product.
Wow, “couldn’t cut it as developers” and yet we charge them with checking the developers work?
And when Ara Pulido was calling for testers to come forward can create an Ubuntu Test community she noted:
Software testing is generally seen as the poor cousin of programming. While the bad reputation of testers happens in all software environments, this is more common in free software communities…
Again “bad reputation of testers”. So what are we software testers doing so wrong?
Typically the software test team that works in an organisation where these views are shared by IT management will be employed in a go/no-go process. The test team will not have been engaged in way that will allow them to continuously sample and inform the quality of the work during the software delivery life cycle, and the first time they get to see the delivery, its too late.
What i have found interesting, is that in any organisation where the test team have a bad reputation, if I suggest that the test team down tools for a period of time, say for example “the whole test team will be out for a week to attend the EuroStar conference”, everyone throws their hands in the air. The mere suggestion that the test team walk off the project is viewed with utter contempt. So paradoxically while the software testing team gets a bad name, and is viewed as not adding any value, the same organisation doesn’t want to lose them, especially if there have been quality issues in the past; the very issues that fueled the bad reputation.
So what can we do about it? Unfortunately what i have found in the organisations where the software testing team has a bad reputation, the testing team are often perpetuating the problem through their actions and also their inaction.
So, if you work in an organisation where testing is getting a bad reputation, start by getting some things straight.
This isn’t an exhaustive list by any means, this is really the low hanging fruit. By changing the behaviors and displays of the testing team, and sticking to it, the test team will begin to be viewed as being more professional.
Remember, Its all too easy to undermine the professionalism of testing by using throw away phrases like “yeah sure, I’ll have a play with it and see what breaks”. That doesn’t sound like a skilled professional at work does it?
I’ve owned an android device, for a fairly short period of time, but recently i found i couldn’t update and apps, or install any new ones, i kept getting obscure messages and seemingly random error codes like 923, 927 and 495, luckily i found a fix.
This had me stumped, a search of the internet, turned up lots of people complaining about the same issue, all over the world.
Many forums contained posts from people who deleted the Google Play store cache and data from within the settings applet, but this didn’t work for me (in fact it just broke the Play store further).
Some posts even suggested flashing new firmware!!
It was only when i read a post from a guy, who said he could update using 3G, but he couldn’t using WiFi, that information gave me an idea..
I started to think that Google probably use their CDN to deliver apps, and that they probably leverage some anycast magic to get the end users traffic on to the nearest Google pop.
With that in mind, i changed the DNS setting in my router, from the ISP supplied on to Googles own Open DNS servers.
I set the primary address to 188.8.131.52 and the secondary to 184.108.40.206, then from within my android device, i turned off WiFi, then turned it back on again, forcing it to drop the current DHCP lease, and (i hoped) any associated DNS caching it may have done.
Sure enough, when i re-opened the Google Play app, it started updating instantly!
Aside: By deleting all of the apps data, the Google Play store now thinks i have two identical devices, and unfortunately doesn’t know what i have installed on the device.
I was reading Teresas blog post, and wondered if the problem wasn’t in the exchange she described, but in the psyche of the characters in the scenario…
Within the blog post “how to find common ground when engineers dont like features” Teresa describes a scenario in which a product manager is challenged by an “Engineer”.
I’m intrigued by the exchange, not because of the content, but because of the use of the word “Engineer” to describe the role. Engineering is a discipline.
Lifted from Wikipedia (http://en.wikipedia.org/wiki/Software_engineering), because i’m too lazy to paraphrase:
“Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. In layman’s terms, it is the act of using insights to conceive, model and scale a solution to a problem.”
Within that definition of engineer, the exchange in the scenario sounded off key. The basic business requirement was being challenged, and that isn’t anything to do with engineering discipline.
While the exchange is fabricated, it is representative of what is happening, i see ideas being challenged by software developers all the time, all too often by self appointed “rock stars” rather than engineers.
In my experience, these people like giving themselves exotic names, ninja, wizard, guru, rock-star or even engineer.
In the real world engineers typically have to endure several years of apprenticeship as well as several years formal academic training, and then have to demonstrate a working knowledge of their subject before a board or governing body, before they can call themselves an engineer, and in order to keep the status they have to provide frequent evidence that their skills and knowledge are up to date.
Would we suffer the same exchange between us and say our plumber?
Me: I want hot water to come out of my tap.
Plumber: i wouldn’t want that.
Me: I’ll find another plumber.
Plumber: Hulo, Ninja heating services, how can i tell you what you want?
I have just been prompted (via some AdWords) to write a quick blog post around the subject of defect prevention. Not detection, prevention.
For a long time the software testing community has been taught that unless a defect is being managed in a defect management tool, then whatever testing process you are following is probably not fit for purpose. That is, you cant be doing serious software testing, because you are not being serious about your bugs. But it is the peddlers of these tools who tell us this.
The software vendors make many fantastic claims in fact
Ergo If you haven’t spent some serious cash on a defect management system you aren’t really testing software, you’re just mucking about. Its crucial to have defect management.
Even HP Quality Center would have us believe that if we use their tool, we will see a “50% reduction in the cost and effort associated with fixing defects”, that is quite a claim.
Interestingly Wikipedia says this “
…Defect tracking is important in software engineering as complex software systems typically have tens or hundreds or thousands of defects
”, holy cow!
Tens or hundreds or thousands? We obviously need a complicated and expensive system to manage that then!
There is of course quite a bit of a difference between having say 20 defects and having 8,000 defects. If I had collected, triaged and managed 8,000 defects, I would expect to get my ass fired, marched right out of the office door. Why? Well for one thing, 8,000 defects is a very good indication that the quality of the product is terrible, therefore something in the build process is very broken, and for another thing, why would you let the number of defects build up to an unmanageable figure like 8,000??
The business can’t make any money out of those defects, it can’t market them, so why invest in them? Why give them a home? Why give them so much time? Managing defects requires a lot of time.
Let’s say it takes 3 minutes to raise a defect, a further 3 minutes for it to be triaged and accepted as a defect, a further 5 minutes for the developers to decide if they accept it (can’t fix/won’t fix), then say a daily defect meeting to update status etc, that takes about 3 minutes a defect (I’m being very optimistic), then a weekly project meeting where the defect list is discussed again.
That’s about 15 minutes of pure ticket pushing for a defect, and that’s before it gets bounced around several times as “can’t reproduce” etc.
So for 8,000 defects that equates to some 234 working days. You haven’t even fixed anything yet, that’s just pure defect management overhead. You think I’m over egging the pudding? Then go tell your CFO, and see what they say.
However you slice it, it is waste.
So, take a long hard look at your defect tracking tool, and ask yourself, is there another, less wasteful way?
The answer is yes. Defect prevention.
I recently bought one of these
You see the device uses an MCP23017 16bit I2C port extender, and most 16×2 LCD displays require a 4-bit bus (4 data lines) , and an RS, RW and E lines, so i was interested to see how Adafruit were implementing the lcd display protocol over the i2c bus.
It arrives as a kit of parts with very little to put together, a few minutes soldering is all that is needed. I only wish i had bought a header with longer pins, like this one
To allow me to tap off the I2c bus for other things i’m working on (RTC, Temp sensor and non volatile ram).
So, the thing with the adafruit shield is, that like everything else for the raspberry pi, it comes with a set of python scripts.
I have nothing against python, i’m sure its a great language, but i want to crack on with what *I’m* doing, i don’t want to start learning python just for this project. So far i’ve written everything in C or Perl. So the examples from Adafruit were no good for me.
I then started thinking about LCDproc, which i have used in the past with a headless Debian box, and a 4×20 LCD display via the parallel port.
LCDproc is great, it runs as a daemon, and you just need to write a client to push data to it. Due to its age, it already has a lot of drivers for different display, including one for an HD44780 LCD display via I2c, so i was hopeful that it wouldn’t be too much work to add the Adafruit display into the mix.
But guess what, i needn’t have worried, because someone else (Jonathan Brogdon) had beat me too it, and his patch had already been merged into the head of the LCDproc source code.
So, here is a recipe for getting LCDproc running on a raspberry pi, with the Adafruit RGB 16×2 LCD display with keypad.
sudo apt-get update sudo apt-get upgrade sudo apt-get install i2c-tools
Now we need to enable i2c
pi@raspberrypi ~ $ sudo sh -c "echo 'i2c-dev' >> /etc/modules" pi@raspberrypi ~ $ sudo sh -c "echo 'i2c-bcm2708' >> /etc/modules" pi@raspberrypi ~ $ sudo reboot
Once pi reboots, see if you can detect the lcd display.
pi@raspberrypi ~ $ i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
The display should be detected at address 0×20
Now, we need to install the tool chain.
pi@raspberrypi ~ $ sudo apt-get install cvs autoconf automake
Now get the current version of lcdproc from source control (because apt-get doesn’t have a version that includes support for the Adafruit LCD yet).
pi@raspberrypi ~ $ cvs -z3 -d:pserver:email@example.com:/cvsroot/lcdproc checkout -P lcdproc
Now we need to configure the build.
pi@raspberrypi ~ $ cd lcdproc pi@raspberrypi ~ $ sh ./autogen.sh pi@raspberrypi ~ $ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-drivers=hd44780
Then run make to build the binaries
pi@raspberrypi ~ $ make
lets check we built the piplate connection type into the hd44780 driver, edit the local LCDd.conf file and set connectiontype to piplate and driver to hd44780.
pi@raspberrypi ~ $ sudo server/LCDd -c ./LCDd.conf -f
A curses LCD emulation window should show, just hit Ctrl+c to terminate LCDd.
Now install the newly built version.
pi@raspberrypi ~ $ sudo make install
Then edit the /etc/LCDd.conf file to look like this:
[server] DriverPath=/usr/local/lib/lcdproc/ Driver=hd44780 Bind=127.0.0.1 Port=13666 User=nobody WaitTime=5 [hd44780] ConnectionType=piplate Device=/dev/i2c-1 Port=0x20 Size=16x2
Ok, lets test by running the lcdproc client to send some data to our newly created LCDproc server.
pi@raspberrypi ~ $ sudo lcdproc
To add the buttons to LCDproc, we need to add further configuration – here is my complete lcdd.conf file:
# LCDd.conf -- configuration file for the LCDproc server daemon LCDd # Modified to support a hd44780 connected to a Raspberry Pi using i2c # # This file contains the configuration for the LCDd server. # ## Server section with all kinds of settings for the LCDd server ## [server] # Where can we find the driver modules ? # IMPORTANT: Make sure to change this setting to reflect your # specific setup! Otherwise LCDd won't be able to find # the driver modules and will thus not be able to # function properly. # NOTE: Always place a slash as last character ! DriverPath=/usr/lib/lcdproc/ # Tells the server to load the given drivers. Multiple lines can be given. Driver=hd44780 # Tells the driver to bind to the given interface Bind=127.0.0.1 # Listen on this specified port; defaults to 13666. Port=13666 # Sets the reporting level; defaults to 2 (warnings and errors only). #ReportLevel=3 # Should we report to syslog instead of stderr ? [default: no; legal: yes, no] #ReportToSyslog=yes # User to run as. LCDd will drop its root privileges, if any, # and run as this user instead. User=nobody # The server will stay in the foreground if set to true. #Foreground=no # Hello message: each entry represents a display line; default: builtin #Hello=" Welcome to" #Hello=" LCDproc!" # GoodBye message: each entry represents a display line; default: builtin #GoodBye="Thanks for using" #GoodBye=" LCDproc!" # Sets the default time in seconds to displays a screen. WaitTime=5 # If set to no, LCDd will start with screen rotation disabled. This has the # same effect as if the ToggleRotateKey had been pressed. Rotation will start # if the ToggleRotateKey is pressed. Note that this setting does not turn off # priority sorting of screens. [default: on; legal: on, off] #AutoRotate=no # If yes, the the serverscreen will be rotated as a usual info screen. If no, # it will be a background screen, only visible when no other screens are # active. The special value 'blank' is similar to no, but only a blank screen # is displayed. [default: on; legal: on, off, blank] #ServerScreen=no # Set master backlight setting. If set to 'open' a client may control the # backlight for its own screens (only). [default: open; legal: off, open, on] #Backlight=open # Set master heartbeat setting. If set to 'open' a client may control the # heartbeat for its own screens (only). [default: open; legal: off, open, on] #Heartbeat=open # set title scrolling speed [default: 10; legal: 0-10] #TitleSpeed=10 # The "...Key=" lines define what the server does with keypresses that # don't go to any client. The ToggleRotateKey stops rotation of screens, while # the PrevScreenKey and NextScreenKey go back / forward one screen (even if # rotation is disabled. # Assign the key string returned by the driver to the ...Key setting. These # are the defaults: ToggleRotateKey=Enter PrevScreenKey=Left NextScreenKey=Right #ScrollUpKey=Up #ScrollDownKey=Down ## The menu section. The menu is an internal LCDproc client. ## [menu] # You can configure what keys the menu should use. Note that the MenuKey # will be reserved exclusively, the others work in shared mode. # Up to six keys are supported. The MenuKey (to enter and exit the menu), the # EnterKey (to select values) and at least one movement keys are required. # These are the default key assignments: MenuKey=Escape EnterKey=Enter UpKey=Up DownKey=Down LeftKey=Left RightKey=Right ## Hitachi HD44780 driver ## [hd44780] ConnectionType=piplate Port=0x20 # Device of the i2c interface [default: /dev/lcd] # Raspberry Pi version 1 require i2c-0; version 2 requires i2c-1 Device=/dev/i2c-0 # Bitrate of the serial port (0 for interface default) Speed=0 # If you have a keypad connected. # You can configure the keypad layout further on in this file. Keypad=yes # Set the initial contrast (bwctusb and lcd2usb) [default: 500; legal: 0 - 1000] Contrast=0 # If you have a switchable backlight. Backlight=yes # If you have the additional output port ("bargraph") and you want to # be able to control it with the lcdproc OUTPUT command OutputPort=no # Specifies the size of the LCD. # In case of multiple combined displays, this should be the total size. Size=16x2 # Character map to to map ISO-8859-1 to the LCD's character set CharMap=hd44780_default # You can reduce the inserted delays by setting this to false. # On fast PCs it is possible your LCD does not respond correctly. # Default: true. DelayBus=false # If you have a keypad you can assign keystrings to the keys. # See documentation for used terms and how to wire it. # For example to give directly connected key 4 the string "Enter", use: # KeyDirect_4=Enter # For matrix keys use the X and Y coordinates of the key: # KeyMatrix_1_3=Enter KeyDirect_1=Enter KeyDirect_2=Up KeyDirect_3=Down KeyDirect_4=Left KeyDirect_5=Right # EOF
In the past Uncle Bob and Martin Folwer have both pissed me off with their “we don’t need testers anymore” messages that they have delivered in the past. To be fair, Martin knows he pissed me off, i told him, (stick to getting more women into IT Martin); but recently Uncle Bob seems to have recognised the benefits of having career testers within the team. Perhaps he hadn’t met good testers before; after the recent discussions I had at the London Tester Gathering it seems that good testers (Agile or not) are a fairly rare breed.
So O.K, let me stand back for a moment and reflect on what XP teaches us in that a highly disciplined team should be able to achieve zero defects, so its easy to say, zero defects means we don’t need testers.
Moreover, at the SIGIST conference in June, Julian Harty (ex Google senior test engineer) delivered a presentation that posed the question, do we need testers. What if we stop testing? After all these days people seem to want speed first and fully working functionality secondary. The future of testing?
So yes the playing field has changed, its true. But that doesn’t mean i have to agree with it.
If the software is crummy, your users will only tolerate it to a point. A great example of this is reading the feedback comments on iPhone App store. Even when a piece of software is offered for free, people leave bad feedback complaining about the uselessness or poor UI etc.
The crux of the matter for me is this. Even if we did find the magic incantation that could give us defect free code, it still wouldn’t mean the business would get quality software.
I’m signed up to Bachs ideal, but i’m embedded in an XP/Lean team. We have 90% test covereage across 903 classes and 201,000 lines of code (and counting). Those thousands of tests run in seconds, before they make their way up the CI pipeline to run UI and performace tests. No nightly build, we test every checkin.
CI had my support 100%, because it should mitigate lots of manual testing. In fact it should mitigate lots of testing. As the product we work on has matured, the CI has formed a regression pack. Its sound great right? So why do I still have a team of 8 testers and a 15% defect rate?? Because developers are humans not robots. Because developers focus on what “Done” looks like, and not the bigger picture. Because they dont understand the context within which the story was written and thus make an assumption. Because they are testing in the small. Because they didn’t have the right data in the development environment. Because there exists two different mindsets between good developers and good testers. But non of those reasons are new, or particular to Agile. Its all old news.
But then i read this by Chief Frank C. Montagna
“Firefighters, as all humans, make mistakes. When firefighters make a mistake on the job, however, it can be life-threatening to themselves, to their coworkers, and to the public they serve. Nonetheless, firefighters will continue to make mistakes and on occasion will repeat a mistake.
Our goal should be to learn from each mistake and to try not to repeat it. We should also teach others not to make the same mistake we made. To do this, we have to admit our mistake publicly by telling others about it. This is not always easy to do. ”
This Agile vs Tester friction just needs us, the testers to be pragmatic and professional; we must continue to share best practice, collaborate and talk to the developers earlier in story life-cycle. We should shout STOP! sooner rather than later, jump in feet first and embrace what may feel like an awkward discussion.
We testers are not here to simply find defects, appoint blame, or hold a “who sucks the most” post mortem. We are here to add value, and if we don’t, then why do we need testers?
A defect report is pretty meaningless. You cant sell it or market it to your customers. Worse, it has overheads. So why have one? Why not have a discussion with a developer and a product owner instead?
We (Developers and QA) both work for the same company, so why aren’t we working together, and demonstrating to Martin and Uncle Bob, that we are valuable and that testing and testers should be taken seriously.
Reading Simons Blog post The Tester’s Headache: Tester Certification – my take… got me simmering again.
This something I have been bending my peers ears with and blogged in passing for over a year now.
For me the value in the foundation cert. Was two fold (btw I’m old school ISEB), it gave testers a commonon taxonomy and the course provided valuable networking.
Today too many of the candidates I interview simply see the certificateas a corgi gas fiiters badge. I have the cert. Therefore I’m a tester.
Worse still many candidates have self studied, and there the only aim is to complete practice exam papers or question banks.
I was chilled to the core when speaking with Dave Evans from SQS as I thought the Agile Tester cert. I had heard about was a joke, or tester lore. It seems istqb are serious.
All that has happened is that the cert. Has been de valued, and so I don’t make it a “must have” in the job spec anymore.
Has the calibre of applicant decreased? Nope, not one bit, it’s just increased the volume.
I still have the blisters from the ISEB practitioner exam, but I can’t think of anything I use from the sylabus now we are all out Agile.