Key Takeaways from Baltimore Innovation Week’s Session on Lean Product Design for Startups

By Design, MVP, Product Design, TestingNo Comments

Bytelion was thrilled to partner in Baltimore Innovation Week 2019 (BIW19), hosting a session titled, “Lean Product Design for Startups”. Since inception, over seven years ago, Bytelion has been a proud supporter of startups in the Greater Baltimore area and beyond. As an everyday practitioner of agile methodology for software development, the team at Bytelion has spent countless hours taking a “lean” approach to designing and developing software and applications for both startups and well-established businesses.

Baltimore Innovation Week 2019 logo

Last night, Bytelion’s Head of User Experience, Marc Hausle, led the session for a large group of BIW19 attendees at Clark Burger in Harbor East. If you were unable to attend the event, here are some of the key takeaways from the session.

What is Lean Product Design?

Clark Burger with people

Founders and entrepreneurs commonly will fall in love with an idea or a “unicorn vision” they have for the business, which is usually based on their untested assumptions. When they build based on these unvalidated assumptions they are more likely to waste valuable time and resources building something nobody wants. The goal of lean product design is to avoid this waste by focusing efforts on only building what you can validate as required based on reliable data and/or customer feedback. Lean product design recommends building something fast so you can begin to test hypotheses against real user feedback.  

Move Fast and Iterate

Once you start gathering feedback and performing other research it is critical to document everything as well as clearly defining how to measure success for both the business and the users. By building what is commonly referred to as an MVP, you can test your hypotheses, validate your assumption or pivot if necessary. Don’t try to be perfect in the beginning and be ok with being wrong as it will allow you to make necessary iterations early before you go too far down the wrong path.

The Design Process

When you are in the design process, you’ll want to create a prioritized list of potential features. Focus on first building the things that you know will have the biggest impact on delivering your product’s value proposition.  “Fall in love with the problem you are trying to solve as opposed to particular features or solutions you are building”. You’ll be more successful if you stay focused on the problem and are willing to iterate towards the developing features that will best solve it and avoiding those that don’t.  Marc also introduced the concept of time-boxing for certain design activities so that you don’t waste any unnecessary time or energy trying to perfect something before you test it.

When taking the lean approach there are a number of practices you can incorporate into building the best user experience for your product. For example, Marc discusses user personas and user journeys, red routes, information architecture, user flows, hand-drawn sketches, wireframes, and prototypes. These practices are all ways to gather and incorporate data garnered from real user interactions and testing. Each exercise also builds off of the other and makes the next step in the process easier. It is also easier to go back and improve and iterate on past versions of what you have done.

Lastly, he discussed design sprints which are a unique five-day process for validating ideas and solving big challenges through prototyping and testing ideas with customers.

Feedback is critical!

If you were able to attend the event we thank you and would love to get your feedback. 

Or if you didn’t make and you are interested in learning more about Lean Product Design please feel free to contact us for a free consultation to see if it makes sense for you. Contact Marc directly via email at 

Automation 101 with Selenium IDE

By TestingNo Comments

Testing is a vital part of the software development lifecycle for any team, from small to large. Testing early and often ensures that bugs are found and fixed promptly, preventing them from snowballing into costly issues down the line. An important part of this process is regression testing or making sure that present functionality isn’t broken by the introduction of new features. Because of the iterative nature of software development, regression test suites tend to grow with every update, and it can quickly become tedious and time-consuming to manually perform all of the test cases. 

This is where automation testing comes to the rescue! By using automation software, such as Selenium, regression testing becomes as simple as pressing a button and letting the computer do all the work. This saves time and frees up resources to focus on other issues. However, making the leap to automation testing can be a daunting task for someone who only has experience with manual QA methods. If you find yourself in that boat, then you’ve come to the right place! In this article, we will learn how to use the Selenium IDE plugin for Google Chrome to create and execute our first automated test case!

Before we get started, download the Selenium IDE plugin for Chrome here:

Creating Your First Test Case

Once you have downloaded Selenium IDE for Chrome, before we can create a test case, we will have to create a new project. Start by launching Chrome browser and clicking on the Selenium icon in the top-right corner. Once Selenium IDE has loaded, you should see a window that looks like this:

