What to Wear: A Tester's Toolbox

Summary:

When it comes to data, we understand that visuals matter; that’s why we create pie-and-graph charts instead of stark spreadsheets. Tara Nicholson explains why clothes, grooming, and posture can be just as important as data. How you present yourself is what marketers call your “brand” and what technical analysts call a “persona.” It expresses how you perceive yourself and how you want others to perceive you in the professional environment.

At the beginning of my career as a software tester, it was office policy for employees to dress in formal wear, eat food only in the break rooms, including coffee, and to start work by 8:00 a.m.

Today, I work in an environment that offers casual dress, near-dark conditions, and flexible schedules to capture that “creative window” of opportunity in each individual contributor. As an outdoor enthusiast with two kids, I perceive time with my hairdryer as wasted minutes of the day I could be using for more valuable endeavors, like time with my spouse, packing a healthy lunch, reading a tech blog, or sleeping. I also know from playing outdoors among lawyers, rocket scientists, real-estate agents, policemen, grant writers, ect., that these professionals are just as brilliant when they are covered in dirt.

So, looks do not matter, right? I can show up in a ponytail, pale-faced, dressed well above minimum HR requirements, and perform just as brilliantly in the workplace. And, of course, it is about being good at what I do that will grant me successes in life. Sounds like dressing casual is a win-win situation all around for the aspiring techy, right? I've come to disagree with this opinion and made truce with the hairdryer I now realize I own.

When it comes to data, we understand that visuals matter; that’s why we create the pie-and-graph charts instead of stark spreadsheets. It’s not just data; clothes, grooming, and posture can be just as important. I invite you to take a few moments to people-watch in a crowded place and match who you see to their hypothetical career goals. The exercise reveals that we can have biases influenced by what people wear and how they carry themselves. Try it and see.

Align Your Goals and Your AppearanceIn many cases, the tester is the liaison between the business perspective and the technical geniuses of a system. We live in the space between washed-out Atari shirts and neckties; between introverted brilliance and social intelligence. That means we need to be able to talk to, and earn credibility with, both sides.
Put yourself in the sprint-review meeting where it is the QA’s turn to demo the software built and tested over the past two weeks. The new page is taking sixty seconds to load due to some hiccup in the wireless connection and all eyes are on you. You are slouching over the monitor dressed in worn-out jeans and a team-wear hoodie. Having earned your way to the senior test-engineering role with your development team, your credibility is not in question at this moment. But to the business team members, your appearance sets the tone of the feature they are about to be shown.
Now imagine the same team collaborating on an all-night coding effort. You’re in the trenches in your hoodie knocking out features in a synchronized dance between bug fixes and tests with the developers. It’s a beautiful thing! Attend another late-night in your pressed black suit, elbows out, back straight, firm jaw, and measure how fast your appearance becomes a topic of discussion, an interruption to the beautiful dance that is a software project. Clearly, you don’t belong.

Credibility is not lost by a single choice in outerwear as suggested in the examples above. What you wear and how you hold yourself can be a powerful tool for you to leverage in such situations by understanding the potential impacts of your choices.

A Little Bit on PostureThe BBC recently reported that ”The way we walk can increase the risk of being mugged.” Additionally, posture doesn’t just change how we are perceived, it influences biochemistry, changing how we feel about ourselves. “Your body language shapes who you are,” says Amy Cuddy, a professor and researcher at Harvard. Posture compliments our clothing and grooming habits, which they can amplify. While it is challenging to sit well in front of a panel of LCD screens, making a conscious decision to try and making a few ergonomic adjustments are worth the effort.

Pick Your Dress Type, But Do It ConsciouslyHow you present yourself is what marketers call your brand and what technical analysts call a persona. It expresses how you perceive yourself and how you want others to perceive you in the professional environment. A strong self-brand has the potential to strengthen credibility: Simple, genuine, consistent messaging. What is your brand message?

Because style varies so much from the coasts to the midwest, specific advice can vary. Here are a few things I have found to be consistent in my experience:

Comfortable attire improves your approach-ability. Skirt suits for show-time. Personal hygiene, clean clothes, and not showing too much skin are unanimously a must in an office space. Abrupt changes in style or degree of formal wear catches peoples' attention. ‘Hawaiian shirt Fridays’ are entirely optional. And, by all means, sport that "Cowgirls Don't Cry" t-shirt on midnight launches, regardless of rank!    

Now consider, what do you want your style to be and what should change?

And please, leave a comment. I can give advice from my experience, but I suspect our readers would like to hear additional or differing observations to consider.

http://www.stickyminds.com/article/what-wear-testers-toolbox

How can you possibly test modern software fully?

Pairing up for fun and profit

 

The common assumption about software testing is that "more is better", and testing all the possible states and variable combinations guarantees you will find all the bugs.
In the real world, however, there is not enough time or enough testers to test every combination of every variable. Not all bugs will be found, making quality assurance a risk management discipline. How can you validate that your product is ready to ship within reasonable time and cost parameters? In other words, how can you manage the risk of not testing everything? One solution is to use structured testing methodologies, supported by proper tools, which help you quantifiably manage this risk.

Practically speaking, the role of quality assurance is to reduce the risk of these bugs ending up in the final product. Software complexity puts a huge burden on QA teams, which are typically much smaller than the development teams writing the software (it's even worse if there isn't a QA team and developers take on the role part time). It is also very easy for one developer to write a small amount of code that requires a significant amount of testing to ensure it functions properly in all situations.
For example, you have to test a dialog box with three drop-down lists to see if any of the combinations cause the program component to fail. The first list has five options, the second has eight options, and the third has three; see Figure 1:

To determine all the possible combinations, you can create a matrix like the following (Figure 2):

As you continue adding combinations, you discover that 120 test cases are required to cover all the possible combinations. You can also determine the number of combinations by multiplying the number of values available in each option (5 x 8 x 3 = 120). If each test takes around two minutes to perform, you are faced with about 4 hours of testing on a simple dialog box. What if you need to test 100 dialog boxes? What if some dialog boxes contain 15 options instead of three?
Now take the concept of complete coverage a step further and consider environmental variables such as operating system, database, and hardware components. How do you ensure you find a bug that occurs only when the application is running on Windows XP and is using MySQL without testing all the possible OS and database combinations?
These examples demonstrate how quickly complete coverage becomes unmanageable. Luckily, you can find most bugs without testing all the combinations. The simplest bugs are single-mode faults, which occur when one option causes a problem regardless of the other settings. For example, a printout is always smeared when you choose the duplex option in the print dialog box regardless of the printer or the other selected options.
Another type of bug is one that occurs when two options are combined - the printout is only smeared when duplex is selected and the printer is a model 394. These are called double-mode faults. Finally, multi-mode faults, which occur when three or more settings produce the bug, are the types of problems that make complete test coverage seem necessary.
However, complete coverage is usually not necessary. A study by Telcordia Technologies found that "most field faults were caused by either incorrect single values or by an interaction of pairs of values" (Cohen, et al. 1996). Another study of the software in medical devices showed that only three of the 109 failures resulted from the combination of more than two conditions (Wallace, 2000).
If you have limited time and resources, you want to find the most common bugs and those that present the highest risk. Suppose the printer error only occurs when the operating system is Windows, the print option is set to duplex, the print quality is draft, and the collate option is not selected. Is it worth your time to find that bug? Does the bug present a big enough risk to the user or application that it will even require a software fix?
Except in the rare cases where life and death are at stake, you can achieve a statistically acceptable level of quality by testing less than 100 per cent of the combinations. One approach to doing this is called pair-wise or all-pairs testing.