Click on ‘Record a new test in a new project’. Name the project whatever you like – I will be naming mine ‘Selenium 101’. After choosing a name, you will be prompted to enter a base URL for the project. For this exercise, we will be using the following URL:

This page was created as a resource to help people learn automation testing, so it is perfect for our purposes. Enter the URL and click ‘Start Recording’.

A new instance of Chrome browser should be launched with the base URL entered. You should see the following banner somewhere on the page:

For our first test case, let’s automate the completion and submission of a basic form. While Selenium IDE is recording, click on the link labeled ‘Fill out forms’. On this page, you will see two forms side-by-side. Fill out the leftmost form with your name and a message, and click ‘Submit’. You will notice that Selenium IDE is recording what you do and translating it into steps for it to recreate later. It should look something like this:

Click on the red square icon in the top-right corner to stop recording. At this point you will be prompted to name the test case – I chose to call it ‘Submit Form’. 


Now that our first test case is made, let’s see it in action! Click on the ‘Run current test’ icon at the top of Selenium IDE (or press ctrl+r). You should see a new Chrome browser instance open and automatically navigate to the base URL, proceed to the ‘Submit Form’ page, enter the values that you chose, and then submit the form. Once it’s completed, you will see a message in the log displayed at the bottom of Selenium IDE indicating that the test was completed successfully (unless it failed for some reason). 

It’s that simple! Now, instead of having to fill out forms manually over and over again, you can automate the process and let the computer do the work for you! 

Now that you’ve gotten your first test case out of the way, I encourage you to explore the website some more and try to create some more automated test cases. The page has several different links that have a variety of web elements for you to play with. As you experiment, take note of how what you do is translated into steps in Selenium IDE. 


This is just the tip of the automation iceberg. While the record-and-play function of Selenium IDE is great for simple tests like the one covered here, there are far more possibilities with creating your own custom test scripts. While that is outside the scope of this article, you can start familiarizing yourself with the scripts by exporting your test cases from Selenium IDE into test scripts. You can choose from a few different programming languages, including Java and Python. This is a great way to start automating some simple test cases while also preparing yourself for bigger and better things with custom test scripts!

Why Do I Need A QA Engineer?

By Agile, Development, Innovators, Startup, TestingNo Comments


Why is a Quality Assurance engineer necessary for development of software? Couldn’t I simply get my developers to QA/review their own work? Could I get get developers to review each other’s work? These are all questions that I have come across at some point or other from multiple people.

Before I answer, let’s briefly summarize what QA is:

What is QA?

QA is the analysis of functionality and overall appearance of your site / app. This can include (but is not limited to): Cross-browser testing, screen resolution compatibility testing, grammar, spelling, functionality.. the list goes on. QA is ideally approached from multiple angles.

When testing a simple ‘contact us’ form, the QA engineer would ensure that the email field ensures that a valid email address is entered, the name fields do not accept numbers, the name fields do not accept special characters, ensuring fields have limits so malicious users cannot overwhelm your system by entering large amounts of characters, etc.

QA Responsibilities

A QA engineer’s responsibility is to review each feature before it is released, suggest edits to issues and approve code before it reaches the product owner. Therefore, not only is the entire site under the QA engineer’s watchful eye, each part of the site is analysed during its creation.

Why is QA Necessary For Development?

As you can see above, the responsibilities for QA are laborious. A dedicated amount of time by someone who knows your system is needed. Not only is QA needed for each release, regular testing across your site is critical to catch issues that may affect it from external sources.
Example: Still running flash player on your site? Browsers are discontinuing support since it is considered deprecated technology. Your QA Engineer will (/would) know this.


Can Developers QA Their Own Work?

The QA engineer should be a consistent team member, part of daily scrums and involved in feature development. Developers however,are assigned a particular module of the whole system and aren’t truly aware of the system as a whole. Not only is development typically modular, a developer has a completely different mindset and thought process. He/she may not consider all the scenarios a tester would consider.
They can definitely code review their peers but QA is a different game entirely.


Want to find out more about software development practices? Check out our Blog!
Bytelion is a full service software development firm. Check out the rest of or contact us to find out more.

What’s the difference between Smoke Testing & Regression Testing?