Implementing all-pairs testing

If testing all the possible combinations of values is not necessary, the question becomes how to construct the all-pairs tests. There are several applications that allow you to enter variables and generate the tests. However, it is helpful to try constructing the test cases manually once or twice so you understand exactly how all-pairs testing works.
Identifying the variables

Before you can implement all-pairs testing, you need to identify the variables. For example, single sign-on support was recently added to your company's sales management application, and the login screen was redesigned for this feature. The application runs on a variety of operating systems, supports several databases, and includes a cross-platform graphical user interface (GUI) and a web-based client. The following table (Figure 3) summarises the variables that affect the tests:

[Note: For the sake of simplicity, the following examples assume that all the variable combinations are valid.]
How do you effectively test single sign-on support based on these different variables? A simple calculation shows there are 48 possible combinations (3 x 4 x 2 x 2). All-pairs testing can significantly reduce that number.
Creating the first pair of values
After identifying the variables, use a spreadsheet to combine the values from a pair of variables. Before starting, arrange the variables by the number of values they contain from greatest to least. In our example, the variables would be placed in the following order: Database, Operating System, Client Type, and Browser. Label the first column in the spreadsheet with the name of the variable with the most values (Figure 4):

Label the second column with the name of the variable with the second-highest number of values (Figure 5):

Pair the first value in the first variable column with the first value in the second variable column (Figure 6):

Then match the first value from the first variable column with the second value in the second variable column (Figure 7):

Continue the process until the first value of the first variable is paired with each of the second variable values (Figure 8):

Skip a row in the spreadsheet to improve readability and to allow for expansion. Then match the first variable's second value with all the values from the second variable (Figure 9):

Repeat the steps until all values in the first two variables are paired up (Figure 10):





Matching the other pairs of values
To add a third variable, start by entering the values in order in a third column, repeating as necessary (Figure 11):

Next, compare the combinations and make sure you have all the possible pairs for the second and third variables. In our example, there is a pair for the Windows Operating System and each Client Type (Figure 12):

There is also a pair for the Linux Operating System and each Client Type (Figure 13):

Finally, there is a pair for the Solaris Operating System and each Client Type (Figure 14):

If a pair is missing, rearrange the values to create the necessary combinations. Notice that it only takes six test runs to cover all the Operating System and Client Type combinations (Figure 15):

Next, compare the combinations between the first and third variables to make sure you have all the possible pairs (Figure 16):



Notice, from Figure 17, that 10 test runs cover all the Database/Client Type and Operating System/Client Type pairs:

If there are more variables, continue the same procedure of creating pairs with the values from the last variable and the values for the other variables.
In our examples, the Browser values are only valid when the Client Type is Web. The following table (Figure 18) shows the Browser values added to the Web test runs:

Verify that all the Web pairs are present for the other variable values. There is a pair for each Browser value and the Web Client Type (Figure 19):

As you can see in Figure 20, there's a pair for each Operating System and Browser value:

Finally, check the pairs for the Browser values and the Database values. Notice, from Figure 21, that the Oracle/Internet Explorer and Access/Firefox pairs are missing:

You could simply add two new test runs to cover the missing Database and Browser combinations, however, before you do that, check for duplicate pairs to see if you can incorporate the missing pairs into the existing runs. Notice, from Figure 22, that the Solaris/GUI and the Windows/GUI pairs are duplicated in the Access and Oracle groups.

You can change the Solaris/GUI pair in the Oracle group and add the Internet Explorer/Oracle pair to that run without affecting the other pairs. You can also change the Windows/GUI pair in the Access group and add the Firefox/Access pair to that run, giving us Figure 23:



From 48 to 12 Test Runs
After pairing up the variables, add a column and number the test runs for easy reference. The following matrix, Figure 24, summarises the final test runs.

Instead of 48 test runs, only 12 are required to provide the proper test coverage. If particular variable combinations have resulted in a higher number of defects in the past, you might want to include additional runs to cover those combinations.
Now, the next thing you have to do is find an automated testing tool to code up the tests and manage the test runs. [There'll be a follow-up interview with Keith in Reg Dev soon, where I'll ask him about implementing this technique in practice - David Norfolk, Ed]

Follow-up Resources

Berger, Bernie. Efficient Testing with All-Pairs International Conference on Software Testing 2003: available here.
Dustin, Elfriede. Orthogonally Speaking: A Method for deriving a suitable set of test cases STQE September/October 2001: available here.
Cohen, David M., Siddhartha R. Dalal, Jesse Parelius, and Gardner C. Patton. The Combinatorial Design Approach to Automatic Test Generation IEEE Software September 1996.
Wallace, Dolores R. and D. Richard Kuhn. Converting System Failure Histories into Future Win Situations Information Technology Laboratory, National Institute of Standards and Technology January 2000 (pdf file); there's a link to a related website here.


http://www.theregister.co.uk/2007/07/15/all_pairs_testing/

 

Agile and Scrum Methodologies from a Testing/QA Perspective

Summary:

Agile software development is already beyond the innovation stage and rapidly moving through an early adoption stage. Have you noticed agile and Scrum being mentioned "everywhere" you look? This write-up will describe key agile/Scrum concepts, the different phases of an agile project managed using Scrum, and the top three things that you should expect as a QA engineer/tester professional. If your organization is looking at agile/Scrum, or you want to keep up-to-date on industry trends, read on.

Agile software development is a methodology for undertaking software development projects in which incremental functionality is released in smaller cycles, and work is performed in a highly collaborative manner by self-organizing teams that embrace and adapt changes to ensure that customer's needs are truly met. Agile Software Development is not new, in fact it was introduced in the 1990s as a way to reduce costs, minimize risks and ensure that the final product is truly what customers requested. The idea behind the Agile approach is that instead of building a release that is huge in functionality (and often late to market), an organization would adapt to dynamic changing conditions by breaking a release into smaller shorter cycles of 1 to 6 weeks. Each cycle is called an iteration, or sprint, and it’s almost like a miniature software project of its own, because it includes all of the tasks necessary to release the incremental new functionality. In theory, at the end of each sprint, the product should be ready for a GA release. Agile methodology emphasizes real-time communication, preferably face-to-face, versus written documents and rigid processes. In addition, one of the most broadly applicable techniques introduced by the agile processes is to express product requirements in the form of user stories. Each user story has various fields including an "actor", a "goal" or task that they need to perform, an explanation
Most agile teams include all the people necessary to release software. At a minimum, this includes programmers and the group or team they are developing the application for, often referred to as their "customers" (customers are the people who define the product; they may be product managers, business analysts, or actual customers). Typically an agile team will also include a ScrumMaster, testers, interaction designers, technical writers, and managers.
What is scrum ? Scrum is really a project management methodology to facilitate agile software development, and enable the creation of self-organizing agile teams. A ScrumMaster is like a traditional project manager in the sense that he/she oversees the centralization of team communication, requirements, schedules and progress. But it is also very different because his/her main responsibility is to facilitate team communications and provide guidance and coaching, while removing impediments to the ability of the team to deliver its goals. Unlike a traditional project manager, the ScrumMaster doesn’t direct the team, because an agile team is based on the philosophy that a team member is committed to the other team members, not to a management authority.
Phases of an Agile Development Project using Scrum
Agile can be customized to fit each corporation in terms of size, iteration time, experience, etc, but typically an agile project will have these phases and milestones.