By TestingNo Comments

You can prevent mistakes found within your application through Quality Assurance (QA) testing. This step is critical for any software project as it helps your team produce the best product before delivering it to the client. In this article, we will discuss two types of QA tests. If you are curious about QA and how it can help your project be sure to read our article Why is QA Essential for your Project?

What is a smoke test?

smoke testing

A smoke test is a quick run through of a site;  it focuses on critical functionality to ensure the site can perform basic features.  The primary features are often called red routes in the software industry.

It only takes a couple of minutes to complete, up to ten minutes at most. What is great about smoke tests is you can perform them either daily or every other day.

Smoke testing came to software testing from a similar hardware test -where the device passed if it did not catch fire (or smoked) the first time it was turned on!

For software purposes, an example of smoke testing could be for a hotel reservation site. In this smoke test example, the tester would ensure the user will be able to sign up, change your password, create a booking, and be notified.


What is a regression test?

A regression test is an in-depth, thorough examination of a site. It tests all of the complex user stories and detailed nuances of the site, therefore; they may take many hours to complete. Performing a regression test ensures any changes made did not negatively impact any of the functionality of the site. A regression test will cover every feature, new and old, along with bug fix checks to make sure bugs did not reappear in the software.

When should I perform a smoke test or a regression test?

You should frequently perform smoke tests. Performing a smoke test immediately following a push to production acts as a way to ensure the high-level functionality of the site is working.

In my experience, you should conduct regression on a per sprint (generally two weeks) basis. A regression test should occur immediately before a push from a testing environment to production. This will ensure that the push to production will not negatively impact the functionality of the site. If we use the previous hotel example, a regression test will check not only the basic items that make the site work but allow us to test more complicated use cases for bookings, such as multiple locations, discounts or promo codes, and international tax law.

Just a quick note about regression testing and developers… Never mix the two.  Developers are too close to the problem to test properly, and it takes them out of their development zone. Developers need to spend the majority of their time developing, rather than doing in-depth testing.


Final Thoughts:

Now that you know a thing or two about the major types of user testing, you can apply the proper technique when you need it! Having your developers conduct smoke testing on their code helps them move along faster with their development, especially in the beginning of a project.  However, you need to be able to invest in regression testing on a routine basis or components of your application will begin to break. This small investment will allow you to fix things quickly and efficiently.

Have any questions about testing?  Our knowledgeable quality assurance team is happy to help! Please contact us

Kathleen was featured in a previous article about our interns.


Why is Quality Assurance Essential for your Project?

By Testing2 Comments

Why is Quality Assurance (QA) an essential step for your software project?

Picture this. Your website or app has finally launched after long and tedious months of development. You are ecstatic with how beautiful the website looks, and so far, it has been working fine… but then… you get a message from a furious user who is complaining that the app does not function correctly on their device.  Or, perhaps you receive a notification about a new change the development team just made and it is causing core features to stop working on the site.

You find yourself in a frenzy trying to figure out how you are going to get your site or app back up and running without losing or upsetting too many customers. Good news! Take a deep breath; you can avoid all of this chaos with Quality Assurance.

Software Bugs, the Inevitable Foe

It’s time to face the unfortunate truth: Software bugs are inevitable; no matter how awesome the development team is, there will always be bugs. According to Techopedia, a Software bug is a problem causing a program to crash or produce invalid output. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results. Preventing bugs is extremely difficult.  If you are running with a very lean team (as are almost all companies on a budget), you might not have time for complete test case development, or you aren’t completing extensive design reviews. Bugs can also happen because of dependencies on other systems.   


But who can Save my App from all of these Bugs?

Who exterminates these software bugs? Our heroes, the Quality Assurance Technicians (QA testers) find the bugs, so your users do not come across them unexpectedly. No one likes it when their app crashes or if the page they are browsing stops responding. The purpose of QA testing is to find and report these issues so they can be eliminated before the software reaches the user.

QA testers mostly do one of two things. They either perform regression testing or go through new features of the site looking for bugs. The regression tests help ensure the functionality of the site does not get diminished with any changes that are made to the site. Before new features can be added to a site or app, they need to be thoroughly tested. All of this QA work eliminates the negative interactions for the user.


Final Thoughts:

QA is a necessity for your next project. Without QA, you should expect a ton of negative feedback from your users. While developers usually test their own code, they don’t have time to review everything. QA testers are there to ensure you and your users have an almost flawless product and fantastic user experience. Your users will thank you for a beautifully designed product that works seamlessly. An app without major bugs will delight your customers and build an honorable reputation for your brand.

From all of us here at Bytelion, we wish you the best of luck when you are exterminating your software bugs!

Kathleen was featured in our intern blog.
Need QA for your future project? Contact us at 


Wireframing for Startups and Corporations

By Design, Development, Estimation, MVP, Software Lifecycle, Testing, Tips & Tutorials

It’s Cheaper!

If you are interested in building bad software with bugs and lots of mistakes, then this article isn’t’ for you.  If you are interested in moving your development team along faster, saving money and building a better product for your user, please read on.  When Bytelion wireframes, it allows us to see the application.  The final wireframe summarizes all of the thoughts held in people’s minds and ensures that everyone not only understands how the application solves your problem but more importantly, it quickly and easily helps others understand what you are thinking.  Wireframing is critical to all lean departments and especially technology start-ups.

How does wireframing save you money?  Simple, it ensures that you have the right workflows up front. In this hypothetical, imagine if you omitted an essential feature on a page that was pushed to production.  To find the bug  for this feature, you have paid for:

  • UI Design (8 hours)
  • UI Implementation (8 hours)
  • Backend Implementation (12 hours)
  • Quality Assurance  (4 hours)
  • Total=32 hours

If you had wireframe the issue, the bug would have cost you

  • Wireframe (2 hours)
  • Total=2 hours

Stealing off of NASA’s slides and making some slight modifications, the blue arrow indicates where wireframing is in the bug detection value stack.  Used early, it is an awesome tool.


Value of catching bugs in wireframes.

NASA value of catching bugs in wireframes.

If you are a startup, every dollar you is extremely expensive and must be spent wisely.  Why focus on fixing bugs in production when you can solve most of your problem in the first two weeks?

To read more about NASA and bugs, check out.

Too Many Wireframe Tools… Which One Should I use?

There are many tools on the market. We have used all of them. I could write pages upon pages of why some systems are better, but here (in no particular order) are some of the tools that are best.

MyBalsamiq – The desktop was by far the best user experience, but its ability to not sync with an online version make this not as usable because customers and team members email different versions of the application. Because we work in a distributed environment, this didn’t work for Bytelion.

Gliffy’s integration with Atlassian’s JIRA + Confluence suite makes this tool amazing.  However, it is so inflexible that maintaining a working wireframe falls apart.   Sorry Atlassian, I still love you.

Azure – Bytelion loved the framework, and it was our primary for years, but found the product confining regarding our on online integration needs.  It slowly came out of favor and was replaced by…. our new go to.

Pidoco – Yes, this is the wireframe company that you probably didn’t hear of.  We didn’t either until we scoured the internet and tested everything we could.  This tool is our new standard.  There are three simple reasons by we love it:

  • Single Page App (SPA) is super fast and responsive.
  • Extremely flexible Workflow System…. THIS IS THE BIG ONE….  If you want to change a workflow, you can configure a workflow in a few minutes and keep different versions of the workflow.  This is ideal for rapidly testing different UX interactions.
  • Pages can be templated.  If a designer changed the header in one location, the header modified for the entire app.

Note, we have no association with the Pidoco company at all.  They did, however, chose to engineer their product well and didn’t take shortcuts.  We respect that and think that they will come out on top of they can build enough market share.

Selecting Red Routes First

Now that you know what tool you are going to use after testing them all :- ) you have to build your wireframes.  For an application, you have different use cases for what a user needs to do.  For example, if you are creating a recipe app, you would need a user to do the following:

  • A user needs to create an online profile
  • The user needs to buy other recipes from other people.
  • User needs to be able to generate their custom avatar online
  • The user needs to be able to post recipes to their Facebook account.

Of these use cases, you only want to select the most critical to making the application work. We call these red routes. In our scenario, we would only want to use these:

  • The user needs to be able to post to their Facebook account.
  • The user needs to buy ABC product.
  • A user needs to create an online profile
  • User needs to be able to generate their custom avatar online