1. Kickoff meeting . Although this may seem routine for any project, with an agile development project this is a key element for getting the project launched. The goal of this meeting is to get everybody on the team together to review the product backlog (which is the master list of all requirements desired in the product that the product owner has drafted in the form of user stories), as well as the user personas (or the profile of each type of product user). In my opinion, this is a nicer and clearer way to introduce product requirements, because you really have more visibility into who is using the product, what are they trying to achieve and why, right from the beginning. A kickoff meeting usually lasts at least half a day with everybody together going over a “story writing workshop” -- in which stories are selected and then decomposed into programmable tasks and written in a white board together along with the time estimates for completion. If you have never seen a product backlog, you can check few samples here in QAZone . Sometime real customers are invited to the kickoff meeting as well to review and clarify the product backlog with the agile team. 
2. The next step in the sprint/iteration planning , in which the team collectively decides the sprint goal and sprint backlog (list of prioritized work to be done for that particular sprint). While the team is collectively creating the sprint backlog, stories need to be broken into either sub-stories or smaller tasks. During this collective team exercise you can really see the differences in project management (at least if you have a more rigid and formal waterfall like type of background), because there is no management authority that assigns tasks to team members. On an agile team all the members jointly associate level of difficulty to specific tasks, they can remove or add additional stories and/or tasks, and tasks are distributed among the team on a per volunteers basis. Unlike a traditional project manager function, the ScrumMaster role in this meeting is to maintain the backlog list in the meeting based on team feedback and consensus, make sure that nobody is volunteering for too many tasks to the point of overload, and facilitate the process of building personal commitment to the team.
3. Now that the Sprint planning is ready in the form of sprint backlog –which is dynamic and not set in stone, in fact it is very likely that it will adapt and change based on new stories, new tasks and/or impediments found throughout the iteration– scrum meetings will be set at the same time and in the same place on a daily basis. If you have never attended a scrum meeting, these meetings are very dynamic in nature and fast, never more than 30 minutes, and ideally 10-15 minutes. The objective is to go around so each team member can answer 3 questions: what have I accomplished since the last meeting (developed, tested, written, etc), what will I be working on next, and what are the problems, if any, preventing me from accomplishing my goals. These meetings are very important to make sure that the team moves towards achieving their sprint goal, or adapts/evolves and changes priorities and tasks as needed if new stories, impediments or new scenarios are encountered.
4. At the end of the sprint or iteration, usually a final acceptance meeting takes place, which is typically done by presenting what the team has accomplished, and by delivering a demo to the customer or to a larger audience.
5. At the end of an iteration there is also a sprint retro meeting , similar to a postmortem meeting at the end of other traditional projects, so the team gets together to evaluate what worked well, and what needs to be improved during their next iteration. 
   
   Top 3 things a QA professional should expect when an organization adopts Agile/Scrum development techniques
   
   Agile and Scrum are really changing the way testing is perceived throughout the project. Testing is not a phase at the end; it really is integrated throughout the entire iteration cycle, and it goes hand in hand with programming tasks. In my experience, when comparing a testing role performed within an agile project, or when using more rigid and formal approaches, I have found that with agile methodologies there is:
   

   1. Better communication and more collaboration among QA & development folks Gone are the days of "give me requirements" and "I will give you bugs
   2. and reports back"...QA folks are involved in the project from the start–along with their development counterparts–and they have access to the same information about product requirements and customer needs at the same time. This participation from the onset, combined with the fact that development and QA are part now of the same agile team, that they get together on a daily basis, and that they have full visibility into the tasks that each other is performing towards the overall success of the sprint, means better and more frequent communication among themselves. In addition, because the entire team meets everyday (development, QA, product management, etc) there are more opportunities for collaboration and more view points towards performing a particular task. Also the traditional "rivalry" that you may find among QA and development is eliminated because there is a single agile team now working to achieve a common goal.
   3. A new "peer to peer" relationship between development and QA personnel You should be prepared to "speak up" much more. Agile methodologies are all about building self-organized teams, and the voice of a QA engineer/tester carries the same weight than a developer. Think about it. In the daily scrum meeting each team member gets asked about their accomplishments (testing, developing, writing product documentation, etc), future plans, and obstacles, treating all of the members as equal partners. On an agile team the question of "how are we going to test it", is as important as "how are going to build it". In addition, because testers tend to be exceptionally good at clarifying requirements and identifying alternative scenarios, (especially when they have full visibility into product requirements and customer needs), they provide valuable input on design and architectural decisions throughout the project, right from the beginning. And these contributions translate into more respect and appreciation from their development counterparts.
   4. Looking for ways to optimize testing efforts will be a "must" You really need to think about automation, and planning and performing your testing efforts very efficiently. With shorter development cycles of typically no more than 6 weeks, and with builds being released all the time, testing efforts really need to be optimized as much as possible, because there is not separate test phase as such. One of the ways to achieve this is by leveraging both Exploratory Testing and Automated Testing throughout the project. Exploratory testing will come very handy when looking for bugs, opportunities to improve, and missing features. So you should plan on "exploring" the product at the beginning of each new sprint, or any time that there is a change done to a product feature within the sprint cycle. Similarly, you will need to plan and build your scripts to perform automated functional and regression testing within the sprint, because there is not enough time for performing thorough manual testing. One of the things to remember is that there are no really lengthy requirement document or specifications–other that the stories encapsulated on the backlog files–so the only way to make sure that each feature is fully developed, tested, and accepted by the product owner before counting it as "DONE!", is by using the sprint backlog as your own test plan (or writing a test case or script for every feature). Some teams are treating test case scenarios as entries that need to be added to the product/sprint backlog files for planning and tracking purposes. Another factor to consider is that development is much more heavily engaged in testing, so you should leverage this, and work very closely with them to plan and build more automated scripts that cover realistic scopes.
   5. If you enjoy being involved in product decision making, helping to shape how a product looks and works, and working in a collaborative environment that encourages team work and peer to peer relationships with your development counterparts, you will enjoy working on an agile project. On the down side, agile software development can be a little bit intimating at the beginning. Agile is all about embracing and rapidly adapting to changes–which might be hard to accept at the beginning–plus there are new processes, and new communication styles in place, so you might feel a little reluctant about it. However, once you get into the dynamics of agile software development, it can be a very fun and empowering experience!

http://www.stickyminds.com/article/agile-and-scrum-methodologies-testingqa-perspective

Scrum Meetings for Test

A year and a half ago I talked about how I was running scrum meetings with my team.  Since then, we've refined the process but have consistently held scrums on a regular basis.  Note that I'm not running a full Scrum system with sprints and product backlogs and such but rather just adopting the scrum meetings from that system.  Currently we have a team of 8 test developers.  We meet twice a week for 1/2 hour.  The format is simple. We go around the room and each person answers three questions:

1. What did I do since last time?
2. What will I be doing next?
3. Is there anything blocking my progress?

Doing this helps me keep the pulse of the team and--more importantly--helps the team keep its own pulse.  It also encourages the team to act as a team.  It is easy in software to put yourself into a silo.  You have a task and you disappear into an office for a few weeks to get it done.  You might talk to your manager about it, but you don't talk to people outside your dependency list.  The disadvantage of this approach is that you don't get help from others.  In a scrum meeting, everyone learns what everyone else is doing.  If someone has experience in something someone else is struggling with, they offer their assistance.  In this way, the team starts supporting itself and the overall output increases.
Along the way, we did things wrong.  We learned from our mistakes.  Here is at least some of that knowledge:

• Scrum is disruptive.  Programming is a matter of building up a mental map of the problem and then writing down the solution.  Once someone has this map built up they can work efficiently.  Having to change to another function is akin to swapping out the pages of the map.  Trying to start back up again requires paging everything back in which is slow.  Unfortunately, the human backing store isn't always stable and some paged out data gets lost.
• Don't run scrum too often.  During a time where you are burning down bugs, meeting daily can be useful.  During the rest of the time, meeting daily is too often.  There isn't enough new to report and, worse, it tends to become disruptive.  Perhaps someone who has done daily scrum during the development phase can explain how this is avoided.
• Scrum can't be seen as judgmental.  I found that without some calibration, team members felt that they were being judged by their progress.  If they didn't have something new to report, they felt it would be held against them.  Because of this, they didn't want to show up.  The solution was making it very clear that scrum meetings were all about status.  Being open is much more important than the level of productivity any individual was able to demonstrate.  The purpose isn't to take notes for the next review.  Being explicit about this helped.
• Don't get bogged down in details.  The natural tendency of engineers when faced with a problem is to solve it.  This is good, but scrum isn't the place for solving problems.  It is the place for surfacing them.  Solutions should be derived outside the meeting.  Keep the meetings to their scheduled time limits.  Don't allow discussions to get into too many details.  Instead, take a note and have a followup discussion later.

http://blogs.msdn.com/b/steverowe/archive/2007/08/13/scrum-meetings-for-test.aspx

Testing Services: Isolate, Automate, and Add Value

Summary:

Understanding what’s going on “behind the scenes” provides us both insights into test design and details on failure, which makes our work more valuable. Testers, who are likely already the subject-matter experts on their applications from a business perspective, become much more powerful assets for their teams when their level of technical knowledge of their application increases through the process of service testing. This is a win-win-win for the tester, the test team, and the project team.

Understanding what’s going on “behind the scenes” provides us both insights into test design and details on failure, which makes our work more valuable. For example, imagine an application with three tiers: a data tier, a web-services tier, and a GUI tier with a different developer for each. A tester who is running tests only through the GUI finds a defect and assigns it to the GUI developer. The GUI developer, after checking his code, realizes that the bug is not in the GUI and assigns it to the web-service developer who, in turn, assigns it to the database developer. As our GUI testers find bugs that exist lower in the architecture, defects will begin taking longer and longer to pinpoint, troubleshoot, and resolve. Tests that are one layer down at the service level can catch the issue earlier and eliminate debugging and handoffs.
Some application architectures make it inherently easier to move beyond black box GUI testing. Service-oriented architectures (SOAs) generally separate the GUI from the business logic, creating a “loose coupling.” This provides greater opportunities for testers to “plug” tests into individual services. Many tools exist to aid in this testing—some open source, others free, and some commercial. While having some knowledge of SOA concepts will help a tester get up and running more quickly on these tools, some of these tools are so easy to use that you can get started and get effective during the same day—no knowledge of web protocols is required.
The tools take care of much of the overhead involved in testing services, including generating the request and reading the response from the service. Adding parameters to run the test with different values is generally straightforward with these tools, which allows you to quite easily move from one test to a suite with boundaries and positive and negative tests, etc.. With the request-response cycle of SOA services generally measured in seconds or less, a large number of test cases can be run against a service in a short period of time.
An Example
To get things started, let’s consider this scenario: a simple web form that takes a zip code into a form and then responds with the city and state represented by that zip code. As intuitive testers, we talk to our development team and learn that this function is driven by an underlying service which uses Simple Object Access Protocol, commonly known as SOAP. The developer tells us that the service is called USZipSoap. All we really need to test this service directly is a copy of SoapUI (free and open source) installed, the location of the Web Services Description Language (WSDL) file, which is the contract in XML form that specifies exactly what the service does and how requests and responses are to be formatted, and the location of the service itself, commonly called the endpoint.
Creating a test to verify the basic function of the USZipSoap service is straightforward and can be accomplished by following these steps. In this example, we will send a valid United States zip code to the USZipsoap service and receive information from the service pertaining to the city, state, and time zone for that zip code.

1. In SoapUI, create a project. This will give you a place to view and store the WSDL as well as your tests.
2. Point SoapUI to the WSDL using the location provided on the website. In real life, your developer would provide the WSDL location to you. This step is not strictly required, but I highly recommend doing this as the WSDL tells you almost everything you need to know about the service.
3. In the navigator window, Soap UI will display the operations made available by the USZipSoap service. Operations are the useful functions provided by the web service. A web service can provide a single operation or multiple operations. In this case, the web service USZipSoap provides four operations. We will use the operation called GetInfoByZIP.
4. The SOAP protocol uses a request and response scheme in which a client makes a formatted request and the service returns a formatted response. At this point, you need to tell SoapUI to add a request by clicking the plus sign next to the name of the operation.
5. Add your data. Using the WSDL as a guide, SoapUI will create and format most of the request for you. You just need to find the XML tags indicating the data needed by the request. In this case, the tags are <web:USZip> </web:USZip>. You add the zip code to be sent to the service between these two tags. If you are using the zip code for Phoenix, AZ in your test, your entry would look like this: <web:USZip> 85040</web:USZip>. SoapUI Pro, the paid version of the tool, provides a form to enter any necessary test data into a request, but this is not necessary in our case.
6. Create a test case by right clicking on the request and selecting “Add to Test Case.” SoapUI will prompt you to create a new test suite into which you can create a new test case.
7. Add one or more assertions to your test case. Assertions tell SoapUI what to look for in the service’s response. There are over a dozen assertions available to validate things like proper response formatting, response time, SOAP faults, and data returned. In this case, we add two “simple contains” assertions to look for the text string “Phoenix” and the text string “AZ.” We also add assertions to validate that the response is valid in the SOAP format and it does not contain a SOAP fault.There are four assertions in total in this example.
8. Execute your test! As soon as the service takes your request and produces a response, SoapUI will indicate whether your assertions were all met and will also allow you to look at the response in case errors are indicated. In this example, all four assertions pass, so green indicators appear next to each assertion. You can see the formatted request and response in the top-center and top-right panels of the screenshot provided.
9. While SOA is used here as an example, it is definitely not the only architecture in which service testing can be applied. Making the transition from black-box testing involves selecting (or building) the right tool for your architecture, and there are tools available for a wide variety of architectures. The key is to find or work with your development teams to create the “plugs” into which your tool can send tests and data (inputs) and from which it can receive results (outputs).
   One (free and open!) test tool that can be used for service testing across a broader range of architectures and programming languages is FitNesse. FitNesse allows (or more accurately it requires) testers and developers to work together to generate test cases and to plug those tests into the application under test. While FitNesse generally requires more developer effort than tools developed for specific architectures, the level of developer effort required when using FitNesse is generally much less than with pure white-box unit testing tools, and once the developer has created the plugs into the application (known as fixtures in FitNesse lingo), the test team can easily add or modify a large number of test cases as their understanding of the application changes. FitNesse has native support or plug-ins to support Java, .Net, Ruby, Python, PHP, and a number of additional languages so it can fit a wide variety of application architectures.
   Moving from strictly GUI-driven tests to service tests has the potential to improve a team’s results, not only through greater test coverage and better long-term efficiency. It also improves the testers’ understanding of their applications. Testers, who are likely already the subject-matter experts on their applications from a business perspective, become much more powerful assets for their teams when their level of technical knowledge of their application increases through the process of service testing. This is a win-win-win for the tester, the test team, and the project team.
   Want More?
   You can find the WSDL, the definition of the zip code service, at http://www.webservicex.net/uszip.asmx?WSDL
   For more information about the USZipSoap service , check out http://www.webservicex.net
   Additional Images
   
   Figure 1. SoapUI is organized so users see the hierarchy of tests, the tester’s request, the service’s response, and the test results all in one unified view.
    
   Figure 2. After the tester enters the zip code in the request pane and clicks the green arrow, the response appears to the right, giving the tester a full view of both the request and its corresponding response.
   
   
   Figure 3. Test results, based on the tester’s assertions, appear at the bottom of the screen and are color-coded to quickly show whether the assertions were valid or invalid.
    

http://www.stickyminds.com/article/testing-services-isolate-automate-and-add-value

Don't Ignore the Smoke Tests

A few days back, a friend and I were chatting on Skype about test automation. I have a really hard time getting excited about automating a graphical interface, but one aspect of automating the browser I am excited about is the ‘really small smoke test’. These tests can be simple and concise, and because of that, low cost. Spending a few minutes of your time watching the smoke test run can be a fantastic way to defocus and notice some things about your product that may normally go unnoticed. Let's explore that idea a little bit.
Try It and See
A smoke test is a short test or set of tests that will run quickly and tell you something about basic functionality in your software. Generally these tests don’t do a whole lot, and that’s just fine.
Selenium IDE is a FireFox plugin that will allow you to record and rerun actions in the web browser. If you are not a programmer, the IDE can be a great tool to create smoke tests. Take a look at this tutorial for selenium IDE to create a smoke test in your browser, but try to do it for your software, not Amazon.
If you are more familiar with programming, you should be able to write something with the Selenium Webdriver framework relatively quickly.
Go ahead and run the test, click the go-button, and then walk away and get some coffee. When you get back, what do you have? A log file and probably nothing else, that’s what. If everything passed, you know very little about what the customer really saw during the test run. If something went wrong, then you have to go back, look at the logs, maybe read some of the test code, and then go to the software to figure out what happened. Sounds time consuming, right? It is.
Now, let’s try that one more time, but this time don’t leave! Stay in front of the monitor and watch what happens as your test moves along. This time when the script is done running, what do you have? You still have your log files, but you also have your observations and all it cost you was a couple of minutes. If the test completed successfully, you know why this time. If the test didn’t complete successfully, you were there to see what happened. Or maybe the test completed without error but you were able to see something else interesting while it was running that the smoke test wasn’t created to catch.
By staying and observing you have expanded this mimeomorphic (done the same way every time) script into a polymorphic-thought exercise that occurred in your brilliant tester brain. You can observe and learn so much more than a simple script ever could.
Focus and Defocus
These tests are so simple that you could potentially execute them yourself without any extra tools. In the world of software testing, we sometimes use focusing and defocusing heuristics to change our perspective. Jesse Alford spoke about these in a lightning talk at the 2013 Conference for the Association for Software Testers in which he compares focusing and defocusing heuristics to photography. Executing a test like this would be a way to focus in on specific detail of your software.
Creating a script can be a way for you to defocus your smoke test. Rather than concentrating on specific details of your test, you have the opportunity to broaden your perception and observe the software in a general way. In the words of Yogi Berra, you can observe a lot just by watching. While the test is running, you can be scanning the software, looking for interesting things that may normally be hidden under layers of focus.
You Can't Go Home Again
I have previously written in my personal blog about a test heuristic I call "You can't go home again." The essence of this heuristic is that running a single test many times is the same as running many slightly different tests. I think this is the case for two reasons: people have extreme difficulty doing a task exactly the same way every single time and there are innumerable variables for a test and knowing how they will affect the outcome is difficult at best. Using the smoke test technique I've described can encourage usage of this heuristic and may give you a more holistic product view. Two ways you could try this out at work tomorrow are watching the smoke test run many times yourself and purposefully defocusing each time, or, by having a few people watch the test run and sharing notes after about what they observed and learned.
The trick goes like this:
1 - Create the script
2 - Run the script
3 - Watch the script run
4 - Learn
5 - Share what you learned

How We BehaveHumans and computers do not behave or act the in the same way no matter how much some people wish they did. It is in our nature to change our actions to better fit the social and cultural situation. Computers and machines are completely unable to do this. They do exactly what we tell them all day, every day till we tell them to stop. They have no social understanding.
Harry Collins and Martin Kusch wrote a book together called The Shape of Actions in which they talk about the kinds of behaviors performed by humans and machines. The book calls these different actions polymorphic or mimeomorphic.
Polymorphic actions are social in nature; the action that occurs varies depending on the social context. Greetings are a good example of this. The way you greet another person can vary wildly based on social circumstance. Think about how you might say “hi” to a friend at school or a potential employer at an interview. Greetings are a pretty simple example, but could you imagine not changing behavior based on social experience?
How Machines Behave
Mimeomorphic actions are actions that are performed independent of  social context, these actions can be performed in an identical way each time. The way a paint spraying machine paints chairs is a mimeomorphic action. The machine may be able to recognize that there are different chairs, but it still paints the chairs the same way every time.

Figure 2. Automotive assembly line: An example of mimeomorphic action being performed on a large scale.
When you kick off an automated test, the series of steps executed are mimeomorphic actions. You defined a sequence and told the computer to perform those actions using some language and guess what, the computer is going to perform those exact actions the same way—every time. Your test suite will never notice things, it will never scratch it’s chin and say, ““Huh, that’s interesting,” and change its behavior to investigate. You do this though; it comes naturally, and for a good tester the urge is near impossible to resist.
Right Here, Right Now
Try this smoke testing technique out for a little bit and see how it works for you. Reframe how you think about smoke tests and what value they offer. Tell us what you find!

http://www.stickyminds.com/article/dont-ignore-smoke-tests

Ejercicios Diagrama de flujo - Propuestos 1

Primera serie de ejercicios propuestos para realizar diagramas de flujo.
Los demás ejercicios Parte 1   Parte 2   Parte 3   Parte 4   Parte 5   Parte 6   Ejemplo 1   Ejemplo 2   Ejemplo 3   Ejemplo 4   Ejemplo 5


 
1) Un hombre desea saber cuanto dinero se genera por concepto de intereses sobre la cantidad que tiene en inversión en el banco. El decidirá reinvertir los intereses siempre y cuando estos excedan a $7000, y en ese caso desea saber cuanto dinero tendrá finalmente en su cuenta.

2) Determinar si un alumno aprueba a reprueba un curso, sabiendo que aprobara si su promedio de tres calificaciones es mayor o igual a 70; reprueba en caso contrario.

3) En un almacén se hace un 20% de descuento a los clientes cuya compra supere los $1000 ¿ Cual será la cantidad que pagara una persona por su compra?

4) Un obrero necesita calcular su salario semanal, el cual se obtiene de la sig. manera:

Si trabaja 40 horas o menos se le paga $16 por hora

Si trabaja mas de 40 horas se le paga $16 por cada una de las primeras 40 horas y $20 por cada hora extra.

5) Un hombre desea saber cuanto dinero se genera por concepto de intereses sobre la cantidad que tiene en inversión en el banco. El decidirá reinvertir los intereses siempre y cuando estos excedan a $7000, y en ese caso desea saber cuanto dinero tendrá finalmente en su cuenta.

6) Que lea dos números y los imprima en forma ascendente.

7) Una persona enferma, que pesa 70 kg, se encuentra en reposo y desea saber cuantas calorías consume su cuerpo durante todo el tiempo que realice una misma actividad. Las actividades que tiene permitido realizar son únicamente dormir o estar sentado en reposo. Los datos que tiene son que estando dormido consume 1.08 calorías por minuto y estando sentado en reposo consume 1.66 calorías por minuto.