We keep it simple and only wireframe the stuff we need.

Don’t be Lazy – Keep Your  Wireframes Current!

Once you create a set of wireframes that accurately reflect what you are trying to do, it is critical to keep it.  These wireframes will come up over and over. For example, if you are designing an aspect of a project that you have not touched in 6 months, having your wireframes current with the design make this is a snap.  Thankfully, Pidoco makes this easy to do.    It takes discipline to do this… keep up the discipline.   It is cheaper, better, and more fulfilling for you in the long run!



Lean Smoke Testing

By DevOps, Software Lifecycle, Testing


You are trying to develop a new application and want to ensure high developer output while installing quality control.  Before installing build servers, setting up testing scripts, etc., make sure that you have proven your market first.  The easiest and cheapest way to create quality in your application is via the developer run smoke test. A lean smoke test is a basic test of the system to ensure that 80% of the application works.  The goal of smoke tests are to ensure a high-quality routine deliverable at very low cost.  This is not a substitute for more complex testing which requires more infrastructure.

Setup Time

5 minutes to set up a template at the start of a project. 5 minutes to update at the end of every sprint with either new tests or to reduce tests. If the tests take more than 10 minutes, then they are no longer smoke tests, they have moved into the realm of regression testing.


  • Software Developers  You do not need nor should you have a tester or PM run your smoke tests.  The dev team needs to be in the repeatable habit of ensuring quality without the laborious burden of detailed regression testing.
  • Scrum Master /PM Ensure that the Smoke tests are accessible via the web to every team.


For example, if the team is building a ticket sales system, a simple action or a set of simple actions like:

  1. User Looking For Events
  2. User buys tickets
  3. User prints tickets

Ideally, if you have more than one person, you will assign them a different platform, so they are routinely testing it against different operating environments to find problems before they arise.  For web development, this could be IE or Firefox.  For mobile, you could have them alternate between iOS and Android.


Like all things, it depends.  Ideally, any time a team conducts development, a smoke test would be completed.  This, however, isn’t always a good idea and introduces waste, especially if you are building your MVP.  A more realistic scenario would be time/effort based.  As a rule of thumb, every 80 hours of development and deployment cycle time should be followed by a smoke test.  A team may elect however to run smoke tests more often if they are trying to debug a set of problems.  Additionally, if you enter production, the product owners may require a zero bug atmosphere.  If this is the case, you need to have the cost vs. benefit conversation for smoke testing.

Time Ratio

80 hours x 60 minutes per hour = 4800 minutes = 10/4800 =  0.2% of time for devs to test


Client Discussion Template

Client:  I tried to do XYZ and found a bug.  Your team screwed up!  I AM NOT PAYING YOU FOR BUGS.  And if you can’t tell, I am angry.

You:  We take quality very seriously. The developers, like you, want to do a great job and make you happy.  There is a balance however between having bugs and building software.

Client: You mean you are delivering shoddy work and I just have to deal with it?

You:  No, that isn’t the case.  We are building functionality into your product to make it more attractive to users and provide value to them.  We can spend more money to reduce errors.  Those efforts include building improved test features, conducting software practices like Test Driven Development, build suites of automated UI, backend testing and would most likely require us to bring another person on the team to achieve those results.   That work requires additional money, time, and management.

Client: That is crazy.  I don’t want all of that.  I just want bug free software.  You should be building software that doesn’t have any bugs.

You:  That is fine, we can do that, but it is going to cost you more money.  You control how we spend our time and what is important to you.  Using our experience, we select software libraries and techniques that will reduce bugs as much as possible.

Client:  Hmmm, well, I guess we can live with minor bugs.  What about the major ones?

You:  Agree.  We cannot have major bugs.  We will spend as little as possible to make sure that major bugs don’t happen and will start conducting small tests every sprint called smoke tests.  That should resolve most of the issues and cost very little on your part.

Client:  Ok, as long as it doesn’t cost me more money.

You:  It is a very lean option.  If we build more complexity, then we will need to invest in more testing capabilities.

Client:  If our product is flying off the shelf, then the investment will make more sense.

You:  Now you are thinking lean!