8) Hacer un algoritmo que imprima el nombre de un articulo, clave, precio original y su precio con descuento. El descuento lo hace en base a la clave, si la clave es 01 el descuento es del 10% y si la clave es 02 el descuento en del 20% (solo existen dos claves).

9) Hacer un algoritmo que calcule el total a pagar por la compra de camisas. Si se compran tres camisas o mas se aplica un descuento del 20% sobre el total de la compra y si son menos de tres camisas un descuento del 10%.

10) Una empresa quiere hacer una compra de varias piezas de la misma clase a una fabrica de refacciones. La empresa, dependiendo del monto total de la compra, decidirá que hacer para pagar al fabricante.

Si el monto total de la compra excede de $500 000 la empresa tendrá la capacidad de invertir de su propio dinero un 55% del monto de la compra, pedir prestado al banco un 30% y el resto lo pagara solicitando un crédito al fabricante.

Si el monto total de la compra no excede de $500 000 la empresa tendrá capacidad de invertir de su propio dinero un 70% y el restante 30% lo pagara solicitando crédito al fabricante.

El fabricante cobra por concepto de intereses un 20% sobre la cantidad que se le pague a crédito.

11) Calcular el total que una persona debe pagar en un llantera, si el precio de cada llanta es de $800 si se compran menos de 5 llantas y de $700 si se compran 5 o más.

12) En un supermercado se hace una promoción, mediante la cual el cliente obtiene un descuento dependiendo de un numero que se escoge al azar. Si el numero escogido es menor que 74 el descuento es del 15% sobre el total de la compra, si es mayor o igual a 74 el descuento es del 20%. Obtener cuanto dinero se le descuenta.

13) Calcular el némero de pulsaciones que debe tener una persona por cada 10 segundos de ejercicio aerébico; la formula que se aplica cuando el sexo es femenino es:

num. pulsaciones = (220 - edad)/10

y si el sexo es masculino:

num. pulsaciones = (210 - edad)/10

14) Una compañía de seguros esta abriendo un departamento de finanzas y estableció un programa para captar clientes, que consiste en lo siguiente: Si el monto por el que se efectúa la fianza es menor que $50 000 la cuota a pagar será por el 3% del monto, y si el monto es mayor que $50 000 la cuota a pagar será el 2% del monto. La afianzadora desea determinar cual será la cuota que debe pagar un cliente.

15) En una escuela la colegiatura de los alumnos se determina según el numero de materias que cursan. El costo de todas las materias es el mismo.
Se ha establecido un programa para estimular a los alumnos, el cual consiste en lo siguiente: si el promedio obtenido por un alumno en el ultimo periodo es mayor o igual que 9, se le hará un descuento del 30% sobre la colegiatura y no se le cobrara IVA; si el promedio obtenido es menor que 9 deberá pagar la colegiatura completa, la cual incluye el 10% de IVA.
Obtener cuanto debe pagar un alumno.

16) Una empresa de bienes raíces ofrece casas de interés social, bajo las siguientes condiciones: Si los ingresos del comprador son menores de $8000 o mas el enganche será del 15% del costo de la casa y el resto se distribuirá en pagos mensuales, a pagar en diez años.
Si los ingresos del comprador son menos de $8000 o mas el enganche será del 30% del costo de la casa y el resto se distribuirá en pagos mensuales a pagar en 7 años.
La empresa quiere obtener cuanto debe pagar un comprador por concepto de enganche y cuanto por cada pago parcial.

17) El gobierno ha establecido el programa SAR (Sistema de Ahorro para el Retiro) que consiste en que los dueños de la empresa deben obligatoriamente depositar en una cuenta bancaria un porcentaje del salario de los trabajadores; adicionalmente los trabajadores pueden solicitar a la empresa que deposite directamente una cuota fija o un porcentaje de su salario en la cuenta del SAR, la cual le será descontada de su pago.
Un trabajador que ha decidido aportar a su cuenta del SAR desea saber la cantidad total de dinero que estará depositado a esa cuenta cada mes, y el pago mensual que recibirá.

18) Una persona desea iniciar un negocio, para lo cual piensa verificar cuanto dinero le prestara el banco por hipotecar su casa. Tiene una cuenta bancaria, pero no quiere disponer de ella a menos que el monto por hipotecar su casa sea muy pequeño. Si el monto de la hipoteca es menor que $1 000 000 entonces invertirá el 50% de la inversión total y un socio invertirá el otro 50%. Si el monto de la hipoteca es de $ 1 000 000 o mas, entonces invertirá el monto total de la hipoteca y el resto del dinero que se necesite para cubrir la inversión total se repartirá a partes iguales entre el socio y él.

19) El gobierno del estado de México desea reforestar un bosque que mide determinado numero de hectáreas. 

Si la superficie del terreno excede a 1 millón de metros cuadrados, entonces decidirá sembrar de la sig. manera:

Porcentaje de la superficie del bosque y Tipo de árbol

70% pino

20% oyamel

10% cedro

Si la superficie del terreno es menor o igual a un millón de metros cuadrados, entonces decidirá sembrar de la sig. manera:

Porcentaje de la superficie del bosque y Tipo de árbol

50% pino

30% oyamel

20% cedro

El gobierno desea saber el numero de pinos, oyameles y cedros que tendrá que sembrar en el bosque,
si se sabe que en 10 metros cuadrados caben 8 pinos, en 15 metros cuadrados caben 15 oyameles y en 18 metros cuadrados caben 10 cedros. También se sabe que una hectárea equivale a 10 mil metros cuadrados.

20) Una fabrica ha sido sometida a un programa de control de contaminación para lo cual se efectúa una revisión de los puntos IMECA generados por la fabrica. El programa de control de contaminación consiste en medir los puntos IMECA que emite la fabrica en cinco días de una semana y si el promedio es superior a los 170 puntos entonces tendrá la sanción de parar su producción por una semana y una multa del 50% de las ganancias diarias cuando no se detiene la producción.
Si el promedio obtenido de puntos IMECA es de 170 o menor entonces no tendrá ni sanción ni multa.
El dueño de la fabrica desea saber cuanto dinero perderá después de ser sometido a la revisión.
 

21) Una persona se encuentra con un problema de comprar un automóvil o un terreno, los cuales cuestan exactamente lo mismo.
Sabe que mientras el automóvil se devalúa, con el terreno sucede lo contrario. Esta persona comprara el automóvil si al cabo de tres años la devaluación de este no es mayor que la mitad del incremento del valor del terreno.
Ayúdale a esta persona a determinar si debe o no comprar el automóvil.

The Impact of Automation on Development

Summary:

If you're thinking of introducing test automation to your process, you may have a plan for how it will affect your testers. But what about the development side of things? In this article, Linda Hayes takes a look at how automation changes the relationship between test and development organizations and offers a way to handle it.

It seems obvious that automation will affect the test organization. Less obvious—but no less real—is that it will also affect the development organization. In fact, when you choose to automate the testing for an application, your relationship with development changes completely.
Think about it. Manual testers only have to be able to interact with the application using the screen, keyboard, and mouse or other device. Automated test tools, on the other hand, have to interact with the software at a deeper level, thus exposing the inner workings of the code and perhaps uncovering problems that prevent or complicate automation. If you're not careful, developers might think you have suddenly transformed into an interfering busybody who is sticking your nose into their business.
This shift in your relationship with development can be handled in a bad way or a good way.
The bad way is that you find yourself struggling with gibberish object names, dynamic attributes, closed objects, custom classes, and other coding horrors that make automation a tale of suffering and failure. You curse the software and the developer it rode in on, because it is downright hostile to your test tool and creates all manner of extra-hard consuming time and resources already in short supply. You moan to management and get sympathy but no action. Curing all of your automation ills will take time that isn't in the schedule. You despair.
Needless to say, the good way is much better. You meet with development as early as possible, before implementation starts if feasible, and:
Sell them on what automation means to them. You will be able to deliver more test coverage faster, resulting in reduced turnaround time and fewer defects that will translate into fewer fire drills and fixes for them. Look for areas where you and development can share both the effort and the rewards, such as the automation of a build or smoke test, or perhaps even unit and integration testing. My experience shows that the greater the involvement of development in the automation effort, the more successful it becomes. Developers can get hooked on using automated tests and would much rather find defects before you do.
Show them how your test tool works, if you have one. If you don't have one, review your options with them to see if you can pick one everyone could use. Discuss your implementation plans, including the framework architecture and key components, such as the object map or repository. Explore possibilities for generating, extracting, or otherwise automatically acquiring the object repository. Discuss change management and maintenance strategies to keep your tests current with the code.
If you can engage them, developers can be creative and responsive to providing the elements of a successful test automation library. In a recent project, the developers with whom I was working offered to develop the entire framework so long as they could take advantage of the tests that were developed.

Educate them on what you need from the software—meaningful, persistent, and unique object names; access to object attributes, methods, and properties; standard classes at best or standard implementations of custom classes at worst; a stable and repeatable test data environment. Explain the implications for automation when these are missing. Discuss whether these issues exist in the application and what the effort and schedule will be to remedy them.
Overcome resistance to investing development resources in enabling automation by pointing out that the rigor and conventions required for automation also make the code more maintainable and transferable over the long term.
Be prepared to pull the plug on automation if you identify significant issues but no solutions are forthcoming. There is no reward for hard work if it doesn't get you anywhere. As they say, discretion is the better part of valor. If the application is a loser, face it and deal with it. Let management know that automation is not feasible and either look for another application to automate or wait until the changes you need can be made.
On the bright side, my experience shows that the more developers understand about automation, the more testable the applications they build and the more willing they are to cooperate. Even doing it the good way doesn't mean the outcome is guaranteed, but it will save you a lot of time and grief because you will find out sooner rather than later whether your relationship with development will survive automation.


http://www.stickyminds.com/article/impact-automation-development

Why Algorithms Matter

New programmers often don't appreciate the power of algorithms.  They have one criteria for a piece of code:  does it calculate the right answer?  If it does, they go with it.  Every CS program has at least one class on algorithms.  However, if you are a self-taught programmer, you may not have been exposed to the ideas.  This article stems from a conversation with a friend who is trying to learn programming on his own.  This is a simple introduction to the concepts of algorithms and an explanation for why you might care about them.  Most of the time the programs we write deal with small enough data sets and fast enough processors that our choice of algorithms doesn't make a material difference.  However, with a large enough number of items the choice of a poor algorithm can make a tremendous difference.
Here is an example.  When I was first programming, I wrote a Java servlet to access a database of all the DVDs we were testing.  This was very early on and there were only a few hundred DVDs in print.  The servlet had one page which would display each of the DVDs along with some vital information in a table format.  I used simple string functions to build up the HTML describing the table.  With 200 discs, everything worked fine.  We were buying all of the DVDs available at the time and eventually our database grew to encompass over a thousand discs.  Somewhere along the line, I noticed that bringing up the "all discs" page was taking a really long time.  It took something like 3 minutes to display the page.  I did some investigation and figured out the problem.  Each time I concatenated another piece of text or table markup, the entire string was copied to a new location along with the new information.  The same string was being copied tens of thousands of times.  The solution was to move to using a StringBuffer object instead of the built-in strings.  StringBuffer utilizes a better algorithm than does string.  The time to render the page dropped from 3 minutes to 30 seconds.
Before beginning, we should define what we mean by algorithm.  An algorithm is a set of instructions for accomplishing a task.  Everything we write in software is an algorithm of some sort but we usually reserve the term for the parts of our programs that accomplish particularly interesting tasks.  More often than not, the reference is to reusable tasks like searching, sorting, etc.  These algorithms are language and platform agnostic.  That is, the concepts will be equally valid on virtually all programming languages, operating systems, and processors.
If we're going to compare the performance characteristics of different algorithms, we'll need some benchmark to measure them against.  We could just run the algorithms and see how long they take, but this only tells us how they behave on that particular data set.  Instead, we use something referred to a "Big-O" notation* to describe the runtime characteristics on a function.  This describes how the behavior of the function (measured in time in all cases in this article) is affected by the size of the data set.  For each value we add, how does the performance react?  If we know how long it takes to do something to a sample set of size 1, can can then compare the time it takes for bigger sample sets.  The notation is as follows:  O(1), O(n), O(n^2), etc.  O(1) indicates that the time is constant--that is, it is unrelated to the size of the input.  O(n) says the time it takes increases linearly with the size of the input.  O(n^2) indicates that the time grows as a square of the number of items.  An algorithm which is in the class O(n) will run faster than one in the class O(n^2).  For example, if it took 25 instructions to do the work for 1 item, an O(n^2) algorithm would take 250,000 instructions for 100 items.  An O(n) algorithm would take just 2,500.
Let's look at some example algorithms and how they affect running time.

Searching for a Phone Number

Think about looking up someone's phone number in a phone book.  How do you do that?  We could just start on page 1 and look at each entry to see if it is the person we are looking for.  This will take a while.  If we consider just pages, not actual names, we'll have to examine and average of half the pages before we find the number we're looking for.  In the worst case, we'll have to look at each page.  My phone book has 969 pages in the residential listings.  That means it will take us an average of 485 pages to find the name we want.  If we're looking for Fred Zylstra, it's going to take us 969 pages.  This is an O(n) algorithm.  This is how many programmers search for an item in a list but this isn't how anyone actually searches in the phone book.  We open to a page in the middle and if what we're looking for is higher in the alphabet, we turn half way toward the front of the book.  If it is lower, we turn half way toward the end.  We keep repeating this process until we find the name.  This algorithm will find the name we're looking for by examining at most 10 pages.  This is O(log2(n)).  Here is a graph of the two functions:

The green line is the linear algorithm.  The red line represents the way most people actually search.

Calculating Fibonacci Numbers

This one is slightly less real world but it demonstrates well the advantage of algorithms.  Fibonacci numbers are a series of numbers where each number is the sum of the two previous numbers.  Formally, F(n) = F(n-1) + F(n-2) where F(0) = 0 and F(1) = 1.  These numbers get large really quickly.  The 10th number is 55.  The 30th number is 832,040.  The 100th is 354,224,848,179,261,915,075.  There are two ways to calculate a Fibonacci number.  This sequence is often used when teaching recursive programming.  The recursive algorithm looks something like this:

UInt64 CalcFibonacciRecursive(UInt64 number)
        {
            if (number == 0) return 0;
            if (number == 1) return 1;
            return CalcFibonacciRecursive(number - 1) + CalcFibonacciRecursive(number - 2);
        }

There is also a non-recursive algorithm.  It looks like this:

UInt64 CalcFibonacciIterative(UInt64 number)
        {
            if (number == 0) return 0;
            UInt64 value = 1;
            UInt64 F2 = 0;
            UInt64 F1 = 1;
            for (ulong i = 1; i < number; i++)
            {
                value = F2 + F1;
                F2 = F1;
                F1 = value;
            }
            return value;
        }

The recursive solution looks a lot more elegant but how does it perform?  let's try calculating F(40).  I tried higher numbers but even F(50) takes minutes to calculate

Algorithm	Elapsed Time (ms)
Recursive	5523
Iterative	<1

The race isn't even close.  Why the big difference?  Let's examine what is going on here.  To calculate the 5th Fibonacci number using the recursive algorithm, we have to calculate F4 and F3.  To calculate F4, we have to calculate F3 and F2.  But wait.  We already calculated F3 directly.  Unfortunately, we end up doing it again.  Here is the complete tree of actions for calculating F5.  Notice all of the redundant work.

If you look closely, you'll see that this is basically a binary tree.  Each time we increment the number by 1, we double the amount of the work we have to do.  We have to do 2^n amount of work.  Thus, the recursive algorithm is O(2^n) whereas the iterative algorithm is O(n).  Here is the graph:

Summary

As you can see, the choice of algorithm can have a drastic effect on the running time of your program.  This is why it is wise to have some familiarity with algorithms when you are programming.  Determining the Big-O value for an algorithm can be complex.  Luckily, any algorithm book will tell you the classification of an algorithm so you can look it up instead of having to dust off your math skills.  Spend some time studying an algorithm book or just do some web searches when you go to use one.  Pay attention to these values.  They will be important some day.
I tried to make this easy to understand but if something isn't clear, please ask.  I'll be happy to explain.

*Big-O notation is actually a misnomer.  What computer scientists call Big-O notation is more properly called Big-Theta notation.  Big-O describes the upper bound, but that bound doesn't have to be close.  We could just call all of our algorithms O(2^n).  While accurate, this doesn't help us much.  Rather we'd like to know what the lowest Big-O value is which still describes the function.  That is Big-Theta.

http://blogs.msdn.com/b/steverowe/archive/2007/08/24/why-algorithms-matter.aspx

On Certification, or Something Like It

Summary:

Jon Hagar writes that testers need to thoroughly understand what certification is all about. As a profession, we need to understand what these pieces of paper mean, the promises they can keep, what they may lead to, and some reasonable expectations for them.

When I started developing and testing software in the late 1970s, there were two kinds of technical staff: “hardware people” and “software people.” Perhaps we had a few other labels like hardware engineer, programmer, and software engineer, but in practice, there were only two kinds.

In my first job in computer programming and while I was still in school, I was a junior business analyst, systems person, programmer, data analyst, and tester. I did it all (under strict supervision and mentoring). We did not have titles and divisions, such as someone being referred to as a “tester.”

In my second “programming” job and after completing a degree, not quite two years later, I think I might have been called software engineer, but nobody was too sure what that was, and my main task was performing structural testing of code. I learned testing (and programming) from the first generation of software people. Most of us had college degrees, but not everyone had formally gone to school, and our degrees were in things like math and physics. We programmed. We tested. We learned. We read the few books on the subject (e.g., Elements of Style, Programming in FORTAN, and the Art of Software Testing). We did not worry about titles or labels—much.

In the thirty-plus years since, the industry has evolved. It is not clear to me if this evolution is entirely a good thing, but it probably contains a mix of both pluses and minuses. Overall, things have improved to some degree.

Enter TestingThe first generation of testers has retired; some are still alive. Those of us who became the second generation have aged and started thinking about how we can improve the pluses of our industry. We have worked to place more education into colleges and in our professions. Items like the IEEE SwEBOK (software engineering book of knowledge) appeared with defined terms for software testing. College programs in software engineering were developed, and during the 1990s and 2000s, hundreds of college classes on software testing became available.

Additionally, IEEE and ISO standards were created in software, systems, and testing, although companies used such standards with mixed results. The industry went from worrying about just creating software to producing “good enough” software. The standards that were developed recognize the value of testing.

Conferences in software testing appeared, some of which live on today, and education in software testing became readily available. We even have established associations, such as the Association of Software Testing (AST).

At the same time as these across-the-board improvements in information about testing, there has been a second track: an explosion in certificates, certification, and even college degrees with a focus on testing. I find that explosion surprising and, perhaps, a bit puzzling.

I have to ask “Does knowledge from a skill list (from a book or standard), degree, certificate, or certification mean that you are a good tester?”  “Does a well-practiced test skill mean that you are a good employee?”

Unfortunately, the answer to both of these questions are “no.” This has led to confusion and debate in the test industry with people expecting great things just because a person has one of these “pieces of paper.” A practiced skill should not be confused with a piece of paper. Pieces of paper come in a variety of forms, as defined here:

• Certification (including testing)
• Certificate (academic meaning you passed a specific class or test)
• Degree (academic meaning you passed a series of classes in a program of classes)

There is a debate, even a passionate argument, about these “pieces of paper” in software testing.

Does having any of these mean you have a skill? Pretty much anyone in any industry would answer “no,” since most of these are focused on knowledge. You must practice with knowledge to have skill. You must learn and grow. What these pieces of paper mean to me are that you have an interest and have shown some ability to learn. This is true in almost every profession and activity. For example, you can read books on snow skiing. You can pass tests of knowledge about skiing. But until you try to practice skiing, by doing it, you have no skiing skill. In fact, for most people skiing practice takes years or a life time to get to be a good (aka, expert) skier.

As a profession, we need to understand what these pieces of paper mean, the promises they can keep, what they may lead to, and what are some reasonable expectations for them. Each of these pieces of paper has a plus side and a minus side. For example, a degree means that you can learn to someone else’s expectations of knowledge, but on the minus side many people with degrees (some Ph.D. students that I’ve known) think they have skill and know it all.

A similar situation exists for people that get certifications or certificates. Further, each piece of paper may have the benefit of exposing the student to knowledge and learning. However, the bad side is this: once people think they know something, they often become close-minded, which is bad.

What to DoAs an industry, we should define the knowledge base, skills, styles, etc., as a move forward. These should be done by the different philosophies (aka, schools) of testing. These will become the basis for people to learn, practice, and develop. It is not good to call people “zombie” testers, say that a standard is “toxic,” or critique degree programs unless you have a solid alternative, can demonstrate with experimental information and data when these statements are true, and engage in meaningful dialog about improvement in the industry.

Next, just because a person has a certification, a certificate or degree, does not mean that I expect much from that person. For example, a person with a degree in massage therapy can help some minor medical ailments, but I am not going to expect of this person nor bash them because they cannot do brain surgery. I would not expect my son the medical student (with many degrees behind him) to be a brain surgeon either.

Each philosophy group in testing needs to work on a knowledge and skill list, a path of progression, specific development paths, as well as practice activities to get software testers to progress. As a hiring manager, I have used the pieces of paper as a quick filter on reading resumes. Once I found people I liked, I would talk to them and see where they were in their practice of software testing and where they wanted to go. If they had passion for the practice of testing and some skill, I’d hire them. If they told me they knew it all and what I was doing was somehow “wrong,” I usually did not hire them—but might have in some rare cases. If they did not want to practice and only wanted a job, I definitely did not hire them. For many companies and hiring managers, degrees, certificates, and certifications play a role in getting a job; so many testers may want to get such pieces of paper to aid themselves in finding gainful employment. However, I encourage you should not to read added value into a simple piece of paper, especially since testing is a professional practice to be worked on for many years.

My goal today was not to settle the discussion, but to stoke it while setting some expectations for civil discourse. Remember, our profession is maturing, but it is not mature. Let’s keep talking.

http://www.stickyminds.com/article/certification-or-something-it